事故复盘后的改进项，多少真正落地了？聊聊你们团队"闭环"的判断标准

背景

先抛一个我自己被戳到的数字：我带过的团队里，P1 以上事故平均每月 1.2 起，每起复盘平均产出 6–8 条改进项；但半年后回看，真正"可验证地生效"的不到 40%。剩下的不是没人做，而是三类：a) 做了但没有对照数据证明有效；b) 做了但被后续需求挤掉；c) 根本没做，复盘文档躺在 Wiki 里吃灰。

举个我亲历的具体例子：去年一次大促前，因为某次 DB 连接池抖动 P0，我们定了 3 条改进项——"连接池参数进配置中心"、"P99 抖动告警阈值重标定"、"每周一跑一次 800 QPS 压测回归"。半年后审计：第一条落地了但没人验证过它真的能让变更在 5 分钟内回滚；第二条告警阈值调过两轮，调完之后到底比之前少报了多少、漏报了多少，没人统计过；第三条压测脚本写完了，但 CI 里挂了 4 个月没跑——因为没有 owner。复盘文档里那行"已闭环"，其实只是"已写完"。

常见分歧 / 几种做法

• 做法 A：纯 owner + 截止日期。每条改进项挂一个人 + 一个 due date，到期检查。问题是"到期"不等于"生效"，而且 owner 换人就断。
• 做法 B：改进项进 backlog，和其他需求一起排。好处是承认资源有限，坏处是事故改进项经常被功能需求挤掉，优先级失真。
• 做法 C：改进项必须有"可验证的验收条件"。比如"压测 800 QPS 下 P99 < 50ms 连续 3 次"才算闭环，而不是"脚本已交付"。这条最严，但写验收条件的成本不低。
• 做法 D：把改进项和 SLO 绑定。改进项不再单独跟踪，而是看它覆盖的 SLO 指标有没有改善。好处是天然有数据，坏处是很多改进项（流程类的）很难映射到 SLO。

我的倾向与理由

我倾向 C + D 组合，且有一条硬规则：复盘改进项的"闭环"必须附带一段可复现的验证记录（一段压测命令 + 输出、一条告警规则的前后对比、一次演练的时间线），否则不算闭环。理由：

1. 事故改进项的本质是"用一次性成本换长期风险下降"，没有验证记录就等于把风险降不降交给运气。
2. 可复现的验证记录本身就是给下一个 on-call 的"防呆文档"，比复盘文档本身更有用。
3. 这条规则逼着写改进项的人想清楚"怎么证明它生效"，而不是"怎么把它写进文档"。

代价是复盘会开得更长（我实测每起事故多 30–45 分钟），但我觉得这个成本远低于"改进项失效后再出一次 P0"的成本。

想听大家聊的

1. 你们团队判断一条改进项"已闭环"的最低标准是什么？是 owner 口头确认，还是必须有数据 / 演练记录？
2. 有没有把"改进项落地率"本身当成一个团队指标在跟踪的？怎么算分子分母？
3. 流程类改进项（比如"变更窗口收紧到 10:00–18:00"）怎么验证它真的降低了风险？
4. 你们有没有遇到过"改进项本身是错的"的情况——复盘时定下来、执行了半年才发现当初根因判断就错了——这种情况你们怎么回滚改进项、又不让团队士气崩掉？

欢迎带具体案例来，越具体越好；我也想把社区里大家的做法整理成一篇"改进项闭环判据清单"发出来。