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