postmortem

无责复盘模板与改进项闭环

补充说明

复盘的目标是改进系统，不是追责个人。好的复盘写清影响、时间线、直接原因和促成条件，并把改进项变成有 owner、截止时间和验收标准的工单。24–72 小时内出初稿，5 个工作日内评审。

“加强培训”“注意操作”不是改进项；能落到机制、监控、自动化或流程上的动作才算。

常用示例

复盘模板：

# INC-2026-1018 支付回调失败复盘

## 摘要
支付回调处理服务因连接池耗尽，导致 12% 订单状态更新延迟 38 分钟。

## 影响
- 时长：14:02–14:40 UTC
- 用户：约 3,200 笔支付
- 收入：无直接损失，2 笔重复退款已修正
- SLO：消耗 38 分钟错误预算

## 时间线（UTC）
14:02 告警触发
14:05 IC 接管，定级 P1
14:09 回滚 payment v2.3.1
14:22 回调成功率恢复
14:40 积压清空，关闭事故

## 根因
直接原因：新版本将下游超时从 2s 调到 30s，连接池被占满。
促成条件：配置模板默认值变更未评审；连接池饱和度没有告警。

## 改进项
| 类型 | 动作 | Owner | 截止 | 验收 |
|---|---|---|---|---|
| prevent | 超时配置纳入模板测试 | @pay | 2026-10-25 | CI 拦截超时 > 5s 的配置 |
| detect | 连接池饱和度 > 80% 告警 | @sre | 2026-10-21 | 演练触发告警 |
| mitigate | 回滚脚本支持一键切流 | @platform | 2026-11-01 | 演练 5 分钟内完成 |

用 5 Whys 找促成条件，不要停在“人为失误”：

现象：回调处理 5xx 升高
1. 为什么：下游请求超时
2. 为什么：连接池耗尽
3. 为什么：新版本超时从 2s 调到 30s
4. 为什么：配置模板默认值被修改且未评审
5. 为什么：模板变更没有对应测试和代码评审规则

改进项优先级规则：

易错点与排错

• 复盘变成追责：当事人隐瞒细节，真正原因永远查不到。
• 只写直接原因，不写促成条件（监控缺失、评审缺失、默认值不合理）。
• 改进项没有 owner、截止时间和验收标准，最后不了了之。
• 改进项写成“加强培训”“提高意识”，无法验证是否完成。
• 只修当前服务，不横向排查使用同一模板或同一依赖的其他服务。
• 时间线时区混乱；统一用 UTC 并标注。
• 复盘拖过一周，日志和记忆丢失；24–72 小时内完成初稿。
• 改进项没有跟踪机制；用统一工单标签并每月回顾未完成项。

读完自测

合上页面，先回答，再展开对照。

1. 无责复盘为什么能提高而不是降低系统可靠性？
2. 一个好的改进项至少包含哪四个要素？
3. 为什么“加强培训”通常不是合格的改进项？

相关条目

• incident-command — 事故指挥流程
• incident-response-playbook — 响应手册
• runbook — 把结论落成可执行步骤
• toil — 削减重复性改进工作
• sre-oncall-checklist — 复盘检查项