复盘改进项「逾期三个月不落地」，该追责谁？聊聊 postmortem 的最后一公里

先抛一个我亲历的场景，大家先看是不是眼熟。

去年 Q3 我们一个核心服务出了 P1：一个缓存击穿导致下游 DB 被打满，恢复花了 42 分钟。复盘做得很「标准」：时间线、根因、影响面、改进项，四样齐全。改进项一共 6 条，其中 3 条是「加布隆过滤器」「补降级开关」「把缓存预热做成发布前必检」，另外 3 条是监控、演练、文档。当时会议室里每个人都认领了 owner，我（SRE）认领了降级开关那条。

结果呢？三个月后我翻 Jira，6 条里只有 1 条（加监控）合入了主干。布隆过滤器那条 owner 换了一轮人，降级开关那条还在「待排期」，缓存预热那条干脆没人提了。更扎心的是：这半年里同一条链路又抖动了两次，虽然没到 P1，但每次 on-call 群里都出现了那句「这不就是上次复盘说的那个问题吗」。

我现在的感受是：复盘会本身不贵，贵的是复盘之后那 90 天。可我们好像只优化了「怎么开好会」，没优化「怎么让改进项真的落地」。

我观察到几种常见做法，各有问题：

1. 靠 owner 自觉 + 周报里提一嘴。问题：owner 被自己的日常需求挤掉，改进项优先级永远排不进 sprint。
2. 复盘改进项直接进 backlog 和正常需求混排。问题：和 40 个业务需求一起排队，P1 级别的改进项输给一个「文案优化」并不罕见。
3. 管理层定期 review 改进项状态（比如月度稳定性例会过一遍未闭环项）。问题：能起作用，但依赖一个「在乎这件事的人」长期在场，人一走就失效。
4. 把「改进项闭环率」做成团队 KPI。问题：指标会被博弈，大家开始把大项拆成 10 个小项快速关闭，闭环率好看，风险没动。
5. 干脆不追责，blameless 到底。我理解精神，但当改进项烂尾导致同类故障重复发生时，"blameless"有时候会被理解成"谁都不负责"。

我个人的倾向，供拍砖：改进项的落地责任不该压在 owner 一个人身上，而应该有一个「改进项守门人」的角色——不一定是 SRE，但必须是那个对系统稳定性有长期承诺的人；同时未闭环的 P0/P1 改进项，应该有一个硬性的「超时升级」机制（比如 30 天未启动自动升级到团队 lead，60 天升级到部门负责人）。我这么想的原因是：owner 负责的是「怎么改」，守门人负责的是「改没改」，两件事的能力要求完全不同，混在一起必然都做好不了。

但我也真的不确定这是不是治标。因为如果团队根本不在乎稳定性，守门人也会被架空；如果团队在乎，可能根本不需要守门人。所以想听听大家：

• 你们的改进项「烂尾率」大概是多少？（不点名，说个量级就行）
• 你们用上面 1–5 里的哪种，或者完全不同的姿势？效果如何？
• 如果改进项 owner 主动说「这个改完风险大于收益，建议降级为文档记录」，你们会接受吗？还是必须改？
• 有没有「改进项落地了但三个月后又被打回原形」的案例？这种是不是更该警惕？

想把这个话题聊透一点，因为我觉得 postmortem 的最后一公里，比会议本身贵得多。