全链路压测(12)：生产压测必不可少的环节
前言
全链路压测系列到这里，已经是第十二篇文章了，整个系列大概有14篇的样子，预计这个月会更新完毕。
前面的文章，我用了很多的篇幅介绍了在事前调研和准备阶段要做的事情，为什么要花这么多篇幅介绍前期的准备工作呢？
因为全链路压测严格来讲，并不是一个单纯的测试手段，而是一整套团队协作和稳定性保障的技术体系。
当然，既然这个系列文章叫做叫做生产全链路压测，那肯定少不了在线上生产环境的压测实践。
这篇文章，为大家介绍下在生产环境都是如何开展压测的，以及压测过程要注意哪些事项。
在生产环境开展全链路压测，相对于测试环境来说风险和成本都是比较大的。因此需要一套严格的流程管控和响应机制，以及高效的团队协同体系。
当然，由于成本和风险问题，全链路压测本身只适合部分企业，而非一个放之全行业通用的技术银弹。即使在少部分落地了生产全链路压测的企业来说，常态化的全链路压测也是很难的。
下面是一个在电商企业双11大促时候的生产全链路压测实施过程，仅做示例参考。
执行压测和问题处理
生产压测其实和我们日常的压测没有太多区别，也是需要经过多轮的压测实施和问题分析定位优化才能完成。
在生产执行压测阶段，一般会根据业务活动情况倒序排期，制定压测轮次和每个轮次的主要目标及TODO项。
下面是我之前某次大促的压测计划排期：
瓶颈定位和优化验证
瓶颈定位和优化验证是性能优化和稳定性保障之中很重要的环节。
由于生产压测大多是在流量低峰的夜间进行，压测实施时间有限，一般比较复杂的性能问题都是在事后线下环境进行优化验证。
而且涉及到比较复杂的业务场景和系统调用关系时，也很难快速的找到性能瓶颈。
遇到这个问题时，常用的临时解决办法是将影响性能的链路进行mock处理，待线下环境优化验证后，再次合并到链路中进行压测验证。
生产压测会暴露很多问题，下面列举一些常见问题：
- 数据准备不足和数据预热问题；
- 各团队资源投入度和信息同步问题；
- 基础的技术平台支撑问题（快速发布、紧急扩容、监控告警）；
- 前期的技术准备和梳理不足（如链路依赖及限流降级熔断措施）；
- 线上操作流程和权限管控问题（临时发布、业务变更及push等）；
每日复盘和事项跟进
由于生产压测的时间窗口有限，一般都会将压测过程遇到的问题全部进行记录，便于事后组织复盘和跟进，在记录相关信息时，重点需要关注如下几点：
- 问题暴露时间（便于事后复盘和排查问题时，查看对应时间段的监控和日志）；
- 问题归属团队（由于生产压测涉及的业务和团队较多，需要明确拆分工作，各自跟进）；
- 问题归属人员（确定问题主要归属人员，主要是便于能投入全部精力来跟进解决问题）；
- 问题影响范围（根据影响范围来评估问题的优先级和严重性，并做好信息同步，避免问题扩大）；
- 问题deadline（需要明确问题的最后解决时间，避免某个环节的block影响全局的压测目标达成）；
下面是之前我在某次大促复盘时整理的问题以及TODOList，仅供参考。
问题风险
TODOList
PS：复盘的目的是更明确问题的影响面和快速解决，需要聚焦问题，而不是甩锅指责！
发布上线和封版值班
在类似双11大促这种大型业务营销活动的稳定性保障时，需要注意如下几个方面：
- 原则上除了和大促相关的变更，其他需求变更或者配置变更都需要顺延；
- 活动开始前和业务产品明确封版时间，避免版本发布导致链路依赖的变化；
- 在最终的性能优化版本发布后，线上的值班和oncall需要有专门的排班机制；
- 紧急发布和临时变更需要有审批流程和实时oncall及回滚机制，避免发布导致问题扩大；
预案执行和监控响应
在上一篇文章中，我们提到了稳定性预案的作用，到这个阶段，就需要针对线上的部分预案进行执行和oncall响应。
一般来讲，类似双11这种大型的业务营销活动，预案也会分前置预案和活动预案以及紧急预案。
预案执行
在执行前置预案时，我的实践经验主要有如下三点：
- 制定具体的预案执行时间和执行人以及验证人；
- 执行预案和线上验证及观察阶段，相关人员最好集中在一起；
- 前置预案需要分批执行，避免同时执行多个预案（假设出现问题，也能快速定位问题原因）；
监控响应
监控响应实际上更多的是一种工作流机制，即针对不同信息，由不同的人在预定的时间范围内响应处理。
监控方面，除了我们常见的基础资源监控（CPU/内存/网络/磁盘）、应用监控（QPS/JVM/threadgroup）、链路追踪监控（trace）之外，还有业务监控大盘、核心链路监控大盘等。
因为技术方面的监控，除了及时的告警通知之外，监控的及时性和准确性以及噪音，有时候会影响我们判断。这个时候业务监控大盘的作用就体现了出来。
业务监控大盘的目的在于：无论技术侧是否发现了问题，只要业务指标的变化数据存在异常，就需要及时介入观察。
