1. 混沌工程概述
混沌工程（Chaos Engineering）是一门在分布式系统上进行实验的学科，旨在通过主动引入故障来验证系统的韧性（Resilience）与容错能力。它并非随机的破坏行为，而是一套严谨的、以假设驱动的实验方法论。
1.1 混沌工程的定义
根据混沌工程原则（Principles of Chaos Engineering）的官方定义：混沌工程是在分布式系统上进行实验的学科，目的是建立对系统承受生产环境中湍流条件能力的信心。
其核心在于通过受控的实验，提前发现系统在异常情况下的薄弱环节，从而在故障真正发生前进行加固。这与传统的“测试”有本质区别：测试验证已知功能，而混沌工程探索未知的脆弱性。
核心公式： 混沌工程 = 假设驱动 + 受控实验 + 持续验证 → 系统韧性提升
1.2 核心原则
混沌工程并非无章可循，其背后有四大核心原则作为指导，确保实验的科学性与安全性。
| 原则 | 描述 | 实战意义 |
|---|---|---|
| 稳态假设 | 定义系统在正常状态下的可测量输出指标（如延迟、吞吐量、错误率），作为实验的“基线”。 | 没有基线，就无法判断实验是否破坏了系统稳定性。 |
| 爆炸半径最小化 | 控制实验的影响范围，避免对真实用户或核心业务造成不可逆的损害。 | 优先在影子环境、低流量实例或特定用户群体中执行。 |
| 持续自动化实验 | 将混沌实验集成到 CI/CD 流水线中，作为常态化的韧性验证手段。 | 从“一次性演练”转变为“持续合规检查”。 |
| 最小化实验复杂性 | 从最简单的故障模式（如单实例宕机）开始，逐步增加复杂度。 | 降低实验门槛，快速获得反馈，避免过度设计。 |
1.3 混沌工程 vs. 故障注入
混沌工程与故障注入（Fault Injection）常被混淆，但二者在目标、方法和范围上存在显著差异。理解这一区别是实施有效混沌工程的前提。
| 维度 | 混沌工程 | 故障注入 |
|---|---|---|
| 目标 | 验证系统整体韧性，发现未知的架构缺陷 | 测试特定组件或代码路径对已知故障的处理逻辑 |
| 方法 | 假设驱动、实验设计、稳态验证 | 预定义故障、触发、观察结果 |
| 范围 | 分布式系统、基础设施、网络、依赖服务 | 通常局限于单个服务、函数或 API |
| 输出 | 系统韧性报告、架构改进项、运维策略调整 | 代码缺陷、异常处理漏洞、超时配置错误 |
| 典型工具 | Chaos Mesh, Litmus, Gremlin | Hystrix, Resilience4j, 自定义脚本 |
实战提示： 故障注入是混沌工程的“执行手段”之一，而非全部。混沌工程更强调“实验设计”和“稳态验证”的闭环。
1.4 混沌工程实验流程（SVG）
下图展示了混沌工程实验的标准闭环流程，从定义稳态到修复加固，形成持续改进的飞轮。
1.5 稳态假设与爆炸半径（SVG）
稳态假设与爆炸半径最小化是混沌工程中最核心的两个原则，它们共同构成了实验的安全边界。下图展示了这两个原则在实验设计中的协同关系。
1.6 实战案例：基线核验中的混沌工程
在本课程《自助服务实现混沌工程基线核验的环境配置与参数同步实战》中，我们将上述原则落地为可重复的自动化流程。一个典型的基线核验场景如下：
- 环境配置基线化： 将生产环境的配置（如超时时间、重试次数、连接池大小）定义为“稳态基线”。
- 参数同步验证： 通过混沌实验（如注入网络延迟），验证配置参数是否被正确同步到所有服务实例。
- 自助服务实现： 开发人员通过自助平台一键触发实验，无需 SRE 介入，降低协作成本。
注意： 基线核验不是一次性的活动。随着系统迭代和配置变更，稳态基线需要持续更新，混沌实验也需要随之调整。
1.7 本章小结
- 混沌工程是一门实验学科，核心是建立对系统韧性的信心。
- 稳态假设和爆炸半径最小化是保障实验安全的两大基石。
- 混沌工程 ≠ 故障注入；故障注入是手段，混沌工程是方法论。
- 在基线核验场景中，混沌工程用于验证配置参数在故障下的正确性与一致性。