每个企业都有一个“关键”基础设施. 一般, 这意味着如果系统脱机, 部分(或全部)业务将陷入停顿，直到技术人员能够让它重新运转起来. 这种情况经常发生在大型软件中, 硬件, 或者需要进行网络升级:新部署的系统包含导致系统故障的意外错误, 或者用户因为不熟悉新系统而犯错误, 在技术人员能够解决部署错误或培训用户之前，生产力就会停止. 在很大程度上, 一段时间的停机或生产力下降是可以接受的风险，以换取新技术的性能和效率的提高, 但这并不普遍. 大多数企业可以承受一定的停机时间，而不会冒太多收入或与客户对抗的风险.

但是当你需要修改的系统是 生死攸关的系统在这种情况下，生命安全取决于能否可靠地使用系统?

本文不再讨论我们花费了大量时间和精力的传统软件开发, 而不是, 看看生命关键系统中的人的因素. 我对这个话题的想法源于我作为911救护车服务信息技术总监的经历, 作为一个国际人道主义灾难应对组织的技术专家, 还有我的博士学位.D. 在麻省理工学院完成了人类系统集成的研究.

在我们开始之前，我想解释一下为什么这可能与你有关. 虽然它可能不明显，你的项目实际上涉及到一个生命关键系统, 这种可能性比你想象的要大得多. 以下所有内容都符合条件，以及无数其他主题:

• 汽车. 与汽车制造商或其供应商合作一个项目? 大学毕业后被一家自动驾驶汽车创业公司招募? 自动制动, 巡航控制系统, 车道控制, 计算机视觉, 障碍识别, 发动机电子控制模块, 等. 每一个都是生命攸关的系统 失败可能是致命的.
• 航空. 当你在3万英尺的高空时，几乎任何系统故障都可能危及生命. 考虑 最近的波音737 MAX事件, 显然，自动驾驶仪和计算机化飞行控制系统对生命至关重要, 但也有很多事情你可能没有想到. 在家里, 如果暖通空调系统中的风扇失灵并产生一点烟雾, 你打开窗户或走到外面呼吸新鲜空气. 你有没有试过在跨大西洋的航班上打开窗户走出去? 即使是最基本的系统, 从厨房里的电源插座到饮料车轮子上的刹车, 在飞机上是否对生命至关重要.
• 通信. 大多数开发人员或工程师都会, 在他们职业生涯的某个阶段, 以一种或另一种身份从事通信系统项目. 对很多人来说, telecommunications don’t initially seem life-critical; after all, 在电话和互联网出现之前，文明发展得很好. 作为一个曾被派往电信基础设施被摧毁的灾区的人, let me tell you what actually happens: people become very ill or injured and can’t call 911; elderly residents can’t call their kids to ask them to pick up their prescriptions from the pharmacy; emergency responders can’t communicate with their dispatchers or with each other; and people who can’t contact their family members become concerned and put themselves in extremely dangerous situations to try to find them. 通信系统绝对是至关重要的.

在当今这个高度依赖科技的世界里, 你从未考虑过的项目，甚至是半重要的项目，最终可能成为一个生命关键系统的重要组成部分.

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

你是否听说过或使用过“遗产”这个词来指代技术系统? 这是个很重的词, 唤起对长期传统的思考, 血统, 还有过去的艰难时光. 在工程领域, 它用来表示已经存在了很长时间的设计，并且被证明是可靠的，并且通常被视为降低风险的理想特征. 在现实中, 这是一种委婉的说法，指的是由于规避风险而从未更新过的过时技术, 在系统故障可能导致可怕后果的行业中，这种现象普遍存在.

这种对传统软件和硬件的喜爱背后有很好的理由. 大家都知道这是有效的, 不太可能出现未知的bug, 而且它的成本是稳定和可预测的. 一个很好的例子就是航天工业:俄罗斯 联盟号飞船 把宇航员送入太空已经有50多年了，在此期间只有一些小的修改, 它继续被使用，因为它可靠和安全. 不幸的是, 这意味着与现代设计相比，它的效率也非常低:而联盟号使用其传统硬件将宇航员送往空间站，每个座位花费美国宇航局8100万美元, 预计SpaceX和波音公司将提供座位 5800万美元 每个都使用他们的现代火箭设计.

It is understandable that few people 想要 to upgrade old systems that still work; executives don’t 想要 the risk, 技术人员可不想处理一台正常运行时间长达12年的神秘服务器, 客户也不想学习新的设计. 不幸的是，在风险最小化和成本节约之间存在一个临界点: 遗产设计最终需要升级，即使是在高风险的环境中.

本文的其余部分将介绍在您的系统对生命至关重要的情况下执行此操作的一些更重要的步骤, 比如急救人员使用的那些, 军事单位, 或飞机.

说服高层

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

不管你是在一家财富500强公司工作，还是在当地的志愿消防部门工作, 一切都归结为同一件事:钱. 企业不想失去它，而非营利组织一开始就没有太多可以合作的地方. 我所发现的唯一可靠的方法，就是说服一个组织的领导去冒险改变一个关乎生命的系统, 从概率, 他们更有可能赚钱/省钱而不是赔钱, 或者他们可以通过技术现代化和提高安全性来减少他们的责任.

这意味着你需要做数学计算. 由于错误(基于您组织中以前的部署)而导致停机时间延长或将来崩溃的可能性有多大, 或者其他组织的数据)? 如果它失败了，预期的影响是什么?代价是什么? 相反，预期的性能或可靠性增益是什么?它们值多少钱? 如果你能表现出这一点，你就很有可能脱颖而出, 你很有可能会得到批准.

这与你无关

你可能对“由工程师”这个短语很熟悉, 为工程师,这个成语暗示工程师们建造了一些东西，供与他们资质相似的人使用. 这是一种非常常见的现象，也是计算机可用性研究在美国兴起的主要促成因素之一 1990年代早期. 作为工程师, 对于技术系统如何工作，我们的思维模式往往与普通终端用户不同, 导致在设计系统时倾向于假设最终用户已经知道系统的功能. 在常规系统中, this leads to errors and unhappy clients; in 生死攸关的系统, 它会导致死亡.

考虑的例子是 法航447航班. 2009年6月1日，一架从里约热内卢飞往巴黎的空客A330飞机正在大西洋上空飞行. 冰晶阻塞了通道 空速管，导致风速测量结果不一致. 飞行计算机脱离了自动驾驶仪, 他们意识到，如果没有正确的空速数据，飞机本身就无法可靠地飞行. 然后它把自己放进一个 “扩展飞行包线” 模式，它允许飞行员执行计算机通常不允许的操作. 你可以想象建造这个系统的工程师是怎么想的 如果自动驾驶仪自动脱离, 这可能是因为飞行员可能需要额外的控制!”

这是工程师们的自然思路, 谁知道什么样的事情可能会导致自动驾驶仪脱离. 对于飞行员来说，情况并非如此. 他们迫使飞机陡然向上爬升, 忽略“STALL”警告, 直到它失去了所有的空速，坠入大海. 机上228名乘客和机组人员全部遇难. 虽然关于他们行为的确切动机有多种说法, 流行的理论是，飞行员认为飞行计算机可以防止控制输入导致飞机失速(这对正常的飞行包线是正确的)。, 他们没有意识到它已经切换到扩展包络模式，因为他们不同意工程师对驱动计算机决策的逻辑的思维模式.

虽然有点迂回，但这将引导我们进入我的主要观点: 您希望用户在特定条件下执行的操作必须是以下操作 让用户感觉自然.

可以指导用户按照特定的程序操作, 但他们并不总能记住正确的做法，或者理解在高压力条件下发生的事情. 设计软件是你的责任, 控制, 和界面的直观方式，使用户固有 想要 去做他们应该做的事.

这意味着终端用户参与设计和开发过程的每个阶段是绝对关键的. There can be no assumptions made about what users will probably do; it must all be evidence-based. 当你设计界面时, 您必须进行研究，以确定它们在用户中引起的思维模式，并在必要时进行调整. 当你测试你的新系统, 您必须在真实的环境和真实的条件下与真实的用户进行测试. 不幸的是，当你改变你的设计时，你必须重新做这些步骤.

尽管每个复杂系统都是独特的, 我想提到三个设计方面的考虑, 特别是, 这应该普遍适用:

• 控件应该代表它们所调用的操作. 幸运的是, 这是相当普遍的, 通常以为GUI按钮选择相关图标或为物理控件选择相关形状的形式出现. “新建文件”按钮使用白纸图标, 飞机上的起落架杠杆有一个轮子形状的旋钮. 然而，人们很容易变得自满. 为什么我们仍然看到3.5”软盘图标为“保存”按钮? 25岁以下的年轻人知道软盘是什么吗? 我们继续使用它，因为我们认为它是有代表性的，但它真的不再是. 它需要不断的努力来确保控件的表示对用户是有意义的, 但要在这与连续性之间取得平衡也是必要的，也是困难的.
• 如果警报系统坏了，它必须是可检测到的. 我们经常使用警示灯，当出现问题时就会激活，比如闪烁的红色指示灯. 这对于吸引用户的注意力是很好的，但是如果灯烧坏了怎么办? 阿波罗登月任务中使用的航天器有几十个各种系统的警示灯, 但它们并没有以传统的方式发挥作用. 而不是在问题出现的时候给他们指明方向, 当一切正常运转时，他们仍然被照亮 从 当有问题的时候. 这确保了熄灭的警示灯不会导致宇航员错过潜在的致命系统错误. 我并不是说你应该使用这种设计, 自20世纪60年代以来，灯泡在可靠性方面取得了长足的进步, 但它给了你一个想法，你的一些计划必须有多深入. 有多少次系统崩溃了而你却不知道, 因为日志记录或通知不能正常工作?
• 模式转换对用户来说必须是明显的. 如果一架空客A330在用户没有注意到的情况下从普通控制模式切换到高级控制模式，会发生什么, 突然间，飞机做了用户认为它做不到的事情? 如果自动驾驶汽车脱离自动驾驶会发生什么, 让用户意外地完全控制? 当模式或功能发生重大转变，需要立即改变用户的操作时，会发生什么, 但用户需要一两分钟才能弄清楚刚刚发生了什么? 而在一个复杂的系统中，可能需要多种操作模式, 没有足够的通知，模式不能转换, 解释, 以及与用户的互动.

将生命关键系统从商店中滚动出来

符合行业最佳实践, 测试阶段对于部署新的生命攸关型系统至关重要. 对新技术的测试可能已经帮助您纠正了大多数错误和可用性问题, 但是，当它必须与现实环境中的其他系统一起使用时，潜在的危险可能会浮出水面. 在系统工程规程中，这被称为“出现."涌现属性是 源于应用程序组件与其环境之间交互的意外行为,” 它们的本质是不可能在实验室环境中检测到的. 邀请一组有代表性的最终用户在仔细的监督下试用您的新系统, 可以检测和评估许多这些属性，以确定在全面部署中可能出现的负面后果.

在与我的客户讨论体系结构时经常出现的另一个主题是分阶段推出. 这是一种选择:用新系统的元素逐渐替换原有系统的元素，直到最终所有元素都被替换. 一次改变一切. 每种方法都有优点和缺点:分阶段推出允许用户逐渐适应新设计, ensuring that changes come in manageable amounts and users aren’t overwhelmed; on the other hand, 它可以在很长一段时间内拖出过程，并导致不断的过渡状态. 立即推出是有益的，因为它们“撕掉创可贴”，加快了事情的发展, 但突然的剧烈变化可能会让用户不知所措.

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

偏差归一化

OK, 所以你的用户测试帮助你设计了一个直观的系统, 你的测试阶段确定了紧急问题, 您的分阶段推出允许用户适应设计, 一切都很顺利. 你做完了，对吧? 不幸的是不.

您的系统不可避免地会出现问题，这是无法避免的. 当用户遇到这些问题时, 他们通常会开发解决方案，而不是向技术团队报告问题. 这些变通办法将成为标准做法，作为“窍门”从老兵那里分享给新人. 社会学家Diane Vaughan创造了一个短语来描述这种现象:偏差归一化.“用户变得如此习惯于越轨行为，以至于他们忘记了这一点, 事实上, 不正常的.

典型的例子是航天飞机挑战者号:固体火箭助推器中的一个部件在发射过程中经常被观察到腐蚀, 虽然每个人都知道腐蚀火箭部件是一件坏事, 这种情况发生得如此频繁，以至于豁免被定期发布，这被认为是正常的. 1月28日, 1986, 每个人最初都知道的问题不应该被允许, 但是他们已经标准化了, 结果是 挑战者号爆炸 以及七名宇航员的死亡.

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

压力下的表现训练

当用户承受压力时，通常会出现生命攸关系统的故障, 肾上腺素激增, 还有狭窄的视野. 法航447航班的飞行员就是这样, 这种情况发生在医护人员身上，他们不记得如何对第一个心脏骤停的病人操作心脏监护仪, 士兵们在交火中不能正确操作无线电.

如前所述，使用直观的设计可以改善这种风险, 但仅凭这一点是不够的. 特别是在高压力场景确实发生但不经常发生的环境中, 培训用户非常重要，而不仅仅是如何操作系统, 但在这种情况下，如何清晰地思考. 如果用户记住与操作设备有关的动作, they can’t deal with unexpected failures because the actions they learned may no longer be appropriate; if they train to think logically and clearly under stress, 它们可以对变化的环境做出反应，并在出现故障时帮助您的系统保持活力.

结论

很明显, 发展中, 部署, 而且维护对生命至关重要的软件要复杂得多，一篇文章无法详细描述. 然而, 考虑这些方面可能会帮助您更好地了解在考虑从事此类项目时所期望的内容. 总而言之:

• 创新是必要的，即使一切都很顺利
• 很难让高管们相信这样的风险是值得的，但数字不会说谎
• 最终用户必须参与流程的每一步
• 在真实的环境和真实的条件下与真实的用户进行测试和再测试
• Don’t assume that you got it right the first time; even though it’s working, 可能存在用户没有告诉您的未检测到的问题.
• 培训用户不仅仅是如何使用系统，还包括如何在压力下清晰思考和适应.

在关闭, 我想指出的是在复杂的安全关键系统中, 无论计划多么周密，事情总有出错的时候, 测试, 还有维护. 当这些系统对生命至关重要时, 一次失败很有可能导致生命或肢体的丧失.

如果这样的悲剧真的发生在你负责的事情上, 这将是你良心上的沉重负担，你可能会认为，如果你更注意或更努力，你可以避免它. 也许这是对的，也许不是，但是预见每一个可能发生的事情是不可能的.

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