从“导弹袭击夏威夷”谈系统设计

如果你留意国际新闻，应当会留意到今年（2018年）1月13日美国夏威夷发生了一件大事：当地时间早上8点03分，所有人都收到了EAS（Emergency Alert System，紧急报警系统）发送的0级短信：夏威夷正处于导弹来袭威胁下。尽快隐蔽。这不是演习。（BALLISTIC MISSLE THREAT INBOUND TO HAWAII. SEEK IMMEDIATE SHELTER. THIS IS NOT A DRILL）。

因为是EAS所发，所以真实性毋庸置疑。再加上，“This is not a drill”对夏威夷来说意义尤其重大——很多人都看过电影《偷袭珍珠港》（又名《虎！虎！虎！》），当日本飞机飞临珍珠港上空的时候，有一名美国水平跑去电报局发电报，内容就是一模一样的“This is not a drill”。所以，这条消息自然引发了夏威夷民众的巨大恐慌，大家四散奔逃，寻找避难场所。我的一位朋友恰好在夏威夷旅游，完整体验了失魂落魄的一幕。

38分钟之后，大家又收到EAS的一条短信：“夏威夷没有导弹威胁。重复。之前是误报”。There is not threat or danger to the State of Hawaii. Repleat. False alarm.

虽然朝鲜危机还没有彻底解决，但在国家安全事务上出现这种事情可不是闹着玩的。尤其是夏威夷人民，自然是出离愤怒。

中文媒体报道此事时普遍强调“乌龙”，以社会新闻的态度来报道海外奇观，中文世界里的讨论也很少。与此不同，美国媒体也进行了大量追根溯源的报道。出于好奇，我总结了自己看到的信息，并打算借这个机会谈谈系统设计。如果你和我一样对事件的来龙去脉、对系统的运行逻辑有兴趣，不妨接着看下去。

这次事故为什么会发生？按照当局说法，报警人员每天会换两次班，每次换班都会进行测试。结果，值班人员本来要选择发送“测试警报”，结果选择了“正式警报”，于是，不幸就发生了。

那么，为什么会把“正式警报”当成“测试警报”？按照前FCC公众和国土安全管理局局长Simpson上将的说法，因为系统太老了，这还是基于PC（操作界面还停留在“上一代”）的系统。警报类型是通过一个普通的下拉菜单来选择的。这样看来，选错也算情有可原。

考虑到预警系统年代久远，我猜下拉菜单大概长这样。

前些年有本关于Web用户界面设计的书很热门，叫《别让我思考》（Do not make me think）。这些年来，移动设备上的用户界面确实进展很大，越来越醒目，越来越符合逻辑，许多时候大家既能够按照直觉来操作，错误操作也能得到及时的防范、反馈、纠正。一切看起来都在朝越来越好的方向进展。

在硬币的另一面，PC上、尤其是面对“内部客户”的操作界面似乎许久也没有更新过了。如果你去电信、煤气之类公司的柜台办业务的时候，留神看过他们的操作界面，就会发现几乎所有界面还停留在十多年前：满屏的菜单、按钮、数据，似乎开发就是一股脑儿把所有的操作按钮和数据都扔到屏幕上了，根本不用考虑用户体验。反正，每个上岗的员工都需要阅读厚厚的手册，反复练习SOP（标准操作规程）。

我和不少Web行业的朋友讨论过这个事情，一种普遍的看法是看不起：这些问题其实不难，但是“传统”行业开不起工资，招不到好人，也就没办法提升效率和用户体验，只能“随他们去吧”。然而，这些行业往往又相当基础，一举一动直接影响巨大。这次“导弹来袭”的乌龙，多半也与此有关。

是不是这些行业的用户界面改进真的那么没价值吗？似乎不是。我也从事过这方面业务的开发，与Web开发可以力求简洁不同，此类业务往往“就是”需要在屏幕上展示尽可能多的数据和操作按钮，同时又要保证操作的高效、明确、准确。把看似矛盾的几种需求聚集于一身，要做好，真不是件简单的事情。

不妨看看美军的做法。前几个月，默虹_美海军学习小站发了一篇文章，讲美国海军的用户界面设计演进过程和理念，很值得参考（原文链接在最后，这里我摘要介绍下）。

在海军的信息系统里，如何准确、迅速地展示各种战场信息？下面两种展现方式，哪种更合适？

告诉你答案吧：两种设计都不合适。第一种不够精确，转来转去的操作也很麻烦。第二种本来还不是这样，最初设计很难准确理解飞机到底往哪飞，所以加上了高度、阴影、速度矢量线，结果整个屏幕乱成了一锅粥。

最终，美军摸索、确定了以本舰为原点，以目标为变量的极坐标方式。实践证明，任何有基本几何知识的高中生，都能准确无误地看懂这张图。

类似的，还有下面这些类似的图表，都是经过了深入思考，被实践证明的展现方式。每一种都凝聚了大量的思考、反复的实践。可以说，这些图表的设计难度，一点也不比面对终端用户的产品低，甚至还要高许多。

说一千道一万，虽然美国海军的用户界面设计值得参考借鉴，弹道导弹入侵报警系统的界面设计估计还停留在相当原始的状态。

在这次乌龙事故中，值得关心的还有一点：为什么8点03分发出错误警报，38分钟之后才发出更正消息？

按照当局的说法，系统设计根本就没考虑过这样的情况。所以警报一经发出，就没法手动取消，更没法更正。所以误报发出之后，官方一度只能通过Twitter来告诉大家“这是误报”。直到忙了整整38分钟之后，官方才找到办法从原误报渠道取消警报、发出更正消息。夏威夷州长Ige说，“已经采取措施缩短更正时间”了。

在机器时代，我们看到很多机器一旦开动就无法立刻停下来，即便结果再坏也不行。这不难理解，似乎和机械的物理特性有关系，没法违背物理规律。但是在软件行业出现这样的情况多少有些说不过去：一旦误报就没法纠正，一旦启动就没法暂停，一旦自动运行就没法手动干预，一旦点错就没法挽回…… 

在我看来，许多软件和系统之所以有这样的特性，并不是因为受到了物理上的限制，而是设计时考虑不周。在面对“你为什么喜欢做软件”时，有一个常见的答案是“控制力强，我可以让电脑（系统）完全按照我的意志去行动”。但是这也带来另一个问题：如果设计（开发）者考虑不够周全，意志的覆盖范围有限，电脑（系统）往往就会不知所措，却仍然处于严密控制之下。遇到例外情况，现场的人只能干瞪眼、空着急——不过，这也正是不少高手“大显身手”的时刻。虽然我坚持认为，真正的高手开发的系统跑起来，不会有太多需要高手“大显身手”的时刻。

不要以为“出钱找好人”就可以解决问题。这次出问题的弹道导弹监控报警系统投入数十亿美元，已经全天不休运行了数十年，用Simpson上将的话说，“没有什么领域比国土安全相关事宜更需要专业素养”。结果是，国防部的系统在测试警报和正式警报之间有一层防火墙，可以严格区分两者，国防部的系统也区分了测试警报和正式警报，测试警报发出时，民众先听到的是“演习！演习！演习！”。然而，这些经验并没有被夏威夷州的报警系统所应用。

当然，报警系统也不是那么好做的。有一些地方政府采取的是比较保守的做法，一定要反复确认险情再触发报警。结果在去年加州的山火中，有一些县因为担心引起恐慌而没有发送警报，导致居民对蔓延的山火全无准备。

这类问题或许没有办法被彻底解决，但改善的空间总是有的，那就是尽可能多地设想可能情境，尽可能多地贴近现实、收集实际的反馈，尽可能细致地思考。试想，如果当初就设计了“误报纠错”流程，本次的乌龙事件也不会闹那么大。

万不要以为这只是产品经历的职责，程序员培养这方面的能力也是相当有价值的。

我听过这么个故事：有套系统已经成型，按照流程走下来，任务生成、分配、调度、执行、结果回收已经做成一条龙服务。但是，总有些特别诡异的问题要排查，因为整套系统是全自动的，所以每次排查都大费周折，都要出动“高手”，高手们也相当乐于出手“力挽狂澜”。后来有个程序员不甘心，觉得事情不该这么办，于是把系统重构，并开发了一套在线诊断系统，于是整个流程可以拆分成细粒度的步骤，每点一下鼠标，就执行一个小步骤，然后详细显示当前的状态、暂停，等待下一次鼠标点击触发…… 

这套系统看起来不稀奇，也不需要什么“高级”的技术。开发它的 程序员却得到了重奖，因为确实为公司解决了大问题，以后出现问题再也不需要动用“高手”了，普通程序员也可以定位问题，而且因为有机制化定位问题的能力，各种机制化的问题也就慢慢暴露出来，被逐个改掉了。那么这位程序员到底做了什么呢？说到底，他无非做了两点：第一，不盲目相信自己的控制力能覆盖一切；第二，赋予其它人合适的控制力。

联系到上面的误报事件，我们似乎可以得到一条经验：系统设计和开发人员不要盲目相信自己的控制力——别忘了，如果要把系统做好，只追求自己的控制力是不够的，其他人也需要有控制力。

---

点击“阅读原文”可以访问默虹_美海军学习小站的《软件也是战斗力：细品美军“宙斯盾”系统人机界面设计》。

本次希望和大家分享的是《黑棋：ISIS的崛起》。世界局势的确很复杂，一种比较普遍但错误的理解是，给各个国家赋予拟人化的性格，似乎“美国”就该这么办，“约旦”就该那么办。然而如果要真正理解事件背后的逻辑，我们就应该知道，拟人化国家的粒度是有问题的，无论美国还是约旦，都有各色利益群体，我们看到的世界其实是各种利益交织作用的结果。了解ISIS崛起之后的来龙去脉，了解它们如何“阴差阳错”诞生，又如何“阴差阳错”地成长、兴旺、衰落，有助于加深我们对世界的了解，也有助于摆脱简单“阴谋论”——我更愿意认为，这是智商上的懒惰或残迹。