技术复盘方法：把失败写进可检验的证据链

九月二十三号，南京。产学研联合评审会散场，走廊里有人问：复盘会为什么总开成追责会？我当时没答好。现在补上：把复盘从“经过陈述”拉回“证据链与决策更新”，很多争执会自然降噪。

先别急着找根因：复盘输入常被污染

技术复盘的第一道坎不是方法，是输入。值班记录、告警、日志、指标、变更单、代码提交、工单、交接班消息，它们的时间基准可能不一致。有人记得是十点零五分，监控显示十点零七分，日志又落在另一台时区没对齐的机器上。差两分钟，因果链就可能接错。 所以复盘前先做证据盘点：哪些是原始记录，哪些是二次描述，哪些只是推断。说白了，先把“看见的”和“猜到的”分开。 事实层、推断层、决策层必须分开写。事实层只放可复核的记录；推断层写假设与置信度；决策层写当时为什么那样选。三层混在一起，复盘会就会变成各说各话。反例很常见：只凭会议回忆确定根因，最后修的是症状，真正的触发条件仍藏在变更窗口里。 分布式系统故障复盘日志时间线证据链图 还有一个限制条件：高干扰系统不可能等证据齐全再复盘。此时可采用“分段冻结”——先固定关键时间窗的日志与指标，余下证据后续补入。复盘报告不必一次封版，但证据索引要能追溯。

因果图要能被打脸：反事实检验有边界

五问法好用，但容易把复杂系统压成单线程故事。更稳妥的做法是画因果图：触发条件、放大机制、防御失效、人为决策各占节点，边上标注证据来源。然后做反事实推演：如果某次变更回滚，如果告警阈值提前十分钟，如果降级开关可用，结果会怎样。 反事实不是写小说，它要能被下一次演练或数据回放检验。无法检验的反事实，只能标为待验证假设，不能直接写成结论。复杂系统里多因耦合是常态，根因唯一化会带来组织学习偏差：大家以为修掉一个点就安全了，实际只是把风险挪了位置。 技术复盘会议白板因果图与反事实推演场景 这里有个边界：安全关键系统不宜做真实反事实试验，只能用仿真、故障注入和灰度回放替代。仿真结果也要标注保真度，避免把模型结论当成现场事实。

组织记忆不是报告库：写入、索引、过期

组织记忆不是报告库：写入、索引、过期 复盘报告最怕沉睡。写入组织记忆时，少写抒情总结，多写可检索标签：故障模式、触发条件、影响面、缓解动作、验证指标、责任人。索引要能让后来者按“现象”找到案例，而不是按部门或日期翻文件夹。 复盘产出应落到下一次的约束上：检查单、门禁、演练脚本、容量阈值、回滚条件。没有约束的复盘，只是文档。过期机制同样重要：旧案例里的架构前提可能已变，定期标记失效比反复引用更诚实。风险是过度形式化——模板越厚，填表越像仪式。轻量模板加证据附件，通常比长报告更可持续。

验证与风险：别让复盘变成指标游戏

验证与风险：别让复盘变成指标游戏 验证复盘是否有效，不看报告字数，看下一次系统行为是否改变。可观察的信号包括同类变更的拦截率、演练中降级路径的通过率、平均定位时间的变化。指标要成组看，单看一个数容易被游戏化：为了降低平均修复时间而提前关闭告警，就是典型反例。 趋势上，日志聚类与异常检测能辅助复盘，但因果审查仍需人工完成。模型能指出“哪里异常”，不能替代“为什么当时这样决策”。复盘的质量，最终由下一次系统行为来裁决。