混沌工程是什么？主动制造故障，让系统在真正出问题前先变强
本文定义了混沌工程（Chaos Engineering），引用Netflix工程师在IEEE Software期刊上发表的原始理论文章，梳理其四大核心原则——围绕稳态行为建立假设、模拟真实世界的多样化事件、在生产环境中运行实验、尽可能缩小影响范围。文章介绍Netflix从随机终止单个实例的Chaos Monkey，逐步发展到模拟整个区域故障的Chaos Kong的分级实验思路，说明"监控面板一片绿"为什么不能等同于系统真正稳定，并结合ServiceDesk Plus的CI停机记录、问题管理等能力，说明企业该如何借助主动的故障模拟，在真实故障发生前先发现并修复系统中的薄弱环节。
监控大屏上所有指标都显示绿色，团队据此认为系统运行状况良好，直到某次真实的服务器故障发生，才发现原本以为会自动切换的备用节点根本没有正确配置，一个看似万无一失的容错机制在真正需要它的那一刻彻底失效。这种"监控显示一切正常"和"真正遇到故障时系统能否扛住"之间的落差，是许多依赖IT事件管理体系、却从未主动验证过自身韧性的团队普遍会遇到的问题。
Netflix工程师提出的混沌工程，正是针对这一落差给出的解法：与其被动等待真实故障来检验系统的韧性，不如主动在可控条件下制造故障，提前暴露系统中原本隐藏的薄弱环节。这套源自大型互联网公司的实践理念，对任何依赖ITSM系统支撑关键业务运行的团队，都具有值得借鉴的价值。
本文将围绕三个问题展开：混沌工程具体是什么，它的核心原则是什么？从Chaos Monkey到Chaos Kong，Netflix是如何分级开展混沌实验的？借助ServiceDesk Plus，企业该如何为这类主动韧性验证提供必要的支撑？
什么是混沌工程？它的核心原则是什么？
混沌工程是Netflix工程师在2010年前后为验证分布式系统的可靠性而提出的一套实验方法论，核心思路是主动、有计划地向系统中引入可控的干扰，观察系统在异常条件下的实际表现，从而在故障真正大规模爆发之前，提前发现并修复潜藏的薄弱环节。Netflix的工程师团队在IEEE Software期刊发表的文章中，将这一实践归纳为几项核心原则：围绕系统正常运行时的稳态行为建立可验证的假设、尽可能模拟真实世界中可能发生的多样化事件（而非单纯的随机故障）、优先在生产环境而非测试环境中开展实验（因为测试环境难以还原真实系统的复杂交互）、并且始终将实验可能造成的影响范围控制在最小、可接受的边界内。
这套方法论背后的逻辑并不复杂：传统的测试手段主要验证系统在预期条件下是否按设计运行，却很少验证系统在真实世界的种种意外条件下会如何反应；而混沌工程恰恰反其道而行之，主动拥抱这种不确定性，用实验去回答"如果这里出了问题，系统到底扛不扛得住"这个问题，而不是等到真实事件发生时才被动地找到答案。
一、从Chaos Monkey到Chaos Kong：分级开展混沌实验
Chaos Monkey：随机终止单个实例，验证基础容错能力
Chaos Monkey是Netflix最早开发并开源的混沌工程工具，会在生产环境中随机终止运行中的服务实例，用来验证当某个具体节点意外宕机时，流量是否能够被正确路由到其他健康实例、用户是否完全感知不到这次中断。这是混沌工程实验中最基础、影响范围也最小的一类实验。
Failure Injection Testing（FIT）：模拟服务间调用失败
在分布式架构中，一个服务往往依赖多个其他服务的调用结果，FIT专门用来模拟服务之间调用失败的场景，验证当某个依赖的下游服务出现异常响应时，调用方是否具备合理的降级或容错处理能力，而不至于因为一个环节的失败拖垮整个调用链路。
Chaos Kong：模拟整个区域级故障，验证最高等级的容灾能力
Chaos Kong是影响范围最大的一类实验，用来模拟整个云服务区域完全不可用的极端场景，验证当一整片基础设施区域彻底失效时，业务能否顺利切换到其他区域继续运行，这类实验通常需要更充分的准备和更严格的监控保障，用来验证企业应对最极端故障场景的能力上限。
从这三类工具的演进可以看出一条清晰的实践路径：先从影响范围最小、风险最可控的实验开始验证基础的容错能力，再逐步扩大实验的复杂度和影响范围，最终具备应对最极端故障场景的验证能力，而不是一上来就贸然挑战风险最高的实验类型。
二、ServiceDesk Plus如何为混沌工程实践提供支撑？
混沌工程本身是一套实验方法论，具体的故障注入通常依赖专门的工具完成，但ServiceDesk Plus作为一套完整的IT服务管理软件，可以在实验前后的关键环节提供必要的支撑：
① CMDB依赖关系视图，帮助规划实验的影响范围
在设计一次混沌实验之前，团队需要清楚了解目标系统与哪些其他配置项之间存在依赖关系，才能合理评估这次实验可能波及的范围。CMDB中记录的配置项依赖关系，可以为实验设计阶段的影响范围评估提供准确的参考依据。
② CI停机记录，将实验造成的可控停机也纳入统一统计
混沌实验过程中产生的计划性停机，同样可以记录在配置项的停机标签页中，与其他类型的停机记录一并纳入统一的可用性统计视图，避免实验数据和日常运维数据脱节，散落在不同的记录渠道里。
③ 问题管理流程，系统性跟踪实验发现的薄弱环节
混沌实验发现的每一个薄弱环节，都可以转化为正式的问题记录，纳入问题管理流程系统性跟踪整改进度，避免"实验发现了问题、却没有人跟进落实修复"的情况，让每一次主动的故障模拟都能真正转化为系统韧性的实际提升。
核心要点速览
- 混沌工程的核心是主动、有计划地引入可控故障，在真实事件发生前提前发现系统的薄弱环节。
- 四大核心原则：围绕稳态建立假设、模拟真实世界事件、在生产环境运行、控制影响范围最小化。
- 从Chaos Monkey（单实例）到FIT（服务调用失败）再到Chaos Kong（整个区域），实验应遵循由小到大的分级推进路径。
- 监控面板显示一切正常，不代表系统在真实故障条件下也能表现良好，两者是完全不同层面的验证。
- 实验发现的薄弱环节应纳入问题管理流程系统性跟踪，避免"发现了却没人修复"的情况。
写在最后：与其等意外发生，不如主动制造一次可控的意外
真正的系统韧性，从来不是靠监控面板上的绿色指示灯证明出来的，而是要靠一次次真实或模拟的故障来检验。混沌工程提供的这套思路，本质上是把原本被动、代价高昂的"真实故障"，替换成了主动、可控、代价低得多的"实验性故障"，让团队能够在真正的意外来临之前，就已经把能想到的薄弱环节修补完毕。
将CMDB依赖关系、CI停机记录与问题管理流程整合进ServiceDesk Plus一体化平台，是为混沌工程这类主动韧性验证提供必要支撑最直接的方式。从为一个非核心系统设计并执行第一次小范围的故障模拟实验开始，团队对自身系统真实韧性的认知，就会比只看监控面板扎实得多。
立即体验 ServiceDesk Plus，为主动韧性验证提供系统化支撑
| ☁️ 免费注册云版本 | 💻 下载本地版 | 📅 预约专家演示 |
常见问题解答（FAQ）
延伸阅读：
