核心要点
无指责（blameless）：对事不对人，目标是改进系统而非追责个人
还原完整时间线：从触发、检测、定位到恢复的关键节点与耗时
用 5 Whys 挖到根因，区分直接原因与深层系统性原因
量化影响并产出可追踪的改进项，每项有明确负责人和截止期限
标准回答
无指责是前提
Postmortem 的核心文化是 blameless：聚焦「系统为什么允许这个错误发生」，而不是「谁犯了错」。否则大家会隐瞒信息，复盘失去价值。
结构化复盘内容
一份合格的复盘应包含：
- 事件摘要与影响（受影响用户数、时长、业务损失）；
- 时间线（触发 → 检测 → 响应 → 恢复，标注各阶段耗时）；
- 根因分析（用 5 Whys 层层追问，挖到系统性根因）；
- 检测与恢复评估（为什么没更早发现、恢复为何慢）。
沉淀改进项
每条改进项要可执行、有负责人、有截止日期，并跟踪闭环。把经验沉淀为监控告警、预案、自动化和 checklist，让同类事故不再复发。
对 ML 系统的特殊点
ML 事故常因数据漂移、特征管道异常、上游分布变化导致，复盘要关注数据与模型监控是否覆盖、是否有自动降级与回滚。
常见误区
⚠️ 常见踩坑
把复盘开成追责会，导致信息隐瞒；或只停在「直接原因」（如某次发布出错），不追问系统性根因，改进项无负责人和期限而不了了之。
追问
追问 1：5 Whys 分析时如何避免停在表面原因？
每一层「为什么」都要指向系统/流程而非个人操作。例如「服务挂了→因为内存溢出→因为输入数据量异常→因为上游没做限流→因为缺乏输入校验和监控告警」。停止条件是追到可通过工程或流程改进消除的系统性根因，而不是「某人忘了」这类个人归因。
追问 2：ML 模型线上掉点但没报错，怎么复盘？
这类是「静默失败」，重点查可观测性盲区。复盘时核对：是否监控了数据分布漂移、特征缺失率、预测分布和业务指标；告警阈值是否合理；是否有训练-服务一致性校验。根因往往是上游数据变化或特征管道异常。改进项通常是补齐数据/模型监控、设置漂移告警与自动降级。
延伸学习
与本题相关的知识库文章、术语、工具与行业资讯。