📚 课程目录第1章课程导入

1. 课程导入

故障注入，说白了就是故意搞破坏。

你想想看，一个系统上线前，我们总得知道它到底有多抗造。正常流程测一遍，压力测试跑一遍，看起来都挺好。但真到了线上，磁盘突然满了、网络延迟飙升、下游服务挂了——这些场景，常规测试根本覆盖不到。

故障注入就是干这个的。它通过主动向系统引入各种异常，来验证系统在真实故障下的表现。我习惯把它叫做「系统免疫接种」——先来点小病，看看身体扛不扛得住。

  核心定义：故障注入是一种通过受控方式向系统引入故障，观察系统行为、测量系统容错能力的测试方法。

常见的故障类型包括：

我在项目中遇到过最典型的案例：一个支付服务，所有单点故障都测过了，一切正常。结果线上同时发生了数据库主库宕机和缓存节点故障，两个故障叠加，系统直接雪崩。事后复盘发现，我们从来没做过「组合故障注入」——这就是教训。

这个问题我问过很多团队。得到的回答大多是「为了稳定性」。但我觉得可以拆得更细一些。

第一，发现你不知道你不知道的问题。

常规测试只能验证已知场景。但故障注入能暴露那些「你以为没问题，其实一碰就碎」的角落。我记得有一次给一个微服务做故障注入，只是把它的依赖接口延迟从10ms提高到500ms，结果整个调用链的超时重试机制就炸了——重试风暴把数据库打挂了。这个场景，压测根本测不出来。

第二，验证你的容错设计是否真的有效。

很多系统架构图上画着熔断、降级、限流，看起来很完善。但真的触发过吗？我见过一个团队，熔断器配置了三年，从来没被触发过。结果线上一次真实故障，熔断器确实生效了——但恢复逻辑有bug，熔断后永远恢复不了。你说这算不算容错？

第三，建立故障响应的肌肉记忆。

故障注入不只是测系统，也是在测人。当告警响起，运维同学能不能快速定位根因？开发同学能不能在压力下冷静修复？这些能力，靠文档和培训是练不出来的。我建议每个团队至少每季度做一次故障注入演练，让所有人「见过血」。

测试类型	覆盖场景	能否发现未知问题	是否验证容错设计
单元测试	代码逻辑	否	否
集成测试	模块交互	有限	有限
压力测试	性能瓶颈	否	否
故障注入	异常场景	是	是

避坑指南：我曾经见过一个团队，故障注入只在预发环境做，而且每次注入前都提前通知所有人。结果线上真出故障时，大家还是手忙脚乱。故障注入要「贴近真实」——随机时间、随机节点、不提前通知，才能暴露真问题。

很多人把故障注入和混沌工程混为一谈。我刚开始接触时也搞混过。其实它们的关系很简单：故障注入是手段，混沌工程是方法论。

混沌工程不是随便搞破坏。它有一套完整的流程：

你看，故障注入只是第三步里的一个工具。混沌工程的核心是「通过实验来学习系统行为」——它是一套科学方法，而不是单纯的破坏活动。

我习惯用一个比喻来解释：故障注入就像手术刀，混沌工程就像外科手术流程。光有刀不行，你得知道切哪里、怎么切、切完后怎么缝合。没有流程的故障注入，就是瞎搞。

我的建议：刚开始做混沌工程时，别想着一步到位。先从最简单的故障注入开始——比如kill一个Pod、模拟一次网络延迟。跑通一次完整的实验闭环，比搞一堆花哨的故障类型重要得多。

故障注入不是什么黑科技。它就是主动给系统找麻烦，看看系统能不能扛住。混沌工程则给了这套做法一个科学框架——先定义什么是「正常」，再假设「出问题也能正常」，然后用故障注入去验证，最后根据结果改进。

记住三个关键点：