一個拼寫錯誤致微軟 Azure DevOps 宕機 10 小時
微軟(ruan)Azure DevOps是一(yi)(yi)套(tao)應用程序生(sheng)命(ming)周期服務。5 月 24 日，Azure DevOps 在巴西南(nan)部(SBR)區域內一(yi)(yi)處 scale-unit(微軟(ruan) Azure 部署架構中最(zui)小的(de)容量單元(yuan))設施發生(sheng)宕(dang)機，宕(dang)機持(chi)續(xu)了 10 個小時。
近日，微軟首席軟件工程經理 Eric Mattingly 對宕機事件表達歉意并透露了宕機原因：一個簡單的拼寫錯誤，致使 17 個生產數據庫遭到刪除。
Mattingly 解(jie)釋道，Azure DevOps 工(gong)程師偶爾會(hui)保存(cun)生(sheng)產(chan)數(shu)據(ju)(ju)庫(ku)的快照，據(ju)(ju)此調(diao)查上報的問題或測試(shi)性能(neng)改進方向。為了清(qing)理這些快照數(shu)據(ju)(ju)庫(ku)，會(hui)有專門的后臺作業(ye)每天(tian)運(yun)行(xing)，并在(zai)快照超過一(yi)定期限后將其刪除。
在最近(jin)的(de)一(yi)波沖刺(敏捷上下文中的(de)小組(zu)項目，編號為 Sprint 222)中，Azure DevOps 工程師執行了代碼升級，想(xiang)要用受支持的(de) Azure.ResourceManager.* NuGet 包替(ti)換掉已被棄用的(de)
Microsoft.Azure.Managment.*包。
這(zhe)對應著一條巨大的(de)(de) pull request 變更請求，會(hui)將(jiang)舊包(bao)中的(de)(de) API 調(diao)用替換為新包(bao)中的(de)(de) API 調(diao)用。引發(fa)此次(ci)事件(jian)的(de)(de)拼寫錯誤就出現(xian)在 pull request 內，導致(zhi)后臺快照刪(shan)除作業(ye)刪(shan)掉了整個服務器。
Mattingly 表示(shi)，“這(zhe)條 pull request 中(zhong)的快照刪除(chu)(chu)作業里(li)隱藏著(zhu)一條拼寫(xie)錯(cuo)誤，它會刪除(chu)(chu) Azure SQL 數(shu)據庫調用(yong)，并替換成(cheng)刪除(chu)(chu)托(tuo)管(guan)數(shu)據庫的 Azure SQL Server 調用(yong)。”
Azure DevOps 工(gong)程師(shi)使用安全部署實(shi)踐(SDP)將(jiang) Sprint 222 部署到了(le)(le) Ring 0(微(wei)軟內部 Azure DevOps 組織)，這里不(bu)存在快(kuai)照數(shu)(shu)(shu)據(ju)庫，所以刪除作(zuo)(zuo)業不(bu)會執行。在 Ring 0 測試幾天(tian)之后(hou)，Azure DevOps 工(gong)程師(shi)又將(jiang)其部署至 Ring 1，也就(jiu)是在此(ci)期間(jian)巴西南部的(de)(de) scale-unit 設施(shi)受到了(le)(le)影響。快(kuai)照數(shu)(shu)(shu)據(ju)庫的(de)(de)存在時(shi)間(jian)觸發了(le)(le)這項 bug，該(gai)作(zuo)(zuo)業在刪除 Azure SQL Server 的(de)(de)同時(shi)，還刪掉(diao)了(le)(le) scale-unit 設施(shi)中所有 17 個生產數(shu)(shu)(shu)據(ju)庫。從(cong)這時(shi)起(qi)，Azure DevOps 的(de)(de) scale-unit 無法處理任(ren)何(he)客戶流(liu)量。
據 Mattingly 介紹，此次宕機事件(jian)并(bing)未引(yin)發數據丟失。為了(le)防(fang)止問題(ti)再次發生，Mattingly 稱微(wei)軟已經采取了(le)各種修復和重新(xin)配置措施，并(bing)向所有受此中斷影響的(de)客(ke)戶(hu)道歉。
為什么耗時 10 小時才完成恢復?
據(ju)了解，Azure DevOps 是(shi)有(you)(you)檢測此類問題的(de)(de)測試(shi)的(de)(de)。但根據(ju) Mattingly 的(de)(de)介紹，“之所(suo)以以往沒(mei)有(you)(you)發(fa)現，是(shi)因為這(zhe)部分代碼的(de)(de)運行(xing)條(tiao)件非常罕見(jian)，我們的(de)(de)測試(shi)并沒(mei)有(you)(you)切實覆蓋這(zhe)些(xie)極端(duan)情況。”有(you)(you)推測認為，這(zhe)種極端(duan)條(tiao)件要求(qiu)刪除(chu)腳本捕捉到特(te)別陳舊的(de)(de)數據(ju)庫快照(zhao)。
雖然目前(qian)數(shu)據已經全部恢復(fu)(fu)(fu)，但整個宕機前(qian)后耗時 10 多個小(xiao)時，為什(shen)么(me)(me)這么(me)(me)久才完(wan)成修復(fu)(fu)(fu)?Mattingly 對此做出了解(jie)釋說明(ming)：“我們(men)在數(shu)據庫被刪除(chu)后的(de) 20 分鐘內檢測到宕機，值班工程師立即參與(yu)修復(fu)(fu)(fu)。在快速理解(jie)問(wen)題來源之(zhi)后，我們(men)開始恢復(fu)(fu)(fu) SQL Server 及所有(you)數(shu)據庫，并禁用了快照刪除(chu)作業以防止該(gai) bug 影響(xiang)到其(qi)他客戶。但由于問(wen)題數(shu)量(liang)較多，因此恢復(fu)(fu)(fu)時間也相對較長(chang)。”
首(shou)先，客戶無法自行(xing)恢(hui)(hui)復(fu) Azure SQL Server，因此必須由(you) Azure SQL 團隊參與恢(hui)(hui)復(fu)工(gong)作。確定需要 Azure SQL 值班(ban)工(gong)程師介入，接洽實(shi)際(ji)情況和問題(ti)，再加上服(fu)務器的實(shi)際(ji)恢(hui)(hui)復(fu)大(da)約耗(hao)費(fei)了 1 個小時。
其次，所(suo)(suo)(suo)有(you)數(shu)據(ju)(ju)(ju)庫(ku)均配(pei)置(zhi)有(you)備份(fen)冗余(yu)，但(dan)部分數(shu)據(ju)(ju)(ju)庫(ku)的創建時(shi)(shi)間早于區(qu)域(yu)冗余(yu)備份(fen)的上線時(shi)(shi)間。在(zai)恢(hui)復(fu)數(shu)據(ju)(ju)(ju)庫(ku)時(shi)(shi)，Azure DevOps 為所(suo)(suo)(suo)有(you)數(shu)據(ju)(ju)(ju)庫(ku)選擇了 Geo-zone-redundant，導致(zhi)一(yi)部分還原數(shu)據(ju)(ju)(ju)按照(zhao)此前(qian)配(pei)置(zhi)的 Zone-redundant 備份(fen)被(bei)復(fu)制到了配(pei)對區(qu)域(yu)。這(zhe)(zhe)種匹配(pei)沖突又讓恢(hui)復(fu)過程延長了好幾個(ge)小(xiao)時(shi)(shi)。對于這(zhe)(zhe)個(ge)問題(ti)，Azure DevOps 將確保所(suo)(suo)(suo)有(you)數(shu)據(ju)(ju)(ju)庫(ku)備份(fen)均按 Azure 區(qu)域(yu)支持被(bei)配(pei)置(zhi)為 Geo-zone-redundant，使其覆(fu)蓋 Azure DevOps 中的所(suo)(suo)(suo)有(you) scale-unit。
最后(hou)，在數(shu)據庫開始恢復上線之后(hou)，由于(yu) Azure DevOps 的 Web 服務器出現了一系列復雜問題，盡管數(shu)據庫內容已經完成還原(yuan)，客戶也仍然無法訪問整個 scale-unit 設(she)施。
這個(ge)問題源自(zi)服務器的(de)(de)預(yu)熱(re)任務，該(gai)任務會通過(guo)測(ce)試調用遍(bian)歷可用的(de)(de)數(shu)據庫列表。但恢復(fu)過(guo)程中(zhong)數(shu)據庫招聘(pin)了(le)一項錯(cuo)誤，導(dao)致(zhi)預(yu)熱(re)測(ce)試“執行(xing)指(zhi)數(shu)級退避重試，令預(yu)熱(re)耗時由正常情(qing)況下的(de)(de)不到(dao)(dao)一秒延(yan)長到(dao)(dao)了(le)平均 90 分鐘(zhong)。”
更復雜的是，整個恢復過程是交錯進(jin)行的，一旦其中一、兩(liang)臺服務器重新開始接收客戶流量，就(jiu)會因過載(zai)而再(zai)次宕(dang)機。最終(zhong)，工程師在只(zhi)能(neng)阻斷所有流向巴西(xi)南部(bu) scale-unit 的流量，確保一切(qie)準備就(jiu)緒再(zai)重新加入負載(zai)均衡器并(bing)處理(li)流量。
如何避免此類問題再次發生?
目前(qian)，Azure DevOps 已經修復了(le)快照(zhao)刪除作業中的(de) bug，并為快照(zhao)刪除作業創建(jian)了(le)新(xin)的(de)測試，面向真實 Azure 資源充(chong)分反(fan)映快照(zhao)數據庫的(de)刪除場(chang)景。
Mattingly 表示(shi)，Azure DevOps 正著手為關(guan)鍵(jian)資源添(tian)加 Azure 資源管(guan)理器鎖，借(jie)此(ci)防(fang)止(zhi)意外刪(shan)除。同時，確保所有 Azure SQL 數(shu)據(ju)庫備份均被配置為 Geo-zone-redundant 形式，并受到 Azure 區域的(de)支持;確保未來(lai)的(de)所有快照數(shu)據(ju)庫，只(zhi)會被創建在不同于生產數(shu)據(ju)庫的(de) Azure SQL Server 實例之上。
此外(wai)，還會修復(fu) Web 服(fu)務(wu)器(qi)預熱(re)任務(wu)的邏輯，確(que)保即(ji)使數據(ju)庫(ku)處(chu)于脫機狀態時也(ye)能(neng)成(cheng)功啟動(dong)。并創建(jian)新的 cmdlet 來恢(hui)復(fu)已被刪除的數據(ju)庫(ku)，確(que)保恢(hui)復(fu)結果使用與被刪除前相同的設置(包括備份冗余)。
參考鏈接：
//status.dev.azure.com/_event/392143683/post-mortem
//www.theregister.com/2023/06/03/microsoft_azure_outage_brazil/
