先抛争点：blameless（无责复盘）被很多团队奉为圭臬，但我越来越怀疑它是不是「把追责从人身上挪到了流程上，却忘了流程本身也会烂」。今天想听大家拍砖。
【背景】 我做了 5 年 SRE，手上复盘过不下 20 起线上事故。印象最深的一次：一次「例行」的慢 SQL 优化上线，DBA 把一条索引从覆盖索引改成了非覆盖，结果大表回表，凌晨把主库 I/O 打满，订单写入 P99 从 40ms 飙到 2.3s，持续 37 分钟，丢了几千笔订单。复盘会按 blameless 走的：不点名人，结论是「变更缺少灰度、缺少执行计划 diff 校验」，产出两条 action item——上线前跑 EXPLAIN 对比、核心库变更走灰度窗口。
问题就出在「不追责」之后的三个月：同样的库，又出了两起变更引发的抖动。我去追 action item 的落地，发现 EXPLAIN 对比那条根本没进 CI，灰度窗口也还是「口头约定」。没人愿意承认「上次是我改错了」，所以也没人愿意为「护栏没建」背 KPI，最后两边都漂了。
【常见分歧 / 几种做法】 我见过三种截然不同的姿势：
- 纯 blameless：事故不点名、不扣绩效、不进晋升材料。好处是事故报得快、藏得少；代价是「明知故犯」没有代价，同一个坑反复踩，护栏靠自觉。
- 强问责：事故定级、定责任人、扣绩效、写进档案。好处是疼、记得牢、变更敬畏心强；代价是事故瞒报、先自保再报、oncall 没人愿意接。
- 混合（我现在的倾向）：对「人」blameless，对「护栏」追责——变更没走灰度、没 diff 校验、没回滚预案，这些是流程/工具/门禁的缺失，要落到具体 owner 和 deadline，建不起来就影响晋升里的「系统能力」项。也就是说，不追「谁按了按钮」，但追「为什么按钮能随便按、按错了没人拦」。
【我的倾向与理由】 我倾向第 3 种。理由很实际：blameless 解决的是「敢不敢报」的问题，它不解决「报完之后会不会改」的问题。事故是果，护栏缺失才是因，追责应该追到因上。而且我个人的经验是——护栏本身需要「有人对它的存在负责」，否则它和 action item 一样，会一起烂掉。把代价挂在流程 owner 身上，比挂在按按钮的人身上，更不容易引发瞒报，因为流程缺失通常是有据可查的（CI 没跑、门禁没配），扯皮成本低。
但我也承认这条路有坑：怎么证明「护栏缺失」而不是「人操作失误」？边界怎么划？谁来当那个对护栏负责的 owner，他有没有足够的权力和预算？这些我都还没想透。
【想听大家怎么选】 特别想问三个场景，你们线上到底怎么定：
- 一次变更引发事故，复盘发现「人确实点错了」，但根因是「按钮本不该出现在生产控制台」——你们追责到谁？
- blameless 的 action item，你们有没有强制的「护栏验收」机制？怎么防止它烂成口头约定？
- 如果让你给「明知故犯」（上次复盘明确写了要灰度，这次又没灰度）定一个「代价」，你会设成什么？绩效、晋升、还是别的？怎么设才不会逼着大家瞒报？
欢迎拿真实事故来对线，越具体越好。