美东时间1月11日早间，美国联邦航空管理局（下称FAA）一个关键系统出现故障，导致全美范围内的航班停飞。虽然随后FAA通过社媒更新消息称，全美航班的停飞令已经取消，但这个关键系统的故障，使得美国航空当局开始重新审视维持美国空中交通系统的弹性问题。
A video board shows flight delays and cancellations at Ronald Reagan Washington National Airport in Arlington, Va., Jan. 11, 2023.
Patrick Semansky/AP
据彭博社，FAA表示，仍在继续通过全面评估来查明故障根本原因，但初步调查发现，故障原因是一个“受损的数据库文件”，且没有证据表明是网络攻击所致。
通过wiki/2023_FAA_system_outage 和其它相关报道，可以大致勾勒出出故障的相关情况。
1、出故障的系统是NOTAM（Notice to Air Missions ），NOTAM是美国联邦航空管理局用于报告航空异常事件的系统，包括空域封锁、恶劣天气、跑道关闭等。对于飞行距离更长的国际航班来说，NOTAM可能多达200页，内容包括跑道关闭、一般鸟类风险警告或低空建筑障碍等信息。美媒援引业内人士的话称，过去NOTAM系统从未发生过全美范围内的故障。
作为航空业局外IT人员，G哥判断为NOTAM 虽然不是飞行本身的指挥系统，但是作为航空异常事件通知系统，也属于飞行关键链路系统。如果对应的事件没有被接收到，风险非常高。比如跨国飞行进入封锁空域，抑或停在不正确的跑道上引发未知风险等。
2、美国空中交通管制官员在美东时间1月10日周二晚间意识到空中任务通知系统（NOTAM）出现问题时，他们想出了一个计划，即在周三早间重启系统，以最大限度减少该系统对美国境内航班的干扰。然而，最终该计划导致了停电和大规模的航班延误，随后FAA下令全美范围航班停飞。
1月10日20点30分，部分航班的飞行员已经无法通过网络获得这些信息。FAA紧急开放了电话应答的备用系统，使晚间的航班得以正常飞行。然而随着新一天的到来，航班越来越多，备用系统已经无法支持，FAA随即在东部时间1月11日上午7点30分左右发出指令，在9点前禁止全美所有航班起飞，已经起飞的飞机不受影响。实际上，故障在8:30 后逐步恢复。
2023 年 1 月 11 日，在美国联邦航空管理局 (FAA) 下令航空公司因系统中断暂停所有美国国内航班后，乘客在奥黑尔国际机场等待航班恢复。
Jim Vondruska/路透社
3、故障的引入，一名工程师在例行的定期系统维护期间错误地将一个文件替换为另一个文件后，NOTAM 系统在下午 3 点 28 分停止处理更新。
据一位了解内部审查情况的高级官员称，周三上午地面停飞和美国联邦航空管理局系统故障影响了全美数千次航班，这似乎是例行定期系统维护期间发生错误的结果。
这位官员说，一名工程师“用一个文件替换了另一个文件”，并没有意识到自己犯了错误。随着系统开始出现问题并最终失败，FAA 工作人员狂热地试图找出问题所在。犯错误的工程师没有意识到发生了什么。“这是一个让国家损失数百万美元的无心之失。”
周三早些时候，美国联邦航空局表示，在计算机故障导致全国航班延误和取消后，美国联邦航空局下令在全国范围内暂停所有国内航班起飞至周三上午 9 点后，正常运营正在“逐步恢复”。
4、Southwest, which canceled thousands of flights after Christmas following a systemwide meltdown, was hit hard, with more than 400 canceled flights. About 10% of Southwest’s Wednesday flights had been canceled and about half delayed as of 6 p.m. ET. 影响：（西南航空：10% 航班取消， 半数delay），整个事件，数百万美元。
5、《NOTAM故障给我们的警示》这篇文章谈到FAA的IT运维如此混乱，确实令人感到不可思议，不过这也不是NOTAM第一次出这么大的问题了，2008年的那次故障更为严重。那时候NOTAM中用于记录异常事件的数据库还是跑在Sun sparc服务器上的Oracle数据库（不知道超期服役的NOTAM是不是指的这套系统，可能性还是很大的）。
那次也是因为运维处置的混乱，导致了2008年5月22日下午到2008年5月23日整个白天的大量航班异常。当时的场景也十分简单，根据NOTAM的维护操作规程，一些使用年限超长的硬盘必须被按期更换。本来是很简单的操作，插入新盘，拔出旧盘，rebuild工作自动完成。不过当时出现了问题，更换后系统的运行性能十分糟糕，于是一系列的临时操作中出现了问题，等他们把主系统搞崩掉，准备切换到备用系统的时候，发现故障已经被传播到备用系统了，备用系统也已经被破坏了。于是他们只能把能读出的数据导出，重新建新库，再导入数据，花了差不多一天多的时间才搞定系统。当系统恢复运行时，依然是存在数据不一致的问题的。
可以看出虽然相隔十多年，不过这两次故障的发展过程如出一辙，我真怀疑这两件事是同一批人干的。
6、有官员将当前的中断与假期期间西南航空公司陷入瘫痪的危机进行了比较：关键 IT 网络中过时的软件逾期无法更换。如果一件事发生故障，系统可能会瘫痪。
不难看出，作为美国航空业也面临做IT系统陈旧，对应的技术架构、运维能力、应急等方面“无法承受之重”。
1、在线变更可以导致的业务影响预期。
如果是业务变更，变更灰度（种子用户、内部用户乃至按比例扩大到外部用户）。如果是非业务变更，如后台文件备份，数据备份，设施切换等，要考虑对在线业务的影响无感或者在可控范围。
2、备用系统的可用性和容量问题。从描述“1月10日20点30分，部分航班的飞行员已经无法通过网络获得这些信息。FAA紧急开放了电话应答的备用系统，使晚间的航班得以正常飞行” 看出，NOTAM似乎不具备多地区多机房能力，只能采用电话应答模式临时支持。这一点风险非常高，如果出现关键系统挂掉而无法随时切换的情况。
3、对于故障的态度，一名工程师“用一个文件替换了另一个文件”，并没有意识到自己犯了错误。随着系统开始出现问题并最终失败，FAA 工作人员狂热地试图找出问题所在。犯错误的工程师没有意识到发生了什么。“这是一个让国家损失数百万美元的无心之失。” 虽然这是对外说辞，但仍体现出官僚机构对于技术故障的敷衍。按照清单革命的说法，大部分问题都是无心或者无知之过，但不能成为借口。
一个文件更换错误，为什么会导致一个全局系统不能访问的故障？ 这本应该是隔离考虑的部分？ 第二个是更换文件，如何确保更换后的结果是符合预期的，如何验证？ 从目前的披露来看，肯定还没有涉及到混沌工程和故障演练之类。
对于高风险业务的关键系统，确保高可靠性和高可用，做好服务隔离性设计和监控，做好变更管理，包括运维体系升级都是非常有必要的。
读者有任何建议和讨论，欢迎回复。
— END —
往期推荐：
技术琐话
以分布式设计、架构、体系思想为基础，兼论研发相关的点点滴滴，不限于代码、质量体系和研发管理。