整理 | 禾木木 責編 | 鄭麗媛
出品 | 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 調用。”
按理來說，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 說：“我們再次向所有受到這次故障影響的客戶道歉。”
網友：微軟隻是繼續“貼膏藥”
盡管如此，但此次微軟的道歉并沒有得到網友的諒解：
▶ “看來 Azure 變得越來越複雜了，而頻繁變化加上日益增加的複雜性，最終隻會走上一條路：更多的災難以及可靠性降低。聽起來微軟對此事故的解決方案是繼續“貼膏藥”，但我認為在某個階段，還是有必要對方法進行更根本的重新思考，避免最終分崩離析。”
甚至因為這個簡單的 Bug 導緻 10 小時當機的結果，不少網友也開始讨論“雲”的必要性：
▶ “關于雲和 DevOps 最可怕的事情是，其實大多數檔案都相當簡潔，但其中總是有許多神奇的鍵/值，而實際上它們在代碼審查中并沒有任何意義。”
▶ “這就是我讨厭雲的衆多原因之一。十多年來，我一直沒有與 IaaS 打交道的樂趣，我的本地内容非常完美，我還成功地抵禦了過去十年中那些想要一次又一次将雲帶回來的人。”
對此，你又有哪些看法呢？
參考連結：
https://www.theregister.com/2023/06/03/microsoft_azure_outage_brazil/
https://status.dev.azure.com/_event/392143683/post-mortem