此拼写错误导致 Microsoft Azure • 注册表中断

由于基本代码错误，Microsoft Azure DevOps 是一套应用程序生命周期服务，周三在巴西南部地区停止工作约十个小时。

周五，首席软件工程经理埃里克·马丁利 (Eric Mattingly) 为中断道歉，并透露了中断的原因： 简单的错字 即删除了十七个生产数据库。

Mattingly 解释说，Azure DevOps 工程师有时会拍摄生产数据库的快照，以查看报告的问题或测试性能改进。 他们依赖于每天运行的后台系统，并在设定的时间段后删除旧快照。

最近一段时间 敌人 – 敏捷团队项目 – Azure DevOps 工程师完成了代码升级，替换了 Microsoft.Azure.Management。 * 支持的包 Azure.ResourceManager。 * 努格特。

结果是一个很大的更改拉取请求，将旧包中的 API 调用替换为新包中的 API 调用。 拉取请求拼写错误 – 需要审查并合并到适用项目中的代码更改。 而删除后台快照任​​务导致删除整个服务器。

“隐藏在这个拉取请求中的是删除快照任务中的一个错字，它用删除托管数据库的 Azure SQL Server 的调用替换了删除 Azure SQL 数据库的调用，”Mattingly 说。

Azure DevOps 有测试来捕获此类问题，但根据 Mattingly 的说法，错误代码仅在特定条件下有效，因此现有测试并未很好地涵盖这些问题。 这些条件大概需要数据库的快照，该快照足够旧以被删除脚本检测到。

Mattingly 表示，Sprint 222 在内部部署（Ring 0）没有发生任何事故，因为没有任何快照数据库。 几天后，软件更改在南巴西规模单位（一组特定角色的服务器）的客户端环境（环 1）中传播。 这个环境有一个足够旧的快照数据库来触发这个错误，导致后台作业删除度量单位的“整个 Azure SQL Server 和所有 17 个生产数据库”。

所有的数据都找回来了，不过用了十多个小时。 马丁利说：这有几个原因。

一是由于客户无法自行恢复 Azure SQL Server，因此 Azure 按需工程师必须处理这个问题，对于许多用户而言，这个过程大约需要一个小时。

另一个原因是数据库具有不同的备份配置：一些配置为区域备份，而另一些则设置为地理区域中的最新备份。 解决这种不匹配会使恢复过程增加很多时间。

“最后，即使在数据库开始重新上线之后，”Mattingly 说，“由于我们的网络服务器存在一系列复杂的问题，即使数据在这些数据库中的客户也无法访问整个域单元。”

这些问题是由服务器预热任务引起的，该任务通过测试调用遍历可用数据库列表。 恢复中的数据库抛出一个错误，触发预热测试“执行指数回滚重试，导致预热平均花费 90 分钟，而正常情况下不到一秒。”

更糟糕的是，这个恢复过程是交错的，一旦其中一两个服务器再次开始接收客户端流量，它们就会过载并停机。 最后，恢复服务需要阻止所有流向 SBU 的流量，直到一切准备就绪，可以重新加入负载均衡器并处理流量。

已实施多项修复和重新配置，以防止问题再次发生。

“我们再次向所有受此次中断影响的客户道歉，”马丁利说。 ®