故障复盘必须产出「可执行产物」才算关单，你们团队的复盘报告是不是已经成了「一次性 PPT」？

【背景】 做了 3 年 SRE，复盘过不下 20 次线上故障，我有个越来越强的体感：复盘报告写得再漂亮，如果没变成代码 / 配置 / 告警，下次同类故障大概率还会来。

举两个我亲历的例子：

• 一次 Redis 大 key 把带宽打满，复盘报告写了 8 页，结论是「上线前必须做 key 大小预估」。三个月后另一个团队新业务又踩了同款坑——因为「预估」这件事没有工具兜底，纯靠人肉。
• 一次 GC 风暴导致 P99 飙 3 倍，复盘建议是「关注 Full GC 频率」。但没人真的把告警规则写出来，半年后另一台机器同样的现象，又是事后才从监控里翻出来。

复盘就像体检报告：报告本身不治病，治病的得是后续开的药方。

【常见分歧 / 几种做法】 我在不同团队见过三种风格：

1. 报告派：复盘就是文档，写清楚时间线 / 根因 / 改进项，改进项扔进 Jira 就完事。好处是轻量、不阻塞；坏处是改进项 90% 会烂尾，因为没人验收「改进项做完了没有」。
2. 流程派：复盘会必须开、改进项必须有人认领、必须有 deadline、必须有 reviewer。比报告派好一档，但 deadline 一过就没人追了，最后还是回到「文档归档」。
3. 代码派：复盘关单的前置条件是——必须至少产出 1 个可执行产物，比如一条告警规则、一个巡检脚本、一段熔断配置、一个 chaos 演练脚本，且合进主干 / 生效后才能 close 工单。

【我的倾向与理由】 我站代码派，但不是「什么都要代码化」。我的判断标准很简单：

• 如果根因是「人没注意」——那复盘必须产出「让机器注意」的东西（告警 / 埋点 / SLO 埋点 / 巡检脚本）。
• 如果根因是「配置错了」——那复盘必须产出「让配置写错时立刻被发现」的东西（配置校验脚本 / 基线检查 / CI 卡点）。
• 如果根因是「流程缺失」——那复盘必须产出「把流程固化到工具里」的东西（发布 checklist / 卡口 / 审批流）。
• 如果根因是「架构性缺陷」——那复盘至少产出「一段可执行的容量评估脚本 / 压测脚本」，让下次评估有数据。

一句话：复盘的产出物，必须让「下次同类故障」要么不发生，要么被机器在 1 分钟内发现。

但我也承认代码派有它的坑：

• 复盘出来的告警阈值如果不经过验证，可能误报满天飞，最后被值班同学一键静音，反而更危险；
• 「可执行产物」如果没有 owner，三个月后照样烂尾；
• 有些根因就是「业务逻辑写错了」，这种复盘产出的代码价值有限，硬凑一个脚本反而形式主义。

【想听大家在什么场景下怎么选】 特别想听三类同学的答案：

1. 你们团队复盘关单的前置条件到底是什么？是「文档归档 + Jira 建单」，还是「至少 1 个可执行产物已合入 / 生效」？
2. 复盘产出的告警规则 / 巡检脚本，有没有 owner 机制？怎么防止三个月后烂尾？（我们目前的做法是每个复盘产物挂一个「复盘 owner」+ 一个季度 review，但效果一般，想看看有没有更狠的机制）
3. 根因是「业务逻辑写错」这种「代码派」不太适用的场景，你们怎么让复盘不流于形式？

欢迎贴具体案例和具体做法，越具体越好——我特别想看「复盘产物 → 三个月后还在跑」的真实例子，这种社区里太少了。