数据库故障致美国超一万航班取消或延迟

在2023年新年的第二周，美国东部时间1月11日上午，6点29分，美国航空监管机构（FAA）发布了一条仅40字的通告，随后不久，很快就宣布停飞全美所有国内航班。通告内容是，FAA正在对NOTAM（Notice to Air Missions）系统进行验证和恢复，在第一条通知之后的50分钟，FAA就宣布停飞所有国内航班。 这应该是自2001年911袭击以来首次出现如此大规模的禁飞。 在两个小时之后，也就是8点50分，FAA宣布NOTAM系统已经恢复，并彻底取消了之前的“禁飞令”。
FAA在当天的晚上18点31分，宣布这次系统宕机是由数据库文件受损导致的，并还将持续跟进并改进。

什么是NOTAM NOTAM是“Notice to Air Missions”的缩写，该系统是用于向飞行员和其机组人员提供实时的潜在风行信息，包括了关闭的跑道、设备状态以及起降过程中相关航班信息等，是一个机场正常运行依赖的一个基础服务。 这次正是NOTAM地城的数据库系统出现了故障。 更进一步的原因：难道运维又要背锅了？ 据一位ABC news（美国广播公司旗下的新闻事业部）的人员透露，根据内部的复盘信息，可能是由于在一次计划维护操作过程中，一位工程师进行了一次文件（数据库文件？）替换操作，之后就出现了故障，最终导致整个美国国内航空瘫痪。
所以，难道运维人员又要被背锅了？不过，目前为止，FAA仅表示该次事件应该与网络攻击没有关系，暂时还没有透露任何更加详细的信息。
堪称典范的故障过程通知 相比互联网行业，航空业务是更加关键的。互联网很多系统出现故障，虽然影响面很大，但大多数都是在经济层面（虽然这个数额可能很大），而很多基础设施行业，如航空，其系统如果故障则可能导致性命攸关的灾难，这次FAA的处理与通知过程，是很多行业学习的典范。
对于FAA，这应该是一次p0级别的故障了，我们来看FAA主要的故障通知时间线吧：

• 6点29分（美东时间）发布第一条通告：说正在恢复NOAMS(Notice to Air Missions System)系统，当前正在进行最后的验证和重启。
• 6点57分：还在进行NOAMS系统的恢复，部分功能已经恢复（参考）
• 7点19分：恢复还在进行中；现在已经命令在9点前暂停所有的国内航班（参考）
• 8点13分：所有空中的航班都可以安全降落。NOAMS告知飞行员相关信息包括关闭的跑道、设备状态以及相关航班信息等。
• 8点15分：在NOAMS的这次突然宕机之后，恢复取得了进展。目前，部分机场已经可以正常起飞。其他机场也预计在9点都能够恢复起飞
• 8点50分：“禁飞令”全面取消，航班逐步恢复
• 18点31分：我们还在持续跟踪根因。目前，这次系统宕机与一个受损的数据库文件有关

企业信息管理的重大隐患：备份恢复与容灾 经验丰富的技术人员一定都明白，系统一定会出故障，数据库也一定会出问题的，只是何时的问题。背后的原因有很多，例如，系统老旧年久失修，以致于当前的技术人员只能去修修补补，而且无法了解系统全貌，那么就会在某个角落踩到某个“坑”。也有可能是，人为失误、硬件故障、软件故障，还有可能是一些不可抗力。而一个大故障，还有可能是多个潜在问题，组合而成。总得来说，是防不胜防。
那么，构建合适的备份与容灾方案，已经成为当代系统可用性建设的重要组成部分。在软件设计过程中，以及实施和运维中，都需要考虑。但是，备份与容灾的投入有如下特点：

• 这是一个“成本”，无法给业务带来直接收益，所以重视程度通常是不够的
• 企业通常是有相关的方案的，但是因为系统的持续演进以及缺乏实际有效的演练，导致看似有方案，实则是无效的，所以，有时候真的是在靠天吃饭
• 备份与容灾的规划，通常对技术和架构能力有非常高的要求，才能够根据合适的业务场景规划合适的方案，小的厂商或者某些以非技术业务为核心的大型企业（例如保险、航空、金融等），通常难以持续保障稳定的团队进行持续的规划

业务连续性的等级划分 在很多的行业标准中都有对容灾规范的描述，例如ISO 22300、ISO 27001:2022、国内等级保护（等保）等。由IBM的SHARE用户组在1992年提出的“7 tiers of disaster recovery”，依旧是一个非常简洁、直白的划分。并在2012年，该等级划分新增到了八个等级：

等级0 没有灾难恢复方案（Tier 0 – No off-site data）

这种情况下，系统是没有任何灾难恢复方案的，没有备份，没有文档，没有高可用计划。通常这种情况下，在发生故障时，系统的恢复时间（RTO）是完全不可预计的，事实上，很有可能系统就恢复不了。

等级1 有冷数据备份方案（Tier 1 – Data backup with no Hot Site）

这种情况下，系统有一份安全的、离线备份数据（通常是磁带）。根据备份的间隔，系统需要接受故障时一定程度的数据丢失，RPO可能是数小时或数天。根据数据量大小，存储设备的效率等，数据的恢复时间（RTO）则可能达数小时或数天。

等级2 由冷备数据且保障恢复资源（Tier 2 – Data backup with Hot Site）

在前面方案的基础上，还会时刻保障充足的资源和基础设施来进行灾难恢复，这时候，通常RTO是可以预期的。

等级3 在线数据备份（Tier 3 – Electronic vaulting）

在前面方案的基础上，对于业务中的关键系统的数据使用一个在线的、安全的存储系统保存，从而达到更快的数据/业务恢复。

等级4 按时间点的备份（Tier 4 – Point-in-time copies）

该等级则要求基于在线的存储系统，实现按时间的数据备份规划。虽然，这种模式下，还是可能会有数小时数据丢失，但是，可以通过增加时间点的密度来减少数据丢失。

等级5 数据保护达到事务粒度（Tier 5 – Transaction integrity）

对于数据一致性非常高的系统，则需要达到这个等级，这种方案已经很接近于零数据丢失了，但，依旧需要依赖于上层的应用系统做一定的处理的。

等级6 零数据或极少量数据丢失（Tier 6 – Zero or little data loss）

这个等级下，无需依赖任何的上层业务系统，就可以达到零数据丢失或者极其少量的数据丢失。

等级7 与业务集成的、高度自动化方案（Highly automated, business-integrated solution）

在方案6的基础上，进一步实现了与业务系统的集成，可以实现自动化的灾难恢复，相比手动的恢复，可以实现更低的RTO。 综述 “7 tiers of disaster recovery” 在实际的场景中，我们看看有哪些对应的情况吧：

• 一般的个人搭建的实验性站点，通常属于等级0，没有考虑任何的灾难恢复方案；
• 如果使用的云服务，那么通过云盘的快照等功能，通过手动快照，则可以实现“等级3”；
• 对于使用云数据库服务RDS的业务，通常RDS可以提供事务粒度的数据保护，也就是“等级5”；
• 对于更加核心的业务系统，例如与金融相关的业务数据，通常需要实现零数据保护方案，例如通过数据库日志镜像技术、Paxos或及其变种的跨数据中心的数据保护方案，例如OceaseBase、PolarDB-X、TDSQL、TiDB等都使用Paxos（或其变种）来使用更加通用的硬件来实现数据保护。这类系统其数据保护通常都可以达到“等级6”。
• 而早期淘宝内部实现的异地多活，则可以认为是一套保护级别达到“等级7”的系统工程。不仅仅要求数据库，而是要求业务系统、中间件、网络/服务器等基础设施都协同起来实现完整的，基于业务的多活系统。

数据库备份的挑战 数据库作为企业数据最重要的持久层，通常，这份数据是最准确、最实时的数据，当其他系统出现数据不一致的时候，都需要依赖数据库中的数据。如果这份数据出现故障，则可能意味着企业的数据资产受损。 因此，数据库的备份也异常重要，而，相比其他数据的备份，数据库的备份也是更加复杂的。这也是为什么企业通常都需要专业的数据库管理人员的原因之一。 具体的，数据库种类繁多，版本也很多，而不同的数据库备份方案可能是完全不同的。例如，MySQL可能是使用外部工具备份、SQL Server则是使用内部命令等。对于增量备份，不同的数据库，差异则更大，有的需要通过归档日志实现、有的则可以通过实时的增量日志实现。另外，数据库备份时，除了备份数据文件之外，通常还需要备份配置文件、增量日志、数据库版本、甚至可能还需要保持部分的系统目录和文件，否则，则可能会出现恢复失败。数据库通常数据量非常大，备份时间很长，网络稳定性、磁盘故障率、OS稳定性等都可能会影响数据库备份效率与有效性。 而这些因素，都增加了数据库备份与恢复的复杂度 。 数据库备份方案 数据库的备份方案有很多种。如果使用的是云数据库RDS，那么，云厂商都会提供默认的数据库备份，不过作为企业依旧需要关注，这个备份的具体情况：例如是否是一个实时备份方案（RPO是否为分钟级），备份数据保存时间，备份数据恢复限制等。 如果使用的是自建数据库，无论是IDC自建还是EC2/ECS自建，则都需要企业中的专业人员（通常为DBA）来构建专门的数据库备份与恢复方案。根据业务系统的属性不同，可能选择使用不同的方案，例如如果业务连续和数据一致性要求并不高，则可以考虑使用EC2/ECS的快照备份，对于更多场景，则需要使用数据库自身的备份工具，构建一个更加实时的备份方案（通常RPO要求接近于分钟）。另外，通常还需要进行定期的恢复演练，避免在一些“角落”出现故障，导致看似正常运转的备份，其实是无效的。 总得来说，数据库备份与恢复是复杂的，需要专业的人员（通常是DBA）持续的维护与建设，并定期的进行演练以保障其确实有效。否则，就可能出现，靠天吃饭，人在家中坐，锅从天上来的情况。 关于本文作者orczhou orczhou是来自NineData（https://ninedata.cloud）的工程师。NineData向企业、开发者提供高效、安全的数据库SQL开发、数据库备份、数据复制/迁移/集成、数据对比等功能，是一个SaaS服务开箱即用，可以快速提升企业SQL开发效率，保障企业数据安全。