原文	How Complex System Fail
原文作者	Richard I. Cook

1. 复杂系统本质上是危险的

所有重要系统（如交通、医疗、电力等），出于自身性质的原因，必然是危险的。虽然系统发生故障的频率不断变化，系统内部处理流程在本质上具有不可降低的危险性。正是在这些危险驱使下建立的防范措施塑造了系统特征。

2. 复杂系统几乎成功的避免了故障

系统失效的高昂代价使得系统逐步建立起多层防范措施，包括技术层面（如备份系统、设备安全特性等）、人员层面（如培训、知识等）以及组织、制度和监管层面（如政策、流程、认证、行为规范、团队培训等）。它们提供的一系列防护，在通常情况下让运维操作远离事故。

3. 灾难性事故源自多重故障

防范措施有效，系统大部分时间运行正常。灾难的发生，往往是由于多个不起眼的小问题同时出现，构成触发系统性故障的条件。少一个问题灾难都不会发生，但当它们遇到一起，系统失效了。换句话说，征候远多于故障。故障最初的征候大部分被系统的安全措施屏蔽了，传递到运维层面的征候也往往没有被一线人员汇报。

4. 复杂系统包含的隐患不断变化

复杂程度导致系统无法在没有隐患的条件下运行。由于不会直接引发故障，这些隐患被当作运维中的小问题。出于成本的考虑，以及难以预测隐患对系统的威胁程度，消除隐患的改进工作受到阻碍。随着技术革新、组织结构调整和系统改进工作的调整，系统内的隐患不断变化。

5. 复杂系统总是带病运行

从上一条可以推导出：复杂系统总是带病运行。有这么多隐患的系统还能工作，因为系统包含了大量冗余，也因为一线人员的运维工作。事故调查几乎总会发现系统曾经出现过快要发生灾难的预兆。一种观点认为应当在故障发生之前找出隐患，这是对系统运维的天真想法。系统运维是动态的，每个部分（组织、人员、技术）都在持续改变。

6. 灾难随时随地可能发生

复杂系统可能发生灾难性故障。一线人员在空间和时间上离潜在故障非常近，灾难随时随地可能发生。能够引发灾难性后果是复杂系统的显著特征。不可能消除潜在风险，这是由复杂系统自身性质决定的。

7. 将事故归因于“根源”是完全错误的

系统失效源于多重故障的共同作用，没有单独的事故“原因”。导致故障的因素不止一个，每个因素又都无法独自引发事故。只有它们一同出现时才会出事。实际上，多重因素关联在一起才能构成事故发生的条件。因此无法单独剥离出事故的“根源”。基于“根源”的分析和结论反映的不是在技术层面上对故障性质的认知，而是将后果归咎于特定原因或事件的社会和文化需求。

8. 事后偏见会影响对一线人员的评价

知道后果的人倾向于认为引发故障的事件应当受到一线人员的重点关注。这表明事后对一线人员处置行为是不精确的。知道了后果的调查人员难以体会一线人员在当时是如何看待这些事件的。看起来一线人员“应当知道”这些因素“必然”引发事故。事后偏见仍然是事故调查的主要障碍，尤其在评价专业能力的时候。

9. 一线人员拥有双重身份：生产人员和维护人员

一线人员操作系统制造产品，同时也要防范事故发生。运维工作的动态性质：兼顾满足产量要求和及时处置事故征候是不可避免的。外界很少了解双重身份的问题。没有故障时，生产人员是主要身份。事故发生后，维护人员是主要身份。外界往往误认为一线人员同时处理两份工作。

10. 操作是在和不确定性博弈

事后看来，故障往往是不可避免的，一线人员的行为则是过错或对事故征兆的无视。但是一线人员的所有行为实际上是赌博，即面对未知结果采取行动。不确定的程度随时变化。事后来看，一线人员的行为显然是在赌博，并且他们赌失败了。但是相对的，成功也是赌博的结果，而这些成功往往被忽视了。

11. 一线行动澄清所有困惑

对于生产目标、资源利用效率、运维成本和效益、以对各种风险后果容忍程度之间的关系，一个组织往往有意保持模糊。一切困惑随着一线人员在系统最前端的操作得到澄清。事后一线人员的行为可能被看作是错误或违规，这种评价存在严重的事后偏见，忽视了其他方面的驱动因素，特别是生产目标压力。

12. 一线人员是复杂系统中的适应性要素

一线人员和基层管理人员主动适应系统，尽量提高生产，降低风险。适应性调整时刻在进行，包括：一、调整系统结构，减少脆弱部件引发事故的风险。二、集中关键资源满足优先需求。三、提供处置已知和未知故障的方法。四、建立检测系统状态变化的方法，以便平稳降低产能，以及其他提高故障恢复能力的方法。

13. 一线人员需要的专业能力不断变化

复杂系统的运维和管理需要大量的专业能力。一线人员的专业能力随着技术革新和人员调整而改变。无论出于哪种原因，对专业能力的培训和改进是系统功能的一部分。因此在任何时候，复杂系统中都会存在不同专业水平的一线人员和实习人员。关于专业能力的核心问题来自于：一、专业能力是一种稀缺资源，需要投入到最困难或最紧急的生产任务。二、需要培养储备专业能力以备不时之需。

14. 系统变更引入新型故障

可靠系统的低故障率鼓励变更，特别是应用新技术降低高频轻微故障的变更。这种变更可能在实际上为新型低频严重故障创造了条件。为了消除已知隐患或提高性能而引入新技术，通常为大规模灾难建立了新路径。很多时候新型低频故障可能比已经修复的问题影响更严重。新型故障难以事先预知，大家都在关注变更预计带来的好处。因为新型严重事故的频率很低，在事故发生前系统可能经历了多次变更，使得变更与故障之间的联系难以确认。

15. “根源”观点限制了防范对潜在故障的效果

事后针对“人为错误”的补救措施通常用于阻止可能“引发”事故的行为。针对事故链末端的措施只能稍微降低未来事故发生的概率。事实上，由于引发潜在故障的条件不断变化，发生相同事故的概率非常低。事后补救措施不仅没有提高安全性，反而增加了系统耦合度和复杂度。增加了潜在故障数量，也让故障检测和恢复变得更加困难。

16. 安全是整体特征，不是局部特征

安全是系统的涌现性特征，而非存在于某个人、某个设备或组织中的某个部门。安全无法购买或制造，它不是独立于其他部分的特性。因此安全不能像原材料一样进行加工。系统的安全状态是动态的。系统的持续变更使得风险和风险管理工作也在不断变化。

17. 一线人员持续维护系统安全

无故障运维是一线人员努力使系统保持在有效范围内的工作的成果。这些工作大多是看起来简单的日常运维。由于运维操作总是有风险的，一线人员对系统状态的调整实际上保障了系统安全。调整工作通常从经过演练的例行事务中选择，有时也会重新组合事务或建立新方法。

18. 无故障运维需要故障处置经验

识别风险并成功处置需要近距离接触故障。提高系统稳定性需要一线人员能够识别临界条件。此时系统状态开始变差，运行情况难以预测，或者无法快速恢复。在复杂系统中，一线人员需要全面评估处置故障，保障系统整体稳定。要提高安全性，需要为一线人员提供故障标准，以及运维操作对系统影响程度的标准：这些操作让系统远离临界条件，还是更靠近临界条件？