伴随着海量请求、节假日峰值流量和与日俱增的系统复杂度一起出现的，很有可能是预料之中以及意料之外的各种故障。

在很多情况下，由于事故处理预案的缺失或者预案本身的不可靠，以及开发人员故障处理经验的缺失，造成在各种报警之中自乱了阵脚，从而贻误了最佳战机。

特别是一些平时线上没出现过的异常故障，一旦突然出现，往往措手不及。

系统是否足够健壮？是否有足够的能力应对故障的发生？当面临故障时会出现什么行为？我们并不希望真正线上出现故障时才去验证这些问题，这样风险太大，成本太大。

所以希望在线上环境隔离真实流量的情况下，提前模拟产生各种任何可能发生的故障，来观察系统的反应，验证预期策略。

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

• 确保系统按我们预想的方式应对故障

• 寻找系统中未预料到的弱点

• 寻找其他提高系统鲁棒性的方式来避免事故实际发生

理想情况是达到如下流程化：例行化故障演练、找出系统风险点、优化业务系统、产出可行有效的故障处理预案。

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

演练的对象即演练的位置，可以针对应用本身，可以针对应用下游，也可以针对应用所在机器

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

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

这个可以在监控系统上观察应用的各项指标表现，比如异常打点，流量打点，业务曲线，机器性能等一系列可能受故障影响的地方。

我们按照流程顺序来看：

1）检查必备基础能力

• 需要应用具备在业务链路中完整传递染色标记流量的能力

• 需要应用具备模拟下游依赖服务故障的能力

• 需要应用具备请求流量录制\回放\隔离的能力

2）确定故障演练范围、环境

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

• 决策原则：选择核心业务链路的请求流量

• 推荐做法：链路分析，标记出核心业务链路

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

• 决策原则：

  此下游服务发生故障的机率大

  此下游服务发生故障时影响的业务范围广

  此下游服务发生故障的会影响核心业务

  此下游服务发生故障时能制定出可行的应对方案

• 推荐做法：

  依赖链路分析，确定业务链路中依赖了哪些下游服务

  反向依赖分析，确定下游服务故障会影响哪些业务链路，评估影响的业务范围

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

• 决策原则：所选环境越接近线上生产环境越好

• 推荐做法：在线上无真实流量的机器做故障演练（关闭外部真实流量）

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

• 流量隔离

• 影子表隔离

4）制定故障应对预案

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

• 预案制定原则：

  预案得有针对的故障或风险类型，可以是一个或多个

  得确定预案在什么情况下才能启动/解除，有什么前置要求条件

  预案得确实有效，即：启动预案后，确实能减小所针对故障的影响范围

  确定预案开启后会造成的额外影响，不能引发新的故障

5）配置故障

6）确定演练目标

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

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

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

7）培训参与的内部人员

8）通知涉及的外部人员

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

• 故障演练的发起应用

• 故障演练起止时间

• 故障演练应用集群环境

• 对每个相关应用的影响预估。比如：对下游依赖服务的调用峰值 QPS、上游服务收到的异常请求比率

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

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

2）开启应用的故障模拟开关，观察故障影响。

注意：为确保不影响真实流量，仅对染色流量发生故障。

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

• 观察故障影响有无按预期消除或减小影响范围

• 观察各项业务指标

• 观察机器负载指标

• 验证业务流程按预期运转（比如：取消展示XX模块、不再请求YY接口）

1）现场清理

• 流量关闭、流量隔离任务关闭

• 故障模拟开关关闭、预案关闭

• 清理演练期间写入的数据、缓存、日志等（可选）

• 演练期间操作改动的业务配置开关复位

• 重启应用

• 通知相关人员演练结束

2）演练报告与总结

• 是否达到预期目标

  预案有无生效

  业务流程是否按预期运转

  机器负载是否正常

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

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

• 整理后续改进点

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

<常态化，制定演练周期>

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

• 演练常态化

• 故障标类化

• 演练智能化

用常态化的演练驱动稳定性进步，丰富更多的故障场景，定义好最小故障场景和处理手段；基于架构和业务分析的智能化演练，沉淀行业故障演练解决方案。

<"todo">