生命关键系统的创新

每个企业都有一个“关键”基础设施。 一般来说，这意味着如果系统下线，部分（或全部）业务将陷入停顿，直到技术人员可以让它再次运行。 这通常发生在需要进行大型软件、硬件或网络升级时：新部署的系统包含导致系统故障的意外错误，或者用户因为不熟悉新系统而在使用新系统时出错，并且生产力停止，直到技术人员能够解决部署错误或培训用户。 在大多数情况下，一段时间的停机或生产力降低是可以接受的风险，以换取提高新技术性能和效率的承诺，但这并不普遍。 大多数企业可以承受一定的停机时间，而不会冒太多收入或激怒客户的风险。

但是，当您需要修改的系统是生命攸关的系统时会发生什么，而生命安全取决于能否可靠地使用该系统？

本文远离我们花费大部分时间的更传统的软件开发，而是着眼于生命关键系统中的人为因素。 我对这个话题的想法源于我作为 911 救护车服务信息技术总监、国际人道主义灾难响应组织的技术专家以及我的博士学位的经历。 在麻省理工学院完成了人类系统集成。

在我们开始之前，我想解释一下为什么这可能与您有关。 虽然您的项目实际上涉及到一个生命攸关的系统可能并不明显，但它的可能性比您想象的要大得多。 以下所有符合条件的，以及无数更多的主题：

• 汽车。 与汽车制造商或其任何供应商合作开展项目？ 被自动驾驶汽车初创公司从大学招聘？ 自动制动、巡航控制、车道控制、计算机视觉、障碍物识别、电子发动机控制模块等。每一个都是生命攸关的系统，其中的故障可能是致命的。
• 航空。 当您在空中飞行 30,000 英尺时，几乎任何系统故障都可能危及生命。 考虑到最近波音 737 MAX 发生的事件，自动驾驶仪和计算机化飞行控制等明显的生命关键系统，但也有很多你可能没有想到的事情。 在家里，如果您的暖通空调系统中的风扇出现故障并产生一点烟雾，您可以打开窗户或走到外面呼吸新鲜空气。 你有没有试过在跨大西洋飞行时打开窗户走出去？ 即使是最基本的系统，从厨房的电源插座到饮料车车轮上的制动器，在飞机上也可能对生命至关重要。
• 通讯。 大多数开发人员或工程师会在其职业生涯的某个阶段以一种或另一种身份从事通信系统项目。 对许多人来说，电信最初似乎并不对生命至关重要。 毕竟，在电话和互联网出现之前，文明的表现还不错。 作为一个部署到电信基础设施被破坏的灾区的人，让我告诉你实际发生的事情：人们生病或受伤，无法拨打911； 老年居民不能打电话给他们的孩子让他们去药房取药； 应急响应人员无法与其调度员或彼此沟通； 无法联系到家人的人开始担心，并把自己置于极其危险的境地试图找到他们。 通信系统对生命至关重要。

在当今严重依赖技术的世界中，您从未认为甚至是半重要的项目最终可能成为生命关键系统的重要组成部分。

但如果它没有坏，就不要修复它

您是否听说过或使用过与技术系统相关的“遗产”一词？ 这是一个强有力的词，唤起了人们对悠久传统、血统和过去困难时期的思考。 在工程界，它用于表示已经存在了很长时间并且已被证明可靠工作并且通常被视为降低风险的理想特征的设计。 实际上，这是对由于风险规避而从未更新过的古老技术的委婉说法，并且在系统故障可能导致可怕后果的行业中普遍存在。

这种对传统软件和硬件的亲和力背后有充分的理由。 它是众所周知的，它不太可能出现未知的错误，并且它的成本是稳定和可预测的。 航天工业就是一个很好的例子：俄罗斯联盟号宇宙飞船已经将宇航员送入太空超过 50 年，在此期间只进行了微小的修改，并且由于可靠和安全而继续使用。 不幸的是，这意味着与现代设计相比，它的效率也极其低下：虽然联盟号的每个座位花费​​ 8100 万美元来使用其传统硬件将宇航员运送到空间站，但 SpaceX 和波音预计每个座位的价格为 5800 万美元使用他们的现代火箭设计。

很少有人愿意升级仍然有效的旧系统，这是可以理解的。 高管不想冒风险，技术人员不想处理机柜中运行时间为 12 年的神秘服务器，客户不想学习新设计。 不幸的是，风险最小化和成本节约之间存在一个临界点：传统设计最终需要升级，即使在高风险环境中也是如此。

本文的其余部分将介绍当您的系统对生命至关重要时执行此操作过程中的一些更重要的步骤，例如急救人员、军事单位或飞机使用的系统。

说服黄铜

根据我的经验，这个过程中最困难的一步可能是让决策者和利益相关者相信需要升级。 在生命攸关的环境中运行的系统通常受到广泛的法律法规和组织政策的约束，这意味着您必须说服他们，他们不仅应该承担风险和花钱，而且还应该参与可能很容易发生的几个多年的官僚剪裁。 您将面临的最强烈反对可能来自法律团队，他们将详细列出您通过引入新技术而使组织面临的潜在责任。 他们是对的：责任是一个主要问题，如果有什么东西坏了，有人受伤或死亡，这可能是一个巨大的道德、声誉和经济负担。

无论您是与财富 500 强公司合作还是与当地的志愿消防部门合作，它总是归结为同一件事：金钱。 公司不想失去它，而非营利组织一开始就没有太多可合作的地方。 我发现说服一个组织的领导层冒险改变一个对生命至关重要的系统的唯一可靠方法是证明，从概率上讲，他们要么更有可能赚钱/存钱而不是赔钱，或者他们可以通过技术现代化和提高安全性来减少他们的责任。

这意味着您需要进行数学计算。 由于错误（基于您组织中以前的部署或来自其他组织的数据）而导致停机时间延长或未来崩溃的可能性有多大？ 如果它确实失败了，预期的影响是什么？成本是多少？ 相反，预期的性能或可靠性增益是多少，它们的价值是多少？ 如果你能证明你很有可能会领先，那么你很有可能会获得绿灯。

这不是关于你

您可能熟悉“工程师为工程师”这个短语，这是一个成语，暗示工程师构建的东西是为具有与他们自己相似资格的人使用的。 这是一个极其常见的事件，并且是 1990 年代初期计算机可用性研究兴起的主要促成因素之一。 作为工程师，我们通常对技术系统如何工作有与普通最终用户不同的心智模型，从而导致在设计系统时假设最终用户已经知道它是如何工作的。 在传统系统中，这会导致错误和不满意的客户； 在生命攸关的系统中，它可能导致死亡。

以法航 447 航班为例。2009 年 6 月 1 日，空中客车 A330 在从里约热内卢飞往巴黎的途中飞越大西洋。 冰晶阻塞了皮托管，导致空气速度测量值不一致。 飞行计算机脱离了自动驾驶仪，认识到它无法可靠地驾驶飞机本身，因为它的空速数据不正确。 然后它将自己置于“扩展飞行包线”模式，允许飞行员执行计算机通常不允许的机动。 您可以想象构建系统的工程师认为“如果自动驾驶仪自行脱离，可能是因为飞行员可能需要额外的控制！ ”

这是工程师的自然思路，他们了解什么样的事情可能导致自动驾驶仪脱离。 对于飞行员来说，情况并非如此。 他们无视“失速”警告，迫使飞机陡峭地向上爬升，直到它失去所有空速并坠入大海。 228 名乘客和机组人员全部遇难。 虽然关于他们行动的确切动机有多种想法，但普遍的理论是飞行员认为飞行计算机会阻止使飞机失速的控制输入（这对于正常的飞行包线来说是正确的），并且没有意识到它已切换到扩展包络模式，因为他们没有共享工程师对驱动计算机决策的逻辑的心理模型。

虽然有点迂回，但这引出了我的主要观点：您希望用户在特定条件下采取的行动必须是用户感觉自然的行动。

可以指示用户遵循特定的程序，但他们并不总是会记住正确的做法或了解在高压力条件下发生的事情。 您有责任以直观的方式设计软件、控件和界面，让用户天生想做他们应该做的事情。

这意味着最终用户参与设计和开发过程的每个阶段是绝对关键的。 不能假设用户可能会做什么； 这一切都必须以证据为基础。 当您设计界面时，您必须进行研究以确定它们在用户中引发的思维模式并根据需要进行调整。 当你测试你的新系统时，你必须在真实的​​环境中和真实的用户一起测试它们。 不幸的是，当您更改设计时，您必须重新执行这些步骤。

尽管每个复杂系统都是独一无二的，但我想特别提及三个设计注意事项，它们应该被普遍应用：

• 控件应该代表它们调用的操作。 幸运的是，这种方式相当普遍，通常表现为为 GUI 按钮选择相关图标或为物理控件选择相关形状。 “新文件”按钮使用一张白纸图标，飞机上的起落架杆有一个轮子形状的旋钮。 但是，很容易变得自满。 为什么我们仍然看到“保存”按钮的 3.5 英寸软盘图标？ 25岁以下的人都知道软盘是什么吗？ 我们继续使用它，因为我们认为它具有代表性，但实际上已经不是了。 它需要不断努力以确保控件的表示对用户有意义，但平衡它与连续性也是必要且困难的。
• 如果警告系统发生故障，它必须是可检测的。 我们经常使用在出现问题时激活的警告灯，例如闪烁的红色指示灯。 这对于吸引用户的注意力非常有用，但是如果灯烧坏了怎么办？ 阿波罗登月任务中使用的航天器有几十个警告灯，用于各种系统，但它们并没有以常规方式运行。 它们不是在出现问题时点亮，而是在一切正常时保持点亮，并在出现问题时关闭。 这确保了烧坏的警告灯不会导致宇航员错过潜在的致命系统错误。 我并不是说您应该使用这种设计，因为自 1960 年代以来，灯泡在可靠性方面已经取得了长足的进步，但它可以让您了解您的一些计划必须有多深入。 有多少次系统崩溃但您不知道，因为日志记录或通知无法正常运行？
• 模式转换对用户来说必须是显而易见的。 如果空客 A330 在用户没有注意到的情况下从正常控制模式转换到高级控制模式，突然飞机做了用户认为它做不到的事情，会发生什么？ 如果自动驾驶汽车脱离其自动驾驶仪，让用户意外地完全控制会发生什么？ 当模式或功能发生任何重大转换需要立即更改用户的操作，但用户需要一两分钟才能弄清楚刚刚发生了什么时，会发生什么情况？ 虽然在复杂系统中可能需要多种操作模式，但在没有足够的通知、解释和与用户交互的情况下，模式无法转换。

将生命攸关的系统滚出车间

根据行业最佳实践，测试阶段对于部署新的生命攸关系统至关重要。 新技术的测试可能已经帮助您纠正了大多数错误和可用性问题，但是当它必须与现实环境中的其他系统一起使用时，可能会出现隐患。 在系统工程学科中，这被称为“涌现”。 紧急属性是“源于应用程序组件与其环境之间的交互的意外行为” ，就其本质而言，在实验室环境中基本上不可能检测到。 通过邀请一组有代表性的最终用户在仔细监督下试用您的新系统，可以检测和评估其中许多属性，以了解可能在全面部署中出现的负面后果。

在与我的客户进行架构讨论时经常出现的另一个主题是分阶段推出。 这是在用新系统的元素逐渐替换现有系统的元素直到最终所有内容都被替换与一次更改所有内容之间的选择。 每种都有优点和缺点：分阶段推出允许用户逐渐适应新设计，确保更改以可管理的数量进行，并且不会让用户不知所措； 另一方面，它可以将过程拖出很长一段时间，并导致持续的过渡状态。 立即推出是有益的，因为它们“撕掉了创可贴”并加快了速度，但突然的剧烈变化可能会让用户不知所措。

对于生命攸关的系统，我发现分阶段推出通常更安全，因为它们允许在生产环境中对单个组件进行增量评估，并在需要回滚某些内容时允许较小的回滚。 但是，这需要根据具体情况进行评估。

偏差归一化

好的，所以您的用户测试帮助您设计了一个直观的系统，您的 beta 阶段识别了紧急问题，您的分阶段推出让用户对设计感到满意，并且一切运行顺利。 你完成了，对吧？ 不幸的是没有。

您的系统将不可避免地出现问题，这是无法解决的。 当用户遇到这些问题时，他们通常会制定解决方法，而不是向技术团队报告问题。 这些变通办法将成为标准做法，作为从老手到新秀的“技巧”分享。 社会学家黛安·沃恩（Diane Vaughan）创造了一个词来描述这种现象：“偏差正常化”。 用户变得如此习惯于异常行为，以至于他们忘记了它实际上是异常的。

经典的例子是挑战者号航天飞机：固体火箭助推器中的一个部件在发射过程中经常被观察到腐蚀，虽然每个人都知道腐蚀火箭部件是一件坏事，但这种情况经常发生，以至于定期发出豁免并被认为是普通的。 1986 年 1 月 28 日，原本大家都知道不应该被允许，但已经正常化的问题，导致了挑战者号的爆炸和七名宇航员的死亡。

作为生命攸关系统的管理员，您有责任防止此类事件的发生。 研究您的用户如何与系统交互。 跟踪他们几天，看看他们是否使用了意想不到的解决方法。 定期发送调查以征求建议的更改和改进。 在您的用户找到在没有您的情况下解决问题的方法之前，花时间和精力来改进您的系统。

压力下的表现训练

当用户遭受压力、肾上腺素激增和视野狭窄时，通常会发生生命关键系统的故障。 它发生在法航 447 的飞行员身上，发生在不记得如何在第一个心脏骤停患者身上操作心脏监护仪的护理人员身上，也发生在士兵在受到攻击时无法正确操作无线电的情况。

通过使用前面讨论的直观设计可以减轻部分风险，但仅此一项是不够的。 特别是在高压力场景确实发生但很少发生的环境中，不仅要培训用户如何操作系统，还要培训用户在这种情况下如何清晰思考。 如果用户记住了与操作设备相关的动作，他们就无法应对意外故障，因为他们学到的动作可能不再适用； 如果他们训练在压力下逻辑清晰地思考，他们可以对不断变化的环境做出反应，并在出现问题时帮助您的系统保持活力。

结论

显然，开发、部署和维护对生命至关重要的软件比在一篇文章中详述的要复杂得多。 但是，这些考虑的领域可能会帮助您更好地了解在考虑从事此类项目时会发生什么。 总之：

• 创新是必要的，即使一切顺利
• 很难让高管相信风险是值得的，但数字不会说谎
• 最终用户必须参与流程的每一步
• 在现实条件下，在真实环境中与真实用户一起进行测试和重新测试
• 不要以为你第一次就做对了； 即使它正在工作，也可能存在您的用户没有告诉您的未检测到的问题。
• 不仅要培训用户如何使用系统，还要培训用户如何清晰地思考和适应压力。

最后，我想指出，在复杂的安全关键系统中，无论您进行多少计划、测试和维护，事情都会在某个时候出错。 当这些系统对生命至关重要时，故障很可能会导致生命或肢体丧失。

万一发生这样的悲剧发生在你要负责的事情上，这将是你良心的沉重负担，你可能会认为如果你多加注意或努力工作，就可以避免它。 也许这是真的，也许不是，但不可能预见每一种可能发生的事情。

一丝不苟地工作，不要自大，你会让世界变得更美好。