工作机制
团队根据日志、仪表盘和聊天记录重建时间线，用用户影响衡量严重程度，并识别多个促成因素，而不是寻找单一元凶。行动项必须有负责人、截止日期和跟踪记录，避免不了了之。评审会分享结论，文档发布到全工程可检索的位置。
适用场景与取舍
任何违反 SLO、影响客户或暴露系统性缺口的事故都应写复盘；未造成后果的险情也值得在细节还清晰时复盘。小事故可使用轻量模板。与只开修复工单相比，复盘会记录检测和协调层面的失败，而不只是眼前的缺陷。代价是占用资深工程师时间，并可能产生超出团队消化能力的行动项；无指责不等于无责任，负责人仍要交付改进。
具体示例
一次部署了过期 TLS 证书，导致结算中断三十七分钟。复盘记录了检测延迟，安排负责人增加证书到期告警，并组织演练验证续期运行手册，所有行动项在两周内关闭。
常见误解与关联概念
复盘不必只写一个根因，复杂系统往往由多个条件共同导致；无指责保护的是坦诚报告，而不是放弃修复责任。复盘也不只用于重大事故，反复出现的小故障常常更有教学价值。事故指挥组织被复盘的响应，运行手册把结论转成可重复的缓解步骤，错误预算提供客观的复盘触发条件。