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 来恢复已删除的数据库，以确保恢复使用与删除之前相同的设置（包括备份冗余）。

更多详情可查看官方公告。