海外跟团游费用虚拟社区

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

余晟以为 2019-06-12 00:03:00

如果你留意国际新闻,应当会留意到今年(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崛起之后的来龙去脉,了解它们如何“阴差阳错”诞生,又如何“阴差阳错”地成长、兴旺、衰落,有助于加深我们对世界的了解,也有助于摆脱简单“阴谋论”——我更愿意认为,这是智商上的懒惰或残迹。

Copyright © 海外跟团游费用虚拟社区@2017