代碼拼寫(xiě)錯(cuò)誤刪微軟數(shù)據(jù)庫(kù)，癱10小時(shí)。-世界聚看點(diǎn)

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

(資料圖片僅供參考)

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

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

“隱藏”著一條拼寫(xiě)錯(cuò)誤

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

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

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

Mattingly 表示：“這條 pull request 中的快照刪除作業(yè)中，隱藏著一條拼寫(xiě)錯(cuò)誤，它會(huì)刪除 Azure SQL 數(shù)據(jù)庫(kù)調(diào)用，并替換成刪除托管數(shù)據(jù)庫(kù)的 Azure SQL Server 調(diào)用?！?/p>

按理來(lái)說(shuō)，Azure DevOps 有一系列測(cè)試可發(fā)現(xiàn)這類問(wèn)題。但 Mattingly 稱，該錯(cuò)誤代碼只在某些條件下運(yùn)行，因此沒(méi)有被現(xiàn)有的測(cè)試機(jī)制及時(shí)發(fā)現(xiàn)。

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

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

為何花費(fèi)了 10 個(gè)小時(shí)才全部恢復(fù)？

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

Mattingly 表示，這其中有幾個(gè)原因：

? 首先，客戶無(wú)法自己恢復(fù) Azure SQL Server，因此必須由 Azure 團(tuán)隊(duì)來(lái)處理這項(xiàng)工作，這個(gè)過(guò)程對(duì)許多人來(lái)說(shuō)大約需要一個(gè)小時(shí)。

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

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

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

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

目前，為防止此次事故再次發(fā)生，微軟方面已實(shí)施各種修復(fù)和重新配置。Mattingly 說(shuō)：“我們?cè)俅蜗蛩惺艿竭@次故障影響的客戶道歉?！?/p>

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

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

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

甚至因?yàn)檫@個(gè)簡(jiǎn)單的 Bug 導(dǎo)致 10 小時(shí)宕機(jī)的結(jié)果，不少網(wǎng)友也開(kāi)始討論“云”的必要性：

?“關(guān)于云和DevOps最可怕的事情是，其實(shí)大多數(shù)文件都相當(dāng)簡(jiǎn)潔，但其中總是有許多神奇的鍵/值，而實(shí)際上它們?cè)诖a審查中并沒(méi)有任何意義。”

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

對(duì)此，你又有哪些看法呢？

參考鏈接：

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

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

- EOF -

溫馨提示

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

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

標(biāo)簽：