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