如何看待系统中的“偶发故障”

复杂系统为什么会失效

每次发生重大产品故障，领导们的第一反应总是惊人地一致：找出那个犯错的人，或者那个出了故障的零件。我们急切地寻找一个清晰的“根本原因”，因为这能给我们一种虚幻的掌控感——似乎只要修复这个点，一切就能重回正轨。

然而，这种寻找单一罪魁祸首的思维方式，可能正是我们理解问题最大的障碍。这种根深蒂固的误解，让我们忽略了更深层、也更令人不安的真相：所有我们依赖的、重要的大型系统——无论是大型机械、金融市场、软件架构还是能源网络，本质上都是定时炸弹，它们从来没有在完美无瑕的状态下运行过。

在当前的工程管理文化中，领导们往往无法理解这些系统运行的复杂性，而是执着于寻找“根本原因”。他们想找到那个“导致一切”的失误，把责任归咎于某条指令，或者某项设备失灵。人们希望混乱背后有一个清晰可控的解释，有个明确的故障归因，可以跟上面交代。这种思维惯性，很大程度上源于工业化早期的思维惯性。

在泰勒制和福特流水线的时代，人们习惯于用将复杂的生产过程分解为简单、可控、线性的步骤。这种模式强调标准化和明确的因果链，并在当时获得了巨大成功。但随着社会复杂度急剧提升，很多产品、工程乃至组织架构，都演变成了多变量、非线性、实时变化，变量之间相互影响的复杂系统。然而，我们的思维模型却未能同步进化，依然停留在处理简单、线性问题的旧模式中，这就造成了认知与现实之间的巨大鸿沟。

那么，这一切意味着什么？

这意味着我们需要对“复杂系统”的有一个新的认识。我们应该停止在每次事故后玩“找人背锅”的游戏了。与其执着于揪出一个单一的“元凶”（无论是某个人、某个部件还是某条规则），不如去理解系统作为一个整体是如何运作的。

首先我们需要认识到，任何大型系统都在同时满足多个互相矛盾的需求。例如，电力系统被要求既要提供极其可靠的电力，又要尽可能降低成本；生产系统被要求既要追求极高的效率，又要保证绝对的安全。这种内在的“效率-安全-成本”冲突，意味着系统永远处于一种动态的权衡和妥协之中，其运行本身就充满了不确定性。

其次，控制系统的反馈循环往往是延迟和扭曲的。一个动作的后果并不会立即显现，就像驾驶一艘巨轮，舵手转动方向舵后，需要很长时间才能看到船头方向的改变。尤其当决策者看到的信息也是延迟的、不完整的，甚至失真的时候，精确判断和及时纠错就变得异常困难。

最后，这种滞后的反馈，加上追求效率的持续压力，共同导致了一个更隐蔽的危险：安全边界的漂移。为了追求更高的产量或效益，系统会不自觉地、渐进地向危险的边缘靠近。每一次小小的“越界”操作，因为没有立即引发灾难，就会被默认为新的“正常”标准。久而久之，最初设定的安全冗余被一点点蚕食，系统在不知不觉中已经运行在崩溃的边缘，这种现象也被称为“常态化偏离”。

在实际生产运营活动中，复杂系统往往并不是靠彻底规避风险来维持安全，而是靠人在模糊中判断、在不确定性中试错、在有限资源中博弈，从而不断地“调整”安全边界。这些微小而连续的适应性行为，在表面上看起来微不足道，却构成了系统稳定运行的基石。

真正提高安全性的，不是寄希望于消除所有潜在的故障点，而是去构建一个更有韧性的系统。在这样的系统中，失效是不可避免的，但它有能力在遭遇意外时及时调整、适应，而不是彻底失控。它允许我们从局部的小失败中学习，从而避免灾难性的整体崩溃。

这要求我们拥抱一种新的理念：Fail better, fail quicker. 只要系统还在运行，风险就不会消失；我们唯一能做的，就是理解它，管理它，并在每一次临界边缘处，重新把系统拉回到脆弱的平衡。

戴明思想

有趣的是，复杂系统的失效控制理论，与上世纪一位质量管理大师——戴明的理论惊人地相似。戴明当年对日本战后工业的重建影响深远，他所倡导的统计过程控制和质量管理哲学，被丰田等企业奉为圭臬，成为了“日本制造”奇迹的基石之一。

想象一下，一个你每天都在用的软件，更新后突然出现一堆bug；或者你常去的一家咖啡店，咖啡的品质时好时坏，让你怀疑人生。这时候，管理者的第一反应总是“救火”：开一场紧急会议，找到那个写错代码的程序员，或是那个没调好咖啡机的店员，然后罚款，连夜补救，解决掉这个“问题”。

看起来很高效，对吗？但为什么同样的事情下个月还会发生？

如果你也觉得这种“打地鼠”式的管理既熟悉又疲惫，那么恭喜你，你已经触及到了一个更深层的真相。戴明早在几十年前就指出了这一点：这种头痛医头、脚痛医脚的做法，恰恰是产品质量平庸的根源。真正的改进，源于理解质量问题的产生，而不是简单地对结果做出反应。

戴明的洞见是：你遇到的所有质量问题，都可以分为两种。

第一种叫“可控故障”。这就像是你的电脑突然蓝屏死机。这是一个不正常的、突然的干扰，原因很明确——可能是操作失误、某个硬件坏了，或者驱动程序崩溃了。对于这种问题，你必须立刻采取行动，找到它，修复它，确保它不再发生。这就像是救火，要立即执行。

但更常见、也更麻烦的是第二种问题，戴明称之为“偶发故障”。这更像是你的电脑整体运行速度时快时慢。它不是由一个单一的、明确的故障引起的，而是系统固有的一部分。可能是你的操作系统有点臃肿，后台开了太多程序，硬盘空间不足……无数个微小的、随机的因素共同作用，造成了这种整体的、难以名状的“卡顿感”。这就是系统的“背景噪音”，它永远存在。

现在，管理中最昂贵、也是最普遍的错误就出现了：我们总是试图用处理“可控故障”的办法，去对付“偶发故障”。

想象一下，当咖啡店的经理发现今天的咖啡口感稍微偏酸一点（一次正常的随机波动），他立刻冲过去批评咖啡师，并让他重新调整咖啡机，写检查，做思想汇报。这种行为，戴明称之为“过度干预”。这非但不会让咖啡品质更稳定，反而会因为频繁的无效调整，增加整个系统的混乱度，让未来的品质波动更大。这就解释了为什么很多团队在老板的“严密监控”下，表现反而越来越差。他们把所有精力都用在了应对老板对每一次正常波动的过度反应上，而不是真正去改善系统。

那么，正确的做法是什么？戴明给出的路径非常清晰。

首先，你要做的，是把那些突然着火的“可控故障”全部扑灭。通过建立一套标准（比如戴明著名的控制图），你可以科学地判断出哪些问题是真正的“异常信号”（分布在三个标准差以外的信号）。一旦发现，立即行动。当所有这些异常信号都被消除后，你的系统就进入了所谓的“稳定状态”。这时，它依然会有波动，但那都只是正常的“背景噪音”。

接下来，真正重要的改进才刚刚开始。当系统稳定后，任何问题的根源都不再是某个具体的人，而是整个系统本身。管理者此时需要考虑的是如何降低系统的随机波动。这意味者优化工作流程，升级工具，改善设计，提供更好的培训。对于咖啡店来说，可能意味着换一台更稳定的咖啡机，或者优化豆子的供应链。对于软件团队来说，可能意味着引入更好的代码审查流程和自动化测试。

戴明理论的智慧在于，它强迫我们停止玩“找替罪羊”的游戏，而是像个工程师一样去审视整个系统。它告诉我们，一个高质量、高效率的组织，不是靠惩罚和事后检查“逼”出来的，而是通过对系统本身不懈地、聪明地改进“设计”出来的。

我们最终要打造的，不是一个不出任何差错的“完美”乌托邦，而是一个更有韧性的系统。它承认波动和失败是常态，并有能力在混乱中学习、适应和进化。

SpaceX

如果说前面的理论听起来有些抽象，那么现实世界中有一个堪称完美的案例，那就是SpaceX。它的发展史，几乎就是对“拥抱失败、改进系统”这一理念的现实演绎。

在传统航天机构，一次火箭发射失败是不可想象的灾难。这往往意味着数年的调查、上级问责和项目的停滞。因此，传统航天机构的首要目标是规避风险。然而在SpaceX，一枚“星舰”原型机在众目睽睽之下化为一团壮观的火焰，几个小时后，马斯克可能已经在社交媒体上分析他们从这次“计划外的快速解体”中学到了什么。

这就是两种思维模式的根本区别。传统模式下，失败的核心问题是“谁该为此负责？”；而在SpaceX的模式下，问题变成了“我们从数据中学到了什么？”。他们将失败视为一次成本高昂、但数据极其宝贵的真实测试，而不是需要推卸的重大责任事故。

这种做法，正是戴明理论的核心所在。SpaceX将研发阶段的爆炸视为系统固有风险，是“偶发性故障”。他们并不追求单次发射的完美表现，而是通过快速的“建造-测试-失败-学习”循环，来系统地优化整个火箭系统的“质量分布”，让它变得越来越可靠。每一次因为“偶发原因”（如某个阀门设计缺陷）导致的失败，都会被用来审视和改进整个系统的设计。在SpaceX，发射事故是被允许，甚至被鼓励的。

SpaceX以一己之力颠覆了整个航天产业的格局。早在2021年，SpaceX的卫星发射数量已经超过了其他国家总和，把每公斤发射成本降低了一个数量级。星链网络目前在技术上已经可以全球部署，千兆网络的费用是每月100刀。

这一切之所以成为可能，在很大程度上因为SpaceX摆脱了传统航天项目所背负的沉重枷锁。它可以单纯地将造火箭视为一个工程学问题，而不是一个不能失败的政治任务。这使得他们能够容忍失败、快速迭代，并将所有精力聚焦于系统改进，而非陷入漫长的问责流程。

或许，当下一次房子失火的时候，除了去抓一个纵火犯来顶罪，我们更应该多考虑一下如何改造我们这栋易燃的房子本身。

参考文献：

查尔斯佩罗，Normal accidents

戴明，Out of the crisi

著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。