一個拼寫錯誤致微軟 Azure DevOps 宕機 10 小時
微軟Azure DevOps是一套應用程序生命周期服務。5 月 24 日，Azure DevOps 在巴西南部(SBR)區域內一處 scale-unit(微軟 Azure 部署架構中最小的容量單元)設施發生宕機，宕機持續了 10 個小時。
近日，微軟首席軟件工程經理 Eric Mattingly 對宕機事件表達歉意并透露了宕機原因：一個簡單的拼寫錯誤，致使 17 個生產數據庫遭到刪除。
Mattingly 解釋道，Azure DevOps 工程師偶爾會保存生產數據庫的快照，據此調查上報的問題或測試性能改進方向。為了清理這些快照數據庫，會有專門的后臺作業每天運行，并在快照超過一定期限后將其刪除。
在最近的一波沖刺(敏捷上下文中的小組項目，編號為 Sprint 222)中，Azure DevOps 工程師執行了代碼升級，想要用受支持的 Azure.ResourceManager.* NuGet 包替換掉已被棄用的
Microsoft.Azure.Managment.*包。
這對應著一條巨大的 pull request 變更請求，會將舊包中的 API 調用替換為新包中的 API 調用。引發此次事件的拼寫錯誤就出現在 pull request 內，導致后臺快照刪除作業刪掉了整個服務器。
Mattingly 表示，“這條 pull request 中的快照刪除作業里隱藏著一條拼寫錯誤，它會刪除 Azure SQL 數據庫調用，并替換成刪除托管數據庫的 Azure SQL Server 調用。”
Azure DevOps 工程師使用安全部署實踐(SDP)將 Sprint 222 部署到了 Ring 0(微軟內部 Azure DevOps 組織)，這里不存在快照數據庫，所以刪除作業不會執行。在 Ring 0 測試幾天之后，Azure DevOps 工程師又將其部署至 Ring 1，也就是在此期間巴西南部的 scale-unit 設施受到了影響。快照數據庫的存在時間觸發了這項 bug，該作業在刪除 Azure SQL Server 的同時，還刪掉了 scale-unit 設施中所有 17 個生產數據庫。從這時起，Azure DevOps 的 scale-unit 無法處理任何客戶流量。
據 Mattingly 介紹，此次宕機事件并未引發數據丟失。為了防止問題再次發生，Mattingly 稱微軟已經采取了各種修復和重新配置措施，并向所有受此中斷影響的客戶道歉。
為什么耗時 10 小時才完成恢復?
據了解，Azure DevOps 是有檢測此類問題的測試的。但根據 Mattingly 的介紹，“之所以以往沒有發現，是因為這部分代碼的運行條件非常罕見，我們的測試并沒有切實覆蓋這些極端情況。”有推測認為，這種極端條件要求刪除腳本捕捉到特別陳舊的數據庫快照。
雖然目前數據已經全部恢復，但整個宕機前后耗時 10 多個小時，為什么這么久才完成修復?Mattingly 對此做出了解釋說明：“我們在數據庫被刪除后的 20 分鐘內檢測到宕機，值班工程師立即參與修復。在快速理解問題來源之后，我們開始恢復 SQL Server 及所有數據庫，并禁用了快照刪除作業以防止該 bug 影響到其他客戶。但由于問題數量較多，因此恢復時間也相對較長。”
首先，客戶無法自行恢復 Azure SQL Server，因此必須由 Azure SQL 團隊參與恢復工作。確定需要 Azure SQL 值班工程師介入，接洽實際情況和問題，再加上服務器的實際恢復大約耗費了 1 個小時。
其次，所有數據庫均配置有備份冗余，但部分數據庫的創建時間早于區域冗余備份的上線時間。在恢復數據庫時，Azure DevOps 為所有數據庫選擇了 Geo-zone-redundant，導致一部分還原數據按照此前配置的 Zone-redundant 備份被復制到了配對區域。這種匹配沖突又讓恢復過程延長了好幾個小時。對于這個問題，Azure DevOps 將確保所有數據庫備份均按 Azure 區域支持被配置為 Geo-zone-redundant，使其覆蓋 Azure DevOps 中的所有 scale-unit。
最后，在數據庫開始恢復上線之后，由于 Azure DevOps 的 Web 服務器出現了一系列復雜問題，盡管數據庫內容已經完成還原，客戶也仍然無法訪問整個 scale-unit 設施。
這個問題源自服務器的預熱任務，該任務會通過測試調用遍歷可用的數據庫列表。但恢復過程中數據庫招聘了一項錯誤，導致預熱測試“執行指數級退避重試，令預熱耗時由正常情況下的不到一秒延長到了平均 90 分鐘。”
更復雜的是，整個恢復過程是交錯進行的，一旦其中一、兩臺服務器重新開始接收客戶流量，就會因過載而再次宕機。最終，工程師在只能阻斷所有流向巴西南部 scale-unit 的流量，確保一切準備就緒再重新加入負載均衡器并處理流量。
如何避免此類問題再次發生?
目前，Azure DevOps 已經修復了快照刪除作業中的 bug，并為快照刪除作業創建了新的測試，面向真實 Azure 資源充分反映快照數據庫的刪除場景。
Mattingly 表示，Azure DevOps 正著手為關鍵資源添加 Azure 資源管理器鎖，借此防止意外刪除。同時，確保所有 Azure SQL 數據庫備份均被配置為 Geo-zone-redundant 形式，并受到 Azure 區域的支持;確保未來的所有快照數據庫，只會被創建在不同于生產數據庫的 Azure SQL Server 實例之上。
此外，還會修復 Web 服務器預熱任務的邏輯，確保即使數據庫處于脫機狀態時也能成功啟動。并創建新的 cmdlet 來恢復已被刪除的數據庫，確保恢復結果使用與被刪除前相同的設置(包括備份冗余)。
參考鏈接：
https://status.dev.azure.com/_event/392143683/post-mortem
https://www.theregister.com/2023/06/03/microsoft_azure_outage_brazil/
