全链路压测是一个比较牛逼的活儿，它可以直观的反应你的平台整条链路在设定的压力下哪个环节是瓶颈。但是它并不是一个人就能完成的事儿，整个全链路压测的过程是“开发+DBA+测试+运维+客服”等等工种集体努力去搞定的。这篇文章主要讲的是全链路压测前应该做哪些准备。而我们的视角就是大促负责压测的PM出发的。
这篇文章的前提就是你要大概明白“全链路压测”是一个怎么回事，用简单的话说，就是DBA或者其他模型人员去做效仿历年大促的真实数据做了一个假数据，然后把这些脱了敏的假数据一股脑再发到平台里，从页面到购物车再到下单再到分单和发货，从头模拟完整的一个大促过程。
既然如此就可知，全链路压测前的重点就是“压测影子数据”的准备。一般来说，大促KO（kick-off）会上会有主PM（主负责人)会在PPT里宣布本次大促重要事项，比如大促前会有几次全链路压测，封网几时开始几时结束，预案何时录入完毕等等核心问题，这里面还有比较重要的点，那就是“交易量级”，比如是20：20：10，这串数字的意思就是主平台订单量：下单成功量：付款成功量，单位是万/秒。
KO会上，主PM还会展示本次大促的时间轴，那么压测的PM就要依据这个总时间轴做一个自己的压测时间轴，如下：
有了这个时间轴，压测PM就要按部就班的完成各个时间的工作：首先在拿到量级后，压测PM就要去联系各位产品经理，咨询他们的业务是否要参与本次大促，比如“汽车配件是否要参与？水果生鲜是否要参与？国际商品是否要参与？”等等，一般来说，这个事情要贴合实际，比如现在疫情影响，很多线下的交易受到了影响，那么可能线下的服务就不会参与到本次大促里。
现在直播带货也成了一种新的电商玩法，那么如果有这个需求，还要评估一下直播间的量级—名气网红的直播间能同时支持多少在线量？这种业务也是在压测范围里的。
产品经理此时会回压测PM一个答复，“我所负责的业务会/不会参加本次大促，大概的峰值QPS是XXX”，此时压测PM会根据产品经理的峰值QPS以及交易量级，自己从历史的数据订单里模仿一个数据模型，一般来说这个数据模型的背后是一整套相当复杂的算法，每个公司都会有自己的绝密算法和对应的格式，这个加工出来模型即要符合之前例子里“20-20-10”的大方向，也要满足各业务经理的要求。比如这个模型可能是“汽车产品3w+水果生鲜2w+服装10w+书籍2w+电子产品3w”这样的一个粗略的样子，而且这个粗略样子里面也要体现出爆款商品和热款商品，当然还会涉及到具体策略+服务间依赖+业务配比等等等等具体的因素。这样最后的模型才是一个近似真实客户下单的状态。
有了这个模型当然还不够，压测的PM还需要再去麻烦产品经理，问一下本次大促有没有什么新的玩法以及特殊的专业保障。如果有了新玩法，那么开发人员就要根据这些需求去修改模块功能，如果有了专业保障那么开发人员就要跟负责稳定性的同学一起研究一下保障方案。
产品经理这边的资料就先告于段落，剩下的时间压测PM就要跟开发同学们泡在一起了。主要就是从开发同学的手上收集“压测目标”和“压测风险”，最好再拿到完整的业务链路图，自己摸一遍完整的链路，然后登到堡垒机上去看一下当前的负载情况、DB压力情况等等，在压测前先判断一下哪些位置可能会有瓶颈。这样梳理出一套完整的业务链路是很必要的，举一个简单的例子：
但是要注意，在梳理的时候要分清哪些模块是核心业务，哪些是高频业务，哪些是边缘业务。因为在平台应急的时候，核心业务不能丢，但是高频的业务是可以适当做降级的。
压测PM倒数第二步就要完成压测过程的具体安排，先跟运营同事确认一个月黑风高的时刻，在那个时刻客户基本都不下单了。然后规定几点几分开始正式冲击，冲击多久；几点几分开始摸高，摸高多久；几点几分开始破坏性演练等等等，这个安排需要传达到各开发手里，让他们对日程有一个了解。
到了压测那一天，压测PM首先要先跟安全部门和客服同学报备今晚会有全链路压测，可能线上会有一些“疑似故障”，不要大惊小怪。报备完毕后，压测PM就要通知开发做好压测的准备，比如检查“监控权限、各系统水位、操作权限”等等，真实压测开始，压测PM开闸放流，开发们就要紧盯监控大屏，通过各云厂家的api、Zabbix、ELK、zipkin、skywalking等等工具获取到模块的各个状态。而压测PM就按照自己之前的压测日程表在压测平台上进行操作，此时除非测试员工反馈线上平台核心业务崩溃了，否则就不要理底下开发的叫唤，压塌了模块没事，开发会采取应急措施—降级 or 限流。压测PM则一定要按预期坚持到结束，本来目标就是要从压测中发现瓶颈和问题，而开发需要做的就是应急操作和记录各种问题，比如“缓存被打穿了；模块日志刷太多了，磁盘爆了；降级脚本失灵了”。在整个压测结束后，压测PM就要先问开发本次的压测模型是否oK，各接口的QPS是否达到预期目标，如果开发有疑问就要针对性的调整模型。此后压测PM还要组织做压测的review，大家一起把压测中发现的问题整理一下，拿出后续的action并解决之。
大促一般都会安排至少2轮压测，这样可以在第二轮压测时候验证第一轮的action是否生效，同时也让开发去可以尝试一些新的压测场景。如果最后一轮压测仍有开发反馈某些链路有问题，那么可以向公司申请单链路压测，重点去压测某个场景和对应的链路。
本文中并没有太多技术性的东西，更多的是流程上的东西。毕竟压测这套系统的搭建可不是一篇文章能说的明白，如果要看技术的话，个人推荐有赞分享的文章：https://mp.weixin.qq.com/s/0a-Sd_fCkE2mDFzNpKxf7A
