📚 课程目录第1章混沌工程概述

1.1 混沌工程概述

混沌工程（Chaos Engineering）是一门在分布式系统上进行实验的学科，旨在通过主动注入故障来建立对系统抵御生产环境中不可预测扰动能力的信心。它并非单纯的破坏行为，而是一种结构化的、以提升系统韧性为目标的实证方法。

1.1.1 混沌工程的起源

混沌工程的概念最早由 Netflix 在 2011 年前后提出并实践。随着 Netflix 从传统的单体数据中心架构迁移到分布式云架构，他们发现传统的测试方法无法覆盖分布式系统中复杂的、非线性的故障模式。为了应对“未知的未知”风险，Netflix 开发了 Chaos Monkey（混乱猴子），该工具会随机终止生产环境中的实例，以验证系统是否能在组件持续失效的情况下正常运行。这一实践逐渐演变为一套完整的工程方法论，并催生了 Chaos Toolkit、Litmus、Gremlin 等开源与商业工具。

  核心理念：混沌工程不是制造混乱，而是通过受控实验来揭示系统的脆弱性，从而在故障真正发生前进行加固。

1.1.2 核心原则

根据《混沌工程原则》（Principles of Chaos Engineering）的定义，一套成熟的混沌实验应遵循以下五大核心原则：

原则	描述	关键动作
1. 定义稳态	明确系统在正常运行时的一组可测量的输出指标（如响应时间、错误率、吞吐量）。	定义 SLO（服务等级目标）作为实验的基准线。
2. 提出假设	假设系统在注入故障后，稳态指标仍能维持在可接受范围内。	例如：“当节点 A 宕机时，支付成功率仍应 > 99.9%”。
3. 引入真实世界事件	注入的故障应模拟生产环境中可能发生的真实扰动，如网络延迟、资源耗尽、服务崩溃等。	使用故障注入工具模拟 CPU 飙高、网络丢包。
4. 在生产环境中运行	混沌实验应在生产环境或与生产环境高度一致的预发环境中执行，以确保结果的真实性。	通过灰度策略或流量镜像控制爆炸半径。
5. 自动化实验	将实验设计、执行、结果分析流程自动化，以持续验证系统韧性。	集成到 CI/CD 流水线中，定期执行。

实践提示：在基线核验阶段，原则 1（定义稳态）和原则 2（提出假设）是故障注入评审的核心输入。如果稳态指标定义不清晰，后续的故障注入实验将无法有效评估系统是否“通过”测试。

1.1.3 混沌工程与故障测试的区别

混沌工程常被误解为传统的故障测试或压力测试。两者在目标、方法和执行方式上存在本质区别。下表从多个维度进行了对比：

对比维度	混沌工程	传统故障测试
核心目标	探索未知的脆弱性，验证系统韧性假设	验证已知功能或边界条件是否通过
实验设计	基于假设驱动，关注系统稳态指标	基于需求文档，关注功能正确性
故障类型	模拟真实世界的复杂、非线性故障（如网络分区、资源争抢）	模拟预定义的、单一故障（如服务返回 500 错误）
执行环境	优先在生产环境或高保真环境中执行	通常在测试环境或沙箱中执行
结果判定	通过/失败基于稳态指标的偏差程度	通过/失败基于断言（Assertion）是否通过
自动化程度	强调持续、自动化的实验流水线	多为手动或半自动的回归测试

下图直观地展示了混沌工程从“定义稳态”到“改进系统”的闭环实验流程，与传统测试的线性执行路径形成鲜明对比。

评审注意：在基线核验的故障注入评审中，必须区分“混沌实验”与“故障测试”。如果评审对象仅包含预定义的、无假设验证的故障注入脚本，应将其归类为传统故障测试，并评估其是否满足混沌工程的核心原则。