混沌工程：提升未知故障下应急管理能力

本篇是《数智万物下的运维思考》第3部分“流程”第3章的“故障管理中的事前管理”的部分内容。主要梳理一下最近行业中比较火的混沌工程，本文简单先从以下5个方面介绍一下我对混沌工程的理解：

• 混沌工程在故障管理闭环中的角色；
• 从混沌角度看混沌工程的关注点；
• 他山之石；
• 混沌工程重点解决什么问题；
• 从工具与机制两方面梳理混沌工程；

1、重温故障预防：未雨绸缪，防微杜渐

在前面《3.3.1 复杂故障场景下的能力提升》中，梳理了一个故障管理闭环周期（如下图），其中“故障预防”属于事前管理环节，重点围绕“发现潜在问题并修复”、“提升故障处置阶段效率”两个目标，达到“未雨绸缪，防微杜渐”的效果，涉及如下工作：

• 发现潜在问题并修复：这项观点重点是接受故障的存在，包括：主动评估运行状况（架构、容量、性能、事件评估）、混沌工程、协同流程及能力问题等。
• 提升故障处置阶段效率：直接目标是缩短故障时间，包括：监控运营（覆盖面、准确性、响应效率）、自动化工具（应急三把斧、运行观察需要的日志/链路/监控性能）、应急演练（桌面、实战）、应急管理（ECC、作战室、应急协同）等。

本文介绍的混沌工程是为了发现系统风险与提升故障处置能力而进行的工程实验。通常是通过主动关闭进程、依赖异常、数据库宕机、断电等多层面的操作，模拟真实情况下的服务失效，再从故障中发现硬件或软件的运行风险，以及组织人员能力与协同效率上的问题。混沌工程的引入是运维复杂性适应性系统的一个解决方案。尤其是在当前业务量及数据量剧增，业务连续性要求越来越高，软件基础设施云原生平台化，应用软件架构微服务化，业务越来越复杂，交易链路节点越来越多，牵一发而动全身，变更引发故障已成常态化等背景，要求软件系统需要围绕弹性、故障设计、优雅降级视角进行构建，驱动企业软件架构的升级。架构升级产生了架构复杂性风险，引入混沌工程就是为了适应架构复杂性风险。混沌工程与当前架构演进背景相吻合，是当前“故障预防”阶段重要的技术及管理方案。

2、他山之石

混沌工程来自于Netflix，大概由来（摘自互联网）如下：

2008年， Netflix主数据库停机三天， 导致DVD租赁业务中断，多个国家的大量用户受此影响。之后Netflix在2011年起，逐步将系统迁移到 AWS 上，运行基于微服务的新型分布式架构。这种架构消除了单点故障，但也引入了新的架构复杂性，需要更加可靠和容错的系统。为此，Netflix启动了Chaos Monkey，通过随机性的故障注入，了解在故障注入后相关联服务的健壮性、弹性，发现故障产生后的风险。随着混沌工程的应用，Netflix在Chaos Monkey的基础上建立了猴子军团，创建了混沌工程师的角色，将混沌工程融入到运维文化中。从公开信息看，国内的混沌工程实践比较早的是阿里，阿里的团队分享了一些混沌工程的实践经验，开源了故障注入的代码，阿里云还有一个故障演练的应用（虽然我认为混沌工程与演练是有区别的）。网上有很多大厂的混沌工程实践，知乎这个链接汇集了不少信息：https://zhuanlan.zhihu.com/p/90294032 ，有兴趣的同学可以上面看看。

3、站在“未知故障与业务连续性”看混沌工程

混沌工程比较火，有些把与演练、测试相关的工作包装成混沌工程，也有一些则将混沌工程限定在分布式架构系统中。我觉得以“混沌”来命名工程实践，要将工程性工作回归混沌理论。在《运维挑战：如何构建复杂环境下的适应性系统》一文中，梳理了复杂与混沌的定义：复杂科学是研究自然界中各类系统复杂性的一门科学,专指复杂系统中的复杂性,研究复杂系统在一定规则下如何产生宏观有序的组织和行为。复杂性有非线性、不确定性、自组织性、涌现性的特性，混沌属于复杂性科学的一个表现，初始条件的一点点变化，造成结果巨大影响，导致系统不可预测。在生活中，我们经常听到的蝴蝶效应、沙丁鱼群、蚁群、人体免疫性系统、社交舆情等都是混沌理论的表现例子。

基于此，我觉得践行混沌工程要以接受复杂与不确定性为思想前提，是对看起来无序、随机、复杂的过程进行分析，发现【未知】的架构逻辑风险并进行改进，以增强在面对【未知】问题时的应对能力。站在这个角度看，演练、测试这类在混沌实验通常主要针对【已知】故障场景，即你在实验之前就已经知道风险，对输入和输出已经有明确预期。这种对【已知】场景的故障验证或加固已经有很多成熟的方法可以参照，看起来不应该作为混沌工程的重点内容，混沌工程应将关键字放在【未知】上。

同时，运维领域的复杂性已经不仅限于一个系统架构的复杂性，像金融企业普遍都有较多历史包袱，新旧系统之间信息通讯，复杂业务连接多个系统，海量数据计算与管理，跨团队协同等都是未知故障的触发点。所以，混沌工程的实践不仅仅是为了应对分布式，微服务架构的信息系统的故障管理，需超越单纯的技术架构领域视角，站在业务连续性保障的全局角度推进混沌工程。

4、挖掘架构风险与加强应急处置能力

与故障事前管理的“发现潜在问题并修复”、“提升故障处置阶段效率”两个目标价值一致，传递到混沌工程的价值，我觉得混沌工程的价值应该关注：挖掘架构风险与加强应急处置能力。

1）架构风险：

不同岗位角色对于IT的视角不一样，项目经理是项目视角，产品经理是产品视角，运维管理员是系统视角。所以本篇的架构风险中，我以系统视角来梳理一下架构风险：

（1）系统自身架构：

部署架构高可用风险：对每个高可用节点进行故障注入，发现架构上高可用健壮性，挖掘架构单点风险。

模块组件（数据库、中间件等）异常风险：对每个模块组件进行故障注入，感知与之关联的模块的故障，挖掘依赖关系是否合理，评估应急方案。

服务异常风险：从应用服务级别，注入故障，感知服务异常时的影响，发现依赖影响，评估应急方案。

API异常风险：从API级别，注入异常，感知故障影响，发现依赖影响，及应急方案。

核心/基本功能异常风险：从功能角度进行故障注入，挖掘系统核心或基本功能，发现依赖影响，评估应急方案。

（2）依赖环境

上下游链路风险：通过故障注入，发现上下游系统影响，梳理影响链路。

基础设施风险：通过基础设施故障注入，查看上层应用的影响。

2）应急处置能力

（1）应急能力：通过实战型的故障，发现相关人员对问题的应急能力，以及问题上报、处理流程是否合理，以战养战。

（2）监控发现：通过对系统注入故障，验证监控指标是否准确，监控维度是否完善，告警阈值是否合理，告警是否快速，告警接收人是否正确，通知渠道是否可用等，提升监控告警的准确和时效性。

（3）自动化操作：通过应急处理过程，查看是否可以进行自动化程度的提升。

（4）其它：根据应急处理过程 ，查看预案或手册完备度、B岗是否就位……

5、混沌工程主流方法概括

没有亲身经历过混沌工程，我摘一个阿里同学梳理的混沌工程步骤：

确定初步的实验需求和实验对象；

通过实验可行性评估，确定实验范围；

设计合适的观测指标；

设计合适的实验场景和环境；

选择合适的实验工具和平台框架；

建立实验计划，和实验对象的干系人充分沟通，进而联合执行实验过程；

搜集预先设计好的实验指标；

待实验完成后，清理和恢复实验环境；

对实验结果进行分析；

追踪根源并解决问题；

从上面看混沌工程可以概括为：计划管理、自动化/线上化执行、故障观察、事后环境恢复4点。

1）工具视角

以运维工具场景的产品设计和工具实现角度看，上面步骤已经有一个相对完整的用户故事，对上述步骤进行线上化、自动化，并加入可观察的能力是工具层面的关注点。我尝试抽象下我理解混沌工程工具需要具备的主要功能：

（1）实验计划管理

模板管理

流水线编排

演练方案设计

审批流程（技术方案评审）

（2）自动化执行

执行控制与风险管控

故障注入工具

应急恢复工具

自动化操作脚本、代理

（3）故障观察

评价系统健康的KPI指标

故障感知涉及的主动拨测、被动监控、数据可视化等功能

应急处置协同连接功能

（4）事后环境恢复

环境恢复的自动化

环境恢复的数据分析

总结报告

跟进闭环

按我的理解，在当前监管控析的平台化中，CI/CD的解决方案与混沌工程涉及的工具有一定的类似，各位可以试试调整相关功能，形成一个新的混沌工程应用方向。

2）流程视角

因为没有具体实践经验，这里抛几点我预测混沌工程需要的相关流程机制上的支持：

决策层面，接受复杂与不确定性，认同故障常态化，并推动有效应对故障的架构设计与应急管理。

执行层面，加强故障注入、故障观察、故障恢复的管控能力，控制好故障影响范围，在对生产保持敬畏之心的基础上践行混沌工程，并建立持续优化的闭环协同机制，混沌工程最终是为了解决问题。

场景层面，生产环境注入故障实验，实际协同应急环境执行应急。

工具层面，加强故障注入的风险管控、操作留痕，并与实际工作场景涉及的工具连接。

end。