故障复盘该追责到人还是只追流程？10 年运维的两难

背景

干了 10 年运维，从 3 人小团队到 200 人的 SRE 组织都待过，主持过上百次故障复盘。有一个话题每次都要吵，而且每次吵完都"各打五十大板"——复盘到底该追责到人，还是只追流程？

我见过两种极端：

• 追责派：某次 P0 是某同事把生产 Nginx 配置改错了，直接点名通报 + 绩效扣 0.5。结果呢？下个月同一团队出了个同类配置事故，没上报，自己悄悄回滚了。为什么？因为"报了就是我的锅，不报最多扣点奖金"。追责确实让当事人痛了一次，但让整个团队的信息透明度降了。
• 追流程派（blameless postmortem）：只写"流程缺陷：缺少配置变更的 code review 卡点"，不写"谁改的"。听起来很美好，但实际执行中，"流程缺陷"经常变成"谁也没错"，最后 Action Item 全是"加强培训""提高意识"这类没法验收的废话。我见过一份复盘报告，7 条 Action Item，6 条是"加强 XXX 意识"。

常见分歧，我总结成 3 种立场

1. 纯追责：不痛就没有记忆，同样的错会犯第二次。"绩效不挂钩的复盘 = 团建。"
2. 纯 blameless：追责让人隐瞒，复盘变甩锅会；安全上报文化比追责更重要。
3. 折中：区分"无心之失"和"明知故犯"——前者追流程，后者追责。但问题是谁来判定"无心"还是"明知"？这个判定权在谁手里？

我的倾向（带具体判据）

我站追流程为主，但有一条红线：

• 默认不追责到人。复盘文档里写"变更人未执行 checklist 第 3 步"，不写"张三忘了执行"。Action Item 必须可验收：不是"加强培训"，而是"在 CI 流水线加一条 lint 规则，Nginx 配置里 proxy_pass 指向内网域名时必须带超时参数，违反则 build fail"。这条规则我写过，上线后同类错误从月均 2.3 次降到 0。
• 红线：数据篡改或故意隐瞒不报。这不是"操作失误"，是职业操守问题，必须追责。但这种情况 10 年里我大概遇到 2 次，占比 <2%。
• 一个量化指标：复盘后 90 天内，同根因故障复发率。我跟踪过 47 次复盘，blameless 模式下复发率 4.3%（2/47），追责模式下 8.5%（4/47）。数字不大，但方向一致：追责让问题被藏起来，藏起来就不会被修。

想听大家说说

1. 你团队现在怎么做的？小团队（<10 人）和大团队（>50 人）做法差别大吗？
2. 有没有"追责反而让团队变好"的真实案例？（我好奇反例）
3. Action Item 怎么验收才不变成"加强意识"？你们有没有可量化的模板？
4. 如果复盘要写"谁做的"，你建议写名字还是写角色（如"当值 SRE"）？

欢迎拍砖，有具体数字和案例的优先。