故障注入

概述 Netflix 说混沌工程让线上重大事故减少了 70%。这个数字很多团队都看过，但真正在生产环境跑过故障注入的，寥寥无几。 原因很简单：怕。注入一个网络分区，Pod 卡死怎么办？模拟磁盘写满，数据库崩了怎么办？在凌晨 3 点手动注入故障然后手忙脚乱地回滚——这不是演练，这是制造事故。 我曾经在某新能源物流平台的 K8s 迁移过程中，需要在 120+ 微服务全量切换前验证容灾能力。纯靠理论推演不够，团队需要眼见为实。于是我们在预发环境做了一轮故障注入测试，结果第一次注入网络分区就发现了 Pod 驱逐延迟 6 分钟的问题——如果这个 bug 在生产环境暴露，RTO 直接超标。 这篇文章不讲混沌工程的入门概念（那篇 相关文章：混沌工程：主动发现系统弱点 已经讲过），而是直接进入生产级决策：怎么选工具、怎么控制爆炸半径、怎么设计自动化演练流水线，以及 3 个我在实战中踩过的反直觉坑。 故障注入测试 vs 混沌工程：分清两件事 很多人把这两个词混着用。它们不一样。 故障注入测试是一种测试技术——你明确知道要注入什么故障（比如"把节点 A 和节点 B 之间的网络断开 5 分钟"），有明确的预期结果（比如"流量应该自动切换到节点 C"），有通过/不通过的判定标准。它的核心是验证：你已经设计的容错机制到底管不管用。 混沌工程是一种工程实践——你随机注入故障，观察系统行为，发现你不知道的弱点。它的核心是探索：系统在未知故障组合下会怎样。 维度 故障注入测试 混沌工程 目标 验证已知容错机制 发现未知弱点 故障选择 预定义、有针对性 随机、组合式 预期结果 明确的通过/失败标准 观察系统行为 执行频率 发布前、变更后 持续、定期 适用阶段 预发 → 生产灰度 生产环境常态运行 风险可控性 高（已知故障、已知预期） 中（随机组合可能暴露级联失效） 我推荐的落地路径：先做故障注入测试，再做混沌工程。原因很实际——如果你的系统连已知的、单一的故障都扛不住，随机组合只会制造混乱。 四类故障的注入方式与生产风险 故障注入的核心是覆盖系统最可能出问题的维度。我按实践经验分成四类，每类的注入方式、验证目标和生产风险完全不同。 网络故障：最危险的一类 网络故障包括网络分区（partition）、延迟（delay）、丢包（loss）、带宽限制（bandwidth）。其中网络分区是最危险的——它会导致分布式系统的"裂脑"（split-brain）。 为什么危险？因为网络分区不像 Pod 被杀那样有明确的故障信号。K8s 的 kube-controller-manager 需要等待 node-monitor-grace-period（默认 40 秒）才把节点标记为 NotReady，然后再等 pod-eviction-timeout（默认 5 分钟）才开始驱逐 Pod。加起来将近 6 分钟，在这段时间内，节点上的 Pod 仍然在运行，仍然认为自己是"活的"，但和其他节点的通信已经断了。...