17 个生产级数据库被误删、瘫痪 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 最可怕的事情是，其实大多数文件都相当简洁，但其中总是有许多神奇的键/值，而实际上它们在代码审查中并没有任何意义。
”