Sunqy 文档库

主题

08 · 故障演练与发布安全 ​

没演练过的回滚只是理论，没预案的故障靠运气。本篇讲混沌工程思路、故障预案、回滚演练与复盘，把"出大事时怎么办"从口号变成可重复的练习。先给结论：发布安全 = 预案 + 演练 + 复盘三位一体，演练的产出不是"没出事"，而是"出事了敢说我会处理"。

速览卡 ​

项内容
一句话定位让"出大事时"有预案、有演练、有复盘的操作指南
核心内容混沌工程思路、故障预案、回滚演练、灰度与开关、复盘方法
读完能回答混沌工程是乱搞吗？怎么低成本开始演练？复盘怎么写才有效？
相关板块D02 · 部署 CI/CD ｜ D05 · 可观测 ｜ S06 · 运维安全

一、先给结论：故障应对的三步循环 ​

text
预案（出事先想好）→ 演练（验证预案）→ 复盘（把教训变改进）

一句话：没有预案，故障时靠人肉猜；没有演练，预案只是文档；没有复盘，演练等于白练。

二、混沌工程：主动制造故障，验证系统韧性 ​

2.1 不是乱搞，是受控实验 ​

混沌工程的核心是在生产/准生产环境、受控地注入故障，验证系统在依赖挂掉时是否按预期降级。

原则说明
先小后大从测试环境、低风险故障开始
有假设再注入先写"预期表现"，再看是否符合
随时可终止故障注入要能一键停止
不追求全乱目标是验证已知的降级设计

2.2 常见演练场景 ​

故障验证什么
杀一个实例副本自愈、流量不中断
断数据库应用是否降级/报错是否友好
高延迟注入超时与熔断是否生效
发一个坏版本回滚链路是否真的可用

类比前端：像"断网测试 PWA 是否离线可用"——先故意制造故障，确认兜底存在。

三、故障预案：出事前就写好 ​

一份可执行的预案要回答五个问题：

问题例子
什么信号触发？5xx 比例 > 5% 持续 10 分钟
谁响应？值班人 + 对应服务 owner
先做什么？看指标 → 看追踪 → 看最近发布
怎么缓解？回滚 / 切流量 / 重启 / 降级开关
什么时候升级？15 分钟未恢复，找更高级别介入
text
预案存放：与代码同仓库（runbook 目录），可被告警直接链接

好预案的标准：一个没参与过系统的人，照着 runbook 也能完成缓解第一步。别写成只有自己看得懂的笔记。

四、发布安全：把"出错"的成本降到最低 ​

4.1 防线叠加 ​

防线作用
功能开关新功能可独立开/关，不随发布绑定
灰度发布小流量先看，风险隔离
一键回滚5 分钟内切回上一版本
数据库兼容迁移向前兼容，回滚不炸

4.2 功能开关 vs 回滚 ​

手段适用特点
回滚整个版本有问题整体切回，重放发布
功能开关单个功能有问题精准、不影响其他发布

最佳实践：高风险功能默认走开关 + 灰度，回滚是最后兜底，不是第一选择。

五、演练与复盘：怎么落地 ​

5.1 低频高价值的演练节奏 ​

频率内容
每月一次回滚演练（挑一个服务）
每季度一次故障注入（断依赖/高延迟）
每半年一次全链路预案演练（跨团队）

5.2 复盘写法 ​

text
发生了什么（时间线）→ 为什么发生（根因）→ 怎么发现（监控）→ 怎么恢复（动作）→ 改进项（有 owner 有截止）

复盘的三个坑：只写"加强监控"这种空话、追责不追因、改进项没有 owner 和日期。改进项要能落到具体改动。

六、自检清单 ​

  • [ ] 关键故障都有预案，runbook 与告警联动
  • [ ] 回滚链路每月演练过，5 分钟内可完成
  • [ ] 高风险功能有开关 + 灰度，回滚兜底
  • [ ] 数据库迁移向前兼容，回滚不炸
  • [ ] 每次故障/演练有复盘，改进项有 owner 和截止

七、常见误区 ​

误区事实
"演练会搞乱生产"受控、可终止、小范围注入是演练的纪律
"预案写一次就够"系统在变，预案要随发布更新
"回滚就是万能"有状态/迁移/开关组合才构成完整防线
"复盘=写报告"没有落到具体改进项的复盘没有价值
"小团队不用演练"人越少越该演练，出事时能救的是预案

八、动手练习 ​

练习 A：写一份 runbook ​

给自己负责的最关键服务写一份故障预案，覆盖"信号、响应、第一步缓解、升级条件"四项。

练习 B：做一次回滚演练 ​

挑一个无状态服务，发一个"故意坏"的版本，按预案 5 分钟内回滚，记录时间线并复盘。

练习 C：注入一次高延迟 ​

在准生产环境给一个依赖注入 2 秒延迟，验证超时/熔断/降级是否符合设计，输出结论。

相关文档 ​

本区 ​

其他域 ​