The register 網(wǎng)站披露，巴西南部地區(qū)部署的 Microsoft Azure DevOps 服務”罷工“了約十個小時。隨后，微軟首席軟件工程經(jīng)理 Eric Mattingly 為本次中斷事件公開道歉，并透露中斷原因是一個簡單拼寫錯誤致使 17 個生產(chǎn)數(shù)據(jù)庫被刪除。

Mattingly 表示 Azure DevOps  工程師會定期對生產(chǎn)數(shù)據(jù)庫進行快照（Snapshot）處理，以便及時調查報告上來的問題或測試性能是否改進，這些舉動都依賴一個每天運行的后臺系統(tǒng)，該系統(tǒng)會在特定時間刪除舊的快照。

在 Azure DevOps 工程師近期進行的一次代碼升級中，用支持的 Azure.ResourceManager.*NuGet 包取代了棄用的 Microsoft.Azure.Management.*包，此舉引起一個大型的拉取請求，其中更換了舊包和新包中的 API 調用。

然而拉取請求中卻出現(xiàn)了拼寫錯誤，誤將刪除快照數(shù)據(jù)庫的調用改成了刪除托管數(shù)據(jù)庫的 Azure SQL Server 的調用，導致后臺快照刪除作業(yè)刪除了整個服務器。

事故原因

Mattingly 指出 Azure DevOps 有專門的測試來捕捉此類問題，但是錯誤的代碼只在某些特定條件下才得以運行，因此在現(xiàn)有的測試中沒有很好的覆蓋到。（據(jù)推測，這些條件需要存在于一個足夠“老”的數(shù)據(jù)庫快照，以便被刪除腳本所捕獲。）

Mattingly 進一步指出由于沒有任何快照數(shù)據(jù)庫，Sprint 222 的內部部署（第0環(huán)）沒有發(fā)生任何意外，幾天后，軟件變更被部署到客戶環(huán)境（第1環(huán)）被用于南巴西規(guī)模單位（一個特定角色的服務器集群）。該環(huán)境中有一個快照數(shù)據(jù)庫，其年齡“老”到足以觸發(fā)該錯誤，最終導致后臺工作刪除了該規(guī)模單位的“整個 Azure SQL 服務器和所有 17 個生產(chǎn)數(shù)據(jù)庫”。

經(jīng)過十多個小時的努力，微軟方面已經(jīng)全部恢復了數(shù)據(jù)庫，為防止此類問題再次發(fā)生，微軟已經(jīng)采取各種修復和重新配置措施。花費如此長時間的原因如下：

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

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

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

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