5 月 24 日，微軟 Azure DevOps 在巴西南部地區(qū)的一處 scale-unit 發(fā)生故障，導(dǎo)致宕機(jī)約 10.5 個(gè)小時(shí)。近日，微軟首席軟件工程經(jīng)理 Eric Mattingly 出面針對(duì)此次故障事件道歉，并透露了導(dǎo)致中斷的原因：即，一個(gè)簡(jiǎn)單的拼寫錯(cuò)誤致使 17 個(gè)生產(chǎn)級(jí)數(shù)據(jù)庫(kù)被刪除。

事件背景起源于，Azure DevOps 工程師有時(shí)需要對(duì)生產(chǎn)數(shù)據(jù)庫(kù)的快照進(jìn)行保存，以調(diào)查報(bào)告的問(wèn)題或測(cè)試性能改進(jìn)。為了確保這些快照數(shù)據(jù)庫(kù)得到清理，會(huì)有一個(gè)專門的后臺(tái)每天運(yùn)行，系統(tǒng)會(huì)在設(shè)定的時(shí)間段后刪除舊快照。

在 Sprint 222 期間，Azure DevOps 工程師升級(jí)了代碼庫(kù)，將已棄用的 Microsoft.Azure.Managment.* 包替換為受支持的 Azure.ResourceManager.* NuGet 包。此舉連帶了大量的 pull request 變更請(qǐng)求，以尋求將舊包中的 API 調(diào)用替換為新包中的 API 調(diào)用。而其中就隱藏了有關(guān)快照刪除作業(yè)中的一個(gè)拼寫錯(cuò)誤，它將刪除 Azure SQL 數(shù)據(jù)庫(kù)的調(diào)用換成了刪除托管數(shù)據(jù)庫(kù)的 Azure SQL Server 的調(diào)用。

Eric 稱，運(yùn)行此代碼的條件很少見(jiàn)，因此測(cè)試機(jī)制沒(méi)有很好地覆蓋。

我們使用我們的安全部署實(shí)踐 （SDP） 將 Sprint 222 部署到 Ring 0（我們的內(nèi)部 Azure DevOps 組織），其中不存在快照數(shù)據(jù)庫(kù)，因此作業(yè)沒(méi)有執(zhí)行。在 Ring 0 部署了幾天之后，我們接下來(lái)部署到 Ring 1，那里是受影響的巴西南部 scale-unit 所在的地方。其中快照數(shù)據(jù)庫(kù)的存在時(shí)間足以觸發(fā)錯(cuò)誤代碼，當(dāng)作業(yè)刪除 Azure SQL Server 時(shí)，它還刪除了 scale-unit 中的所有 17 個(gè)生產(chǎn)數(shù)據(jù)庫(kù)。從那時(shí)起，該 scale unit 就無(wú)法處理任何客戶流量。

Azure DevOps 工程師在數(shù)據(jù)庫(kù)刪除開始后 20 分鐘內(nèi)檢測(cè)到中斷，并開始著手修復(fù)。目前數(shù)據(jù)已經(jīng)全部恢復(fù)，但卻花費(fèi)了長(zhǎng)達(dá)十個(gè)小時(shí)。對(duì)此 Mattingly 則解釋了幾個(gè)原因：

首先，客戶無(wú)法自己恢復(fù) Azure SQL Server，因此必須由 Azure SQL 團(tuán)隊(duì)來(lái)恢復(fù) Azure SQL Server。“確定我們需要 Azure SQL 的值班工程師，讓他們參與進(jìn)來(lái)并恢復(fù)服務(wù)器，這個(gè)過(guò)程大約需要一個(gè)小時(shí)。”

其次，數(shù)據(jù)庫(kù)有不同的備份配置，一些被配置為 Zone 冗余備份，另一些則被配置為較新的 Geo-zone 冗余備份。協(xié)調(diào)這種不匹配情況給恢復(fù)過(guò)程增添了不少時(shí)間。

最后，在數(shù)據(jù)庫(kù)開始重新上線后，由于 Web 服務(wù)器出現(xiàn)了一系列復(fù)雜的問(wèn)題，即使是數(shù)據(jù)位于這些數(shù)據(jù)庫(kù)中的客戶，也無(wú)法訪問(wèn)整個(gè) scale-unit。

根據(jù)介紹，這些問(wèn)題源于服務(wù)器預(yù)熱任務(wù)，該任務(wù)通過(guò)測(cè)試調(diào)用遍歷可用數(shù)據(jù)庫(kù)列表。在恢復(fù)過(guò)程中的數(shù)據(jù)庫(kù)出現(xiàn)了一個(gè)錯(cuò)誤，導(dǎo)致預(yù)熱測(cè)試 “執(zhí)行指數(shù)級(jí)的 backoff retry，使得正常情況下只需不到 1 秒的預(yù)熱平均耗時(shí)了 90 分鐘?！?/p>

更復(fù)雜的是，這個(gè)恢復(fù)過(guò)程是交錯(cuò)進(jìn)行的，一旦有一兩臺(tái)服務(wù)器開始重新接受客戶的流量，它們就會(huì)過(guò)載并出現(xiàn)故障。最終，恢復(fù)服務(wù)需要工程師阻斷所有流向巴西南部 scale-unit 的流量，直到一切都準(zhǔn)備就緒后再重新加入負(fù)載平衡器和處理流量。

微軟方面表示，已經(jīng)實(shí)施各種修復(fù)和重新配置，以防止問(wèn)題再次發(fā)生。

已經(jīng)修復(fù)了快照刪除作業(yè)中的錯(cuò)誤。

為快照刪除作業(yè)創(chuàng)建了一個(gè)新測(cè)試，它針對(duì)真實(shí)的 Azure 資源充分執(zhí)行快照數(shù)據(jù)庫(kù)刪除方案。

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

確保所有的 Azure SQL 數(shù)據(jù)庫(kù)備份都配置為 Geo-zone-redundant。

確保所有未來(lái)的快照數(shù)據(jù)庫(kù)都在生產(chǎn)數(shù)據(jù)庫(kù)的不同 Azure SQL Server 實(shí)例上創(chuàng)建。

正在修復(fù) Web 服務(wù)器預(yù)熱任務(wù)中的邏輯，以便即使數(shù)據(jù)庫(kù)處于 offline 狀態(tài)也能成功啟動(dòng)。

正在創(chuàng)建一個(gè)新的 cmdlet 來(lái)恢復(fù)已刪除的數(shù)據(jù)庫(kù)，以確?；謴?fù)使用與刪除之前相同的設(shè)置（包括備份冗余）。