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

在 2023 年新年的第二周，美国东部时间 1 月 11 日上午，6 点 29 分，美国航空监管机构（FAA）发布了一条仅 40 字的通告，随后不久，很快就宣布停飞全美所有国内航班。通告内容是，FAA 正在对 NOTAM（Notice to Air Missions）系统进行验证和恢复，在第一条通知之后的 50 分钟，FAA 就宣布停飞所有国内航班。

这应该是自 2001 年 911 袭击以来首次出现如此大规模的禁飞。

在两个小时之后，也就是 8 点 50 分，FAA 宣布 NOTAM 系统已经恢复，并彻底取消了之前的“禁飞令”。

FAA 在当天的晚上 18 点 31 分，宣布这次系统宕机是由数据库文件受损导致的，并还将持续跟进并改进。

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 分：我们还在持续跟踪根因。目前，这次系统宕机与一个受损的数据库文件有关

FAA主要的故障通知时间线

企业信息管理的重大隐患：备份恢复与容灾

经验丰富的技术人员一定都明白，系统一定会出故障，数据库也一定会出问题的，只是何时的问题。背后的原因有很多，例如，系统老旧年久失修，以致于当前的技术人员只能去修修补补，而且无法了解系统全貌，那么就会在某个角落踩到某个“坑”。也有可能是，人为失误、硬件故障、软件故障，还有可能是一些不可抗力。而一个大故障，还有可能是多个潜在问题，组合而成。总得来说，是防不胜防。

那么，构建合适的备份与容灾方案，已经成为当代系统可用性建设的重要组成部分。在软件设计过程中，以及实施和运维中，都需要考虑。但是，备份与容灾的投入有如下特点：

• 这是一个“成本”，无法给业务带来直接收益，所以重视程度通常是不够的

• 企业通常是有相关的方案的，但是因为系统的持续演进以及缺乏实际有效的演练，导致看似有方案，实则是无效的，所以，有时候真的是在靠天吃饭

• 备份与容灾的规划，通常对技术和架构能力有非常高的要求，才能够根据合适的业务场景规划合适的方案，小的厂商或者某些以非技术业务为核心的大型企业（例如保险、航空、金融等），通常难以持续保障稳定的团队进行持续的规划

业务连续性的等级划分

在很多的行业标准中都有对容灾规范的描述，例如 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 的工程师。NineData 向企业、开发者提供高效、安全的数据库 SQL 开发、数据库备份、数据复制/迁移/集成、数据对比等功能，是一个 SaaS 服务开箱即用，可以快速提升企业 SQL 开发效率，保障企业数据安全。