故障演练

对于很多大型企业（如阿里巴巴）来说，经过多年的技术演进，系统工具和架构已经高度垂直化，服务器规模也达到了比较大的体量。当服务规模大于一定量（如10000台）时，小概率的硬件故障每天都会发生。这时如果需要人的干预，系统就无法可靠的伸缩。

为此每一层的系统都会面向失败做设计，对下游组件零信任，确保在故障发生时可以快速的发现和处理。但这些措施在故障发生时的有效性、故障恢复工具的真实容灾能力、处理问题人员的熟练度，沟通机制、容灾措施对上层的影响等问题，平时并没有太多的机会验证，往往都是在真实故障中暴露。

故障演练就是这个背景下诞生的，沉淀通用的故障场景，以可控成本在线上故障重放，以持续性的演练和回归方式的运营来暴露问题，不断验证和推动系统、工具、流程、人员能力的提升，从而提前发现并修复可避免的重大问题，或通过验证故障发现手段、故障修复能力来达到缩短故障修复时长的作用。

故障演练验证，是指基于混沌工程的故障演练实现对业务系统的验证。演练可以分为有损演练和无损演练，一般通过低频的有损演练发现业务架构问题、验证业务容灾能力，通过高频的无损演练实现对业务的监控发现/报警响应、组织应急等能力进行验证。

演练方案设计理论基础

技术型故障分析归纳，大致可以按照IaaS、PaaS、SaaS的层次进行归类。

上面的分类是一个宏观视角，不是一个系统设计的视角。所以可以对故障模型再做一次升级，并得到一些推论：

• 故障是来自于硬件（如IaaS层），软件（如PaaS或SaaS）的故障。并且有个规律，硬件故障的现象，会在软件故障现象上有所体现。

• 故障隶属于单机或是分布式系统之一，分布式故障包含单机故障。

• 对于单机或同机型的故障，以系统为视角，故障可能是当前进程内的故障，比如：如FullGC，CPU飙高； 进程外的故障，比如其他进程突然抢占了内存，导致当前系统异常等。对于大多数无损突袭演练的故障模拟，只需要关注故障对当前系统的影响，而不是真的需要外部产生故障。

• 此外，还有一类故障，可能是人为失误，或流程不当导致，这部分不做重点讨论。

常见的故障类型都可以映射到这个故障模型中，模拟故障的演练系统及方案也可以基于该模型进行设计。在设计演练方案的过程中，可以考虑在模型中每个环节进行故障注入，验证故障应急方案。

不同演练类型和目标

根据演练过程对线上业务的影响，演练可分为有损演练和无损演练。由于对业务的影响不同，两种演练可以进行的演练频次、可实现的业务验证目标都有不同。

有损演练是指直接在线上真实业务环境注入异常进行演练，演练模拟的真实有效性高，为了平衡业务影响一般会选择最核心场景、在业务最低峰期做演练，而且演练频次相对较小，例如为了验证多活容灾能力的机房断网演练，一般是一个月一次的演练频次；无损演练是指在一套无线上真实业务流量的隔离环境做演练，配合压测模拟流量注入异常进行演练，由于业务无损，可以支持较高频次的演练，比如为了类比/形变复现线上类似故障、验收故障复盘的改进action、演练监控感知能力/报警响应能力等，可以组织对不同业务团队轮流参与的每周1次的高频演练。

故障演练实践参考

阿里巴巴集团借助混沌工程实现了无损演练和有损演练的常态化执行，缩短建设大规模演练实施的进程、加速演练执行效率，让业务更聚焦在架构/流程风险识别与系统优化/容灾能力建设上，保障混沌工程实验投入产出比最大化。

生产环境做三大类场景的低频演练：

• 机房断网演练，通过对业务资源的IP级别编排，实现先单个业务断网演练验证，再逐步扩大业务范围、直至所有业务的机房断网演练，保证线上多活容灾能力的持续有效性，避免因业务迭代、基础设施/中间件变化导致的多活容灾能力失效问题；

• 全民扫雷收集发现的线上重大架构/业务问题的模拟验证以及修复后的验收；

• 一年左右一次的生产突袭演练，一般由CTO操作注入，验证从监控感知发现->报警快速响应->高效组织应急->定位排查止损的全链路故障处理流程。

仿真环境（常态引流1%线上流量的全链路灰度环境，或者新业务建设环境）做高频的模拟演练：

• 各业务自身监控感知能力/报警响应速度的演练验证；

• 各业务的历史故障形变/抽象的场景，在本业务和其它业务做回放演练验证，以及历史故障重要改进措施的演练验收；

• 各业务组织应急协同能力以及各类预案有效性演练验证。