P0 事故复盘，到底该追问「人」还是追问「系统」？

背景： 我做了 15 年技术产品，经历过大大小小 40 多次线上事故复盘。每次复盘会，气氛几乎一样：前 10 分钟大家还在客观还原时间线，15 分钟之后就开始变成「当时为什么没有 double-check」「这个流程谁定的」「这个人能不能再仔细点」。会议从 1 小时拖到 2 小时，最后产出一句「下次注意」，然后散会。

我观察到的做法大致分三派： 1.「人因派」：事故根因 80% 是人的疏忽，复盘核心是追责 + 培训 + 写进绩效。 2.「系统派」：人一定会犯错，复盘核心是「为什么系统允许这个错误发生且不被拦截」。 3.「折中派」：两者都看，但先定 30 分钟只讲系统，后 30 分钟再聊流程改进，不点名。

我的倾向与理由： 我明确站「系统派」，但不是绝对的。我的判断标准很简单：如果同一个错误，换一个值日生，大概率还会犯——那问题在系统，不在人。具体来说，复盘时我会追问三个数字： ① 这个操作的「安全距离」是多少？（从错误操作到不可恢复，中间有几道拦截？0 道就是设计缺陷。） ② 发现到恢复用了多少分钟？（MTTR 能不能从 45 分钟压到 15 分钟？监控、告警、回滚脚本各占多少？） ③ 同类事故过去 12 个月出现了几次？（1 次是意外，3 次是系统性漏洞，说明流程本身有洞。）

我见过最痛的一次：一个配置变更误操作把生产库的 200 万行数据覆盖了，MTTR 3 小时。复盘时大家盯着「谁点的确认按钮」，最后定下来「加强培训」。三个月后，同一个操作，换一个人，又犯了一次。因为系统层面根本没有「二次确认 + 影响行数预估 + 自动备份」这三道拦截。

想听大家聊聊：

• 你们团队的复盘会，实际是哪种风格？有没有踩过「复盘变成批斗会」的坑？
• 你们用什么机制来保护参与者敢说真话？（比如 blameless 承诺、匿名提交、复盘模板强制先写系统原因再写人的因素？）
• 如果让你设计一个「复盘模板」，你要求必填的前 3 个字段是什么？