5 月 24 日，微軟 Azure DevOps 在巴西南部地區的一處 scale-unit 發生故障，導致宕機約 10.5 個小時。近日，微軟首席軟件工程經理 Eric Mattingly 出面針對此次故障事件道歉，并透露了導致中斷的原因：即，一個簡單的拼寫錯誤致使 17 個生產級數據庫被刪除。

事件背景起源于，Azure DevOps 工程師有時需要對生產數據庫的快照進行保存，以調查報告的問題或測試性能改進。為了確保這些快照數據庫得到清理，會有一個專門的后臺每天運行，系統會在設定的時間段后刪除舊快照。

在 Sprint 222 期間，Azure DevOps 工程師升級了代碼庫，將已棄用的 Microsoft.Azure.Managment.* 包替換為受支持的 Azure.ResourceManager.* NuGet 包。此舉連帶了大量的 pull request 變更請求，以尋求將舊包中的 API 調用替換為新包中的 API 調用。而其中就隱藏了有關快照刪除作業中的一個拼寫錯誤，它將刪除 Azure SQL 數據庫的調用換成了刪除托管數據庫的 Azure SQL Server 的調用。

Eric 稱，運行此代碼的條件很少見，因此測試機制沒有很好地覆蓋。

我們使用我們的安全部署實踐 （SDP） 將 Sprint 222 部署到 Ring 0（我們的內部 Azure DevOps 組織），其中不存在快照數據庫，因此作業沒有執行。在 Ring 0 部署了幾天之后，我們接下來部署到 Ring 1，那里是受影響的巴西南部 scale-unit 所在的地方。其中快照數據庫的存在時間足以觸發錯誤代碼，當作業刪除 Azure SQL Server 時，它還刪除了 scale-unit 中的所有 17 個生產數據庫。從那時起，該 scale unit 就無法處理任何客戶流量。

Azure DevOps 工程師在數據庫刪除開始后 20 分鐘內檢測到中斷，并開始著手修復。目前數據已經全部恢復，但卻花費了長達十個小時。對此 Mattingly 則解釋了幾個原因：

首先，客戶無法自己恢復 Azure SQL Server，因此必須由 Azure SQL 團隊來恢復 Azure SQL Server。“確定我們需要 Azure SQL 的值班工程師，讓他們參與進來并恢復服務器，這個過程大約需要一個小時。”

其次，數據庫有不同的備份配置，一些被配置為 Zone 冗余備份，另一些則被配置為較新的 Geo-zone 冗余備份。協調這種不匹配情況給恢復過程增添了不少時間。

最后，在數據庫開始重新上線后，由于 Web 服務器出現了一系列復雜的問題，即使是數據位于這些數據庫中的客戶，也無法訪問整個 scale-unit。

根據介紹，這些問題源于服務器預熱任務，該任務通過測試調用遍歷可用數據庫列表。在恢復過程中的數據庫出現了一個錯誤，導致預熱測試 “執行指數級的 backoff retry，使得正常情況下只需不到 1 秒的預熱平均耗時了 90 分鐘。”

更復雜的是，這個恢復過程是交錯進行的，一旦有一兩臺服務器開始重新接受客戶的流量，它們就會過載并出現故障。最終，恢復服務需要工程師阻斷所有流向巴西南部 scale-unit 的流量，直到一切都準備就緒后再重新加入負載平衡器和處理流量。

微軟方面表示，已經實施各種修復和重新配置，以防止問題再次發生。

已經修復了快照刪除作業中的錯誤。

為快照刪除作業創建了一個新測試，它針對真實的 Azure 資源充分執行快照數據庫刪除方案。

正在為關鍵資源添加 Azure 資源管理器鎖，以防止意外刪除。

確保所有的 Azure SQL 數據庫備份都配置為 Geo-zone-redundant。

確保所有未來的快照數據庫都在生產數據庫的不同 Azure SQL Server 實例上創建。

正在修復 Web 服務器預熱任務中的邏輯，以便即使數據庫處于 offline 狀態也能成功啟動。

正在創建一個新的 cmdlet 來恢復已刪除的數據庫，以確保恢復使用與刪除之前相同的設置（包括備份冗余）。