如何做好一次故障演练？

1 为什么要进行故障演练？

互联网行业在发展过程中，诞生很多出名的业务产品，如支付宝、淘宝、微信等几乎全民皆用的产品。但伴随着用户不断增长，业务产品技术层面出现了众多挑战，如海量请求、节假日峰值流量和与日俱增的系统复杂度，导致了很多预料之中以及意料之外的各种故障。在很多场景下，由于缺少故障处理预案或预案本身可靠性问题，及技术人员缺乏故障处理经验，造成故障发生时，技术人员在报警轰炸中自乱阵脚，延误故障的最佳处理时机。特别是从未出现过的异常故障，一旦出现，会直接对技术人员心里造成恐慌，措手不及，不知所措。

那么业务系统架构是否足够健壮？是否有足够的能力去应对故障的发生？故障来临时会出现什么情况？如何去应对？为什么没有事前预料这些异常情况？有什么方法能够预知或提前检测这些异常情况呢？这是技术团队需要在平日的工作中需要前置考虑的问题，而不是当故障来临时才去验证这些问题，因为风险太大，成本太大。综上所述，提前 模拟产生各种任何可能发生的故障，来观察系统的反应，验证预期策略是尤为必要的。那么故障演练的目标是什么呢？

总结一下，故障演练主要有以下几个目标：

• 确保系统按我们预想的方式应对故障
• 寻找系统中未预料到的弱点
• 寻找其他提高系统稳定性的方式来避免事故实际发生
• 验证监控报警的覆盖率与及时性、准确性。

理想的故障演练结果是形成流程化： 

• 例行化故障演练
• 监控报警覆盖并及时触发报警
• 根据故障信息找出系统风险点
• 优化业务系统
• 产出可行有效的故障处理预案

2 什么是故障演练？

了解了为什么需要进行故障演练，接下来了解一下什么是故障演练？

故障演练是应用系统高可用能力测评的核心，也是验证系统稳定性的核心能力，一次完整的故障演练是由演练的对象、对象发生的具体故障、应用的预期故障应对表现、对应用表现的实际观察和判断几部分组成。

2.1 演练对象

演练对象即演练的靶场，即可以针对应用本身，也可以针对应用下游，还可以针对应用系统所在机器。

2.2 演练对象发生的具体故障

常见的故障类型有以下一些：

故障类型	举例
依赖RPC服务故障	超时/不可用，连接池无可用连接
中间件故障	Kafka 超时/不可用，Redis超时/不可用
基础设施故障	数据库超时/不可用，DNS 超时/不可用
机器故障	CPU 满载，网卡流量满载，网络中断，机器宕机，机房断电，磁盘空间满载
异常流量	入口流量激增，流量掉零

2.3 故障时应用系统的应对表现

故障时应用系统的应对表现也就是预案，针对每种要演练的故障情况，制定故障应对预案，预案模板参考：

链路/场景	故障	可否演练	影响	关联报警	应对预案	操作 SOP	实施预案后的影响	预案解除条件	预案解除 SOP	预案实施失败的应对方案

2.4 对应用表现的实际观察和判断

可以在监控系统上观察应用的各项指标表现，比如异常打点，流量打点，业务曲线，机器性能等一系列可能受故障影响的地方来确定业务系统当前状态，也可通过监控报警来确定业务系统是否有异常。

3 故障演练怎么做？

3.1 故障演练前

3.1.1 检查必备基础能力

• 需要应用具备在业务链路中完整传递请求链路标记流量的能力
• 需要应用具备模拟下游依赖服务故障的能力
• 需要应用具备请求流量录制\回放\隔离的能力

3.1.2 确定故障演练范围、环境

1）要对哪些请求流量注入故障？

• 决策原则： 选择核心业务链路的请求流量
• 推荐做法： 链路分析，标记出核心业务链路

2）要模拟哪些下游服务的故障？

• 决策原则： 此下游服务发生故障的机率大 此下游服务发生故障时影响的业务范围广 此下游服务发生故障的会影响核心业务 此下游服务发生故障时能制定出可行的应对方案
• 推荐做法： 依赖链路分析，确定业务链路中依赖了哪些下游服务 反向依赖分析，确定下游服务故障会影响哪些业务链路，评估影响的业务范围

3）在哪个应用环境模拟故障？

• 决策原则： 所选环境越接近线上生产环境越好，也可在业务低峰期在生产环境进行(慎重选择)
• 推荐做法： 在线上无真实流量的机器做故障演练（关闭外部真实流量）

4）回放流量隔离和影子表隔离

• 流量隔离
• 影子表隔离

5）制定故障应对预案

针对每种要演练的故障情况，制定故障应对预案

• 预案制定原则： 预案得有针对的故障或风险类型，可以是一个或多个 得确定预案在什么情况下才能启动/解除，有什么前置要求条件 预案得确实有效，即：启动预案后，确实能减小所针对故障的影响范围 确定预案开启后会造成的额外影响，不能引发新的故障

6）配置故障

7）确定演练目标

• 确定所制定故障应对预案确实生效，即：启动预案后，确实能减小所针对故障的影响范围

• 确定故障发生时期业务流程按预期运转（通过业务指标、埋点监控、相关的业务链路追踪工具确定）

• 确定应用机器的负载指标在预期范围内（通过各种基础工具的告警确定） （根据自身业务特点设置更多的检查点）

8）培训参与的内部人员

9）通知涉及的外部人员

根据评估出的影响范围通知相关业务应用 RD、运维 RD、基础组件 RD。通知内容要素：

• 故障演练的发起应用
• 故障演练起止时间
• 故障演练应用集群环境
• 对每个相关应用的影响预估。比如：对下游依赖服务的调用峰值 QPS、上游服务收到的异常请求比率

推荐做法： 将所有相关人员拉入一个工作群，群名「XXX应用故障演练」，在群里发送故障演练通知、组织协同

3.2 故障演练中

1）将录制的线上流量逐步加压回放到故障演练的发起应用中的无真实流量机器

2）开启应用的故障模拟开关，观察故障影响 注意：为确保不影响真实流量，仅对染色流量发生故障

3）启动应用的故障应对预案

• 观察故障影响有无按预期消除或减小影响范围
• 观察各项业务指标
• 观察机器负载指标
• 验证业务流程按预期运转（比如：取消展示XX模块、不再请求YY接口）

3.3 故障演练后

3.3.1 现场清理

• 流量关闭、流量隔离任务关闭
• 故障模拟开关关闭、预案关闭
• 清理演练期间写入的数据、缓存、日志等（可选）
• 演练期间操作改动的业务配置开关复位
• 重启应用
• 通知相关人员演练结束

3.3.2 演练报告与总结

• 是否达到预期目标 预案有无生效 业务流程是否按预期运转 机器负载是否正常

• 是否有预期之外的现象发生

• 关键指标（业务指标、机器负载指标）收集整理

• 整理后续改进点

3.4 故障演练什么时候做？

3.4.1 初期

需要把故障以场景化的方式沉淀，以可控成本在线上模拟故障，让系统和开发人员平时有更多实战机会，加速系统、工具、流程、人员的进步。

3.4.2 中期

进行红蓝对抗，一方攻，一方防

3.4.3 稳定期

常态化，不定期演练，采取突袭方式进行。

3.5 故障演练后续规划

故障演练的后续工作主要会关注在以下方向：

• 演练常态化
• 故障标类化
• 演练智能化

用常态化的演练驱动稳定性进步，丰富更多的故障场景，定义好最小故障场景和处理手段；

基于架构和业务分析的智能化演练，沉淀行业故障演练解决方案。