复盘如果只写“增加监控、加强测试”，下一次故障仍然可能按相同方式发生。有效复盘需要区分事实、推断和未确认问题，并把改进变成可验证的责任项。
先还原时间线与业务影响
记录最早异常、首次发现、开始处理和恢复的时间，以及受影响的业务范围。统一时间基准，保留日志与发布记录。不要为了让过程看起来完整而补写没有证据的时间点。
区分触发因素与放大条件
一次错误配置可能触发故障，缺少兼容校验、重试放大和告警延迟可能扩大影响。复盘不应只寻找最后操作的人，而要解释系统为什么允许问题传播。
改进项需要验收办法
例如补充某条契约测试、限制特定重试、增加业务积压告警，并明确责任人与验证场景。泛泛的“优化架构”无法安排优先级，也难以证明完成。
验收让其他成员重走排查路径
用保留资料定位已知问题，检查文档、仪表盘与运行手册是否足够。改进是否有效，应在后续演练或发布中验证，而非仅以工单关闭结束。
常见问题：没找到唯一根因就不能结束复盘吗？
可以记录确定事实、候选原因和待验证项，避免把猜测包装成结论；未完成调查需要明确后续责任。
技术参考：Google SRE：故障复盘。具体接口与配置请结合使用版本核对。
将评估落实到你的系统
如果你的团队正遇到类似问题，可以从一条关键业务路径开始，整理现状、证据与约束，通过系统架构诊断明确优先级、候选方案和验证范围。