代碼拼寫錯誤刪微軟數(shù)據(jù)庫，癱10小時。-世界聚看點

轉(zhuǎn)自：CSDN（ID：CSDNnews）

(資料圖片僅供參考)

5 月 24 日，微軟 Azure DevOps 在巴西南部（SBR）區(qū)域內(nèi)一處 scale-unit（微軟 Azure 部署架構(gòu)中最小的容量單元）設(shè)施發(fā)生癱瘓，持續(xù)了 10 個小時。

6 月 2 日，微軟首席軟件工程經(jīng)理 Eric Mattingly 為這次故障出面道歉，并透露了具體原因：一個簡單的錯誤拼寫，導致了整整 17 個生產(chǎn)級數(shù)據(jù)庫被刪除。

“隱藏”著一條拼寫錯誤

Mattingly 解釋道，Azure DevOps 工程師偶爾會對生產(chǎn)級數(shù)據(jù)庫的快照進行保存，以查看報告上的問題或測試性能改進。為清理這些快照數(shù)據(jù)庫，會有專門的后臺每天運行，系統(tǒng)會在一段設(shè)定的時間后刪除舊快照。

在最近的一波 sprint （敏捷開發(fā)術(shù)語中的迭代開發(fā)周期）中，Azure DevOps 工程師執(zhí)行了一次代碼升級，將已棄用的 Microsoft .Azure. Management.* 軟件包換成受支持的 Azure.ResourceManager.* NuGet 軟件包。

這個操作，連帶著大量 pull request 變更請求，會將舊包中的 API 調(diào)用替換為新包中的 API 調(diào)用——而引發(fā)此次事件的拼寫錯誤，就出現(xiàn)在 pull request 內(nèi)，導致后臺快照刪除作業(yè)刪掉了整個服務(wù)器。

Mattingly 表示：“這條 pull request 中的快照刪除作業(yè)中，隱藏著一條拼寫錯誤，它會刪除 Azure SQL 數(shù)據(jù)庫調(diào)用，并替換成刪除托管數(shù)據(jù)庫的 Azure SQL Server 調(diào)用。”

按理來說，Azure DevOps 有一系列測試可發(fā)現(xiàn)這類問題。但 Mattingly 稱，該錯誤代碼只在某些條件下運行，因此沒有被現(xiàn)有的測試機制及時發(fā)現(xiàn)。

Mattingly 表示，Azure DevOps 工程師使用安全部署實踐（SDP）將 Sprint 222 部署到了 Ring 0（微軟內(nèi)部部署），那里不存在快照數(shù)據(jù)庫，所以刪除作業(yè)不會執(zhí)行。但幾天后，Azure DevOps 工程師又將其部署至 Ring 1（客戶環(huán)境），也就是巴西南部的 scale-unit 設(shè)施。該環(huán)境中有一個比較舊的快照數(shù)據(jù)庫，因此觸發(fā)這個錯誤代碼，于是它在刪除 Azure SQL Server 的同時，還刪掉了 scale-unit 設(shè)施中的 17 個生產(chǎn)級數(shù)據(jù)庫。

好在，據(jù) Mattingly 介紹，此次事件并未引發(fā)數(shù)據(jù)丟失。為了防止問題再次發(fā)生，Mattingly 稱微軟已采取了各種修復和重置措施，并向所有受此中斷影響的客戶道歉。

為何花費了 10 個小時才全部恢復？

據(jù)微軟官方介紹，這 17 個生產(chǎn)級數(shù)據(jù)庫被刪后 20 分鐘不到，其工程師就檢測到了中斷并立即開始搶修，但依舊花費了 10 個小時才完全恢復。

Mattingly 表示，這其中有幾個原因：

? 首先，客戶無法自己恢復 Azure SQL Server，因此必須由 Azure 團隊來處理這項工作，這個過程對許多人來說大約需要一個小時。

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

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

這些問題是服務(wù)器預熱任務(wù)引起的，該任務(wù)會通過測試調(diào)用遍歷可用的數(shù)據(jù)庫列表。但恢復過程中的數(shù)據(jù)庫拋出了一個錯誤，導致預熱測試“執(zhí)行指數(shù)級的 backoff 重試“，結(jié)果導致正常情況下只需不到 1 秒的預熱過程，平均耗時了 90 分鐘。

更復雜的是，整個恢復過程是交錯進行的，一旦其中一兩臺服務(wù)器重新開始接收客戶流量，就會因過載而再次停運。最終，工程師只能阻斷所有流向巴西南部 scale-unit 的流量，確保一切準備就緒后，再重新加入負載均衡器并處理流量。

目前，為防止此次事故再次發(fā)生，微軟方面已實施各種修復和重新配置。Mattingly 說：“我們再次向所有受到這次故障影響的客戶道歉?！?/p>

網(wǎng)友：微軟只是繼續(xù)“貼膏藥”

盡管如此，但此次微軟的道歉并沒有得到網(wǎng)友的諒解：

?“看來 Azure 變得越來越復雜了，而頻繁變化加上日益增加的復雜性，最終只會走上一條路：更多的災難以及可靠性降低。聽起來微軟對此事故的解決方案是繼續(xù)“貼膏藥”，但我認為在某個階段，還是有必要對方法進行更根本的重新思考，避免最終分崩離析?！?/p>

甚至因為這個簡單的 Bug 導致 10 小時宕機的結(jié)果，不少網(wǎng)友也開始討論“云”的必要性：

?“關(guān)于云和DevOps最可怕的事情是，其實大多數(shù)文件都相當簡潔，但其中總是有許多神奇的鍵/值，而實際上它們在代碼審查中并沒有任何意義?！?/p>

?“這就是我討厭云的眾多原因之一。十多年來，我一直沒有與 IaaS 打交道的樂趣，我的本地內(nèi)容非常完美，我還成功地抵御了過去十年中那些想要一次又一次將云帶回來的人?！?/h4>

對此，你又有哪些看法呢？

參考鏈接：

https://www.theregister.com/2023/06/03/microsoft_azure_outage_brazil/

https://status.dev.azure.com/_event/392143683/post-mortem

- EOF -

溫馨提示

關(guān)注【擴展迷EXTFANS】

閱讀更多精彩內(nèi)容

標簽：