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 個生產數據庫”。

經過十多個小時的努力，微軟方面已經全部恢復了數據庫，為防止此類問題再次發生，微軟已經采取各種修復和重新配置措施?；ㄙM如此長時間的原因如下：

• 第一：由于客戶自己無法恢復 Azure SQL Server， 必須由 Azure 工程師來處理這一問題，這一過程大約需要一個小時：
• 第二：數據庫具有不同的備份配置，一些數據庫被配置為區域冗余備份，另一些數據庫被設置為最近的地理區域冗余備份，協調這種不匹配的冗余備份，需要花費幾個小時；
• 最后一個原因：在數據庫開始恢復在線后，由于自身網絡服務器存在一系列復雜問題，使用這些數據庫的客戶也無法立刻訪問整個規模單元。

據悉，這些問題由服務器預熱任務引起，該任務通過測試調用在可用數據庫列表中反復進行，恢復過程中的數據庫出現了一個錯誤，就會觸發預熱測試 執行指數回退重試，導致預熱平均需要 90 分鐘，在正常情況下此操作只需要幾秒鐘。

更為復雜的是，整個恢復過程交錯進行，一旦有一兩臺服務器開始接受客戶流量，就會出現過載現象，然后停機。因此，恢復服務需要阻斷所有到巴西南部規模單位的流量，直到一切都充分準備好后，才重新加入負載平衡器并處理流量。

文章來源：https://www.theregister.com/2023/06/03/microsoft_azure_outage_brazil/