【文 / 观察者网专栏作者 张仲麟】
当地时间 7 月 19 日，全球无数打工人突然发现，他们的电脑屏幕要么蓝屏要么连不上系统服务器。而往常非常管用的 " 重启大法 " 也失去了效果，重启之后依然得面对那硕大的蓝屏。
这次微软蓝屏导致的系统瘫痪遍布全球，但在北美尤其严重，对社会运行产生了严重影响：航班停飞、911 热线打不通、酒店无法办理入住、医院取消手术、商店无法营业，而这一切都源于一家鲜为人知的 *** 安全公司 CrowdStrike ——当然现在已经变成家喻户晓了。
这次全球性的 " 蓝屏事件 " 发生的原因说白了并不那么让人意外。作为全球 *** 安全与云计算端点保护领域顶尖公司之一，有大量公司和云服务器使用 CrowdStrike 公司的 Falcon 平台，并且运行在 Windows 平台上。
此次事件，就是由于 CrowdStrike 最新的一个软件更新与 Windows 平台出现了严重的兼容性问题，并由此导致出现了大面积的 " 蓝屏死机 "，而且 " 无限循环 "。如果仅仅局限于个人电脑上也就罢了，但问题更新同样应用在云服务器上（比如微软自家的 Azure 云服务）并且同样导致了严重问题，这使得 " 蓝屏事件 " 对公共领域造成广泛影响，而航空业又首当其冲。
" 蓝屏 " 中的美国航司
由于各个国家的航空公司所采用的信息系统方案各不相同，使得在 " 蓝屏事件 " 中受到的影响也各不相同：有些是自助值机系统无法使用只能柜台办理，有些是登机牌无法打印只能手写，有些则是从值机到配载系统全部无法使用，彻底丧失运作能力。
航空公司的信息系统涉及到微软 Azure 云服务以及基于 Windows 系统的终端是重灾区，最要命的是那些在云服务上运行的信息系统服务器。
那一天，人们终于想起了被蓝屏所支配的恐惧，以及面对 Windows 系统无能为力的屈辱
由于身处美国具有 " 地利 "，美国航空公司就成了本轮 " 蓝屏事件 " 的重灾区了，美国三大航（达美、美国、美联航）一个不落全部遭殃，对所有航班发出地面停飞指令，FAA 要求空中交通管制员告知飞行员，航空公司目前遇到了通信问题。除此之外，捷蓝航空、边境航空、精神航空这些中小航空公司也受到严重影响，关键系统无法使用并导致航班大量取消。
可以看到由于系统崩溃，7 月 19 日美国飞行的航班数量比起前一天明显减少
作为本轮蓝屏事件的主要受害者，达美、美国航、美联航有大量航班被取消，而其中受影响更大的是美国客流量更大的机场——亚特兰大机场。作为全美更大的枢纽机场也是达美航空的基地机场，在本轮 " 蓝屏事件 " 中累计取消了五百多班航班，其中多为达美航空的航班。紧随其后的是芝加哥奥黑尔机场取消了近 200 班、纽约拉瓜迪亚机场取消了三分之一航班。而美国之外欧洲机场的航班也受到了不小的影响，阿姆斯特丹机场进出港航班有 40% 延误，柏林机场有三分之一航班取消。
有意思的是，这一轮大规模系统故障却没有对美西南航空与阿拉斯加航空造成影响，还包括 UPS、FEDEX 这两个航空货运，而其背后的原因又堪称 " 黑色幽默 "。
美西南航空目前使用的航班运控系统是基于 1992 年的 Windows3.1 系统运行的，而其机组调配体系则是基于 *** 呼叫。因此这一轮由于错误更新包导致的 Windows 系统与云服务大规模系统宕机事件，对美西南航空来说真就是 " 系统过于落后，所以毫无影响 "。
UPS 和 FEDEX 也是差不多的情况，他们仍然在使用 Windows95 或者 Windows3.1 来运行其关键运营系统，因此得以躲过这一劫。
而其他没有受到影响的美国航司多是一些地区性的支线航空公司，这些小航空公司的信息与运行系统较为原始，用不起昂贵的云服务，因此也逃过一劫得以正常运行。联想到 2022 年圣诞节北美暴雪天气带来的大范围延误中，美西南由于系统过于落后导致迟迟无法恢复航班运行，本次事件也算是 " 风水轮流转 "，证明了 " 成熟系统 " 所具备的 " 高稳定性 " 优势。
缺位的应急处置
在本轮更新导致大规模系统崩溃的 " 蓝屏事件 " 中，最让人大跌眼镜的莫过于美国三大航在系统崩溃发生后，直截了当地打出了白旗，停飞所有航班。在我看来，这无疑是非常匪夷所思的，因为这些运控系统都是重要系统，不仅仅关系到航空公司自己的日常运控，也是国家关键交通系统的一部分。
此类航空运控系统，往往对其可靠性与强韧性都有着极高的要求，确保不会因为崩溃对航空运作造成严重影响。国际民用航空组织（ICAO）就在一系列文件中对航空运控系统的备份和冗余提出了具体的要求，以避免单一系统崩溃造成严重后果，包括：
要求定期备份关键运营数据。 必须在硬件和软件上实现冗余，包括备用服务器、存储设备等。 必须制定详细的灾难恢复计划，涵盖各种灾难性场景。 关键系统（如空中管制系统）需要具备自动故障切换功能且运行数据同步，主系统一旦发生故障，可以立即切换到备用模式运行。
如果我们看本次 " 蓝屏事件 " 的话，会发现那些美国航司并没有（或者说没做到）灾难恢复计划，也没有实现关键系统故障后自动切换到备份。当然有一种可能是他们确实有备份，但是备份同样遭遇了蓝屏（例如同样基于 Windows 系统运行且被错误更新影响），这就给人一种 " 为了避免鸡蛋放在一个篮子里，于是买了多个 P2P 理财防止暴雷 " 的感觉。
作为一个有着丰富现场经验的人，我对本次美国同行们的表现也是颇为不解，因为航空公司对于此类情况必然会有应急预案，在系统降级或完全不可用的情况下确保更低限度的运作。以我在一线工作中的经历而言，飞机的配载虽然现在都是通过信息化系统进行，但每一个配载人员都保留着手工画配载表的手艺活。一旦发生配载系统故障无法使用，就照着机号对应的机型翻出配载表的 PDF 文档，将配载表打印出来，然后手工配载手工计算，获得飞机起飞数据。而这种手工操作是极为基础的业务技能，年年练、月月练、周周练，就是为了确保需要切手动计算的关键时刻不会掉链子。
手工操作是这个行业的基本功
而其他相关环节及部门也一样对应急演练有着近乎偏执的要求。作为与值机部门有工作交叉的部门，我们几乎每个月都能接到来自值机的 *** ，要求建立一个虚拟航班以供他们进行应急演练。而值机应急演练的内容就是中航信系统（国内使用的民航运营系统）宕机的情况下，基于本地模式进行旅客值机和登机牌办理，甚至在无法打印的情况下给旅客手写登机牌让旅客登机。
也因此，当看着美国同行因为值机系统、配载系统等诸多系统随着 " 蓝屏事件 " 挂掉，导致航班运作彻底瘫痪时，我就很不解：你们平时不练手工的么？你们就没有应急预案么？你们应急预案不演练的么？你们没有备份系统么？
为何中国没有受到影响
这次影响全球的 " 蓝屏事件 " 对中国几乎没有造成影响，中国民航运作完全正常，仅有一些外航航班（如美国航空、美联航）受国外影响导致了延误，其原因也并不复杂。
首先，对于终端电脑来说，是使用 Windows 系统且涉及到安装了 CrowdStrike 公司的安全软件，在更新了错误补丁后，才会产生无限 " 蓝屏重启 " 的问题，而国内航司电脑终端往往并不使用该公司的安全软件。而且对于系统更新往往是比较谨慎的态度，没事不会更新，使用的 Windows 版本也是更成熟稳定的老版本为主。
其次，国内航空公司大部分使用的都是中航信系统，其运行环境基于 Linux，也没有使用微软的 Azure 云服务或者亚马逊的 AWS。这一定程度上避免了我国民航关键基础系统遭遇错误更新所导致的全面崩溃。
作为事关中国民航运作的重要系统，中航信所运营的计算机系统和 *** 属于一种 " 关键基础信息系统 "，被列入国务院监管的八大重点系统之一。除春秋航空等少数航空公司外，其他航空公司均使用中航信系统。中航信系统的安全性和稳定性也得到了国家的高度重视和严格监管，确保了系统的稳定性与可靠性。
当然这并不代表中航信系统不会出现问题，在 2020 年 8 月 25 日就曾发生过中航信离港系统使用异常，导致部分机场无法值机的问题。根据通报，在当天上午 10 点 32 分发生异常导致部分机场无法值机，在 11 点 07 分就全部恢复了正常。虽然造成了一定影响，但由于仅持续了半个小时，因此没有造成较大影响，总体运行平稳。
虽说中航信系统几十年不改的指令操作界面饱受诟病，但对关键基础信息系统来说，运行稳定是压倒一切的。而基于完全自主的信息系统与运行环境，也让我们得以避免遭受 " 蓝屏事件 " 的池鱼之祸，避免如美国同行那样闹个大笑话。
通过这起事件，我们也更加意识到了，在关键信息系统已经成为重要基础设施的当下，实现完全的自主可控是极为重要的。而这不仅仅包括信息系统，也包括操作系统。在 *** 安全形势越发严峻的当下，其必要性已经无需质疑了，这不仅仅是技术层面的选择，更是国家安全与产业发展的战略需要。
发表评论