前言
前面的几篇文章从生产全链路压测的定义，内部立项和技术调研，聊到了测试验证以及全链路压测的对企业业务和技术团队的价值，算是整体上的构建一个认知的概念。
从这篇文章开始，会进入具体的落地实践环节。这篇文章中，我会介绍生产全链路压测的落地实施全流程，即每个环节要做什么事情。
四大阶段
如果将生产全链路压测作为一个阶段性的技术项目来看，全链路压测从开始到项目结束，需要经过四个阶段。
整体的实施流程图如下所示：
接下来我来为大家解密，生产全链路压测落地实施，在不同的阶段都会做哪些事情。
筹备阶段
确定业务范围
一般来说线上实施线上全链路压测之前，要明确本次压测需要验证的业务范围。
核心业务定义
出问题会影响其他业务链路；
流量较高且出现问题会影响整体业务目标的达成；
核心项目定义
前面提到了生产全链路压测是个复杂的技术项目，那么如何定义这种技术项目呢？
大型业务活动有关的项目，如电商双11大促；
影响业务目标达成的项目，如电商每年的各种购物节；
风险相对可控的核心项目，一般核心业务稳定性要求更高；
注意事项
按照5W+1H原则进行梳理，交付的checklist一定要准时明确；
尽量不要在大型业务活动前进行大量变更，如有需要明确变更的范围和风险；
明确业务目标
确认业务范围后，接下来就是明确业务的目标。常见的业务目标，包含哪些信息呢？以电商的大促举例：
单日GMV/DAU、客单价；
支付订单量、订单履约率；
用户复购率、推荐准确率；
转化技术指标
明确业务目标后，接下来就是要将其转化为技术指标，这是个很吃技术设施建设以及经验的活儿。下面是一个例子：
以上述的GMV和客单价为例，假设：
客单价为500，单日GMV为10亿，那么支付订单量为10亿/500=200W；
假设日常支付订单量为50W，支付转化率为40%，订单支付QPS峰值为200。预估大促时的支付转化率为60%，则可得：大促峰值订单支付QPS为（200/40%）*60%*（200W/50W）=1200QPS。这个1200QPS是个保底数值，一般为了留有一定冗余空间，会上浮30%，即订单支付的QPS预估为1500；
电商的导购浏览下单支付转化链路一般为：首页→商品详情→创建订单→订单支付→支付成功，这个过程是类似漏斗的一个转化逻辑。假设首页→商品详情转化率为40%，商品详情→创建订单转化率为40%，创建订单→订单支付转化率为40%，那么可得：创建订单QPS为1500/40%=3750，商品详情QPS为3750/40%=9375，首页QPS为9375/40%=23437；
所以，你学废了么？这里只是举个例子，大家在实践中可以按照具体的情况进行转化计算，案例仅供参考。
任务拆解&组建团队
这里是2部分的内容：任务拆解和组建团队。
任务拆解
任务拆解即将下述备战阶段的各个一级目标，拆解为多个更详细的二级甚至三级任务，并且对应到人和时间。
组建团队
一般来说，这种复杂的大型技术项目，建议组建一个临时的虚拟技术保障团队，涉及到的每个团队指定对应的owner来负责，做到事和人有一一对照的关系，这样才能更好的保障业务目标达成。
大促保障kickoff
kickoff即举行一个启动会，一般会由这个项目的总负责人对项目的关键目标和指标进行介绍，虚拟技术保障团队的构成，以及拆解到每个owner身上的任务，做到信息同步，便于后续的任务开展。
kickoff有四大关键要素，分别是：
组建技术团队
项目管理团队：一般是由项目负责人和PMO团队构成；
任务执行团队：各个任务的owner以及各团队的核心成员；
后勤保障团队：IT、行政都部门负责网络、饮料零食、加班打车等后勤事宜；
明确关键目标
大促业务目标
大促技术指标
关键里程碑节点
合理拆分指标
备战阶段目标
作战阶段目标
复盘阶段目标
定义关键机制
信息同步机制：复杂的技术项目，信息同步的效率和一致性很重要；
团队协作机制：拆解出来的任务，很多需要多团队协同配合，因此需要制定合理的合作机制；
紧急事件处理机制：如线上紧急变更、紧急发布、目标变更等都需要有对应的应对策略，否则容易手忙脚乱；
备战阶段
核心链路梳理
核心链路梳理主要是做下面几件事：
根据业务范围确认应用范围；
根据应用范围和访问量确认核心链路；
根据核心链路和监控确认流量转化的漏斗模型；
根据核心链路梳理不同应用和接口之间的强弱依赖；
根据强弱依赖制定大促时候的各种技术预案和应急处理手册；
线上容量评估
容量评估需要考虑如下几点因素：
当前线上的流量和资源的使用率；
按照预估的技术指标提前预购准备相应的资源；
基础准备工作
基础准备工作，无非就是下面几件事：
环境准备：包括生产环境的改造、影子库表等准备；
数据准备：包含基础铺底数据、测试数据、预热数据；
脚本准备：包括压测脚本、任务更新脚本、一些运维的ansible脚本；
技术业务优化
常见的优化项如下：
大促作战的监控大屏，包含技术和业务监控；
服务保护措施如限流、降级、熔断、灾备等；
资损防护处理，如异常流量、异常支付、舆情风控等；
技术方案评审
这里的方案主要包含2类：
压测方案：即本次大促或者技术项目的整体压测方案；
大促预案：包含前置的主动预案、业务活动的紧急预案以及容灾恢复预案。其主要构成分别是：
前置主动预案：限流、降级、熔断、隔离；
活动紧急预案：业务（活动入口关闭/防资损）、技术（服务宕机/CPU使用率过高/磁盘空间不足）；
容灾恢复预案：紧急扩容、机房断电处理、断网备份方案；
封版&线上预热
这一阶段，主要进行下述的几件事：
大促封版：即如非必要，禁止线上发布变更，必须发布走审批流程，确保活动期间的线上稳定性；
流控检查：相关同学针对各个应用核心链路和接口及外部交互等流量出入口进行查验，避免出现异常情况；
权限检查：针对服务保护及其他相关稳定性系统的权限，授权给相关人员，便于活动期间及时排查解决问题；
系统巡检：针对系统运行状态、资源使用率等情况进行每日定时检查，避免异常因素导致的整体稳定性受损；
线上预热：这是线上压测前的最后一环，对线上需要扩容的机器、所需的数据进行提前预热，可通过小流量试跑来验证线上预热准备是否充足；
实施线上压测
线上压测的过程，实际上和日常压测没太多区别，下面这张图足以说明一切：
预案演练验证
预案演练验证环节，即针对之前备战阶段梳理出的各种预案，进行一一验证。主要验证如下两点：
预案是否按照预期生效；
预案生效后对正常的业务是否造成影响；
作战阶段
执行前置预案
如果有经历过电商双11大促值班的同学，或许应该能明白这点的作用。
一般前置预案包含定时JOB时间调整、部分边缘业务降级（如商品评论、小红点）、支付入口调整、订金结算等。
在线值班保障
在线值班保障，主要是应对在峰值流量冲击时候，各个应用和对应人员能及时应对突发的各种问题。如下图所示：
如果一切正常，那就一切正常。
如果出现异常情况，就按照预定的各种预案进行快速处理，核心目标是线上业务止血并快速恢复。
这里就体现了作战手册和大促保障kickoff阶段的三大关键机制的重要性了，我们再次回顾一下，他们分别是：
信息同步机制：复杂的技术项目，信息同步的效率和一致性很重要；
团队协作机制：拆解出来的任务，很多需要多团队协同配合，因此需要制定合理的合作机制；
紧急事件处理机制：如线上紧急变更、紧急发布、目标变更等都需要有对应的应对策略，否则容易手忙脚乱；
复盘阶段
复盘是个好习惯，知道哪里做得好，哪里做的不好并找到原因加以改正，持续优化我们的系统。一般复盘主要做下面四件事：
业务复盘
订单增长率：客户支付订单同步环比的增长率，推荐品类购买的转化率；
支付履约率：用户从首页导购到商品详情以及订单支付的履约率，整体的转化漏斗；
DAU转化率：日活和业务增长之间的转化比率，评估红包&优惠券及业务活动的效果以及ROI；
技术复盘
场景覆盖率：本次大促的技术准备对业务的覆盖率，建议结合QPS等指标一起分析；
监控覆盖率：综合监控指标的时延、准确率、告警提示、异常指标分析等体系的不足进行分析；
预案覆盖率：针对主动、紧急、容灾预案的执行百分比以及效果进行评估。主动预案执行率和目标达成率越高，紧急和容灾预案执行率越低，证明预案更完善；
容量评估准确率：根据压测结果和资源成本以及实际的使用量，评估容量的精确性不足之处，为容量规划和成本管控提供决策参考；
压测模型准确率：根据实际访问量和压测的流量模型进行对比分析，不断优化流量模型的精准度；
沟通协作问题复盘：评估整个项目实施期间，团队在沟通、信息同步、跨团队协作方面的不足之处；
改进落地
通过复盘，找到不足之处，然后针对性的落地改进措施，这是一个case by case的过程。
好的case应该进行提炼，不断优化，甚至加强宣导和奖励。做的不好的case也要落地改进TODO项并及时跟进验证。
SOP宣讲
所谓SOP，是Standard Operating Procedure三个单词中首字母的大写，即标准作业程序，指将某一事件的标准操作步骤和要求以统一的格式描述出来，用于指导和规范日常的工作。
而全链路压测的SOP，就是将这个技术项目中适合本企业或者团队的流程和过程通过标准化的定义而成为一种规范。
SOP的主要目的在于：记录过程、沉淀经验、赋能团队、提高效率。
文末回顾
本篇文章主要介绍了生产全链路压测落地实施的全流程，当然由于细节太多，很多内容无法描述的很清楚。
部分事项为什么要这么做的原因，我会在后续的系列文章中一一为大家拆解和讲解。
最后，推荐一个很好的Github项目：大型营销活动技术保障作战手册-数列科技出品。
我曾参与这个作战手册的制作，这个手册很好的为这种大型的营销活动和技术项目提供了一个全新的丰富视角，很值得技术同学去了解学习。
精彩链接
发表评论