全链路压测(11)：聊聊稳定性预案
前言
全链路压测出现的初衷是阿里为了解决双十一线上系统在峰值流量冲击下的稳定性和可用性问题，在后续落地及不断的演进过程中，出现了很多技术领域的最佳实践。
前面的文章也为大家介绍了很多全链路压测从项目启动到准备阶段的很多细节。这篇文章，我想谈谈在全链路压测落地演进过程中，一个很重要的实践——稳定性预案。
什么是预案？
通过字面意思来看，预案通俗易懂，即针对预期可能出现的问题所设计的解决方案。
放在全链路压测领域，其实稳定性预案并非全链路压测体系中的一部分，而是可以看做一个独立的细小领域，但又和全链路压测有重要的联动关系。
因为全链路压测大多在生产环境开展，虽然可以通过流量识别和数据隔离来保证不对线上业务和数据造成影响，但毕竟是在生产环境执行，有些问题难以避免。
预案有哪些类型？
从我近几年的实践经验来说，预案大概分入如下几种类型：
日常预案
线上服务发布失败的回滚方案；
线上服务负载过高的监控告警通知方案；
用户无感知的灰度发布、无损发布等方案；
限流、降级、熔断等服务治理领域的技术方案；
线上服务防止黑客攻击的各种高防和安全应对方案；
大促活动预案
一般大促活动都是指类似618、双11等营销活动，视业务情况而定。常见的有：
日志归档；
消息降级（小红点）；
评论关闭（商品评论、社区动态评论）；
本地缓存（降级和熔断后的兜底手段）；
定时job错峰（job任务错开流量高峰）；
依赖解耦（核心服务的强依赖解耦，避免雪崩）；
服务分组（核心服务、核心MQ按照权重优先级做分组隔离）；
客户端限流浮层（针对服务限流后用户频繁点击导致的流量放大场景）；
业务稳定性预案
商品推荐临时关闭；
线上对账和防资损校验；
调整商品退货退款到账时间；
PS：预案体系成熟后，可通过平台开关的方式进行配置，收拢权限，避免人为操作导致的问题。
预案的作用是什么？
从技术角度来讲，任何一个细微问题都可能导致生产出现重大故障，因此针对性的设计对应的预案就显得至关重要。
从业务角度来讲，无论技术做任何的改动和优化，最终的目的都是为了业务目标的达成。而系统的稳定性，无论从用户体验还是业务目标达成的角度来看，都是不可忽视的一环。
因此预案的作用就呼之欲出：从技术的角度出发，为业务目标的达成提供多维度的稳定性保障。
如何制定预案？
上面列举了很多常见的稳定性预案，在我看来制定预案是一个经验+评估的问题。常见的制定预案的方式如下：
从日常的线上问题着手，汇总问题和解决方案，复盘得到TODO项和落地验证；
从系统设计和业务需求分析角度开始，前置性的进行评估分析，设定对应的预案；
从用户体验和用户行为分析角度出发，优化用户操作过程和交互逻辑，避免类似问题；
最后的经验之谈
所有预案都需要经过评估分析；
没有验证的预案都是潜在的风险；
预案都是有风险和成本的，避免过度设计；
预案的最终目标是保障业务目标达成，而非秀技术；
如果喜欢我文章，点赞、关注、在看三连走起。
往期技术文章推荐