📚 课程目录第2章混沌工程原则

混沌工程原则：稳态假设、多样化现实世界事件、在生产中运行、自动化实验

混沌工程并非随机的破坏行为，而是一套严谨的、以实验验证为核心的方法论。其背后有四大核心原则，构成了所有故障注入与隔离验证实践的基石。理解并遵循这些原则，是区分“混沌工程”与“混乱测试”的关键。

  核心认知： 混沌工程的目的是通过受控实验，建立对系统应对生产环境中混乱状态能力的信心。它不是制造破坏，而是系统性地发现弱点。

在开始任何实验之前，必须明确定义系统的“正常”状态。这个状态通常通过一组可量化的业务指标（Service Level Indicators, SLIs）和系统指标来衡量，例如：请求延迟、错误率、吞吐量、CPU 利用率等。稳态假设就是断言：在注入故障后，系统仍然能够维持这些指标在可接受的范围内。

实践要点： 稳态假设是实验的“裁判”。没有明确的假设，就无法判断实验是通过还是失败。建议使用 SLO（Service Level Objective）作为稳态假设的边界。

生产环境中的故障是多样且不可预测的。混沌工程实验必须覆盖尽可能广泛的现实世界事件，而不是只测试少数几种已知故障。这包括硬件故障、软件错误、网络分区、流量激增、资源耗尽、配置变更等。

避坑指南： 不要只测试“容易模拟”的故障。优先选择那些历史上曾导致过事故、或者架构上最薄弱的环节。多样化是发现未知弱点的关键。

这是混沌工程最具争议但也最核心的原则。只有生产环境才具备真实的流量、真实的数据、真实的依赖关系和真实的用户行为。任何非生产环境（如 staging、testing）都无法完全复现生产环境的复杂性和不确定性。

为什么必须上生产？
- 非生产环境的流量模式、数据分布、配置参数与生产环境存在差异。
- 许多故障（如资源竞争、缓存雪崩、热点问题）只有在真实负载下才会暴露。
- 对生产环境进行实验，才能验证监控、告警、限流、降级、熔断等容错机制是否真正有效。
如何安全地在生产中运行？
- 最小爆炸半径： 从影响最小的实验开始，例如只影响一个实例、一个用户或一个请求。
- 灰度发布实验： 先在低风险区域（如影子流量、金丝雀集群）执行实验。
- 自动回滚机制： 一旦检测到稳态假设被打破，实验应立即自动终止并回滚。

  关键区别： 在 staging 环境测试是“质量保证”，在生产环境进行受控实验才是“混沌工程”。前者验证功能正确性，后者验证系统韧性。

混沌工程不是一次性的活动，而是一个持续的过程。手动执行实验效率低、易出错、不可重复。必须将实验自动化，并将其集成到 CI/CD 流水线或作为持续验证平台的一部分，实现“持续混沌”。

自动化带来的收益：
- 可重复性： 相同的实验可以在不同时间、不同环境重复执行，对比结果。
- 规模化： 可以同时运行数百个实验，覆盖更多故障场景。
- 持续验证： 每次代码部署、架构变更后，自动运行实验，防止回归。
- 降低人为风险： 减少手动操作带来的误操作风险。
自动化实验流程：
1. 编排： 定义实验计划，包括目标、稳态假设、故障注入参数、持续时间。
2. 执行： 由自动化平台（如 Chaos Mesh, LitmusChaos, Gremlin）执行故障注入。
3. 观测： 自动收集实验期间的指标、日志、链路追踪数据。
4. 分析： 自动对比实验数据与稳态基线，判断实验是否通过。
5. 告警/回滚： 如果实验失败，自动触发告警并执行回滚操作。

工具推荐： 开源社区常用的自动化混沌工程平台包括 Chaos Mesh（Kubernetes 原生）、LitmusChaos（云原生）、ChaosBlade（阿里巴巴开源）。它们都支持 CRD 定义实验，易于集成。

这四大原则共同构成了混沌工程的实验框架。稳态假设提供了实验的评判标准；多样化现实世界事件确保了实验的覆盖面；在生产中运行保证了实验的有效性；自动化实验则让混沌工程成为可持续的工程实践。