历史上的一次大的因为用户界面导致的灾难 [译]
我想花点时间探讨历史上的一次大的因为用户界面导致的灾难：1988 年 7 月 3 日，美军海军导弹巡洋舰 USS Vincennes (CG-49) 在波斯湾上空误击伊朗航空 655 号航班，机上 290 人全部遇难。
当时，这起灾难令人不解。Vincennes 装备了当时最新的宙斯盾作战系统（Aegis Combat System），这是全球最先进的防空系统，利用先进的计算机技术设计用于同时识别、追踪并击落数百架苏联轰炸机。那么，它如何可能在面对一架单独的民用飞机时犯下如此严重的错误呢？
美国海军的官方报告完全为宙斯盾开脱，将责任归咎于舰员。但后来曝光的细节强烈表明，击落事件至少部分是因为宙斯盾用户界面的重大缺陷。
如果你对这个事件不太了解，可以在维基百科上找到一个页面，里面有详细的介绍（https://en.m.wikipedia.org/wiki/Iran_Air_Flight_655）。因此，我不打算回顾整个事件，而是想专注于导致 Vincennes 舰长和船员犯下这一重大错误的用户界面问题。
（这是一个复杂的话题，我会尽量简短地说明，保证。）
1988 年 7 月 3 日被 USS Vincennes 击落的空客 A300B2-203 EP-IBU 飞机。
美国海军导弹巡洋舰 USS Vincennes。
伊朗航空 655 号航班被灾难性击落的第一个用户界面缺陷出现在飞机从伊朗班达尔阿巴斯国际机场起飞后不久。
无论是过去还是现在，世界上所有大型飞机都装有一种称为 IFF（“识别敌友”）的装置。这是一个无线电应答器，能够对请求做出回应，提供一组代码，以表明飞机是民用还是军用，以及其类型。
Flight 655 安装了识别友敌系统 (IFF)，并准确报告其为民用客机。起飞后不久，Vincennes 查询其 IFF，得到确认为民用客机。到此为止，一切正常。
问题出在 Aegis 系统的 IFF 控制台操作上。操作员通过控制器移动光标至目标位置，并按下按钮来“锁定”新目标进行追踪。一旦“锁定”，Aegis 就会追踪该目标。但问题是，除非操作员执行额外步骤，将光标固定于该目标，否则随着目标移动，光标不会跟随。它将继续在目标_原来的位置_发送 IFF 请求，直到操作员再次移动光标。
在 Flight 655 的情况中，操作员正确地锁定了目标，但未固定光标。因此，当 Flight 655 离开时，Vincennes 仍向其起飞跑道发送 IFF 请求。
紧接着从该跑道起飞的是伊朗的一架 F-14 军用战斗机。光标在跑道上停留约 90 秒，足以让 Vincennes 接收到军用战斗机的 IFF 响应。于是 Flight 655 从未知目标被重新归类为可能的敌对目标。
当 Vincennes 船长和船员查看显示器时，他们从那时起看到的是一个被标记为 F-14 战斗机的、朝他们方向前进的目标。
一名水手操作 Aegis 控制台
接下来的问题源于 Aegis 系统向船员反馈数据的方式。
整个系统基于屏幕设计。每位船员都有自己的屏幕来处理他们负责的数据。这些数据随后汇总到一组大型显示器上，供船长和高级官员监控总体情况。
这本身并无不妥。但关键在于，为高层决策者设计的“大局观”仪表板视图的成败完全取决于提供给该视图的数据。设计仪表板需要压缩和总结信息。如果简单地传递所有信息，会令决策者不堪重负。因此，问题在于决定包含哪些信息，而哪些不包含。
在 Aegis 防御系统的原始版本中，大型显示屏可以展示所有被跟踪目标的位置和航向，但并未显示它们的高度。这一点至关重要，因为高度，尤其是高度的变化，是判断被跟踪目标意图的关键线索。例如，如果一架飞机正向你飞来但同时在上升，它攻击你的可能性就较低。相反，如果它向你俯冲，这通常预示着攻击。
Vincennes 舰长在监视一个向他靠近的目标时，由于大屏幕没有显示高度信息，他无法迅速判断该目标是在上升还是下降。这些关键信息虽然存在，但只能在操作员的小屏幕上深入查找，而非在大屏幕的总体情况展示中。
Aegis 在 USS Vincennes 上的显示屏
随着 Flight 655 逐渐靠近，Vincennes 的舰长意识到他需要明确该飞机是在上升还是下降。因此，他请求了这一信息，但这时发生了第三次也是最后一次用户界面（UI）的失败。
Aegis 的一大特色功能是能从多艘船只的传感器中提取并统一展示数据。在一个任务组中，所有船只通过数据链路相连。当多艘船只监测到同一个目标时，Aegis 能自动整合这些信息，形成一个对所有连接船只上的操作员都可见的统一跟踪目标。
为了方便识别这些被跟踪目标，Aegis 会为每一个新目标分配一个四位数的追踪编号。不同船只对同一目标的追踪编号可能不同。Aegis 将整合这些信息，选定一个编号作为官方编号，并舍弃其他编号。
然而，这个过程中存在两个用户界面问题。首先，被舍弃的追踪编号会被回收利用，分配给新的目标。其次，当 Aegis 改变某个目标的追踪编号时，并没有明显的提示，编号只是在显示屏上默默变化。
当 Flight 655 起飞时，同时被 Vincennes 和其护航舰 USS Sides 发现并追踪。Vincennes 给它分配的追踪编号是 4474，而 Sides 分配的是 4131。Aegis 将这两个监测信息统一在 4131 这个编号下。随后，4474 这个编号被重新分配给了一架正在下降的美国 A-6 轰炸机。
在做出开火决定的关键时刻，Vincennes 号的舰长请求了一份关于飞机高度的报告。但他未意识到飞机的追踪编号已变更，还以为它是原先分配的 4474 号。因此，他要求了关于 4474 号的信息，值班人员便在控制台输入了这个编号。结果显示目标正在快速下降。
事实上，655 航班并未下降，自从从 Bandar Abbas 起飞后一直在上升。但在这个决定性时刻，Aegis 系统的操作员却在监视另一架完全不同的飞机。
一架美国 A-6“入侵者”轰炸机。
接着，Vincennes 号舰长下达了开火命令，随后发生的是一场悲剧。
我不是要把这次误击事件的全部责任推到 Aegis 身上。实际上，如果你去查看维基百科，会发现那天早晨出现了许多问题。
但同时，Aegis 系统在此也不是完全无辜。其界面设计不佳，导致 Vincennes 号的船员误解了他们所面临的真实情况。
海军的报告责怪船员没有正确使用系统，但对于那些设计信息系统的人来说，这显然是在逃避责任。人在压力下容易犯错，而战斗场合的压力尤为巨大。如果一个系统不能适应这种压力环境——如果它不能全力支持操作员，即使在出现失误时也能确保他们获取必要信息——那么问题不在于操作员，而在于设计者。
附言：如果你想深入研究这个话题，我找到的最佳资料是美国空军上尉 Kristen Ann Dotterway 于 1992 年撰写的硕士论文《复杂动态系统的系统分析：USS Vincennes 事件研究》。
Dotterway 上尉在论文中逐分钟梳理了事件的经过，比较了海军的官方说法和 Vincennes 号舰长后续采访中的陈述，并提供了揭示海军说法漏洞的数据。
这份文档篇幅颇厚，但若你渴望深入探索该领域，它会引领你走得比维基百科页面上的信息更远。你可以通过以下链接下载该文档的 PDF 版本：