因一个代码拼写错误,17 个生产级数据库被误删、瘫痪 10 小时!

因一个代码拼写错误,17 个生产级数据库被误删、瘫痪 10 小时!_第1张图片

整理 | 禾木木   责编 | 郑丽媛

出品 | CSDN(ID:CSDNnews)

5 月 24 日,微软 Azure DevOps 在巴西南部(SBR)区域内一处 scale-unit(微软 Azure 部署架构中最小的容量单元)设施发生瘫痪,持续了 10 个小时。

6 月 2 日,微软首席软件工程经理 Eric Mattingly 为这次故障出面道歉,并透露了具体原因:一个简单的错误拼写,导致了整整 17 个生产级数据库被删除。 

因一个代码拼写错误,17 个生产级数据库被误删、瘫痪 10 小时!_第2张图片

3ed3e8114e10afc3625fbbe541202459.png

隐藏”着一条拼写错误

Mattingly 解释道,Azure DevOps 工程师偶尔会对生产级数据库的快照进行保存,以查看报告上的问题或测试性能改进。为清理这些快照数据库,会有专门的后台每天运行,系统会在一段设定的时间后删除旧快照。

在最近的一波 sprint (敏捷开发术语中的迭代开发周期)中,Azure DevOps 工程师执行了一次代码升级,将已弃用的 Microsoft .Azure. Management.* 软件包换成受支持的 Azure.ResourceManager.* NuGet 软件包。

这个操作,连带着大量 pull request 变更请求,会将旧包中的 API 调用替换为新包中的 API 调用——而引发此次事件的拼写错误,就出现在 pull request 内,导致后台快照删除作业删掉了整个服务器。

Mattingly 表示:“这条 pull request 中的快照删除作业中,隐藏着一条拼写错误,它会删除 Azure SQL 数据库调用,并替换成删除托管数据库的 Azure SQL Server 调用。”

按理来说,Azure DevOps 有一系列测试可发现这类问题。但 Mattingly 称,该错误代码只在某些条件下运行,因此没有被现有的测试机制及时发现。 

Mattingly 表示,Azure DevOps 工程师使用安全部署实践(SDP)将 Sprint 222 部署到了 Ring 0(微软内部部署),那里不存在快照数据库,所以删除作业不会执行。但几天后,Azure DevOps 工程师又将其部署至 Ring 1(客户环境),也就是巴西南部的 scale-unit 设施。该环境中有一个比较旧的快照数据库,因此触发这个错误代码,于是它在删除 Azure SQL Server 的同时,还删掉了 scale-unit 设施中的 17 个生产级数据库。 

好在,据 Mattingly 介绍,此次事件并未引发数据丢失。为了防止问题再次发生,Mattingly 称微软已采取了各种修复和重置措施,并向所有受此中断影响的客户道歉。

222ecae59eea562bdea6aa6a985ca5a6.png

为何花费了 10 个小时才全部恢复?

据微软官方介绍,这 17 个生产级数据库被删后 20 分钟不到,其工程师就检测到了中断并立即开始抢修,但依旧花费了 10 个小时才完全恢复。

Mattingly 表示,这其中有几个原因:

▶ 首先,客户无法自己恢复 Azure SQL Server,因此必须由 Azure 团队来处理这项工作,这个过程对许多人来说大约需要一个小时。

▶ 其次,数据库有不同的备份配置,一些数据库被配置为 Zone 冗余备份,另一些数据库被配置为最新的 Geo-zone 冗余备份。协调这种不匹配情况给恢复过程增添了不少时间。

▶ 最后,在数据库开始重新上线后,由于 Web 服务器出现了一系列复杂的问题,即使是数据位于这些数据库中的客户,也无法访问整个 scale-unit 设施。 

这些问题是服务器预热任务引起的,该任务会通过测试调用遍历可用的数据库列表。但恢复过程中的数据库抛出了一个错误,导致预热测试“执行指数级的 backoff 重试“,结果导致正常情况下只需不到 1 秒的预热过程,平均耗时了 90 分钟。

更复杂的是,整个恢复过程是交错进行的,一旦其中一两台服务器重新开始接收客户流量,就会因过载而再次停运。最终,工程师只能阻断所有流向巴西南部 scale-unit 的流量,确保一切准备就绪后,再重新加入负载均衡器并处理流量。 

目前,为防止此次事故再次发生,微软方面已实施各种修复和重新配置。Mattingly 说:“我们再次向所有受到这次故障影响的客户道歉。” 

204bc6701a5ef98bec7369ca95d8c7a8.png

网友:微软只是继续“贴膏药”

尽管如此,但此次微软的道歉并没有得到网友的谅解:

▶ “看来 Azure 变得越来越复杂了,而频繁变化加上日益增加的复杂性,最终只会走上一条路:更多的灾难以及可靠性降低。听起来微软对此事故的解决方案是继续“贴膏药”,但我认为在某个阶段,还是有必要对方法进行更根本的重新思考,避免最终分崩离析。”

甚至因为这个简单的 Bug 导致 10 小时宕机的结果,不少网友也开始讨论“云”的必要性:

▶ “关于云和 DevOps 最可怕的事情是,其实大多数文件都相当简洁,但其中总是有许多神奇的键/值,而实际上它们在代码审查中并没有任何意义。”

▶ “这就是我讨厌云的众多原因之一。十多年来,我一直没有与 IaaS 打交道的乐趣,我的本地内容非常完美,我还成功地抵御了过去十年中那些想要一次又一次将云带回来的人。”

对此,你又有哪些看法呢? 

参考链接:

https://www.theregister.com/2023/06/03/microsoft_azure_outage_brazil/

https://status.dev.azure.com/_event/392143683/post-mortem

推荐阅读:

▶不要拿 ChatGPT 干这 6 件事

▶法律科技创新赛题剧透|点我了解第二届“移动云杯”大赛

▶发布 21 年后,Windows XP 被破解,仅 18KB 即可离线激活

你可能感兴趣的:(数据库)