微软道歉！代码错拼、误删 17 个生产级数据库、瘫痪 10 个小时
周三，由于一个基本的代码错误，微软 Azure DevOps （一套应用程序生命周期服务）在巴西南部地区停止运行了大约 10 个小时。
周五，微软首席软件工程经理 Eric Mattingly 为这次故障出面道歉，并透露了具体的原因：一个简单的错误拼写删除了整整 17 个生产级数据库。
Mattingly 解释道，Azure DevOps 工程师偶尔会对生产级数据库拍取快照，以查看报告的问题或测试性能改进。工程师还依赖一个每天运行的后台系统，该系统在一段设定的时间后删除旧快照。
在最近的一次 sprint （敏捷开发术语中的迭代开发周期）中，Azure DevOps 工程师执行了一次代码升级，将弃用的 Microsoft .Azure. Management.* 软件包换成支持的 Azure.ResourceManager.* NuGet 软件包。
结果是大量的代码更改合并请求将旧软件包中的 API 调用换成了新软件包中的 API 调用。
拼写错误就出现在合并请求中，这是一个必须经过审查后合并到适用项目中的代码更改。
拼写错误导致后台快照删除作业「删除了整台服务器」。
Mattingly说：“这个合并请求中隐藏着快照删除作业中的一个拼写错误，结果把删除 Azure SQL 数据库的调用换成了删除托管数据库的 Azure SQL 服务器的调用。”
Azure DevOps 有一系列测试来发现这些问题，但据 Mattingly 声称，错误的代码只在某些条件下运行，因此没有被现有的测试及时发现。
据推测，这些条件需要存在一个足够旧的数据库快照才会被删除脚本发现。
Mattingly 表示，由于没有任何快照数据库，Sprint 222 是在内部部署（Ring 0）的，没有发生任何事故。几天后，将软件变更被部署到巴西南部扩展单元（scale unit，负责特定角色的服务器集群）的客户环境（Ring 1）中。该环境有一个足够旧的快照数据库，足以触发这个代码错误。从而导致后台作业删除了扩展单元的“整台 Azure SQL Server 和所有 17 个生产级数据库”。
数据后来已经全部恢复，但前后花了十多个小时。
Mattingly 表示，这有几个原因。
一个原因是，由于客户无法自己恢复 Azure SQL Server，因此随时待命的Azure 工程师只好处理这项工作，这个过程对许多人来说大约需要一个小时。
另一个原因是数据库有不同的备份配置：一些数据库被配置为 Zone 冗余备份，另一些数据库被配置为最新的 Geo-zone 冗余备份。协调这种不匹配情况给恢复过程增添了不少时间。
Mattingly 表示：“最后，即使在数据库开始重新上线之后。由于我们的 Web 服务器出现了一系列复杂的问题，整个扩展单元仍然无法访问，连那些数据在那些数据库中的客户也无法访问。”
这些问题是服务器预热任务引起的，该任务使用测试调用遍历可用数据库列表。恢复过程中的数据库抛出了一个错误，导致预热预测“执行指数级的 backoff 重试，结果导致预热过程平均耗时 90 分钟，而正常情况下不需要 1 秒。”
更为复杂的是，这个恢复过程是交错的；一旦一两台服务器再次开始接收客户流量，它们就会过载，随后崩溃。最终，恢复服务需要阻塞通向巴西南部扩展单元的所有流量，直到一切都准备好，重新加入负载均衡系统并处理流量。
各种修复版和重新配置已经到位，以防止这个问题再次发生。
Mattingly 说：“我们再次向所有受到这次故障影响的客户道歉。”
微软 Azure 故障报告：
