自12月18日阿里云香港可用區(qū)C因為機房水冷機組出現(xiàn)故障，導致一次阿里云歷史上最長的宕機后，官方終于在圣誕節(jié)那天，出具了一份非常翔實的調查報告《關于阿里云香港Region可用區(qū)C服務中斷事件的說明》，稱得上是實事求是面對問題了。

我從業(yè)十五年，參與建設過4000個節(jié)點的私有云，也搞過機房裝修和上架，還有一點運維經(jīng)驗，算是有相關經(jīng)驗，跟大家討論一下以后自家單位的容災應該怎么做吧。

大家先看這次阿里云宕機事故的重點時間線，8點56就發(fā)現(xiàn)機房溫控告警了，然后9點01就正確定位到制冷異常了。這個問題阿里云沒有隱瞞的必要，因為機房突然升溫，只能是空調（冷機）故障了。

這個事故的主要原因，就是因為制冷設備整整10個小時不能恢復工作，機房升溫太快，工程師為了保護數(shù)據(jù)，只能逐步關機。

次要原因是，在關機后還是有某個包間因為溫度過高導致噴淋裝置啟動。手機和電腦不能進水都已經(jīng)是常識了，服務器上淋了水那還得了？

再次原因，就是阿里云香港Reigon的架構設計，同樣沒有遵循自己提到的「全鏈路多可用區(qū)的業(yè)務架構設計」，新擴容的ECS管控系統(tǒng)啟動時依賴的中間件服務部署在可用區(qū)C機房，導致可用區(qū)C一旦宕機，擴容服務也啟動不了。相信后續(xù)阿里云一定會全網(wǎng)巡檢，整體優(yōu)化多可用區(qū)高可用設計，避免制造單點故障，類似依賴OSS單AZ和中間件單AZ的問題，再次出現(xiàn)就說不過去了。

第四個原因，是對于云服務來說，高可用架構能夠保障是某幾臺物理服務器（ECS、OSS、RDS）因為故障宕機時，原來的應用可以漂移到同一個AZ（可用區(qū)）的其他服務器上，保證服務的連續(xù)性和數(shù)據(jù)的可用性。但是原有復雜的分布式架構在一個AZ（可用區(qū)）整體出現(xiàn)網(wǎng)絡、服務器、存儲全部下線的時候，國內(nèi)沒有廠家敢于承諾100%實現(xiàn)全量無傷漂移到其他可用區(qū)，或者其他機房的。

打個比方，如果把中國大陸看成一個CN可用區(qū)，那么當武漢或者上海出現(xiàn)疫情的時候，是能夠把病人疏散到其他城市去治療，緩解自身醫(yī)療壓力的。但是當舉國上下都遭遇新冠的時候，病人還能往哪送？阿里云這次遭遇的是一個AZ（可用區(qū)）整體下線，里面近千個機柜、上萬臺設備的數(shù)據(jù)，又能切換到哪里？

第五個原因，是對極小概率事件的應急預案，是沒法考慮得那么周詳?shù)模踔镣耆紤]不到。比如誰能提前考慮服務器被噴淋裝置噴水導致?lián)p壞的場景？誰能考慮一個主備配置4+4的水冷機組，能夠同時出現(xiàn)故障，修好卻需要10個小時？

第六個原因，是對于一個巨型系統(tǒng)來說，有能力搞清楚里面所有的細節(jié)的總工程師，一定在新項目上，絕不是去搞運維浪費人才。其他的成員都是分模塊承擔任務的，他們只能選擇信任其他模塊。例如搞數(shù)據(jù)庫（RDS）的同學關注的是支持跨區(qū)遷移，誰能考慮到跨區(qū)遷移依賴的反向代理竟然不是跨區(qū)高可用的，結果大部分數(shù)據(jù)庫成功遷移了，但是香港可用區(qū)C一旦宕機，依賴這個反向代理的的數(shù)據(jù)庫就遷移不了。

所以，我來點評一下。

阿里云宕機的主要原因是機房主備水冷機組共用了同一個水路循環(huán)系統(tǒng)，存在單點故障，修這個就用了10個小時。然而這個機房還只是阿里云租的。查了一下阿里云香港C區(qū)所在的機房，應該是下圖的香港粉嶺安匯中心/安樂電話機房。（來自知乎@香港sim精神小伙）

這個機房原來是PCCW電訊盈科的，然后Vantage(數(shù)據(jù)中心園區(qū)提供商，其母公司是紐交所上市公司，代碼DBRG）在2021年剛剛收購了電訊盈科的數(shù)據(jù)中心。

《Vantage Data Centers 完成對 PCCW DC 的收購，將其一流的超大規(guī)模數(shù)據(jù)中心平臺帶到香港和吉隆坡 - Vantage Data Centers》

這兩棟機房同屬Vantage的HKG1園區(qū)，大概機房參數(shù)如下：

所以阿里云也是倒霉，租了個機房還換了東家。換了東家之后，最了解情況的中基層領導很可能已經(jīng)被掃地出門了，Twitter不就是這樣么？所以故障響應就會不及時。

修個水冷機組還要用10個小時，其中真正有效的時間就是排水補氣的3小時，除此之外，定位原因怎么要用3個半小時的？這個水冷機組的服務商也挺廢物的。

定位原因的3個半小時，就是設備維護商趕到現(xiàn)場的時間。一個重要數(shù)據(jù)中心的冷機壞了，香港的設備維護上用了3個半小時才到達現(xiàn)場，這種服務水平和響應速度極不可靠，從深圳到廣州也用不了三個小時吧。

另外，解鎖群控邏輯，手動啟動4臺冷機，竟然要用3小時32分，也說明服務商的工程師對這個系統(tǒng)根本都不熟，大概率是照著操作手冊現(xiàn)學現(xiàn)賣的。

2020年，微軟Azure位于美國東部的數(shù)據(jù)中心發(fā)生服務中斷，持續(xù)六小時。微軟披露說，冷卻系統(tǒng)故障是導致這次停機的原因，發(fā)生故障的樓宇自動化控制導致氣流減少，隨后整個數(shù)據(jù)中心的溫度峰值阻礙了網(wǎng)絡設備的性能，使計算和存儲實例無法訪問。但是微軟的信息披露沒有阿里云這一次這么翔實，這一點還是要給阿里云的實事求是點個贊。

2021年11月，網(wǎng)易游戲機房大規(guī)模服務器宕機，原因同事是機房過熱，空調重新開機也沒有解決問題。但幸好這只是游戲服務器，玩家是可以接受的。但是大陸的服務更到位，網(wǎng)易的宕機只用了3小時就恢復了。

2022年夏天，倫敦的谷歌云及甲骨文數(shù)據(jù)中心出現(xiàn)制冷系統(tǒng)故障，導致數(shù)據(jù)中心氣溫升高，產(chǎn)生宕機。甲骨文的是系統(tǒng)自動采取保護措施關閉作業(yè)，于是業(yè)務宕機；谷歌的是溫度過高導致存儲故障，引起虛擬機宕機，然后谷歌也關閉了一部分機器。

所以根據(jù)《建筑設計防火規(guī)范》GB50016規(guī)定，重要機房、配電房是需要做氣體自動滅火，這是中國大陸的規(guī)定。

但是我國的國標之間也有沖突，比如根據(jù)《《數(shù)據(jù)中心設計規(guī)范》GB 50174-2017》，只要數(shù)據(jù)中心的系統(tǒng)在其他數(shù)據(jù)中心內(nèi)有承擔相同功能的備份系統(tǒng)時，也可以設置自動噴水滅火系統(tǒng)。這個規(guī)范的主編單位是中國電子工程設計院。

我在2010年參與了蘇州國科數(shù)據(jù)中心Tier-IV機房項目，當時是東北亞最高端的機房，那時候我們用的就是七氟丙烷氣體滅火。參見《運營環(huán)境 蘇州國科數(shù)據(jù)中心》

為什么要用對人體有微毒性的七氟丙烷滅火，而不是用干粉、氣水霧或者噴淋方式滅火呢？因為電子設備就沒有不怕水的，干粉也會對設備造成傷害。順口再說一句，國外聲稱他們重視員工生命，所以建議少用這種有毒的氣體滅火方式。這方面很多公司都參考了美國消防協(xié)會NFPA的標準，國際某個頭部的云廠商也有不少這類設計。

我參與的項目還是經(jīng)受住了考驗，2022年10月13日，蘇州國科數(shù)據(jù)中心A2棟建筑屋頂備用冷卻塔起火，半小時后撲滅，但是建筑內(nèi)的蘇州超算中心數(shù)據(jù)機房安然無恙，數(shù)據(jù)沒受影響，說明氣體滅火還是極有必要的，要不然超算中心就無了。

當然，氣體滅火也有弊端，比如對空間有要求，大于3600平方就達不到消防效果，這些在國標里都有提及。此外氣體的儲備量也是有限制的。

這個機房原來是PCCW電訊盈科的，也是資深數(shù)據(jù)中心運營商，真的會這么離譜么？《電訊盈科PowerBase方案》里面也寫的非常清楚，數(shù)據(jù)中心對制冷機組、供電機組全年無休監(jiān)控?，F(xiàn)在看來，制冷機組的監(jiān)控明顯失靈，反而是機房先升溫告警，然后才找到了制冷機組的問題。

雖然這次故障的源起是機房。但硬件設備的能力和可靠性是有限的，這就是為什么有云計算的原因。我認為，我們需要提升數(shù)據(jù)中心設施的可靠性，但不應該只專注于此。云計算不應當如此嚴重的依賴于單個機房，阿里云更應該做的是提升云產(chǎn)品的穩(wěn)定性，加強整個AZ層面的災備演練。

IDC圈盤點了近幾年的前十大數(shù)據(jù)中心災難事故，《盤點：近年數(shù)據(jù)中心十大災難事件_機房_火災_服務器》，包括2020年韓國SK公司數(shù)據(jù)中心火災，影響了3.2萬個服務器；2021年3月，歐洲云計算巨頭OVH在法國的數(shù)據(jù)中心嚴重火災，一共4座數(shù)據(jù)中心，有一座被完全燒毀。導致法國360個政府、企業(yè)與公共事業(yè)網(wǎng)站直接癱瘓。

2021年，河南多機房因汛情斷電，還有位于河南的數(shù)據(jù)中心出現(xiàn)機房進水情況；2022年谷歌數(shù)據(jù)中心電氣爆炸，影響了40多個國家的1338臺服務器。這種事一篇稿子都寫不下。

所以，重要應用和數(shù)據(jù)，請務必做到狡兔三窟，一定要充分考慮云主機的單點故障，做好多可用區(qū)的高可用，做好數(shù)據(jù)的容災和備份；千萬不要全盤相信連鎖型的自動化操作。

在極端情況下，全自動化操作容易導致出現(xiàn)多米諾骨牌一樣的連鎖反應。比如這次阿里云香港機房的冷機就是群控啟動的，死活就啟動不起來。因為再完備、再安全、再可靠的自動化方案，哪怕平時運轉非常正常，趕上寸勁和巧合，總會出現(xiàn)無法預計的問題。

人體的設計也有這種Bug，當免疫系統(tǒng)在體內(nèi)殺新冠病毒殺瘋了的時候，他才不會管人體是否受得了，直接燒到42度，或者免疫風暴走起。反正新冠病毒總得死，但是人會不會死，免疫系統(tǒng)不在乎。

自動噴淋滅火系統(tǒng)也是，反正只要溫度過高我就要噴水，我的任務是保證火被撲滅了，但是物理服務器進水會不會損壞，自動噴淋滅火系統(tǒng)不在乎。特斯拉也是，他的自動控制系統(tǒng)只負責接管車輛駕駛，至于是不是剎車失敗，會不會造成人員傷亡，自動控制系統(tǒng)不在乎。

我的群暉NAS有100T的容量，其中有5T工作文檔數(shù)據(jù)，算是我十五年來攢下的命根子。兩個月之前，我在三天里連續(xù)壞了兩塊硬盤，真的是嚇出一身冷汗；我做了Raid5，如果只壞一塊盤，數(shù)據(jù)是可以恢復的；但是如果同時壞了兩塊盤，那我事務的數(shù)據(jù)就全game over了。

在這件事情之后，我直接搞了個同城災備和異地容災。同城災備是我買了一塊16T的硬盤，接在群暉NAS上，把我的重要數(shù)據(jù)每日備份；異地容災就是一年幾百塊買了阿里云盤，映射成WebDAV，也是每天備份我的重要數(shù)據(jù)，這樣才能保證數(shù)據(jù)可靠性。

對于應用服務來說，一定要考慮好安全性，比如反親和性，兩臺虛擬機不要放在同一臺物理機上；比如做好鏡像備份和容器的編排，在異地設置好備份，保證必要的時候可以快速在異地拉起容器；比如做好數(shù)據(jù)庫的異步同步，基本保證數(shù)據(jù)的一致性，在應用里不要直接寫死數(shù)據(jù)庫的IP地址，還是要用域名指向。

比如2019年3月，騰訊云上海南匯機房的光纜被施工挖斷，等于所有網(wǎng)絡都不通了，暖暖、QQ 飛車，王者榮耀，吃雞等 90 多個服務受到影響，這種問題就屬于意外，也沒法問責云廠商。

所以，如果老板問為什么要花這么多資金和人力來搞容災，那就可以告訴老板，不管是谷歌云、甲骨文、微軟云、阿里云、還是騰訊云，全都出過故障，只要是服務，就有不可用的時候，所以靠誰不如靠自己。像阿里云這次故障中，在架構層面設計了多可用區(qū)高可用方案的客戶，就完全沒有受到影響，當然，安全是需要額外成本的。

每個公司都是自己業(yè)務應用和數(shù)據(jù)的第一責任人，不應該也不能把希望全部寄托在云廠商身上。

比如2021年3月，云廠商OVH在法國的數(shù)據(jù)中心起火之后，游戲《Rust》表示，25臺歐洲服務器完全損毀，沒有備份，數(shù)據(jù)無法被修復。你說這個數(shù)據(jù)丟失的主責是云廠商OVH，還是游戲運營商呢？像阿里云香港機房本月的可用時間大約是98%左右，也會按照規(guī)則賠償25%的月費用，但是用戶的業(yè)務穩(wěn)定和數(shù)據(jù)安全，能全部依賴于供應商么？當然不能。

阿里云這一次的信息披露，算是這么多家云廠商中最坦誠、最詳盡的了，也是給各個企業(yè)一個充分的經(jīng)驗借鑒，讓大家在容災方案設計時，除了保證應用和數(shù)據(jù)的高可用，還要考慮中間件的高可用；除了考慮自身的架構設計，也要考慮租賃的數(shù)據(jù)中心的制冷和防火設計者有沒有腦血栓

畢竟人生中充滿了黑天鵝事件，我們除了積極應對風險，還能怎么辦呢？狡兔務必三窟就是唯一的答案。

參考資料

[1]

香港sim精神小伙: https://www.zhihu.com/people/15217944045

[2]

Vantage Data Centers 完成對 PCCW DC 的收購，將其一流的超大規(guī)模數(shù)據(jù)中心平臺帶到香港和吉隆坡 - Vantage Data Centers: https:///news/vantage-data-centers-finalizes-pccw-dc-acquisition-to-bring-its-best-in-class-hyperscale-data-center-platform-to-hong-kong-and-kuala-lumpur/