一个简单的代码拼写错误导致 17 个生产数据库被删！微软 Azure DevOps 宕机 10 小时始末

由于低级错误，本该清理数据库快照的修复代码却删掉了整个服务器。

一个拼写错误致微软 Azure DevOps 宕机 10 小时

微软Azure DevOps是一套应用程序生命周期服务。5 月 24 日，Azure DevOps 在巴西南部（SBR）区域内一处 scale-unit（微软 Azure 部署架构中最小的容量单元）设施发生宕机，宕机持续了 10 个小时。

近日，微软首席软件工程经理 Eric Mattingly 对宕机事件表达歉意并透露了宕机原因：一个简单的拼写错误，致使 17 个生产数据库遭到删除。

Mattingly 解释道，Azure DevOps 工程师偶尔会保存生产数据库的快照，据此调查上报的问题或测试性能改进方向。为了清理这些快照数据库，会有专门的后台作业每天运行，并在快照超过一定期限后将其删除。

在最近的一波冲刺（敏捷上下文中的小组项目，编号为 Sprint 222）中，Azure DevOps 工程师执行了代码升级，想要用受支持的 Azure.ResourceManager.* NuGet 包替换掉已被弃用的 Microsoft.Azure.Managment.*包。

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

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

Azure DevOps 工程师使用安全部署实践（SDP）将 Sprint 222 部署到了 Ring 0（微软内部 Azure DevOps 组织），这里不存在快照数据库，所以删除作业不会执行。在 Ring 0 测试几天之后，Azure DevOps 工程师又将其部署至 Ring 1，也就是在此期间巴西南部的 scale-unit 设施受到了影响。快照数据库的存在时间触发了这项 bug，该作业在删除 Azure SQL Server 的同时，还删掉了 scale-unit 设施中所有 17 个生产数据库。从这时起，Azure DevOps 的 scale-unit 无法处理任何客户流量。

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

为什么耗时 10 小时才完成恢复？

据了解，Azure DevOps 是有检测此类问题的测试的。但根据 Mattingly 的介绍，“之所以以往没有发现，是因为这部分代码的运行条件非常罕见，我们的测试并没有切实覆盖这些极端情况。”有推测认为，这种极端条件要求删除脚本捕捉到特别陈旧的数据库快照。

虽然目前数据已经全部恢复，但整个宕机前后耗时 10 多个小时，为什么这么久才完成修复？Mattingly 对此做出了解释说明：“我们在数据库被删除后的 20 分钟内检测到宕机，值班工程师立即参与修复。在快速理解问题来源之后，我们开始恢复 SQL Server 及所有数据库，并禁用了快照删除作业以防止该 bug 影响到其他客户。但由于问题数量较多，因此恢复时间也相对较长。”

首先，客户无法自行恢复 Azure SQL Server，因此必须由 Azure SQL 团队参与恢复工作。确定需要 Azure SQL 值班工程师介入，接洽实际情况和问题，再加上服务器的实际恢复大约耗费了 1 个小时。

其次，所有数据库均配置有备份冗余，但部分数据库的创建时间早于区域冗余备份的上线时间。在恢复数据库时，Azure DevOps 为所有数据库选择了 Geo-zone-redundant，导致一部分还原数据按照此前配置的 Zone-redundant 备份被复制到了配对区域。这种匹配冲突又让恢复过程延长了好几个小时。对于这个问题，Azure DevOps 将确保所有数据库备份均按 Azure 区域支持被配置为 Geo-zone-redundant，使其覆盖 Azure DevOps 中的所有 scale-unit。

最后，在数据库开始恢复上线之后，由于 Azure DevOps 的 Web 服务器出现了一系列复杂问题，尽管数据库内容已经完成还原，客户也仍然无法访问整个 scale-unit 设施。

这个问题源自服务器的预热任务，该任务会通过测试调用遍历可用的数据库列表。但恢复过程中数据库招聘了一项错误，导致预热测试“执行指数级退避重试，令预热耗时由正常情况下的不到一秒延长到了平均 90 分钟。”

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

如何避免此类问题再次发生？

目前，Azure DevOps 已经修复了快照删除作业中的 bug，并为快照删除作业创建了新的测试，面向真实 Azure 资源充分反映快照数据库的删除场景。

Mattingly 表示，Azure DevOps 正着手为关键资源添加 Azure 资源管理器锁，借此防止意外删除。同时，确保所有 Azure SQL 数据库备份均被配置为 Geo-zone-redundant 形式，并受到 Azure 区域的支持；确保未来的所有快照数据库，只会被创建在不同于生产数据库的 Azure SQL Server 实例之上。

此外，还会修复 Web 服务器预热任务的逻辑，确保即使数据库处于脱机状态时也能成功启动。并创建新的 cmdlet 来恢复已被删除的数据库，确保恢复结果使用与被删除前相同的设置（包括备份冗余）。

参考链接：

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

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