事故复盘方法论

2 minIntermediate2026/6/14

Blameless Postmortem、5-Whys根因分析与复盘报告。

1. Blameless Postmortem

1.1 核心原则

“Blame the process, not the person.” — 无责复盘

原则说明
无指责关注系统和流程缺陷
全透明复盘文档全员可见
学习导向目标是改进而非追责
行动导向每个发现都要有改进行动

1.2 为什么无指责

  • 指责导致隐瞒问题
  • 大多数事故是系统性问题而非个人失误
  • 心理安全感是高效团队的基础

2. 5-Whys根因分析

2.1 方法

连续问5次”为什么”,从表象追溯到根本原因:

问题: 网站响应超时
为什么? → 数据库查询慢
为什么? → 缺少索引
为什么? → 新增查询未添加索引
为什么? → 代码审查未检查索引
为什么? → 缺少数据库查询审查清单

2.2 注意事项

注意说明
不要指向个人”因为张三忘了”不是根因
不要停在太浅层至少追问3层
不要过度深挖5层通常足够
多条路径可能有多个根因

3. 复盘报告

3.1 报告模板

# 事故复盘: [标题]

## 基本信息

- 事故时间:
- 持续时长:
- 影响范围:
- 严重级别:
- 值班工程师:

## 时间线

| 时间  | 事件     |
| :---- | :------- |
| HH:MM | 告警触发 |
| HH:MM | 开始排查 |
| HH:MM | 确认根因 |
| HH:MM | 实施修复 |
| HH:MM | 服务恢复 |

## 影响评估

- 受影响用户数:
- 业务损失:
- 数据影响:

## 根因分析

### 直接原因

### 根本原因

(5-Whys分析)

## 改进行动

| 编号 | 行动 | 负责人 | 截止日期 | 优先级 |
| :--- | :--- | :----- | :------- | :----- |
| 1    |      |        |          | P0     |
| 2    |      |        |          | P1     |

## 经验教训

### 做得好的

### 需要改进的

### 幸运的地方

3.2 复盘会议

1. 主持人介绍事故概况 (5min)
2. 值班工程师讲述时间线 (10min)
3. 集体讨论根因 (15min)
4. 制定改进行动 (10min)
5. 总结经验教训 (5min)

4. 复盘文化

要素说明
及时性事故后48小时内完成复盘
全员参与相关人员都应参加
文档公开复盘报告存档可查
跟踪闭环改进行动必须落实
定期回顾季度回顾复盘改进效果