本刊很喜欢谈论一个话题，复杂系统。
本周推荐的来自芝加哥大学认知实验室的医学博士 Richard I. Cook 总结的 18 点对负责系统的认知；
特别是大型软件系统由于依赖和协作变得特别多，逐渐演变为一个复杂系统；
每次大型软件系统的事故复盘，总让我想起本篇。
这 18 点在介绍
- 关于事故的本质
- 事故是如何被的
- 事故是如何归因的
- 以及由此产生的对病人安全/系统安全的新理解
具体的 18 点
- 复杂系统本质上是危险系统
- 所有这些有趣的系统(例如交通、医疗、发电)本身就具有内在的、不可避免的危险性。
- 危险暴露的频率有时可以改变，但是该系统所涉及的过程本身具有内在的、不可减少的危险性。
- 正是这些危险的存在，推动了针对这些系统特征的危险的防御措施的建立。
- 复杂系统都在时刻严密防御事故的发生
- 随着时间的推移，事故的严重后果导致了对事故的多层防御的构建。
- 这些防御包括明显的技术组成部分(例如备份系统、设备的“安全”特性)
- 人为组成部分(例如培训、知识)
- 但也包括各种组织、机构和监管防御(例如政策和程序、认证、工作规则、团队培训)。
- 这些措施的效果是提供了一系列防护罩，通常可以使作业避免发生事故。
- 事故的发生需要多个故障点、单个不足以引发事故
- 小故障中的每一个都是引起灾难的必要因素，但只有组合起来才足以导致故障
- 大多数初始故障轨迹被设计好的系统安全部件所阻挡
- 复杂系统包含潜在的不断变化的故障混合因素
- 消除所有潜在的故障主要受到经济成本的限制，但也因为在事实发生之前很难看出这种故障
- 由于技术、工作组织和消除故障的努力的改变，故障不断变化。
- 复杂系统往往是以降级模式在运行
- 前面一点的推论是，复杂的系统像破碎的系统一样运行。
- 事故后的审查几乎总是注意到，系统有一个历史存在的“原始事故”。
- 认为这些恶化的条件应该在明显的事故发生之前就被认识到的观点通常建立在系统性能的天真概念之上。
- 系统操作是动态的，组件(组织、人员、技术)发生故障并不断被替换。
- 事故往往就发生在眼前
- 复杂系统有可能发生灾难性故障。
- 人类实践者几乎总是在物理上和时间上与这些潜在的失败非常接近。
- 灾难可能在任何时间和几乎任何地点发生
- 事故的事后归因 想要找到 事故的根本原因是不成立的，不可能孤立地找出事故的“根本原因”
- 造成事故的原因是多方面的。其中的每一个都不足以造成事故。
- 只有这些原因共同作用，才足以造成事故。
- 事实上，正是这些原因联系在一起，才造成了事故所需的环境。
- 因此，不可能孤立地找出事故的“根本原因”。
- 事后偏见仍然是事故调查的主要障碍，对事故的事后偏见其是对人类表现的评估
- 系统的人类运营者有2个角色：生产者同时努力防止事故的发生
- 局外人很少承认这一角色的双重性。
- 在非事故时候，强调生产的作用。
- 事故发生后，强调对失效的防范作用。
- 在任何时候，局外人的观点都会误解操作者与两个角色同时进行的持续参与。
- 所有从业者的行为都是赌博
- 所有实践者的行为实际上都是赌博，也就是说，面对不确定的结果时发生的行为。
- 不确定性的程度可能会随时间而变化。
- 从业者的行为是赌博，这一点在事故发生后显而易见;
- 一般来说，事后分析认为这些赌博是不好的。
- 但反过来说，成功的结果也是赌博的结果，并没有得到广泛的认可。
- 果断的行动可以解决所有的歧义
- 事故发生后，从业人员的行为可能被视为“错误”或“违规”，
- 但这些评估严重偏向事后，忽视了其他驱动力，特别是生产压力。
- 人类从业者是复杂系统的适应性因素
- 从业人员和一线管理人员积极调整系统，使生产最大化，事故最小化。
- 这些适应经常发生在一个时刻一个时刻的基础上。
- 其中一些改进包括:
- 重组系统，以减少易损部件的故障暴露。
- 将关键资源集中在预期需求高的领域。
- 提供预期故障和意外故障后退或恢复的途径。
- 建立及早发现系统性能变化的手段，以便适当削减生产或其他提高弹性的手段。
- 人类有关复杂系统的专业知识在不断发生变化
- 复杂系统的运行和管理需要大量的人类专业知识。
- 随着技术的变化，这种专门知识的性质也在发生变化，但也因为需要更换离职的专家而发生变化。
- 在任何情况下，技能和专门知识的培训和完善都是系统本身功能的一部分。
- 因此，在任何时候，一个给定的复杂系统将包含具有不同程度专业知识的实践者和受训者。
- 与专业知识有关的关键问题产生于:
- 需要将稀缺的专业知识作为最困难或最苛刻的生产需求的资源;
- 需要发展专业知识以备将来使用。
- 在可靠的系统中，明显的事故发生率较低，这可能会鼓励改变，改变带来新形式的事故
- 对“原因”的认知限制了防御未来事故的能力。
- 事故后的补救措施通常会增加系统的耦合性和复杂性，而不是增加安全性
- 安全性是系统的特征，而不是组件的特征
- 人类不断地创造安全性
- 无故障运维需要有处理故障的经验
推荐：