线上事故复盘，到底该无责（Blameless）还是必须定责到人？两种流派吵了十年没吵出结论

先说背景，我是干运维的，十几年里经历过从「出问题先找谁」到「出问题先找事」的转变，但每次换团队、换公司，这个老问题都会重新吵一遍，所以我今天想把它摊开聊聊，看看大家到底是怎么落地的。

【背景】 无责复盘（Blameless Postmortem）这套理论在 SRE 圈子里已经传播很多年了：核心主张是——人不是 bug，流程和环境才是；复盘要对着「为什么会发生」而不是「谁该背锅」，否则没人敢说真话，事故报告全是套话，同一个坑下次继续踩。

【常见的几种做法 / 分歧】 我把身边见过的分成三派：

1. 纯无责派：复盘会里明确禁止出现「某同学操作失误」这种表述，只写「操作缺少二次确认环节」；事故不进入绩效考核，甚至鼓励主动上报。
2. 定责派：尤其是国内不少团队，事故要分级（P0/P1/P2），要定责任人，扣绩效、发通报。理由是「不定责就没有痛感，痛感没了改进就没人推」，而且管理层要一个交代。
3. 折中派：对内复盘用无责话术挖根因，对外/对上汇报时保留「操作失误」的责任表述，两套话术并行。

我自己的观察：纯无责派在创业小团队、工程师文化强的地方能跑通，但一到大组织、跨部门、有 KPI 考核的地方，基本都滑向折中或定责；而折中派最折磨人——工程师心里清楚「这套是写上去好看的」，真实根因反而被藏到第二份文档里。

【我的倾向与理由】 我倾向无责，但有一个前提：组织必须真信。理由有三：

• 事故根因 70% 以上出在系统（监控盲区、变更没卡口、容量没余量），归咎到个人既不准也不公平；
• 无责不是免责，是把「追责的能量」转成「改进的能量」——同样一次误操作，定责只会让当事人下次更谨慎，无责复盘却能让全团队都补上那条缺失的护栏；
• 数据说话：Google SRE 的实践里，无责复盘后同类事故复发率明显下降，因为大家愿意把「为什么没被发现」写出来，而不是把「不是我的锅」写出来。

但我也承认它的软肋：当事故造成大额资损、涉及合规时，纯无责会让管理层和老板没法接受，「无责」在老板眼里可能等于「无担当」。所以我的真实立场是：复盘动作本身必须无责，但改进项（Action Item）必须有 owner、有 deadline、有验收——把「责任」从「人」挪到「事项」上。

【想听大家在什么场景下怎么选】 想听听各位的真实经验，特别是这几个场景：

1. 你们团队的事故复盘到底是真无责还是「纸面无责」？怎么判断的？
2. 当事故造成明确资损 / 客户投诉时，无责复盘怎么跟管理层交代？有没有可复用的「对上话术」？
3. 无责复盘的 Action Item 落地率你们怎么保证的？有没有踩过「复盘很热闹、改进全落空」的坑？
4. 跨团队事故（A 团队变更导致 B 团队故障），无责边界怎么划？

这个话题我猜会吵起来，欢迎正反方都来，最好带真实案例，别只讲理论。