微软 1 个代码拼写错误，17 个生产级数据库被误删瘫痪 10 小时！

　　点击蓝色“最码农”关注我哟

　　加个“星标”，每天下午18:03，一起学技术

　　转自：CSDN（ID：CSDNnews）

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

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

　　“隐藏”着一条拼写错误

　　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 称微软已采取了各种修复和重置措施，并向所有受此中断影响的客户道歉。

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

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

　　Mattingly 表示，这其中有几个原因：

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

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

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

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

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

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

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

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

　　▶ “看来 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