一、故障注入基础：从“故意搞坏”说起
各位好，我是老张。做测试架构十几年了，今天咱们聊聊故障注入。
你可能会问：为什么要故意搞坏系统？这不是自找麻烦吗？
嗯，我刚开始接触这个领域时，也有同样的疑惑。直到有一次线上事故，让我彻底改变了看法。
1.1 什么是故障注入
故障注入，说白了就是主动往系统里塞故障。不是等故障自己来，而是我们提前动手。
举个例子：
- 正常测试：验证用户登录功能是否正常
- 故障注入：把认证服务直接 Kill 掉，看系统怎么反应
我个人习惯把故障注入分成两类：
| 分类 | 手段 | 典型场景 |
|---|---|---|
| 编译时注入 | 修改代码、插桩 | 模拟内存泄漏、空指针 |
| 运行时注入 | 系统调用劫持、网络延迟 | 模拟磁盘满、网络丢包 |
我在项目中遇到过最典型的案例：一个支付系统，平时跑得好好的。我们注入了一个“数据库连接池耗尽”的故障，结果发现整个订单服务都挂了。这就是故障注入的价值——提前暴露那些你以为不会出问题的问题。
1.2 故障注入的目的与价值
为什么要做故障注入？我总结了三个核心目的：
- 验证容错机制——你的熔断、降级、限流到底管不管用？
- 发现隐藏缺陷——正常路径测不到的边界情况
- 评估恢复能力——出事后系统多久能自愈
核心价值一句话：故障注入不是制造麻烦，而是用最小的成本，提前发现最大的隐患。
你想想看，线上出了故障，每多一分钟就是几十万的损失。而故障注入，就是在实验室里把这些问题先炸出来。
我记得有一次，我们给一个微服务网关做故障注入。注入了一个“下游服务返回500”的故障，结果网关直接 OOM 了。为什么？因为重试机制没做限制，无限重试把内存打满了。这种问题，正常测试根本测不出来。
我的经验：故障注入发现的缺陷，80%以上都是“非功能性”问题——性能、稳定性、资源泄漏。这些在功能测试里很难覆盖到。
1.3 故障注入在混沌工程中的位置
很多人把故障注入和混沌工程混为一谈。其实它们的关系是这样的：
- 故障注入：是一种测试技术，关注“注入什么故障”
- 混沌工程：是一种实验方法，关注“系统在故障下的行为”
说白了，故障注入是混沌工程的核心工具。没有故障注入，混沌工程就是空谈。
下面这张图，是我自己梳理的故障注入在混沌工程中的位置：
从这张图可以看得很清楚：
- 混沌工程是顶层方法论，它告诉你“为什么要做实验”
- 故障注入是底层执行工具，它告诉你“怎么制造故障”
- 两者缺一不可
注意：千万不要把故障注入当成混沌工程的全部。我曾经见过一个团队，买了各种故障注入工具，天天往系统里塞故障，但从不分析结果。这就是典型的“为了故障而故障”，失去了混沌工程的意义。
1.4 故障注入的常见误区
做故障注入这么多年，我总结了一些常见误区：
| 误区 | 表现 | 正确做法 |
|---|---|---|
| 只注入不观察 | 故障注入完了，不看监控指标 | 注入前先确定观察指标 |
| 一次性注入太多 | 同时注入多个故障，无法定位根因 | 每次只注入一个故障变量 |
| 忽略恢复验证 | 只验证故障发生时的表现 | 必须验证故障恢复后的状态 |
| 只在测试环境做 | 生产环境从不做故障注入 | 灰度环境逐步推进到生产 |
我曾经犯过一个错误：在测试环境做了一堆故障注入，结果都通过了。上线后，生产环境一个简单的网络抖动，系统就崩了。为什么？因为测试环境的网络延迟、资源限制和生产环境完全不一样。从那以后，我坚持故障注入必须在生产环境做——当然，是在可控范围内。
避坑指南：刚开始做故障注入，建议从“最小爆炸半径”开始。比如先注入一个非核心服务的延迟，观察系统反应。等团队有了经验，再逐步扩大范围。
1.5 本章小结
好了，这一章的内容就到这里。我带你回顾一下核心要点：
- 故障注入是主动制造故障的测试技术
- 它的核心价值是提前发现隐患，而不是制造麻烦
- 在混沌工程中，故障注入是核心执行工具
- 做故障注入要避免常见误区，尤其是“只注入不观察”