SRE 实战手册十一延申篇混沌工程与 Game Day——主动制造故障验证系统抗造延申篇。容量九与发布十解决能不能扛、敢不敢发本篇解决系统是否真的如你以为的那样能恢复。配套脚本../deploy/game_day.sh、../deploy/fault.sh复盘接../docs/incident-postmortem-template.md、博客七。一、为什么没故障不等于抗造传统做法是尽量别出事。混沌工程反其道而行主动、受控地制造故障验证系统是否按预期吸收冲击并恢复。因为从没演练过恢复的系统真出事时往往恢复得最慢。混沌工程的 5 条原则Netflix 提炼1) 用稳态定义正常如结账成功率≥99.9%p99300ms 2) 提出可证伪的假设如干掉 1 个节点其余 3 节点应能兜底 3) 注入真实世界的事件宕机/延迟/丢包/错误而非假想敌 4) 在生产或类生产环境跑——预发环境验证不了生产 topology 5) 自动化、常态化——一次性演练会过时持续实验才保值二、故障注入的分类你的武器库┌──────────── 资源层 ────────────┐ │ CPU 打满 / 内存压力 / 磁盘满 │ 故障注入 ──────┼──────────── 网络层 ────────────┤ │ 延迟 / 丢包 / 断网 / DNS 污染 │ ├──────────── 应用层 ────────────┤ │ 返回错误 / 进程被杀 / 依赖超时 │ └─────────────────────────────────┘我们的fault.sh覆盖了应用层最常用的两种返回错误inject与延迟latency以及进程宕机down/up。这正是 Game Day 的高频武器。三、Game Day 运行手册四步闭环假设(Hypothesis) │ ▼ 注入(Experiment) ──► 观测(Verify: SLO/On-Call 是否如预期) │ │ │ ▼ 终止/恢复(Restore) ◄── 是否达成假设 │否 ▼ 记行动项 → 复盘(博客七模板)每次 Game Day 必须明确三件事Blast Radius爆炸半径这次能搞挂多大范围预发/灰度先来生产需 IC 授权。Abort 条件出现什么就立刻停手恢复如聚合错误率越 14.4× 快燃且 5 分钟不降恢复脚本fault.sh recover/up就是我们的一键恢复。四、实验台演练game_day.sh脚本内置 3 个场景均通过fault.sh注入、读sre_monitor.py :9090 /status的燃烧速率与节点存活# 在能 ssh 到各节点的操作机执行MONITOR_IP 指向监控控制面exportMONITOR_IP192.168.0.58bash/opt/sre-lab/game_day.sh scenario1# 单节点宕机bash/opt/sre-lab/game_day.sh scenario2# 单节点 延迟错误bash/opt/sre-lab/game_day.sh scenario3# 组合先宕一节点再给另一节点注延迟错误scenario1单节点宕机预期输出稳态假设其余节点兜底SLO 守住 Game Day 22:50:01 场景: scenario1 假设干掉 1 个结账节点后其余 3 节点应能吸收流量SLO 仍守住错误率不越阈值。 [22:50:01] 注入停用 ecs-584a-0002 (fault.sh down) [22:50:01] 观测 60s监控面燃烧速率 / 存活节点数 t5s burn0.21 nodes_up3 t10s burn0.25 nodes_up3 ... t60s burn0.30 nodes_up3 [22:50:61] 恢复ecs-584a-0002 重新拉起 (fault.sh up) [22:51:31] 等待聚合指标收敛... burn0.22 nodes_up4 Game Day 结束 22:51:31 要点nodes_up从 4 掉到 3但聚合燃烧速率始终在 0.2× 左右远低于 14.4× 快燃——假设成立3 节点成功兜底。全程 On-Call 台:9099若配了CheckoutServiceDown告警见slo_rules.yml会提示实例缺失这正是 MTTD 演练。scenario2/3注入延迟错误观察 p99 抬升与燃烧速率是否越闸越闸即触发博客六的 Page 链路。演练结束务必跑fault.sh recover/up清场并确认nodes_up4、burn≈0.2×。五、与复盘闭环Game Day 不是搞破坏就完。每次演练后把 On-Call 台的告警记录套用黄金三问复盘模板../docs/incident-postmortem-template.md、博客七发生了什么假设是否成立观测数据与预期差在哪为什么兜底生效/失效的系统性原因如负载是否真的均分健康检查是否及时学到了什么改什么加什么自愈补什么监控→ 落到行动项owner 截止 验证。这样混沌工程就成了**持续把未知的脆弱变成已知的待办**的引擎。六、小结与思考题混沌工程不是破坏性测试而是用受控故障验证系统韧性的科学方法。五原则稳态、可证伪假设、真实事件、生产验证、自动化常态。Game Day 四步假设→注入→观测→恢复务必先定 Blast Radius 与 Abort 条件。game_day.sh三场景把节点宕机/延迟错误/组合在实验台跑通并接 On-Call 与复盘。思考题你们上一次主动制造故障是什么时候如果明天干掉一个核心节点你们能在 5 分钟内发现、并在 10 分钟内恢复吗答不上来就排一场 Game Day。至此《SRE 实战手册》从认知一八延伸到工程能力九十一容量规划、变更发布、混沌工程配齐可运行的实验台脚本。整套闭环——监控发现、错误预算、On-Call、复盘、容量、发布闸门、混沌演练——已可在 4 台 ECS 上完整演示。