事后复盘生成器

可进入评审的 Markdown

生成结果适合放进工单、PR 或设计评审。它应在实现开始前写清责任人、决策、证据和后续工作。

事故：重复退款尝试

规格缺口：
- 未定义重试行为
- 客服后台忽略 pending provider 状态

后续：
- 增加幂等验收标准
- 增加支付渠道超时 fixture

导出之后

把生成的复盘草稿当成起点，而不是最终答案。替换示例值，补证据，指定评审人，删掉团队不会维护的字段。

• 把输出放在实现工作旁边。
• 每条验收项都要映射到测试或评审证据。
• 不要粘贴密钥、客户数据或私有事故细节。

区分事实和解释

时间线里写可验证事实：告警时间、回滚时间、错误率、影响范围和沟通记录。根因和贡献因素再解释为什么这些事实会发生。

让影响可度量

不要只写“部分用户受影响”。尽量补上请求数、失败率、用户数、收入影响、SLO 消耗、数据损坏范围或客服工单数量。

根因保持机制化

好的根因解释系统如何失败，而不是谁犯了错。写清触发点、缺失的护栏、扩散路径、发现缺口，以及现有流程为什么没挡住。

把发现转成有责任人的行动项

每个行动项都应该有责任人、截止日期、跟踪位置和验证方法。“改进监控”不够好；“结账 5xx 超过 2% 持续 5 分钟时告警”才可评审。

发现

团队是从自己的监控、用户反馈，还是下游影响中知道事故的？下次应该由哪个信号更早触发？

缓解

是否存在明确的回滚路径、runbook、功能开关或熔断策略？如果没有，行动项应该提升响应速度，而不只是预防。

预防

哪份规格、测试、迁移检查、合约门禁或评审问题，本来可以在发布前发现这次问题？

弱行动项

改进发布检查，增加更好的告警。

这太宽泛，无法分配、验证或关闭。它没有说明哪个检查、哪个告警、什么阈值，以及什么结果能防止复发。

强行动项

新增迁移门禁：禁止没有默认值或回填计划的 NOT NULL 列变更。责任人：数据库平台。截止：2026-05-15。验证：CI 中的失败示例迁移。

这个行动项具体、有负责人、有日期，并且可以测试。

先开一次短评审会

用草稿和事故响应人员、客服、产品、工程一起核对事实。会议目标不是追责，而是校准时间线、影响范围和证据来源，把没有日志或客户证据支撑的猜测从复盘中移除。

行动项必须进入任务系统

复盘文档不是任务管理工具。每个行动项都要复制到团队 tracker，写清负责人、截止日期、验证方式和事故链接，后续才能确认它真的降低了复发概率或缩短了检测时间。

到期后回看一次

在行动项截止日期后安排一次复查。如果某项只被标记完成却没有测试、监控或 runbook 证据，应重新打开，或拆成更小但可验证的改进项。

不参加会议也能看懂事故

读者应该能从文档中理解什么失败了、谁受影响、团队如何发现、如何缓解、根因证据来自哪里，而不需要翻内部聊天记录。

后续行动可以被审计

每个行动项都应有任务链接、负责人、截止日期和验证方式，方便之后检查它是否真的完成，以及是否降低了复发概率或检测时间。

把事实和解释分开

时间线只放带时间戳的事实，根因分析再讨论故障如何扩散。这样复盘时不会把“发生了什么”“为什么发生”和“接下来改什么”混在一起。

行动项进入跟踪系统

Markdown 不是后续工作的唯一记录。把每个行动项复制到团队 issue 系统里，补上负责人、截止时间、验证方式和复盘链接，避免会议结束后失去追踪。

什么时候写复盘？

事实还新鲜时就开始草稿，但不要在日志、客户影响、时间线和行动项责任人核实前关闭。仓促复盘通常会留下模糊行动项。

行动项多少条合适？

通常两到五条。更多时往往说明团队在罗列所有可能改进，而不是选择最能降低复发或缩短发现时间的少数改变。

面向无责复盘

表单把时间线、影响、发现、响应、根因、经验和行动项分开，避免复盘把事实、解释和后续工作混成一段模糊说明。

按可行动性复查

生成复盘会检查是否说明故障扩散机制、发现和缓解缺口，以及行动项是否有负责人、截止日期和验证方式。

由编辑维护

作者与编辑：Daniel Marsh。复查流程：编辑政策。纠错与工具问题：联系。最近复查：2026 年 4 月 28 日。