一个代码拼写错误引发微软Azure故障，17个生产级数据库被删

5 月 24 日，微软 Azure DevOps 在巴西南部地区的一处 scale-unit 发生故障，导致宕机约 10.5 个小时。近日，微软首席软件工程经理 Eric Mattingly 出面针对此次故障事件道歉，并透露了导致中断的原因：即，一个简单的拼写错误致使 17 个生产级数据库被删除。

事件背景起源于，Azure DevOps 工程师有时需要对生产数据库的快照进行保存，以调查报告的问题或测试性能改进。为了确保这些快照数据库得到清理，会有一个专门的后台每天运行，系统会在设定的时间段后删除旧快照。

在 Sprint 222 期间，Azure DevOps 工程师升级了代码库，将已弃用的 Microsoft.Azure.Managment.* 包替换为受支持的 Azure.ResourceManager.* NuGet 包。此举连带了大量的 pull request 变更请求，以寻求将旧包中的 API 调用替换为新包中的 API 调用。而其中就隐藏了有关快照删除作业中的一个拼写错误，它将删除 Azure SQL 数据库的调用换成了删除托管数据库的 Azure SQL Server 的调用。

Eric 称，运行此代码的条件很少见，因此测试机制没有很好地覆盖。

我们使用我们的安全部署实践 （SDP） 将 Sprint 222 部署到 Ring 0（我们的内部 Azure DevOps 组织），其中不存在快照数据库，因此作业没有执行。在 Ring 0 部署了几天之后，我们接下来部署到 Ring 1，那里是受影响的巴西南部 scale-unit 所在的地方。其中快照数据库的存在时间足以触发错误代码，当作业删除 Azure SQL Server 时，它还删除了 scale-unit 中的所有 17 个生产数据库。从那时起，该 scale unit 就无法处理任何客户流量。

Azure DevOps 工程师在数据库删除开始后 20 分钟内检测到中断，并开始着手修复。目前数据已经全部恢复，但却花费了长达十个小时。对此 Mattingly 则解释了几个原因：

首先，客户无法自己恢复 Azure SQL Server，因此必须由 Azure SQL 团队来恢复 Azure SQL Server。“确定我们需要 Azure SQL 的值班工程师，让他们参与进来并恢复服务器，这个过程大约需要一个小时。”

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

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

根据介绍，这些问题源于服务器预热任务，该任务通过测试调用遍历可用数据库列表。在恢复过程中的数据库出现了一个错误，导致预热测试 “执行指数级的 backoff retry，使得正常情况下只需不到 1 秒的预热平均耗时了 90 分钟。”

更复杂的是，这个恢复过程是交错进行的，一旦有一两台服务器开始重新接受客户的流量，它们就会过载并出现故障。最终，恢复服务需要工程师阻断所有流向巴西南部 scale-unit 的流量，直到一切都准备就绪后再重新加入负载平衡器和处理流量。

微软方面表示，已经实施各种修复和重新配置，以防止问题再次发生。

已经修复了快照删除作业中的错误。

为快照删除作业创建了一个新测试，它针对真实的 Azure 资源充分执行快照数据库删除方案。

正在为关键资源添加 Azure 资源管理器锁，以防止意外删除。

确保所有的 Azure SQL 数据库备份都配置为 Geo-zone-redundant。

确保所有未来的快照数据库都在生产数据库的不同 Azure SQL Server 实例上创建。

正在修复 Web 服务器预热任务中的逻辑，以便即使数据库处于 offline 状态也能成功启动。

正在创建一个新的 cmdlet 来恢复已删除的数据库，以确保恢复使用与删除之前相同的设置（包括备份冗余）。