拆穿表象的锤子：根本原因分析为何经常失灵

上周跟长三角一家汽配厂的运维主管喝咖啡，他杯沿磕着桌子，骂了快半小时。说三个月内同一台冲压机连出三次故障，每次出问题都拉着团队做复盘找根因，第一次说操作工没按规程点检，罚了两千，第二次说轴承采购批次不合格，换了供应商，第三次又坏了，拆开来发现整个润滑管路设计就有问题——从机床安装好那天起，就留着隐患。 你看，绝大多数人找根因，都是找那个离结果最近的、好背锅的原因，不是真的根本原因。

被误读的归因逻辑

很多人默认，因果就是一条直线，出了问题往前捋，捋出第一个出问题的节点，就是根因。 错得离谱。 我们现在面对的绝大多数问题，不管是工业生产、互联网运维还是公司管理，都是复杂系统下的多因聚合结果，不是单链条的线性事件。就像飞机失事，很少是因为单独一个部件坏了，往往是部件老化+维修疏漏+天气干扰+操作界面设计缺陷凑到了一块，才出了大事。 市面上流行的很多工具，比如5why分析法，本来是帮人跳出表面，但很多人用着用着就变了味。问了一个为什么，得到一个答案，就停下了。设备停了为什么？因为轴承断了。轴承为什么断？因为杂质多。然后就停了，换轴承，罚采购，完事。不会再问，为什么杂质多的轴承能进厂？为什么进厂检验没筛出来？为什么检验流程会漏掉这一项？ 制造业设备故障根因追溯层级图 说穿了，大家不是找不到真的根因，是不想找。找个人背锅多快，解决系统问题多麻烦啊。罚操作工两千块，半小时搞定整改报告，要改管路设计，要重新走审批，要花几十万改生产线，哪个领导愿意批？

归因过程里看不见的陷阱

第一个陷阱，是把因果的时间顺序当成因果逻辑。事情出了之后，A发生在B前面，就说A是B的原因。之前有个互联网公司，服务器宕机三个小时，最后复盘结论说是新来的运维误操作，把人开了完事。半年后又宕机，才发现权限管理系统从根上就错了——所有运维都能直接访问生产库，没有操作审核，没有二次确认，没有回滚机制，不出事才怪。 第二个陷阱，是无限递归。你说设备坏了根因是润滑管路设计错了，再往下挖，设计错了是因为设计工程师当时怀孕请假，交接没做好，再往下挖是公司当时人手不够招不到人，再往下挖是行业招人难，再往下挖是人口出生率下降...挖到最后全是不可抗力，什么问题都解决不了。 第三个陷阱，是幸存者偏差。出了问题才找根因，没出问题的时候永远不会想，这次没出事是不是侥幸。很多工厂的安全检查，都是出事之后大张彻查，风头过了又回到老样子，就是因为没出事的时候，没人愿意挖潜在的根因。 复杂系统多因一果根因分析路径图 说实话，我见过太多公司的复盘会，开着开着就变成甩锅大会，根因分析变成了找软柿子捏的工具，最后什么问题都没解决，下次该出还是出。

找对方向的几个基本准则

找对方向的几个基本准则 第一个要明确的，就是根因的边界，停在可改变的因素上。你不用挖到地球形成那个层面，也不要停在“某个人不小心”这个层面。根因必须是你能改变的，比如说设备坏了，你停在“操作工粗心”，你能改变的是什么？你只能罚他，但是改不了问题，如果你挖到“点检流程设计不合理，点检点太多操作工根本看不过来”，这就是可改变的，你可以调整点检流程，减少没必要的点检项，这就能解决问题。 多找系统问题，少找个人问题。航空业为什么事故率越来越低？就是因为他们从来不把事故根因归到飞行员操作失误，哪怕真的是操作错了，也会挖为什么会出错，是不是仪表放错了位置，是不是提示音不对，是不是培训没覆盖这种场景，是不是流程给飞行员的压力太大了。整个系统改了，后来的飞行员就不会犯同样的错。如果只是开掉那个飞行员，下次换个飞行员还是会错。 只给重复发生的大问题找原因，不要给所有问题都挖根因。就是说，如果你只是保险丝烧了一次，换了就完了，不用大张旗鼓做分析，只有那种重复发生的，影响大的问题，才需要花时间挖根因。过度分析本身就是一种浪费，很多小公司本来就没多少人力，天天挖根因，正事都不用干了。 要验证你找到的根因是不是真的。怎么验证？如果你改了这个因素，同样的问题还会不会发生？如果改了之后还发生，说明你找错了。之前那个冲压机的例子，改了润滑管路之后，两年没出问题，那说明找对了，如果换了轴承换了操作工还是出，那显然根因不对。 不过话说回来，哪怕找错了，也比躺平不找强？不对，找错了比不找更糟，因为你会误以为问题解决了，放松了警惕，下次出更大的事。 现在越来越多企业开始用大数据辅助回溯，把系统全链路运行数据留存，出问题后能顺着所有节点捋一遍，比人拍脑袋找准多了。但技术永远只是工具，核心还是你愿不愿意直面真的问题，还是只想找个背锅的。 很多时候，问题的根因不是找不到，是掌权的人不想找到。对吧？