线上问题发生后，复盘常会追问为什么当时没发现、没提前提醒，或者为什么选了这个方案。这些需要问，不过如果一直围绕某个人本来应该做什么，容易漏掉当时实际有什么信息、受到哪些限制。
结果已经发生以后，人会自然地觉得线索十分明显。真正需要还原的，是结果尚未发生时，参与者面对的是什么。
当时知道什么
复盘首先应该区分事后事实与当时信息。
现在知道配置会引起故障，不代表设计时就能确认，事后看清了完整调用链，也不代表当时每个人都掌握全部依赖。
需要重新列出当时可获得的信息：需求怎样描述，历史数据是多少，类似方案是否运行过，监控暴露了什么，还有哪些信息当时不存在。
如果关键事实当时已经存在，却因为检查不足没有被识别，这是可以改进的判断问题。如果事实只能在事后获得，就不能用今天的确定性要求昨天的人提前知道答案。
当时受到什么约束
技术方案从来不是只在正确与错误之间选择。
上线时间、可用人员、旧系统兼容、外部依赖和迁移成本都会影响决定。有时团队知道一个方案不够理想，仍然因为时间和风险选择它。这不一定意味着决定错误，但应该确认当时是否明确记录了代价。
复盘时把约束重新列出来，才能判断下一次应改变哪一项条件。若问题来自排期不合理，增加一条代码规范没有帮助，若风险来自信息没有同步，只要求开发更加谨慎也很难奏效。
谁参与了判断
复杂项目很少由一个人独立决定。
产品确定目标，技术评估实现，测试判断覆盖范围，负责人平衡时间和资源。最后的方案可能经过多轮讨论，也可能在一次临时沟通中仓促确定。
复盘需要还原决策过程，而不是把结果压缩到最后执行的人身上。谁提供了什么信息，分歧如何解决，风险由谁接受，都应该尽量清楚。
这样做并非分摊责任，而是找到系统真正缺少的机制。否则，每次复盘都以个人“以后注意”结束，相似问题仍会在另一位同事身上重演。
风险是否被看见并接受
并非所有风险都能在上线前消除。
影响较小的风险可以通过监控和回滚应对，发生概率低、解决成本又高的，团队可能决定暂时接受。复盘时还要确认这些风险讨论过没有，出了问题准备怎么办。
如果风险已经被识别并由相应角色接受，复盘重点应放在原有判断是否合理。如果风险从未进入讨论，则要检查信息收集、评审和升级机制为什么失效。
个人责任仍然存在
强调决策条件，不是为了否认个人责任。
有人遗漏了本应完成的检查，有人知道风险却没有同步，有人在缺少依据时作出了过度承诺，这些都需要准确说明。只是个人问题也应该具体到行为，而不是用“责任心不足”概括一切。
具体问题才有可能形成具体改进：增加检查项、调整权限、补充监控、明确决策人，或者让重大风险留下记录。
复盘最终要改变条件
一次有效复盘不必找到唯一责任人，也不一定能得到完整根因。但它至少应该让下一次面对相似问题时，团队拥有比上一次更多的信息和更好的条件。
如果会议最后只留下“加强意识”“提高重视”，通常意味着问题仍然没有被还原清楚。
把当时的信息和选择说清楚，才知道下一次该补哪项检查、改变哪条约定，不必每次都停在提醒大家以后注意。