数据库故障致美国超一万航班取消或延迟-创新互联

在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的工程师。NineData向企业、开发者提供高效、安全的数据库SQL开发、数据库备份、数据复制/迁移/集成、数据对比等功能,是一个SaaS服务开箱即用,可以快速提升企业SQL开发效率,保障企业数据安全。

你是否还在寻找稳定的海外服务器提供商?创新互联www.cdcxhl.cn海外机房具备T级流量清洗系统配攻击溯源,准确流量调度确保服务器高可用性,企业级服务器适合批量采购,新人活动首月15元起,快前往官网查看详情吧


文章标题:数据库故障致美国超一万航班取消或延迟-创新互联
文章网址:http://pwwzsj.com/article/ceisdp.html