2023年6月3日消息，由于基本代码错误，Microsoft Azure DevOps 是一套应用程序生命周期服务，周三在巴西南部地区停止工作约十个小时。
周五，首席软件工程经理埃里克·马丁利 (Eric Mattingly) 对中断表示歉意，并透露了中断的原因：一个简单的拼写错误删除了 17 个生产数据库。
Mattingly 解释说，Azure DevOps 工程师偶尔会拍摄生产数据库的快照，以调查报告的问题或测试性能改进。他们依赖于一个每天运行并在一段时间后删除旧快照的后台系统。
在最近的冲刺期间——敏捷术语中的一个小组项目——Azure DevOps 工程师执行了代码升级，用支持的 Azure.ResourceManager.* NuGet 包替换了弃用的 Microsoft.Azure.Managment.* 包。
结果是一个很大的变更拉取请求，将旧包中的 API 调用替换为新包中的 API 调用。拼写错误出现在拉取请求中——必须审查并合并到适用项目中的代码更改。它导致后台快照删除作业删除整个服务器。
“隐藏在这个拉取请求中的是快照删除作业中的一个拼写错误，它将删除 Azure SQL 数据库的调用换成了删除托管数据库的 Azure SQL Server 的调用，”Mattingly 说。
Azure DevOps 有测试来捕获此类问题，但根据 Mattingly 的说法，错误代码仅在特定条件下运行，因此现有测试并未很好地涵盖这些问题。据推测，这些条件需要存在足够旧的数据库快照以被删除脚本捕获。
Mattingly 表示，由于没有任何快照数据库，Sprint 222 在内部部署（Ring 0）没有发生任何事故。几天后，软件更改被部署到巴西南部规模单位（特定角色的服务器集群）的客户环境（Ring 1）。该环境有一个足够旧的快照数据库来触发错误，导致后台作业删除缩放单元的“整个 Azure SQL Server 和所有 17 个生产数据库”。
数据已经全部恢复了，但是用了十多个小时。Mattingly 说，这有几个原因。
一是由于客户无法自行恢复 Azure SQL Server，因此 Azure 工程师必须随时待命处理这个问题，这个过程对许多人来说大约需要一个小时。
另一个原因是数据库有不同的备份配置：一些是为区域冗余备份配置的，而另一些是为最近的地理区域冗余备份设置的。协调这种不匹配使恢复过程增加了许多小时。
“最后，”Mattingly 说，“即使在数据库开始重新上线之后，由于我们的网络服务器出现了一系列复杂的问题，整个规模单位仍然无法访问，即使数据在这些数据库中的客户也是如此。”
这些问题是由服务器预热任务引起的，该任务通过测试调用遍历可用数据库列表。恢复过程中的数据库抛出了一个错误，该错误导致预热测试“执行指数退避重试，导致预热平均花费 90 分钟，而正常情况下不到一秒。”
更复杂的是，这个恢复过程是交错的，一旦其中一两台服务器再次开始接收客户流量，它们就会过载并停机。最终，恢复服务需要阻止所有流向南巴西规模单元的流量，直到一切都准备好重新加入负载均衡器并处理流量。
已实施各种修复和重新配置，以防止问题再次发生。
“我们再次向所有受此次中断影响的客户道歉，”马丁利说。
文章来源：https://www.theregister.com/2023/06/03/microsoft_azure_outage_brazil/
