故障复盘怎么开才不变成扯皮会
故障复盘是 SRE 的核心活动。但很多公司的复盘开成了"找责任人大会"，效果反而是负的。本文是我组织过 30+ 次复盘的总结。
反模式：上来就问"谁的责任"
最常见也最毁文化的开法。一旦定责，大家就开始：
- 推诿（不是我）
- 隐瞒细节
- 不愿暴露真实问题
下次出事，没人敢主动暴露。
正确：blameless 复盘
铁律：对事不对人。
具体做法：
- 不出现具体人名，只说"操作人"、"开发"、"值班"
- 不评价"做得好/不好"，只复盘"发生了什么"
- 重点是"如果再来一次怎么不踩这个坑"
标准议程（90 分钟）
1. 时间线（30 分钟）
按分钟级别列出所有事件：
14:32 - 监控告警 "API 5xx > 5%"
14:33 - 值班 A 收到告警，开始查 dashboard
14:35 - 发现是 db-1 CPU 跑满
14:38 - 重启 db-1 失败
14:42 - 切到 db-2 (slave 提升)
14:45 - 业务恢复
时间线要细到分钟。先列事实，不下结论。
2. 影响范围（15 分钟）
- 多少用户受影响
- 业务损失（订单数、收入）
- 持续时长
量化的目的：知道下次值得花多大力气避免。
3. 根因分析（30 分钟）
用 5 Whys：
Why 1: 为啥 5xx 增多？→ 因为 db-1 CPU 满
Why 2: 为啥 CPU 满？→ 因为有个慢查询
Why 3: 为啥慢查询出现？→ 因为新发的代码没加索引
Why 4: 为啥没加索引？→ 因为 review 没看出来
Why 5: 为啥 review 看不出？→ 因为没 SQL 静态分析工具
根因往往不是"操作失误"，是"流程或系统没有兜住"。
4. Action items（15 分钟）
每个 action 必须有：
- 具体行为（不要"加强 review"这种空话）
- 负责人
- deadline
- 验收标准
例：
- ✅ "运维平台加 SQL 静态分析 plugin，未使用索引的 SQL 不允许 merge。@张三，2 周内完成。"
- ❌ "加强代码 review。@团队。"
几条铁律
别开晚于事故 1 周
记忆模糊 + 当事人调岗，越往后越没价值。
不超过 8 人
人多了变成讨论会。核心是：当事人 + 直接相关方 + 主持人。
主持人不是当事人
否则容易自我辩护。主持人最好是无利害关系的第三方。
一定要写文档
口头复盘等于没复盘。文档至少包含：
- 时间线
- 影响范围
- 根因
- Action items 和进度
存到 wiki，下次类似故障第一时间找出来对照。
文化建设
复盘文化好不好，看一个指标：有人主动暴露"差点出事"吗？
- 如果有，说明大家信任"暴露问题不会被骂"
- 如果没有，复盘文化是死的
我们公司有个机制叫"近失"（near miss）报告——你没造成故障但差点造成的，写下来给团队学，奖励而非惩罚。
一个反例
我之前公司有次大故障，定责到一个新员工。他后来辞职了。3 个月后类似故障再发——因为根本问题（缺监控）没解决，新员工只是触发器。
如果当时不定责而是修流程，第二次故障就不会发生。
几个 action 经常被忽视
- 更新 runbook：故障定位过程里发现的"哪个步骤花了 10 分钟才查到"，写进 runbook 下次 1 分钟
- 加监控：被告警发现的故障是"还行的"，被用户投诉发现的是"灾难"。每次复盘看监控覆盖
- 故障演练：写到 action 里就排进季度演练计划，否则永远不会做
教训：复盘不是要"惩罚谁"，是要让系统变得"傻瓜也能正确操作"。