因一个代码拼写错误，17 个生产级数据库被误删、瘫痪 10 小时！ _微软

出品 | CSDN（ID：）
5 月 24 日，微软 Azure在巴西南部（SBR）区域内一处 scale-unit（微软 Azure 部署架构中最小的容量单元）设施发生瘫痪，持续了 10 个小时。
6 月 2 日，微软首席软件工程经理 Eric为这次故障出面道歉，并透露了具体原因：一个简单的错误拼写，导致了整整 17 个生产级数据库被删除。
“隐藏”着一条拼写错误
解释道，Azure工程师偶尔会对生产级数据库的快照进行保存，以查看报告上的问题或测试性能改进。为清理这些快照数据库，会有专门的后台每天运行，系统会在一段设定的时间后删除旧快照。
在最近的一波（敏捷开发术语中的迭代开发周期）中，Azure工程师执行了一次代码升级，将已弃用的.Azure. .* 软件包换成受支持的 Azure..* NuGet 软件包。
这个操作，连带着大量 pull变更请求，会将旧包中的 API 调用替换为新包中的 API 调用——而引发此次事件的拼写错误，就出现在 pull内，导致后台快照删除作业删掉了整个服务器。
表示：“这条 pull中的快照删除作业中，隐藏着一条拼写错误，它会删除 Azure SQL 数据库调用，并替换成删除托管数据库的 Azure SQL调用。”
按理来说，Azure有一系列测试可发现这类问题。但称，该错误代码只在某些条件下运行，因此没有被现有的测试机制及时发现。

文章插图
表示，Azure工程师使用安全部署实践（SDP）将222 部署到了 Ring 0（微软内部部署），那里不存在快照数据库，所以删除作业不会执行。但几天后，Azure工程师又将其部署至 Ring 1（客户环境），也就是巴西南部的 scale-unit 设施。该环境中有一个比较旧的快照数据库，因此触发这个错误代码，于是它在删除 Azure SQL的同时，还删掉了 scale-unit 设施中的 17 个生产级数据库。
好在，据介绍，此次事件并未引发数据丢失。为了防止问题再次发生，称微软已采取了各种修复和重置措施，并向所有受此中断影响的客户道歉。
为何花费了 10 个小时才全部恢复？
据微软官方介绍，这 17 个生产级数据库被删后 20 分钟不到，其工程师就检测到了中断并立即开始抢修，但依旧花费了 10 个小时才完全恢复。
表示，这其中有几个原因：
? 首先，客户无法自己恢复 Azure SQL ，因此必须由 Azure 团队来处理这项工作，这个过程对许多人来说大约需要一个小时。
?其次，数据库有不同的备份配置，一些数据库被配置为 Zone 冗余备份，另一些数据库被配置为最新的 Geo-zone 冗余备份。协调这种不匹配情况给恢复过程增添了不少时间。
?最后，在数据库开始重新上线后，由于 Web 服务器出现了一系列复杂的问题，即使是数据位于这些数据库中的客户，也无法访问整个 scale-unit 设施。
这些问题是服务器预热任务引起的，该任务会通过测试调用遍历可用的数据库列表。但恢复过程中的数据库抛出了一个错误，导致预热测试“执行指数级的重试“，结果导致正常情况下只需不到 1 秒的预热过程，平均耗时了 90 分钟。

文章插图
更复杂的是，整个恢复过程是交错进行的，一旦其中一两台服务器重新开始接收客户流量，就会因过载而再次停运。最终，工程师只能阻断所有流向巴西南部 scale-unit 的流量，确保一切准备就绪后，再重新加入负载均衡器并处理流量。
目前，为防止此次事故再次发生，微软方面已实施各种修复和重新配置。说：“我们再次向所有受到这次故障影响的客户道歉。”