故障复盘要不要写"责任人"？blameless 和点名制，我两种都踩过坑

背景

做了 5 年 SRE，经手过 20 多次 P0/P1 复盘。我先后在两种文化下待过：

• A 团队（blameless 派）：复盘文档模板里根本没有"操作人"一栏，只写"某变更由 on-call 执行"。
• B 团队（点名派）：复盘必须写"操作人：xxx，审核人：xxx"，严重违规的还会同步到绩效系统。

两种模式我都亲眼见过翻车。

我踩过的两个坑

坑 1：blameless 下，大家反而不敢说真话。 A 团队有一次线上事故：某同学凌晨手动跑了一个"清理脚本"，把生产库一张 3000 万行的表 truncate 了。复盘会上他反复说"我不确定是不是我跑的"，最后只写了"某次变更操作异常"。因为没人会追责，他也没动力精确还原自己到底敲了什么命令——文档里缺了最关键的"操作序列"，action item 变成了"加强脚本权限管控"这种正确但没法落地的废话。

坑 2：点名制下，根因被"操作失误"四个字盖过去了。 B 团队有一次 P0：发布平台一个灰度批次卡住了，on-call 手动跳过了灰度直接全量，结果新版本有个 NPE，直接雪崩。复盘文档里"责任人"写得很清楚，但根因只有一句"操作失误，加强培训"。真正该改的东西——发布平台灰度卡住时为什么没有自动回滚、为什么 on-call 有"手动跳过灰度"这个按钮——没人提，因为写了就等于在说"平台设计有缺陷"，而平台团队也在被追责。

我的倾向（不是银弹，是我现在在用的折中）

1. 复盘文档正文里不写"责任人"，但必须写"操作序列"。谁做的不重要，做了什么、按什么顺序做、当时看到什么监控/日志才做的这个决定——这才是 action item 的原料。
2. "违规操作"走单独通道。如果操作本身违反了变更流程（比如没走审批、绕过灰度），这不是复盘讨论的范畴，而是流程执行问题，由 SRE lead 或 TL 线下单独跟进，不进复盘文档。复盘只讨论"系统为什么允许这个操作发生"和"怎么让正确操作更容易、错误操作更难"。
3. action item 必须绑定"系统改动"，不允许出现"加强培训""提高意识"这类动词。我现在的验收标准是：每条 action item 必须能对应一个工单（改代码 / 改配置 / 加告警 / 删按钮），否则打回。

想听大家聊聊

• 你们团队的复盘是 blameless 还是点名？实际运转下来效果怎么样？
• 有没有遇到"blameless 导致没人说真话"或者"点名导致大家只写操作失误不写根因"的案例？
• action item 的验收标准你们是怎么定的？有没有"写了但没人跟进"的烂尾 action item 治理经验？
• 一个具体场景想请教：如果一次事故里，操作人确实严重违反流程（比如没走审批直接改了生产配置），同时又暴露了平台缺陷（平台本来就不该允许他直接改）——这两件事在复盘里到底怎么拆？

欢迎带真实案例来，匿名的也行，我主要想听"机制设计"层面的讨论，不是听谁对谁错。