1. 混沌工程概述
混沌工程（Chaos Engineering）并非简单的“在系统里搞破坏”，而是一门通过受控实验来发现系统薄弱环节、建立对系统在生产环境中行为信心的学科。它起源于 Netflix 在 2010 年左右为解决微服务架构下不可预测的故障而提出的实践方法，随后被业界广泛采纳，成为 SRE 和云原生架构的核心能力之一。
1.1 混沌工程的起源
2010 年，Netflix 将其基础设施从传统数据中心迁移到 AWS 云平台。在分布式系统中，网络延迟、服务器宕机、磁盘故障等不再是“是否会发生”的问题，而是“何时发生”的问题。Netflix 的工程师团队意识到，与其被动等待故障发生，不如主动、持续地注入故障，验证系统在异常条件下的行为是否符合预期。由此诞生了 Chaos Monkey——一个随机终止生产环境中 EC2 实例的工具。随后，Netflix 逐步构建了完整的混沌工程工具链（包括 Chaos Kong、Latency Monkey 等），并最终将混沌工程提炼为一门独立的工程学科。
1.2 核心原则
混沌工程并非无章可循的破坏行为，它遵循以下两条核心原则：
| 原则 | 定义 | 实践要点 |
|---|---|---|
| 稳态假设 | 系统在正常运行状态下存在一组可观测的“稳态指标”（如响应时间、错误率、吞吐量）。混沌实验的目标是验证系统在遭受扰动后，能否维持或自动恢复到该稳态。 | 实验前必须定义明确的稳态指标基线；实验后对比指标偏差，判断系统是否“健康”。 |
| 爆炸半径 | 任何混沌实验都必须将影响范围控制在可接受的边界内，避免对真实用户或核心业务造成不可控的损害。 | 通过实验环境隔离、流量限制、用户分桶、熔断机制等手段，确保故障影响不会扩散到整个系统。 |
1.3 混沌工程与故障注入的区别
很多初学者容易将混沌工程等同于故障注入（Fault Injection），但两者在目标、方法和范围上存在本质差异。下表从多个维度进行对比：
| 维度 | 混沌工程 | 故障注入 |
|---|---|---|
| 目标 | 验证系统整体韧性，发现未知的薄弱环节 | 测试特定组件在已知故障模式下的行为 |
| 实验设计 | 基于稳态假设，设计假设驱动的实验 | 基于故障模型，设计预定义的故障场景 |
| 范围 | 端到端、跨服务、跨层级的系统行为 | 通常聚焦于单个服务、API 或基础设施组件 |
| 结果分析 | 对比稳态指标偏差，评估系统韧性 | 验证故障处理逻辑是否正确（如降级、重试） |
| 典型工具 | Chaos Monkey、Litmus、Chaos Mesh | Hystrix、Resilience4J、Toxiproxy |
简单来说，故障注入是混沌工程的一种技术手段，而非混沌工程本身。混沌工程更强调“实验”的完整闭环：定义稳态 → 提出假设 → 注入扰动 → 观测指标 → 分析偏差 → 改进系统。而故障注入往往只覆盖“注入扰动”和“观测指标”两个环节。
1.4 混沌工程实验流程（SVG 图）
下图展示了混沌工程的标准实验流程，从定义稳态到改进系统的完整闭环：
1.5 混沌工程与容量水位的关系
在本课程《故障注入与 Grafana：混沌工程容量水位口径实战》中，混沌工程是验证容量水位是否合理的关键手段。通过受控的故障注入实验，你可以回答以下问题：
- 水位阈值是否安全？ 当 CPU 达到 80% 时，系统是否还能满足 SLO？
- 弹性扩缩容是否及时？ 在流量突增时，扩容动作能否在稳态指标恶化之前完成？
- 依赖组件是否成为瓶颈？ 当数据库延迟增加 200ms 时，上游服务的容量水位是否被拉高？