从复盘中学习
复盘记录发生了什么，事故学习追问因为事故改变了什么。闭环包括重建时间线、识别促成因素、提出修复、分配负责人、验证完成，并把教训分享给不在现场的人。一个写出优秀文档却重复同类事故的组织并没有学习，只是记录。
促成因素而非单一根因
复杂故障很少有单一根因。要寻找使事故成为可能的组合：潜伏缺陷、缺失护栏、含糊的运行手册、监控盲区和压力下做出的决定。追问每道防线为何失效，而不是停在“人为错误”。人为错误通常是调查的起点而非结论。这种框架能在多个层面产生修复。
验证修复
行动项是一个假设：如果完成，会降低事故复发的可能性或影响。验证变更确实部署、告警在测试中确实触发、运行手册步骤确实有效。把完成度和有效性分开跟踪。例如，增加仪表盘不是修复，除非有人确认它显示了事故中缺失的信号。
超越团队分享与衡量
发布可读摘要、在工程论坛演讲，并把发现转化为培训和设计评审。未遂事件也值得同样对待，因为它们以更低代价携带教训。跨团队比较事故，寻找系统性模式：同样缺失的超时、同样不清的归属、同样危险的发布路径。跟踪故障模式复发率、行动项完成时间，以及响应者是否更快识别类似条件。例如，一个团队能在几分钟而非几小时内发现重复故障，即使代码路径仍在，也已经学到了东西。