Postmortem

解决什么问题：同一个事故不要发生第二次—— 没有 postmortem 的团队，每个事故都是"新的"；有了 postmortem，事故 = 系统改进的输入。

它是什么

Postmortem（事故复盘） 是在事故恢复后，对事故的系统性回顾—— 目的是找出根因（Root Cause）而非替罪羊，并把 "这次学到的教训"转化成"下一次不会犯的机制"。

事故发生 ──→ 应急恢复 ──→ 写 Postmortem ──→ 改进措施 ──→ 验证
   ↑                                                      │
   └──────────────── 闭环回到事故预防 ─────────────────────┘

SE@G Ch 24（"Postmortem Culture: Learning from Failure"）： "Blameless postmortems are the foundation of a learning organization. The goal is not to find who is at fault; it is to find why the system allowed the fault to cause harm."

V2 视角（V2 B5 + B7）：postmortem 是闭环的记忆机制—— 没有 postmortem，闭环"跑过就忘"；有了 postmortem，闭环 "每次跑都更聪明一点"。

关键属性

属性	值/含义
blameless	不追责个人，追系统设计缺陷
时效	事故后 1-3 天内出初稿，1-2 周内发布
结构	时间线 + 影响 + 根因 + 行动项
行动项	必须有 owner + 截止日期 + 验证标准
公开	全员可访问（除敏感信息外）
闭环	行动项必须被验证（再次发生 = 失败）
可量化	衡量"这次 postmortem 是否有效"
轻量	过度仪式化 = 没人愿意写

怎么用

场景 1：标准 Postmortem 模板

markdown

# 事故复盘：<标题>

## 摘要
- 时间：YYYY-MM-DD HH:MM ~ HH:MM
- 影响：XX% 用户 / XX 分钟 / XX 元损失
- 级别：P0 / P1 / P2
- 触发：<最初症状>

## 时间线（按分钟）
- HH:MM — 告警触发
- HH:MM — 值班响应
- HH:MM — 应急动作（扩容 / 回滚 / 限流）
- HH:MM — 服务恢复
- HH:MM — 关闭告警

## 根因分析（5 Whys）
1. 为什么：用户看到 5xx？
2. 因为：服务 B 调用服务 C 超时
3. 为什么：服务 C 慢？
4. 因为：数据库连接池耗尽
5. 为什么：连接池配置过低 + 流量峰值
→ 根因：**配置未根据历史峰值调整**

## 行动项
- [ ] A1：连接池自动扩容（owner: 张三，截止: YYYY-MM-DD）
- [ ] A2：增加连接池使用率告警（owner: 李四，截止: YYYY-MM-DD）
- [ ] A3：复盘下次同类峰值（owner: 王五，截止: YYYY-MM-DD）

## 学到的教训
- 教训 1：<抽象的、可复用的洞察>
- 教训 2：...

场景 2：Blameless 的具体做法

✗ 反例（找替罪羊）：
"张三没看监控，所以故障扩大了"
→ 个人责任 → 下次没人敢说 → 组织失忆

✓ 正例（找系统问题）：
"监控界面把告警藏在第 3 层菜单，值班没看到"
→ 系统设计问题 → 改界面 → 下次值班能看到

关键话术：用"系统允许了"取代"某人没做"—— "系统允许了一次误操作造成大面积影响" 比 "张三误操作" 更有价值。

场景 3：Postmortem 的闭环验证

发布 postmortem ──→ 排期行动项 ──→ 实施改进 ──→ 验证
                                              │
                                              ↓
                              同样的故障不再发生？ ── 是 → 成功
                                              │
                                              └─ 否 → postmortem 失效

失败标志：行动项一直挂着没完成、或者完成但没人验证、或者同类事故再次发生——任一发生 = 这个 postmortem 文化没建立起来。

常见误区

"找责任人"——错。Blameless 是 postmortem 的灵魂，找责任人 = 文化崩溃
"写完就归档"——错。行动项没 owner / 截止 = 形式主义
"只有大事故才写"——错。小的 near-miss 也要写——预防的成本远低于修复
"root cause = 最终原因"——错。5 Whys 要挖到可改的系统设计层，不能停在"人犯错"
"postmortem = 道歉信"——错。postmortem 是改进文档，不是情感宣泄

关键洞察

Postmortem 不是文档——是 L4 层的"学习记忆"。
没有 postmortem，每次事故都是孤立的；有了 postmortem，事故 = 团队集体学习的输入——系统会越跑越聪明。

Postmortem ​

它是什么 ​

关键属性 ​

怎么用 ​

场景 1：标准 Postmortem 模板 ​

场景 2：Blameless 的具体做法 ​

场景 3：Postmortem 的闭环验证 ​

常见误区 ​

关键洞察 ​

相关链接 ​