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

1.1 混沌工程概述

混沌工程（Chaos Engineering）是一门在分布式系统上进行实验的学科，旨在通过主动注入故障来建立对系统抵御生产环境中动荡条件能力的信心。它并非随意的破坏，而是有计划的、受控的实验过程。

1.1.1 混沌工程的起源

混沌工程的概念最早由 Netflix 在 2011 年左右提出并实践。随着 Netflix 从传统的单体数据中心架构迁移到 AWS 云上的微服务架构，系统复杂性和故障模式呈指数级增长。传统的测试方法（如单元测试、集成测试）无法覆盖分布式系统中复杂的网络分区、时钟偏差、资源竞争等“暗债”（未知的脆弱点）。

Netflix 开发了 Chaos Monkey（混乱猴子）工具，随机终止生产环境中的实例，以验证系统是否能在没有人工干预的情况下自动恢复。这一实践逐渐演变为一套完整的工程方法论，并催生了 Chaos Toolkit、Litmus、Chaos Mesh 等开源工具。

核心理念：混沌工程不是制造灾难，而是通过受控实验提前发现灾难，从而避免真正的生产事故。

1.1.2 核心原则

混沌工程遵循一套严谨的实验原则，以确保实验的安全性和有效性。根据《混沌工程原则》（Principles of Chaos Engineering），核心原则包括：

原则	描述	实践要点
1. 建立稳定状态的假设	定义系统在正常情况下的可测量行为指标（如延迟、吞吐量、错误率）。	使用 SLO/SLI 作为稳态基线。
2. 多样化真实世界的事件	注入的故障应反映真实生产环境中可能发生的事件，如网络延迟、资源耗尽、服务宕机。	优先模拟硬件故障、依赖服务超时、流量突增。
3. 在生产环境中运行实验	生产环境是唯一能真实反映系统行为的地方，但必须通过“爆炸半径”控制风险。	使用灰度策略、流量镜像、最小化影响范围。
4. 自动化持续运行实验	混沌实验应作为 CI/CD 或 GameDay 的一部分，持续验证系统韧性。	集成到流水线，设置定时任务或事件触发。
5. 最小化爆炸半径	实验必须设计有“熔断”机制，一旦发现异常指标超出预期，立即停止实验并回滚。	设置告警阈值、手动/自动终止开关。

  关键区别：混沌工程的核心是实验，而不是测试。测试有已知的预期结果，而实验是为了发现未知的脆弱点。

1.1.3 混沌工程与故障注入的区别

混沌工程常被误解为“高级的故障注入”。实际上，两者在目标、方法和范围上有本质区别。下表清晰展示了它们的差异：

维度	故障注入	混沌工程
目标	验证特定故障场景下的系统功能正确性（如：数据库挂了，应用是否报错）。	探索系统未知的脆弱点，验证系统整体韧性（如：数据库挂了，系统能否优雅降级并自动恢复）。
方法	预定义的、确定性的故障注入（如：kill 进程、丢包）。	假设驱动的实验，包含“提出假设 → 注入故障 → 测量稳态 → 验证假设”的闭环。
范围	通常针对单个组件或接口。	覆盖分布式系统的全链路，包括基础设施、网络、中间件、应用层。
运行环境	多在测试环境或预发布环境。	强烈建议在生产环境或与生产环境等价的镜像环境中进行。
结果	通过/失败，验证已知故障。	发现未知的“暗债”，提升系统韧性信心。

简单来说，故障注入是混沌工程的一种工具或手段，但混沌工程远不止于故障注入。它是一套完整的实验科学体系，强调“假设-实验-验证”的循环。

常见误区：不要将混沌工程等同于“在生产环境乱搞”。没有稳态假设、没有爆炸半径控制、没有自动化回滚的故障注入，只是“破坏性测试”，而非混沌工程。

1.1.4 混沌工程实验流程（SVG）

下图展示了混沌工程实验的标准闭环流程，这也是 GameDay 联动混沌基线验收的核心操作模型：

1.1.5 混沌工程在 GameDay 中的角色

GameDay（游戏日）是一种定期的、有组织的韧性演练活动。混沌工程为 GameDay 提供了核心的实验引擎。在《GameDay 联动混沌基线验收》课程中，我们将混沌工程作为验证基线（Baseline）是否达标的唯一手段。

基线定义：在混沌实验开始前，明确系统的稳态指标（如 P99 延迟 < 200ms，错误率 < 0.1%）。
实验设计：根据基线要求，设计对应的混沌实验场景（如模拟一个 AZ 宕机、Redis 集群主节点故障）。
验收标准：混沌实验过程中，系统指标是否始终维持在基线范围内。如果超出基线，则视为验收失败，需要修复后重新验证。