线上故障复盘该不该追责：写「人配错了参数」还是「流程缺陷」，哪种写法的改进真正落地？

【背景】 做了 5 年 SRE，经手过 20+ 次线上故障复盘（postmortem）。每次写复盘文档时，都会撞到一个绕不过去的问题：「根因」那一栏，到底写人还是写流程？

我见过三种典型写法：

• 写法 A：「根因：某工程师在部署时误将 --max-connections 设为 100（正确值 1000），导致连接池打满，服务雪崩。」
• 写法 B：「根因：部署流程缺少参数校验环节，CI/CD pipeline 未对关键参数做 sanity check。」
• 写法 C：「根因：操作失误 + 部署流程缺少参数校验 + oncall 缺少连接池水位告警，三者叠加导致。」

三种写法对应的改进动作完全不同，而改进动作是否落地，我观察到的差异非常大。

【常见分歧 / 几种做法】

1. 纯 Blameless 派（Google SRE 那套）

• 根因只写系统/流程缺陷，绝不出现在
• 理由：追责 → 人不敢说真话 → 复盘流于形式 → 同类故障反复发生
• 我的踩坑：某次故障后写「流程缺陷」，改进项是「加强培训」——三个月后同类故障又发生了，因为真正该改的部署校验脚本没人推动

2. 追责派

• 根因必须落到人，改进项必须落到责任人 + deadline
• 理由：没有责任人 = 没有优先级 = 永远不会做
• 我的踩坑：某次故障后追责到人，改进项确实落地了；但下次复盘会上没人敢说真话了，连续三次复盘结论都是「偶发性问题」

3. 折中派（我目前的做法）

• 根因写「人 + 流程 + 监控」三层，但改进项只落流程和监控
• 理由：人的失误是表象，流程和监控是根因；但改进项如果全是「加强培训」「提高意识」，等于没改
• 遗留问题：怎么判断哪些「人的失误」背后确实没有流程可以兜底？

【我的倾向与理由】

我倾向写法 C + 改进项只落系统侧（流程/监控/工具），不给人打绩效。但有一个硬约束：如果同一个人在同一个系统上同类失误出现两次，第二次复盘必须升级处理，不再走 blameless。

理由：

1. 5 年经验里，「加强培训」落地率不到 10%，「加一条自动化校验」落地率超过 80%——改进项的形态比追责本身更能推动落地
2. 但完全免责会让「操作成本极低、影响极大」的动作（改生产配置、批量 DDL）没有敬畏心
3. 真正的根因永远是「系统允许了一个不该允许的操作发生」

【想听大家在什么场景下怎么选】

特别想听几种场景的实践：

1. 小团队（<10 人 SRE）：没有专职 SRE，开发自己运维，复盘时追责还是免责？
2. 大团队（>50 人 SRE）：有专门 oncall，但根因经常是「业务代码写错」，追责到开发还是 SRE？
3. 跨团队故障：A 团队改了配置导致 B 团队服务挂了，复盘文档谁写、改进项谁推？
4. 你们公司的复盘文档是公开的还是只对内的？公开后会不会影响追责尺度？
5. 有没有量化数据：追责型复盘 vs 免责型复盘，3 个月后同类故障复发率分别是多少？

欢迎拿真实案例来对线，不用客气。