故障复盘：blameless post-mortem

blameless 是底线

"无指责复盘"（blameless postmortem）的意思不是：

❌ 不分析错在哪
❌ 大家相安无事

而是：

✓ 关注系统、流程、工具为什么允许这种错误发生
✓ 假设任何处于同样位置、有同样信息的人都会做出类似决策
✓ 让人愿意暴露真实经过——只有真实信息能产生真实改进

反过来：找人背锅的复盘 → 下次故障会被掩盖 / 缩小 → 系统性问题永远改不掉。

一份 postmortem 的标准结构

# Incident #2026-04-12: 付款 API 大量 5xx
**作者**：xxx
**状态**：草稿 / 评审中 / 已归档
**严重等级**：SEV-2

## 摘要（TL;DR）
2026-04-12 14:23–15:48 期间付款 API 返回 5xx 比例升至 35%，
影响约 N 万次交易。根因是 X，修复方式是 Y。

## 影响
- 持续时间：1h25m
- 影响请求数 / 用户数
- 业务影响（金钱损失 / 用户投诉数 / SLO 燃烧）

## 时间线（用户时区）
14:23 监控 fire：错误率 P1 告警
14:24 on-call ack
14:30 定位到 db 连接池耗尽
14:45 临时扩 connection pool 缓解
15:48 根因 commit 回滚后完全恢复

## 根因分析
- 直接原因：xxx
- 触发条件：xxx
- 为什么没被防住：xxx
- 为什么没更早发现：xxx

## 哪些做对了
- 监控触发及时
- on-call 5 分钟 ack
- 缓解步骤准备过演练

## 哪些做得不够
- 触发条件 1 周前 PR review 时被忽视
- runbook 没覆盖该场景
- 故障缓解后到完全恢复差 1 小时

## 行动项
| # | Action | Owner | 时限 | 状态 |
|---|---|---|---|---|
| 1 | 加 connection pool 用量监控 | @alice | 2026-04-25 | TODO |
| 2 | DB schema 改动加 review 必跑 checklist | @bob | 2026-05-10 | TODO |
| 3 | 完善 runbook 加这种故障应对 | @carol | 2026-05-05 | TODO |

5 Whys 之外的方法

经典 5 Whys 简单但容易只追单一根因——多数生产故障是多因素叠加。

更系统的视角：

Causal Chain：列出导致故障的"因果链"，每个节点都标"为什么没被防住"
Adaptive Capacity Lab 的方法：关注系统适应性、人因、协作链路
Etsy 的 Just Culture：把人的决策放在当时的语境下评估，而不是事后视角

复盘的几个误区

误区	改
"都是 X 改了 Y 导致"	系统为什么允许 X 改 Y 又部署到生产
只列时间线没分析	时间线是骨架，分析是肉
没有具体行动项	改进会被时间冲淡
行动项没人跟进	6 个月后再回顾时全是"TODO"
复盘文档存到 Wiki 就忘	定期回顾历史故障，看模式

行动项的两个分类

预防类（避免再发）：加监控 / 加测试 / 改架构
缓解类（再发也能更快恢复）：完善 runbook / 加自动化恢复

理想是两类都有——只有预防没缓解 = 还会再发；只有缓解没预防 = 同一个错每月一次。

严重等级（SEV）

可以用 1–4 或 1–5：

SEV-1：影响公司业务、所有用户、有数据丢失
SEV-2：影响主要服务、大量用户
SEV-3：影响部分功能、部分用户
SEV-4：内部工具问题，用户无感

每级触发不同流程：SEV-1 通常强制写复盘；SEV-3+ 由团队自决。

公开还是私密

理想：全公司可见，让别的团队也能学到（含敏感数据脱敏后）。现实：法律 / 客户合同有时限制——内部清晰版 + 对外简版的两份是常见做法。

复盘频率

当下（24–72 小时内）：写草稿趁记忆新鲜
一周内：评审会议，团队 + 利益相关方过一遍
季度：把多个事故合起来看模式
年度：从 SLO / 故障数据看趋势