全链路压测（十二）：生产压测必不可少的环节

前言

全链路压测系列到这里，已经是第十二篇文章了，整个系列大概有 14 篇的样子，预计这个月会更新完毕。

前面的文章，我用了很多的篇幅介绍了在事前调研和准备阶段要做的事情，为什么要花这么多篇幅介绍前期的准备工作呢？因为全链路压测严格来讲，并不是一个单纯的测试手段，而是一整套团队协作和稳定性保障的技术体系。

当然，既然这个系列文章叫做叫做生产全链路压测，那肯定少不了在线上生产环境的压测实践。

这篇文章，为大家介绍下在生产环境都是如何开展压测的，以及压测过程要注意哪些事项。

在生产环境开展全链路压测，相对于测试环境来说风险和成本都是比较大的。因此需要一套严格的流程管控和响应机制，以及高效的团队协同体系。

当然，由于成本和风险问题，全链路压测本身只适合部分企业，而非一个放之全行业通用的技术银弹。即使在少部分落地了生产全链路压测的企业来说，常态化的全链路压测也是很难的。

下面是一个在电商企业双 11 大促时候的生产全链路压测实施过程，仅做示例参考。

执行压测和问题处理

生产压测其实和我们日常的压测没有太多区别，也是需要经过多轮的压测实施和问题分析定位优化才能完成。在生产执行压测阶段，一般会根据业务活动情况倒序排期，制定压测轮次和每个轮次的主要目标及 TODO 项。下面是我之前某次大促的压测计划排期：

瓶颈定位和优化验证

瓶颈定位和优化验证是性能优化和稳定性保障之中很重要的环节。

由于生产压测大多是在流量低峰的夜间进行，压测实施时间有限，一般比较复杂的性能问题都是在事后线下环境进行优化验证。而且涉及到比较复杂的业务场景和系统调用关系时，也很难快速的找到性能瓶颈。

遇到这个问题时，常用的临时解决办法是将影响性能的链路进行 mock 处理，待线下环境优化验证后，再次合并到链路中进行压测验证。

生产压测会暴露很多问题，下面列举一些常见问题：

1. 数据准备不足和数据预热问题；

2. 各团队资源投入度和信息同步问题；

3. 基础的技术平台支撑问题（快速发布、紧急扩容、监控告警）；

4. 前期的技术准备和梳理不足（如链路依赖及限流降级熔断措施）；

5. 线上操作流程和权限管控问题（临时发布、业务变更及 push 等）；

每日复盘和事项跟进

由于生产压测的时间窗口有限，一般都会将压测过程遇到的问题全部进行记录，便于事后组织复盘和跟进，在记录相关信息时，重点需要关注如下几点：

1. 问题暴露时间（便于事后复盘和排查问题时，查看对应时间段的监控和日志）；

2. 问题归属团队（由于生产压测涉及的业务和团队较多，需要明确拆分工作，各自跟进）；

3. 问题归属人员（确定问题主要归属人员，主要是便于能投入全部精力来跟进解决问题）；

4. 问题影响范围（根据影响范围来评估问题的优先级和严重性，并做好信息同步，避免问题扩大）；

5. 问题 deadline（需要明确问题的最后解决时间，避免某个环节的 block 影响全局的压测目标达成）；

下面是之前我在某次大促复盘时整理的问题以及 TODOList，仅供参考。

问题风险

TODOList

PS：复盘的目的是更明确问题的影响面和快速解决，需要聚焦问题，而不是甩锅指责！

发布上线和封版值班

在类似双 11 大促这种大型业务营销活动的稳定性保障时，需要注意如下几个方面：

1. 原则上除了和大促相关的变更，其他需求变更或者配置变更都需要顺延；

2. 活动开始前和业务产品明确封版时间，避免版本发布导致链路依赖的变化；

3. 在最终的性能优化版本发布后，线上的值班和 oncall 需要有专门的排班机制；

4. 紧急发布和临时变更需要有审批流程和实时 oncall 及回滚机制，避免发布导致问题扩大；

预案执行和监控响应

在上一篇文章中，我们提到了稳定性预案的作用，到这个阶段，就需要针对线上的部分预案进行执行和 oncall 响应。类似双 11 这种大型的业务营销活动，预案也会分前置预案和活动预案以及紧急预案。

预案执行

在执行前置预案时，我的实践经验主要有如下三点：

1. 制定具体的预案执行时间和执行人以及验证人；

2. 执行预案和线上验证及观察阶段，相关人员最好集中在一起；

3. 前置预案需要分批执行，避免同时执行多个预案（假设出现问题，也能快速定位问题原因）；

监控响应

监控响应更多的是一种工作流机制，即针对不同信息，由不同的人在预定的时间范围内响应处理。监控方面，除了我们常见的基础资源监控（CPU/内存/网络/磁盘）、应用监控（QPS/JVM/threadgroup）、链路追踪监控（trace）之外，还有业务监控大盘、核心链路监控大盘等。

因为技术方面的监控，除了及时的告警通知之外，监控的及时性和准确性以及噪音，有时候会影响我们判断。这个时候业务监控大盘的作用就体现了出来。

业务监控大盘的目的在于：无论技术侧是否发现了问题，只要业务指标的变化数据存在异常，就需要及时介入观察。