The 因拼register 网站披露 ，巴西南部地区部署的写错 Microsoft Azure DevOps 服务”罢工“了约十个小时 。随后，误个微软微软首席软件工程经理 Eric Mattingly 为本次中断事件公开道歉 ，数据删除并透露中断原因是库被一个简单拼写错误致使 17 个生产数据库被删除 。
Mattingly 表示 Azure DevOps 工程师会定期对生产数据库进行快照（Snapshot）处理，因拼以便及时调查报告上来的写错问题或测试性能是否改进 ，这些举动都依赖一个每天运行的误个微软后台系统 ，该系统会在特定时间删除旧的数据删除快照 。
在 Azure DevOps 工程师近期进行的源码下载库被一次代码升级中 ，用支持的因拼 Azure.ResourceManager.*NuGet 包取代了弃用的 Microsoft.Azure.Management.*包，此举引起一个大型的写错拉取请求 ，其中更换了旧包和新包中的误个微软 API 调用 。
然而拉取请求中却出现了拼写错误 ，数据删除误将删除快照数据库的库被调用改成了删除托管数据库的 Azure SQL Server 的调用 ，导致后台快照删除作业删除了整个服务器 。
Mattingly 指出 Azure DevOps 有专门的亿华云测试来捕捉此类问题 ，但是错误的代码只在某些特定条件下才得以运行 ，因此在现有的测试中没有很好的覆盖到 。（据推测 ，这些条件需要存在于一个足够“老”的数据库快照 ，以便被删除脚本所捕获。）
Mattingly 进一步指出由于没有任何快照数据库 ，Sprint 222 的内部部署（第0环）没有发生任何意外 ，几天后 ，建站模板软件变更被部署到客户环境（第1环）被用于南巴西规模单位（一个特定角色的服务器集群） 。该环境中有一个快照数据库 ，其年龄“老”到足以触发该错误 ，最终导致后台工作删除了该规模单位的“整个 Azure SQL 服务器和所有 17 个生产数据库” 。
经过十多个小时的努力 ，微软方面已经全部恢复了数据库，为防止此类问题再次发生 ，微软已经采取各种修复和重新配置措施 。花费如此长时间的原因如下：
第一 ：由于客户自己无法恢复 Azure SQL Server ， 必须由 Azure 工程师来处理这一问题 ，这一过程大约需要一个小时 ：第二：数据库具有不同的源码库备份配置 ，一些数据库被配置为区域冗余备份，另一些数据库被设置为最近的地理区域冗余备份 ，协调这种不匹配的冗余备份 ，需要花费几个小时；最后一个原因 ：在数据库开始恢复在线后 ，由于自身网络服务器存在一系列复杂问题 ，使用这些数据库的客户也无法立刻访问整个规模单元。据悉，这些问题由服务器预热任务引起，该任务通过测试调用在可用数据库列表中反复进行 ，恢复过程中的数据库出现了一个错误，云计算就会触发预热测试 执行指数回退重试 ，导致预热平均需要 90 分钟 ，在正常情况下此操作只需要几秒钟 。
更为复杂的是 ，整个恢复过程交错进行 ，一旦有一两台服务器开始接受客户流量 ，就会出现过载现象 ，然后停机 。因此 ，恢复服务需要阻断所有到巴西南部规模单位的流量 ，直到一切都充分准备好后，才重新加入负载平衡器并处理流量 。服务器租用
文章来源：https://www.theregister.com/2023/06/03/microsoft_azure_outage_brazil/
