这几年针对理财产品主导过多次生产环境的全链路压测，各个产品的细节上会有一些不同，但主体思路大致如下：
1. 模型的搭建，比如是什么产品，有哪些接口参与，活动量多大，接口的漏斗模型，可以通过以往的活动中的接口调用量来借鉴
2. 产品及数据及压测脚本的准备，在后管配置产品，下单手机号的准备，有支付账号的手机的准备，编写好压测脚本
3. 压测脚本的入参最好打上标签，这样方便做数据清理，比如某些字段上带一些关键字，搜索起来比较方便
4. 提前在App端发公告，在某个晚上的1点到3点系统维护。然后我们在这个时间段做压测
5. 压测的关联方也要通知到位，确保压测期间他们的系统有人能够支持
6. 压测，按照接口的调用比例， 采用多台机器逐步上传压测并发数，并实时监控被压测服务性能以及压测机的性能，如果有分布式压测平台，通过不同地区但压测机进行压测，压测效果会更好
7.在压测过程中通过pingpoint，cat等监控工具，这样可以完整到串联各个接口及系统之间到调用链路，方便开发测试运维一起定位压测问题
8. 整理压测报告，列出性能瓶颈等信息
9. 清理压测数据，在T+1日对这些压测支付订单，按照压测产品的维度，在后管系统对所有支付订单做退款处理
下面是某一款产品的一个大致压测流程：
我们取得的成果：
发现来诸多性能问题，包括Redis缓存穿透问题；分页展示问题；支付接口同步和异步的混合使用；部分接口的读写分离；以及系统实在抗不下的情况下水平扩容
趟过的坑也不少：
实名制绑定的账号比较少；脏数据的清理；压测白名单控制；压测脚本设计的不规范，比如API返回的值size太小，不符合真实用户的返回结果；
另外一个问题，为什么一定要生产环境做全链路压测，测试环境全链路压测不行吗？回答如下：
1. 配置不一样，由于经费问题，测试环境的机器一般要比生产少一半，并且机器的配置也比生产要差一些，所以很难用测试环境可承受最大压测数量来来比推断出生产可承受的最大压力容量
2. 测试环境连的关联方，有许多事用挡板做掉了，所以关联方的性能对我们来讲是黑洞
测试环境的压测我们主要用来做纵向对比，比如同一个接口，在上一个版本和现在这个版本情况下，接口的响应时间错误率等有多大变化等