故障复盘怎么开才不变成扯皮会

故障复盘是 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 里就排进季度演练计划，否则永远不会做

教训：复盘不是要"惩罚谁"，是要让系统变得"傻瓜也能正确操作"。