伴随着海量请求、节假日峰值流量和与日俱增的系统复杂度一起出现的，很有可能是预料之中以及意料之外的各种故障。
在很多情况下，由于事故处理预案的缺失或者预案本身的不可靠，以及开发人员故障处理经验的缺失，造成在各种报警之中自乱了阵脚，从而贻误了最佳战机。
特别是一些平时线上没出现过的异常故障，一旦突然出现，往往措手不及。
系统是否足够健壮？是否有足够的能力应对故障的发生？当面临故障时会出现什么行为？我们并不希望真正线上出现故障时才去验证这些问题，这样风险太大，成本太大。
所以希望在线上环境隔离真实流量的情况下，提前模拟产生各种任何可能发生的故障，来观察系统的反应，验证预期策略。
总结一下，故障演练主要有以下几个目标：
确保系统按我们预想的方式应对故障
寻找系统中未预料到的弱点
寻找其他提高系统鲁棒性的方式来避免事故实际发生
理想情况是达到如下流程化：例行化故障演练、找出系统风险点、优化业务系统、产出可行有效的故障处理预案。
故障演练是应用高可用能力测评的核心，一次完整的故障演练由演练的对象、对象发生的具体故障、应用的预期故障应对表现、对应用表现的实际观察和判断几部分组成。
演练的对象即演练的位置，可以针对应用本身，可以针对应用下游，也可以针对应用所在机器
常见的故障类型有以下一些：
也就是预案，针对每种要演练的故障情况，制定故障应对预案，预案模板参考：
这个可以在监控系统上观察应用的各项指标表现，比如异常打点，流量打点，业务曲线，机器性能等一系列可能受故障影响的地方。
我们按照流程顺序来看：
1）检查必备基础能力
2）确定故障演练范围、环境
要对哪些请求流量注入故障？
决策原则：选择核心业务链路的请求流量
推荐做法：链路分析，标记出核心业务链路
要模拟哪些下游服务的故障？
在哪个应用环境模拟故障？
3）回放流量隔离和影子表隔离
4）制定故障应对预案
针对每种要演练的故障情况，制定故障应对预案
5）配置故障
6）确定演练目标
确定所制定故障应对预案确实生效，即：启动预案后，确实能减小所针对故障的影响范围。
确定故障发生时期业务流程按预期运转（通过业务指标、埋点监控、相关的业务链路追踪工具确定）。
确定应用机器的负载指标在预期范围内（通过各种基础工具的告警确定）（根据自身业务特点设置更多的检查点）
7）培训参与的内部人员
8）通知涉及的外部人员
根据评估出的影响范围通知相关业务应用RD、运维RD、基础组件RD。通知内容要素：
推荐做法：将所有相关人员拉入一个工作群，群名「XXX应用故障演练」，在群里发送故障演练通知、组织协同。
1）将录制的线上流量逐步加压回放到故障演练的发起应用中的无真实流量机器。
2）开启应用的故障模拟开关，观察故障影响。
注意：为确保不影响真实流量，仅对染色流量发生故障。
3）启动应用的故障应对预案：
1）现场清理
流量关闭、流量隔离任务关闭
故障模拟开关关闭、预案关闭
清理演练期间写入的数据、缓存、日志等（可选）
演练期间操作改动的业务配置开关复位
重启应用
通知相关人员演练结束
2）演练报告与总结
是否达到预期目标
预案有无生效
业务流程是否按预期运转
机器负载是否正常
是否有预期之外的现象发生
关键指标（业务指标、机器负载指标）收集整理
整理后续改进点
需要把故障以场景化的方式沉淀，以可控成本在线上模拟故障，让系统和开发人员平时有更多实战机会，加速系统、工具、流程、人员的进步。
<常态化，制定演练周期>
故障演练的后续工作主要会关注在以下方向：
用常态化的演练驱动稳定性进步，丰富更多的故障场景，定义好最小故障场景和处理手段；基于架构和业务分析的智能化演练，沉淀行业故障演练解决方案。
本文作者:猿奋 来源:运维派
CIO之家 www.ciozj.com 微信公众号:imciow