首頁 > 行業 > 正文

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

2023-06-17 22:03:24來源：擴展迷EXTFANS

轉自：CSDN（ID：CSDNnews）

(資料圖片僅供參考)

5 月 24 日，微軟 Azure DevOps 在巴西南部（SBR）區域內一處 scale-unit（微軟 Azure 部署架構中最小的容量單元）設施發生癱瘓，持續了 10 個小時。

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

“隱藏”著一條拼寫錯誤

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

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

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

Mattingly 表示：“這條 pull request 中的快照刪除作業中，隱藏著一條拼寫錯誤，它會刪除 Azure SQL 數據庫調用，并替換成刪除托管數據庫的 Azure SQL Server 調用?！?/p>

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

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

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

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

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

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

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

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

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

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

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

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

網友：微軟只是繼續“貼膏藥”

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