1. 故障演练概览：什么是故障演练、发展历史、与混沌工程关系
大家好。我是这门课的主讲，一个在线上系统可靠性领域摸爬滚打了十来年的老兵。今天开始，我们聊聊故障演练。
有人觉得这玩意儿很玄乎。说白了，它就是主动找茬。
你想想看，一个系统跑得好好的，为什么要搞它？我的答案是：等它自己出问题，代价太大了。提前模拟一下故障，看看系统会不会死，死了怎么救，这才是正经事。
1.1 什么是故障演练
故障演练，就是在一个受控的环境里，故意给系统制造一些破坏性事件，来验证它的容错、恢复和可观测性。听起来像自虐？其实这是一种预防性体检。
我在2016年参与过一个电商大促项目。那时候线上节点挂了，监控没反应，运维大哥手动查了很久。那次之后，我养成了一个习惯：每上线一个关键服务，先给它"死一死"看看。
核心价值：故障演练不是为了让系统垮掉，而是为了在真正垮掉之前，知道它怎么垮，以及怎么救。
它与传统测试的区别，我整理了一张表，方便你对比：
| 维度 | 传统测试 | 故障演练 |
|---|---|---|
| 目标 | 验证功能是否符合预期 | 验证系统在异常下的行为 |
| 输入 | 正常/边界数据 | 故障事件（丢包、高延迟、节点宕机） |
| 关注点 | 正确性、响应时间 | 韧性、恢复时间、逃逸行为 |
| 触发方式 | 脚本/人工点击 | 故障注入工具（模拟器/Agent） |
| 失败后果 | Bug 修复后重测 | 立即回滚或终止实验，修复后重测 |
这里有一个误区：有人把故障演练和压力测试混起来。压力测试是让它跑得快，故障演练是让它跑得烂。两者不同，但可以配合用。
我的建议：刚开始做故障演练，别一上来就拔网线。从最小的故障开始，比如对一个接口注入1秒的延迟。先学会走，再学跑。
1.2 发展历史
故障演练不是新鲜事物。它有一个清晰的演进路径。
- 混沌工程的萌芽（2011年前后）——Netflix 推出了 Chaos Monkey。这个工具会随机杀死生产环境中的实例。起初大家都觉得这帮人疯了。我记得当时在技术论坛上看到争论，有人直接说"这是自杀式运维"。
- 原则的确立（2014-2016）——Chaos Engineering 的概念正式提出。核心原则开始形成：稳态假设、实验假设、最小爆炸半径。
- 平台化与工具化（2017-2020）——出现了很多开源和商业工具：Chaos Mesh、Litmus、Gremlin。故障演练开始从"极客玩具"变成"工程必备"。我以前参与过某云厂商的故障演练平台建设，观察到了一个现象：工具变了，但思路没变。
- 规模化与常态化（2021至今）——故障演练被嵌入到发布流水线。持续验证+自动化回滚逐渐普及。
这个演变很有意思。最早大家觉得这是"找死的操作"，现在几乎所有中大型互联网公司都有自己的故障演练平台。为什么？因为不演练，你真的不知道系统在哪一刻会崩。
1.3 与混沌工程的关系
这两个词经常被混用。我得说清楚：混沌工程 ≠ 故障演练。
| 特征 | 混沌工程 | 故障演练 |
|---|---|---|
| 定位 | 一门实验科学，一套理论框架 | 具体实践方法，是混沌工程的手段之一 |
| 目标 | 探寻未知的系统脆弱点，验证稳态假设 | 模拟已知故障，验证容错和恢复能力 |
| 实验方式 | 假设驱动、系统化、随机模糊 | 场景化、剧本化、流程清晰 |
| 产出 | 新的认知，发现盲区 | 具体的数据和报告，修复和改进项 |
我个人的理解是：混沌工程是"为什么做"，故障演练是"怎么做"。你可以把故障演练看作是混沌工程落地的核心抓手之一。没有演练，混沌工程就成了纸上谈兵。
我曾经踩过坑：有一家公司直接照搬了一个开源的高阶混沌工具，随手就杀掉了生产环境的半数节点，结果发现没有对应的熔断和限流机制，业务中断很久。你想想看，这就是"只学其形，未学其神"。注意，混沌工程的核心原则"最小爆炸半径"是铁律，任何时候都不能违背。
下面这张图总结了故障演练与混沌工程的关系，以及故障演练本身的核心要素：
总结一下本章的核心要点：
- 故障演练是什么？——主动模拟故障，验证系统韧性。
- 发展路径：从 Chaos Monkey 到平台化、常态化。
- 与混沌工程的关系：混沌工程是理论，故障演练是手段。两者缺一不可。