如何做好一次故障演练？

本文转载自微信公众号「随猿记」，转载本文请联系随猿记公众号。

为什么要进行故障演练?

伴随着海量请求、节假日峰值流量和与日俱增的系统复杂度一起出现的，很有可能是预料之中以及意料之外的各种故障。在很多情况下，由于事故处理预案的缺失或者预案本身的不可靠，以及开发人员故障处理经验的缺失，造成在各种报警之中自乱了阵脚，从而贻误了最佳战机。特别是一些平时线上没出现过的异常故障，一旦突然出现，往往措手不及。

系统是否足够健壮?是否有足够的能力应对故障的发生?当面临故障时会出现什么行为?我们并不希望真正线上出现故障时才去验证这些问题，这样风险太大，成本太大。所以希望在线上环境隔离真实流量的情况下，提前模拟产生各种任何可能发生的故障，来观察系统的反应，验证预期策略。

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

1. 确保系统按我们预想的方式应对故障
2. 寻找系统中未预料到的弱点
3. 寻找其他提高系统鲁棒性的方式来避免事故实际发生

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

什么是故障演练?

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

(1)演练的对象

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

(2)对象发生的具体故障

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

(3)应用的预期故障应对表现

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

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

(4)对应用表现的实际观察和判断

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

故障演练怎么做?

故障演练前

1. 检查必备基础能力

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

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

(1) 要对哪些请求流量注入故障?

• 决策原则：

选择核心业务链路的请求流量

• 推荐做法：

链路分析，标记出核心业务链路

(2) 要模拟哪些下游服务的故障?

• 决策原则：

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

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

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

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

• 推荐做法：

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

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

(3) 在哪个应用环境模拟故障?

• 决策原则：

所选环境越接近线上生产环境越好

• 推荐做法：

在线上无真实流量的机器做故障演练(关闭外部真实流量)

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

• 流量隔离
• 影子表隔离

4. 制定故障应对预案

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

• 预案制定原则：

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

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

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

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

5. 配置故障

6. 确定演练目标

• 确定所制定故障应对预案确实生效，即：启动预案后，确实能减小所针对故障的影响范围
• 确定故障发生时期业务流程按预期运转(通过业务指标、埋点监控、相关的业务链路追踪工具确定)
• 确定应用机器的负载指标在预期范围内(通过各种基础工具的告警确定)

(根据自身业务特点设置更多的检查点)

7. 培训参与的内部人员

8. 通知涉及的外部人员

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

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

推荐做法：

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

故障演练中

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

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

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

（编辑：常州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!