6月2日，微软首席软件工程经理埃里克·马丁利(Eric Mattingly)为失败道歉，并透露了具体原因:一个简单的拼写错误导致17个生产级数据库被删除。
隐藏了一个拼写错误。
马丁利解释说，Azure DevOps工程师偶尔会保存生产级数据库的快照，以检查报告中的问题或测试性能改进。为了清理这些快照数据库，每天会有专门的后台运行，系统会在设定的时间后删除旧的快照。
在sprint(敏捷开发术语中的迭代开发周期)的最新一波中，Azure DevOps工程师进行了代码升级，替换了已弃用的Microsoft .Azure. Management。*带有受支持的Azure.ResourceManager的软件包，* n获取软件包。
这个操作加上大量的pull request更改请求，会用新包中的API调用替换旧包中的API调用——而导致这个事件的拼写错误会出现在pull请求中，导致后台快照删除作业删除整个服务器。
马丁利说:“这个拉取请求中的快照删除作业隐藏了一个拼写错误，它将删除Azure SQL数据库调用，并替换为删除托管数据库的Azure SQL Server调用。”
按理说Azure DevOps有一系列的测试来发现这样的问题。但马丁利表示，错误代码只在特定条件下运行，因此没有被现有的测试机制及时发现。
马丁利说，Azure DevOps工程师使用安全部署实践(SDP)将Sprint 222部署到Ring 0(微软内部部署)，那里没有快照数据库，因此删除作业不会被执行。但几天后，Azure DevOps工程师将其部署到Ring 1(客户环境)，这是巴西南部的规模单位设施。在这个环境中有一个旧的快照数据库，所以触发了这个错误代码，所以它删除了缩放单位设施中的Azure SQL Server和17个生产级数据库。
幸运的是，根据马丁利的说法，这一事件没有造成数据丢失。为了防止问题再次发生，马丁利表示，微软已经采取了各种修复和重置措施，并向所有受此次中断影响的客户道歉。
为什么花了10个小时才完全恢复？
据微软官方介绍，这17个生产数据库的工程师在被删除后不到20分钟就检测到了中断，并立即开始修复，但仍然需要10个小时才能完全恢复。
马丁利说，这有几个原因:
首先，客户无法自己恢复Azure SQL Server，因此Azure团队必须处理这项工作，这对于许多人来说大约需要一个小时。
其次，数据库有不同的备份配置。一些数据库被配置为区域冗余备份，而其他数据库被配置为最新的地理区域冗余备份。协调这种不匹配会增加恢复过程的时间。
最后，在数据库再次开始联机后，由于Web服务器中的一系列复杂问题，即使客户的数据位于这些数据库中，也无法访问整个秤台设备。
这些问题是由服务器预热任务引起的，该任务通过测试调用遍历可用数据库列表。但是，数据库在恢复过程中抛出了一个错误，导致预热测试“执行指数回退重试”。因此，预热过程通常不到1秒，平均时间为90分钟。
更复杂的是，整个恢复过程是交错的。一旦有一两台服务器再次开始接收客户流量，就会因为过载而再次关闭。最后，工程师只能阻止所有到巴西南部的扩展单元的流量，并确保在重新加入负载平衡器和处理流量之前一切准备就绪。
目前，为了防止这种事故再次发生，微软已经实施了各种修复和重新配置。马丁利说:“我们再次向所有受此故障影响的客户道歉。”
网友:微软只是继续“贴膏药”
尽管如此，微软的道歉并没有得到网友的理解:
“看来Azure变得越来越复杂了，频繁的变化和不断增加的复杂性只会导致一条路:更多的灾难和降低的可靠性。听起来微软对这次事故的解决方案是继续“贴膏药”，但我认为在某个阶段，还是有必要从更根本上重新思考方法，以避免最终分崩离析。”
甚至因为这个简单的Bug造成了10个小时的宕机，很多网友开始讨论“云”的必要性:
“cloud和DevOps最可怕的地方在于，大部分文件其实都挺简洁的，但里面总有很多神奇的键/值，其实在代码审查中没有任何意义。”
“这是我讨厌云的众多原因之一。十多年来，我从未有过与IaaS打交道的乐趣。我的本地内容非常完美，在过去十年里，我成功地一次又一次地抵制了那些想要把云带回来的人。”
对此你怎么看？