整理 | 禾木木 責編 | 鄭麗媛
出品 | 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