上周三美国FAA NOTAM系统导致了数千航班的延误，一千多航班取消，这件事在国内被疯狂炒作。NOTAM是美国联邦航空管理局用于报告航空异常事件的系统，包括空域*、恶劣天气、跑道关闭等。
因为这几天事情比较忙，因此虽然有不少朋友聊到这件事，我也没有太关注这个事情。周五的时候，一个客户打电话和我讨论这个事件，说他们领导要他们写份材料，分析一下从NOTAM事故中能吸取到什么经验教训，他和我讨论如何写这篇文章。当时我手头看到的信息很少，甚至还没有搞清楚是data file还是database file故障导致了问题，因此也不太好分析当时到底是什么地方出现了问题。
于是我说可以从两个方面讨论吧，一个是系统可用性的增强，如何在出现大问题的时候确保系统关键功能可用，在线备份系统要经常演练，确保其可用;另外一个是如何防止主系统错误的传播，避免主系统故障传播到备份系统。
周末看到有些微信群的朋友在讨论这个问题，正好在乡下闲着无事，于是查找了一些关于1月11日NOTAM故障的资料，用谷歌一搜居然发现*已经有了这个条目，通过*我们了解到了更丰富的信息。
从标红的字上，我们可以看到是在一次例行检修中一个工程师在生产系统中错误地替换了一个数据文件导致了数据库故障，致使NOTAM系统无法写入新数据，最终引发了这个惨剧。周六在一个微信群里有人讨论这个问题，我还说好像还不确定数据文件还是数据库文件，其实我也不希望是DBA的错误操作导致了问题，不过从*的描述中可以看出，这次故障好像还是必须DBA出来背锅。
这短短的几个字含义十分丰富，可以确定的是运维人员的失误是导致这次故障的最主要原因。前阵子几个朋友在聊到疫情的时候还开玩笑，疫情再不结束，老板会发现没有DBA的在现场工作，系统会变得更稳定。因为他们在做年终总结的时候，发现DBA经常因为封闭而无法上班的2020年和2022年，是最近十年里系统故障率最低的2年。
错误替换文件意味着一次比较大的维护作业，*中说的是一项周期性例行作业。实际上可能不完全如此。
从ABC的一篇报道中周二晚上联邦交通部长发布的消息中可以看到实际上周二晚上已经将系统切回了主系统，但是主系统依然存在问题。从ABC的报道的细节中可以看出，NOTAM曾经切换到了备用系统，不过数据存在问题，因此后来还是被再次切换回了主系统，并且很快就彻底歇菜了。在此期间，他们也祭出了DBA的终极绝招-重启大法，不过依然无效。于是11日FAA只能发布故障公告。
FAA在次日的0:45分就发布了紧急通告。从上述信息虽然还是无法了解整件事的完整过程，甚至连损坏的是什么数据库文件都不清楚。不过NOTAM的高可用系统建设水平之低，还是令人吃惊的。
从ABC的另外一篇报道《Software maintenance mistake at center of major FAA computer meltdown: Official》中我们可以看到更多的一些细节，这个工程师做出了错误的文件替换后，系统故障了，但是他并没有意识到他的错误操作，也并没有把他的错误操作与随后发生的故障联系在一起。而他的同事则“疯狂”地查找问题的原因，期间犯下了很多错误，最终导致灾难无法挽回。这些低级错误居然会发生在FAA的系统上，真的有些匪夷所思。
在这篇报道的最后，还含蓄地说这是一次故障，而不是故意破坏。这和我们事后打板子时候的风格也十分类似，板子高高举起，轻轻落下。最后一行字也十分令人回味，这套系统已经早就已经超期服役了。
FAA的IT运维如此混乱，确实令人感到不可思议，不过这也不是NOTAM第一次出这么大的问题了，2008年的那次故障更为严重。那时候NOTAM中用于记录异常事件的数据库还是跑在Sun sparc服务器上的Oracle数据库(不知道超期服役的NOTAM是不是指的这套系统，可能性还是很大的)。那次也是因为运维处置的混乱，导致了2008年5月22日下午到2008年5月23日整个白天的大量航班异常。
当时的场景也十分简单，根据NOTAM的维护操作规程，一些使用年限超长的硬盘必须被按期更换。本来是很简单的操作，插入新盘，拔出旧盘，rebuild工作自动完成。不过当时出现了问题，更换后系统的运行性能十分糟糕，于是一系列的临时操作中出现了问题，等他们把主系统搞崩掉，准备切换到备用系统的时候，发现故障已经被传播到备用系统了，备用系统也已经被破坏了。于是他们只能把能读出的数据导出，重新建新库，再导入数据，花了差不多一天多的时间才搞定系统。当系统恢复运行时，依然是存在数据不一致的问题的。
可以看出虽然相隔十多年，不过这两次故障的发展过程如出一辙，我真怀疑这两件事是同一批人干的。回到我那个朋友要写的那篇文章上，从这次事故，我们能学到什么呢?
首先，如此关键的系统，在线备份系统(这里我没有说灾备系统，而是在线备份系统，可以是灾备系统，也可以是一个简化的同数据中心备份系统，甚至可以是一个CDM系统，不过在线备份系统起码要能够符合SLA的前提下，支撑起码80%以上的业务高峰负载)是十分必要的。在线备份系统的存在可以确保关键业务不会因为某个IT故障而停止运行。
第二个方面是在线备份系统要有防止故障传播的能力，我搞运维的这二十多年里遇到过多次生产系统故障，灾备系统产生同样故障的案例。错误操作，数据逻辑错误等是会随着复制传播的。需要通过一些技术手段来防范此类故障。早期有些用户使用延迟应用备机来防止主系统的逻辑错误。不过现在有更丰富的手段来规避此类问题。比如存储复制时在备份存储上的定期快照，ADG备库上启用闪回等。
第三个方面是确保备用系统可用的问题。很多备用系统可能永远没有被启用过，当真的需要启用的时候，往往就会掉链子。为了避免这个问题，很多银行采用同城双机房轮流运行的模式，至少每年有2-3个月在备用机房运行核心系统，从而确保备系统随时都是可用的。不过这种模式需要建设1:1的备用系统，对于影响面十分巨大的关键系统，这点投资是完全必要的。根据ABC的报道，本次NOTAM故障造成的因为航班取消延误的直接经济损失是数百万美金，如果早点把钱投入到IT系统上，会好很多。
第四个方面就是关键系统超期服役的问题，系统刚刚建好时候问题不多，而超期服役产生的隐患是巨大的，一方面超期服役的系统往往需要更为细致，更多的例行运维，这也增加了故障的可能性。
第五个方面就要谈谈运维了，从这次故障以及2008年那次故障来看，运维团队的责任是很大的。因为运维团队的不专业操作导致了这两次故障从小问题变为大问题。实际上，对于有备系统的关键业务系统，其硬件变更操作的流程应该是首先升级备系统，确认无误后主系统切换到备系统运行，然后再去升级主系统。不知道为什么NOTAM系统没有按照这个工作流程去操作。至于操作中的一些问题，实际上是十分明显的，大家从几篇报道中自己就能体会出来，我就不细说了。实际上，到目前为止，我并没有看到更为细致的描述，也不能用维护Oracle的思路来猜测其中发生的问题的原因。本次故障，不需要特别专业的解读，已经看到了很多我们可以借鉴，并在运维工作中避免的问题了。