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