凌晨两点线上告警响了。某个团队的核心模块出了问题用户侧报错数据写入异常影响范围还在扩大。排查了三个小时定位到根因是三个月前一次架构调整埋下的隐患。第二天早上领导在工作群里了那个负责执行的工程师。「这个问题是你当时改的你来解释一下。」工程师翻出了三个月前的会议记录。领导亲口说的「按我说的做我来负责。」这不是某个人的失误这是我们整个防御体系的失效。这种事在职场里太常见了。智联招聘的调查显示超过56%的职场人表示曾遭遇上级或同事推卸责任。盖洛普的数据更直接只有约33%的员工认为自己的直属上级会在出错时主动承担责任。剩下那67%你懂的。问题出了第一反应不是「哪里出了问题」而是「谁来背这口锅」。这两个问题看起来像是一回事其实差得很远。前者是在找系统漏洞后者是在找替罪羊。心理学上有个概念叫「基本归因错误」1977年由心理学家李·罗斯提出。大意是人在解释他人失败的时候天然倾向于高估个人因素低估情境因素。翻译成大白话就是你失败了是因为你不行。我失败了是因为环境太复杂。权力不对等会把这个偏差放大好几倍。上级看下属的失误几乎本能地会想「这个人能力有问题」或者「态度不行」而不是先问「我们的流程是不是有漏洞」「当时的决策是不是有问题」。所以那个工程师的处境其实是一个结构性的陷阱不是他一个人的倒霉。说到这个有个模型值得聊一聊。英国心理学家詹姆斯·里森在1990年提出了「瑞士奶酪模型」。他的核心观点是重大事故从来不是由单一失误引发的。你可以把每一道防线想象成一片奶酪每片奶酪上都有洞代表这道防线的缺陷。正常情况下这些洞不会对齐光线穿不过去。但当所有层的漏洞恰好对齐的时候事故就发生了。当所有层的漏洞恰好对齐的时候事故就发生了。回到那个工程师的案例你拆开来看漏洞其实有好几层。领导拍板的决策没有经过充分的技术评审这是第一层漏洞。执行过程中没有完整的风险评估文档这是第二层。上线前的测试覆盖不够这是第三层。监控告警的阈值设置不合理导致问题扩大才被发现这是第四层。每一层单独看都不是致命的。但四层漏洞对齐了事故就来了。这时候把责任压在执行工程师一个人身上不只是不公平更是在浪费一次真正修复系统的机会。锅背了流程没变下次还会出同样的事。怎么说呢这种事让人心寒的地方不只是「被甩锅」本身。更让人难受的是你当时是信任那个「我来负责」的。你按他说的做你以为有人在你前面挡着。结果出了事那个人第一个把你推出去。这种信任的崩塌比锅本身更伤人。哈佛商业评论有个研究叫「责任下移」说的是组织中管理层倾向于将失败归因于执行层将成功归功于自身。这不是某几个坏领导的个人品质问题而是一种系统性的组织行为模式。这不是某几个坏领导的个人品质问题而是一种系统性的组织行为模式。知道这一点不是为了原谅那些甩锅的人而是为了让自己不再那么困惑「为什么他会这样对我」。因为在那个系统里他大概率也是这么被训练出来的。那个工程师后来怎么样了他把会议记录截图发到了群里没有多说一句话。领导沉默了一会儿说「这个事情我们内部再讨论一下。」讨论的结果是复盘会上用了瑞士奶酪模型把这次事故拆成了四个层面的系统问题每个层面都有对应的改进措施和负责人。没有人被单独点名背锅。那个工程师跟我说他当时其实做好了最坏的打算。没想到结果是这样。他说「我只是不想让这口锅变成我职业生涯里的一个污点仅此而已。」我觉得他说的是事实。我们写代码不是为了背锅而是为了创造价值。一个健康的组织应该把事故当成修复系统的机会而不是寻找替罪羊的时机。这才是一个学习型组织应该有的样子。屏幕前的你如果也遇到过类似的处境我想说留好记录不是为了对抗是为了让事实说话。锅可以背但要背得清楚背得明白。不属于你的一克都不用多背。