混沌工程

概述 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 仍然在运行，仍然认为自己是"活的"，但和其他节点的通信已经断了。...

概述 凌晨两点，你被电话吵醒。监控大屏一片红，核心交易链路 P99 延迟飙到 8 秒，上游服务开始超时熔断，客服群里用户截图已经刷屏了。你一边远程连 VPN，一边脑子里飞速转——这场景上次演练时见过吗？预案里有没有覆盖？切换步骤还记得吗？ 如果你这时候还在翻 wiki 找文档，那说明一件事：你的预案只是写了，没练过。 故障预案不是写完就完事的文档。它是一套需要反复演练、不断修正的应急肌肉记忆。就像消防队不会只在纸上画逃生路线——他们会点真火，拉真警报，让人在浓烟里跑。SRE 的故障演练也是同一个道理：不逼团队在接近真实的故障场景里做决策，到了真正出事的时候，你永远不知道谁会卡壳。 这篇文聊聊怎么把故障预案从"写给别人看的文档"变成"团队真正能执行的作战手册"，以及怎么设计演练体系让团队保持手感。 故障预案的本质：不是文档，是决策树 预案要解决什么问题 很多人把故障预案理解成一份操作手册——“如果 A 挂了，执行步骤 1-2-3”。这没错，但太浅了。真正有用的预案是一棵决策树，帮值班人员在高压环境下快速做对三件事： 判断故障等级——这事值不值得半夜叫人？叫到哪一级？ 选择止损路径——先切流量、先回滚、还是先扩容？ 确定沟通节奏——谁对外发声、多久同步一次、什么时候升级 我见过太多预案写得像产品说明书，事无巨细地列了 50 个步骤，值班同学在故障现场根本来不及看。好的预案应该短、狠、准——能在 30 秒内定位到对应的处置方案，3 分钟内开始执行止损。 预案体系的三层结构 层级 内容 目标读者 更新频率 L1 应急卡片 单服务故障的快速处置步骤（≤10 步） 值班 On-Call 每次演练后 L2 灾备预案 跨服务故障的切换方案与回滚流程 SRE 团队 每季度 L3 业务连续性预案 机房级故障的全面接管方案 SRE + 业务方 每半年 L1 应急卡片是日常用得最多的。它不是 wiki 上的长文，而是一张可以打印出来贴在工位上的卡片。格式很简单： # [服务名] 应急卡片 ## 故障特征 - 核心指标：P99 延迟 > 500ms 或 错误率 > 1% - 典型告警：service_latency_p99_critical / service_error_rate_high ## 快速止血（按优先级） 1....

可靠性工程：不只是"不出故障" 可靠性工程的目标不是追求零故障——那既不现实也不经济。真正的目标是：在故障不可避免的前提下，让系统具备快速发现、自动恢复、持续学习的能力。 Google SRE 提出的核心公式： MTTR << MTBF / (MTBF + MTTR) × (1 - SLO) 这个公式揭示了一个关键事实：当故障间隔（MTBF）远大于修复时间（MTTR）时，系统的可用性自然趋近于 SLO 目标。因此，可靠性工程的发力方向是双重的——延长无故障时间（提升 MTBF）和缩短故障恢复时间（降低 MTTR）。 可靠性层级模型 参考 CMMI 能力成熟度模型的思想，可靠性工程同样存在层级递进关系。从低到高分为五个层级： 层级 特征 典型表现 L1 被动响应 故障发生后人工处理 告警轰炸 → 人工排查 → 手动恢复 L2 监控覆盖 关键指标可观测 仪表盘完备，告警有阈值，但恢复仍靠人 L3 自动化恢复 常见故障自动处理 健康检查自动重启、HPA 自动扩容 L4 主动预防 提前发现风险 压测、容量规划、混沌工程主动注入故障 L5 自愈系统 闭环自适应 故障自动感知 → 诊断 → 恢复 → 学习 大部分团队的真实水平在 L2 到 L3 之间。从 L3 到 L4 的跨越是最关键的——它意味着从"等故障来"转变为"主动找故障"。L5 自愈是理想态，也是持续演进的方向。 层级跃迁的关键 L1 → L2：建设可观测性体系（指标、日志、链路追踪）。 L2 → L3：引入自动化恢复机制（Kubernetes 健康检查、HPA、自动故障转移）。 L3 → L4：引入混沌工程，主动验证系统的弹性。 L4 → L5：建设自愈闭环，将人工经验沉淀为自动化策略。 每一层级的跨越都需要对应的技术投入和组织能力建设，不能跳级。...

概述 传统的可靠性保障思路是"尽量不出故障"——加监控、加告警、加冗余。但这种被动防御有一个根本缺陷：你不知道系统在故障发生时的真实表现，直到故障真正发生。 混沌工程反其道而行之：主动、可控地注入故障，在故障变成事故之前发现系统的弱点。 它不是搞破坏，而是一种科学的实验方法——提出假设（“系统应该能承受某节点故障”），设计实验（杀掉一个节点），验证假设（服务是否仍然正常），发现弱点（如果服务异常了）。 Netflix 的 Chaos Monkey 开创了这一领域，如今混沌工程已经成为 SRE 体系的重要组成部分。从原理、实验设计、爆炸半径控制、Kubernetes 实战到常态化实践，详细梳理如何把混沌工程从"概念"落地为"日常实践"。 关于混沌工程的原则，可参考 Principles of Chaos Engineering 和 Chaos Engineering Book。 一、混沌工程的原理 核心思想 混沌工程的核心思想是： 在正常流量期间，通过有意注入故障来验证系统的弹性，从而在故障变成事故之前发现并修复弱点。 这与传统的测试有本质区别： 维度 传统测试 混沌工程 目标 验证"代码是否正确" 验证"系统是否能承受故障" 环境 测试环境 生产环境（或接近生产的预发环境） 故障来源 预定义的测试用例 真实模拟的故障场景 发现时机 开发阶段 运行阶段 关注点 功能正确性 系统弹性 为什么要在生产环境做 混沌工程最反直觉的一点是"在生产环境注入故障"。为什么不 在测试环境做？ 测试环境无法复制生产的复杂性：生产环境的流量模式、数据量、网络拓扑、依赖关系与测试环境完全不同 测试环境的故障不会造成真实影响：没有压力，就不会暴露在压力下才出现的问题 只有在生产环境才能验证完整的恢复链路：告警是否触发？On-Call 是否响应？自动恢复是否生效？ 当然，直接在生产环境做混沌实验需要严格的控制——这正是"爆炸半径控制"要解决的问题。 混沌工程的四条原则 根据 Principles of Chaos Engineering，混沌工程遵循以下原则： 围绕稳态行为定义"正常"：先定义系统的正常状态（SLI/SLO），再注入故障看是否偏离 假设稳态在对照组和实验组中都保持：一部分流量/节点不注入故障（对照组），一部分注入（实验组），对比差异 在真实环境中实验：生产环境或接近生产的环境 自动化持续运行：不是一次性实验，而是持续自动化运行 混沌工程的收益 chaos_engineering_benefits: direct_benefits: - "提前发现系统弱点和单点故障" - "验证告警和恢复机制是否有效" - "提升团队对故障的响应能力" - "验证架构设计假设是否成立" indirect_benefits: - "建立团队对系统弹性的信心" - "驱动架构改进（从'看起来能扛'到'验证过能扛'）" - "减少真实故障的 MTTR（因为已经演练过类似场景）" - "培养'故障不可避免'的工程文化" 二、从 Chaos Monkey 说起 Netflix 的混沌工程演进 Netflix 是混沌工程的开创者，其演进路径值得参考：...