技术复盘（Postmortem）不是事故后的”甩锅大会”，而是把一次故障转化为团队长期资产的关键动作。故障不可避免，但能否从故障里长出监控、流程和文化，取决于复盘做得好不好。本文给出可落地的 Postmortem 模板、时间线写法与组织节奏，帮你把踩过的坑变成别人不用再踩的护栏。
很多团队把复盘等同于”写事故报告”，结果文档归档后再没人看，同样的故障三个月后换个人又踩一遍。真正的复盘有清晰产出：一份结构化的时间线、一张根因分层图、以及 2–3 条可验证的改进项。它服务于未来，而不是审判过去。
一、为什么技术复盘值得专门做
1. 复盘的对象是系统，不是人
健康的工程团队默认”人都会犯错，问题出在系统没拦住错误”。一个运维凌晨手滑执行了错误的删除命令——这不应该靠”以后小心点”来避免，而应该靠权限分级、二次确认、操作审计来避免。复盘追问的是”系统为什么放行了这个危险操作”，而不是”这个人为什么这么笨”。把矛头指向系统，团队才敢在复盘会上说真话。
2. 复盘产出的是”护栏”，不是”检讨书”
一篇好的 Postmortem 结尾一定挂着改进项（Action Items），而且每条都能被验证：谁负责、什么时候完成、怎么证明它生效。比如”增加数据库主从延迟监控，超过 5 秒告警”就比”加强数据库稳定性”强一百倍。护栏的价值在于，当下次同类触发出现时，系统自己就把风险挡在门外。
二、一份合格的 Postmortem 长什么样
结构上，推荐固定为七个区块：摘要、影响面、时间线、根因、修复过程、改进项、经验沉淀。前五个还原事实，后两个产生资产。下面是一份可直接抄的模板：
# 事故复盘：订单服务写入超时（INC-2026-0831）
## 摘要
2026-08-31 02:14 起，订单创建接口 P99 从 120ms 飙升至 8s，错误率 12%，
持续 26 分钟后自动恢复，03:10 人工确认止血。
## 影响面
- 影响用户：约 3.2 万笔下单请求，其中 3800 笔失败需重试
- 业务损失：估算 GMV 影响约 ¥X（待财务核算）
- 关联系统：支付回调、库存扣减短暂阻塞
## 时间线
见下方 Timeline 区块（精确到分钟）
## 根因
直接原因：慢 SQL 全表扫描；深层原因：缺索引 + 无慢查询告警
## 修复过程
02:40 kill 阻塞会话；02:55 加复合索引；03:10 监控恢复
## 改进项
1. [P0] DBA 在 48h 内补齐订单表复合索引（owner: 张三）
2. [P1] 一周内接入慢查询告警，>200ms 持续 1min 即报（owner: 李四）
3. [P2] 两周内对核心表做索引评审（owner: 王五）
## 经验沉淀
把"索引评审"纳入发版前检查清单，避免同类问题反复。三、根因要分层，别停在”直接原因”
绝大多数故障都有三层原因，只写第一层等于没复盘。比如一次缓存雪崩：直接原因是大量 key 同时过期；间接原因是过期时间没打散；深层原因是发布流程没有对缓存预热做校验。只处理直接原因，下次换种姿势照样崩。下面这张分层表建议直接贴进复盘模板：
| 层级 | 要回答的问题 | 典型例子 | 改进落点 |
|---|---|---|---|
| 直接原因 | 这一刻发生了什么 | 慢 SQL 拖垮连接池 | 紧急止血 / 临时限流 |
| 间接原因 | 为什么会发生 | 缺复合索引、没预热 | 加索引 / 写脚本 |
| 深层原因 | 为什么系统允许它发生 | 发版无缓存校验、无告警 | 流程 / 监控 / 文化 |
四、时间线怎么写才不翻车
时间线必须精确到分钟，且区分”发生时间”和”发现时间”——两者之间的差值就是你的可观测性盲区。用结构化格式写，比写散文强：既能机器解析，也方便事后统计 MTTR。示例：
timeline:
- t: "02:14" event: "订单接口 P99 开始上升" source: 监控告警
- t: "02:21" event: "错误率突破 5% 阈值" source: APM
- t: "02:33" event: "值班被电话叫起" source: 告警平台
- t: "02:40" event: "kill 阻塞会话，错误率回落" source: DBA 操作
- t: "02:55" event: "补充复合索引" source: DBA 操作
- t: "03:10" event: "指标全部恢复正常，确认止血" source: 监控看板
# MTTR = 发现(02:21) -> 止血(03:10) ≈ 49 分钟
# 盲区 = 发生(02:14) -> 发现(02:21) = 7 分钟（需压缩）五、复盘会的组织节奏与禁忌
1. 24 小时内开，30 分钟收
复盘会拖得越久，记忆越模糊、情绪越防御。最佳窗口是故障后 24 小时内，会议控制在 30 分钟：前 10 分钟过时间线和根因，中间 10 分钟定改进项 owner 和 deadline，最后 10 分钟同步结论。文档在会前就写好初稿，会上只做确认和拍板，不要现场从零拼。
2. 三不原则：不追责、不防御、不空谈
- 不追责：除非是主观恶意或严重违反已明示的红线，否则默认”系统问题”，聚焦改进；
- 不防御：当事人不解释”我当时没办法”，而是说明”系统当时缺什么能力”；
- 不空谈：每条改进项必须有人、有期、可验证，散会即建跟踪单，一周后回看。
六、把复盘沉淀为可复用的资产
复盘最怕”写完即归档”。要让它变成资产，有三个抓手：① 建故障模式库，同类根因合并，新人不看血泪史也能避坑；② 把高频改进项反哺进发版检查清单与代码评审（可对照 代码评审文化：高效 CR 落地实战指南 把”是否含监控/回滚方案”列为必查项）；③ 定期做技术分享（参见 技术分享怎么做才有效：工程师知识沉淀指南），让一次故障的教训覆盖整个团队。再往前一步，这些沉淀会和 技术债工程决策、技术选型决策矩阵、源码阅读方法 一起，构成团队工程能力的护城河。流程层面，把复盘动作接进 GitHub Actions 的发版流水线，事故单自动关联发布版本，根因追溯一键可达。
小团队可以从”每次 P1/P2 故障必写 Postmortem”这一条铁律起步，不必追求完备。关键是让复盘成为习惯而非负担——文档轻、会议短、改进可验证。今天就可以挑最近一次故障，用上面的模板写一份，把它的根因分层和两条改进项填进去，散会前定好 owner。
七、小结
技术复盘（Postmortem）的终极目标，是让同一个故障只发生一次。做到三件事即可起步：对象指向系统而非个人、根因分三层别停在第一层、改进项必须有人有期可验证。时间线精确到分钟、会议 30 分钟收口、文档反哺检查清单与分享。当复盘成为团队肌肉记忆，故障就从”危机”变成”免费的培训费”——你花的每一分钟，都在给未来的自己买保险。
