一个代码拼写错误引发微软Azure故障，17 个生产级数据库被删
我们使用我们的安全部署实践 (SDP) 将 Sprint 222 部署到 Ring 0（我们的内部 Azure DevOps 组织），其中不存在快照数据库，因此作业没有执行。在 Ring 0 部署了几天之后，我们接下来部署到 Ring 1，那里是受影响的巴西南部 scale-unit 所在的地方。其中快照数据库的存在时间足以触发错误代码，当作业删除 Azure SQL Server 时，它还删除了 scale-unit 中的所有 17 个生产数据库。从那时起，该 scale unit 就无法处理任何客户流量。
首先，客户无法自己恢复 Azure SQL Server，因此必须由 Azure SQL 团队来恢复 Azure SQL Server。“确定我们需要 Azure SQL 的值班工程师，让他们参与进来并恢复服务器，这个过程大约需要一个小时。”
其次，数据库有不同的备份配置，一些被配置为 Zone 冗余备份，另一些则被配置为较新的 Geo-zone 冗余备份。协调这种不匹配情况给恢复过程增添了不少时间。
最后，在数据库开始重新上线后，由于 Web 服务器出现了一系列复杂的问题，即使是数据位于这些数据库中的客户，也无法访问整个 scale-unit。
已经修复了快照删除作业中的错误。
为快照删除作业创建了一个新测试，它针对真实的 Azure 资源充分执行快照数据库删除方案。
正在为关键资源添加 Azure 资源管理器锁，以防止意外删除。
确保所有的 Azure SQL 数据库备份都配置为 Geo-zone-redundant。
确保所有未来的快照数据库都在生产数据库的不同 Azure SQL Server 实例上创建。
正在修复 Web 服务器预热任务中的逻辑，以便即使数据库处于 offline 状态也能成功启动。
正在创建一个新的 cmdlet 来恢复已删除的数据库，以确保恢复使用与删除之前相同的设置（包括备份冗余）。
-End-
往期推荐
最后推荐一个基于GPT-4的产品，千语千问AI，汇集了常用的AI产品，可以免费体验；
识别二维码或点击阅读原文，让千语千问AI产品成为你工作的好助手