一、故障背景
12月18日阿裡雲香港Region發生重大故障，多個重要網際網路服務受到影響，包括澳門日報、金融管理局、澳門銀河、蓮花衛視、澳門水泥廠等基礎服務，澳覓和MFood等外賣平台，多個區塊鍊交易所也受到影響。詳情見官方故障報告《關于阿裡雲香港Region可用區C服務中斷事件的說明 (aliyun.com)》。我的新書《SRE原理與實踐：建構高可靠性網際網路應用》剛釋出，借此機會推薦給所有關注網際網路服務可靠性的人。本文我會深入分析故障情況和潛在問題，并對照書中内容來探讨問題根源及解決思路，詳細内容請閱讀原書。
圖1：新書封面
https://item.jd.com/13603499.html
網際網路服務中斷是個行業難題
本次故障給客戶造成直接經濟損失和品牌形象的影響。雲廠商按照SLA賠償對大部分客戶來說是微不足道的、與損失難以對等；對雲而言，支付SLA賠償是一個損失，更重要是影響了客戶對雲的信任，可能會促使一些客戶實施遷雲或者選擇多雲架構；影響了市民和客戶服務，特别是本地生活服務的那些使用者、交易平台需要進行投資的使用者。
網際網路服務中斷是個行業難題，國外故障監測網站Downdetector統計了2022年前十大報障最多的網際網路服務，如下圖2所示。故障報告最多是Spotify和WhatsApp，使用者主動報告近300萬例。故障并不鮮見，我書中開篇列舉了近4年行業典型故障，觸目驚心，有的故障導緻損失上億美元，有的導緻企業市值蒸發千億，有些嚴重影響使用者生活。
圖2：2022全球故障報告次數Top10（源自 Downdetector.com）
二、機房->雲産品->業務幾個層都暴露嚴重問題
把故障過程先簡單描述一下，由于制冷裝置故障引起的機房内伺服器不可用，機房故障影響了ECS、RDS、OSS、SLB、NAT等雲産品，同時由于容量不夠導緻管控系統和API調用不可用，造成了大量的客戶業務不能使用。可以看出這裡涉及三層服務，機房及伺服器、雲産品及管控系統、業務服務。這三層任何一個出現問題都可能導緻業務故障。如何分析可靠性問題并識别風險，詳見書中3.4《可靠性分析與架構風險》。
（一）直接原因：制冷系統的僞高可用
先看冷機修複的問題
其時間線如下：
12月18日08:56，阿裡雲監控到香港可用區C機房包廂通道溫控告警
12:30，冷機裝置供應商到場
14:47，排查遇到困難，其中一個包廂因高溫觸發了強制消防噴淋
15:20，經冷機裝置商工程師現場手工調整配置，冷機群控解鎖完成并獨立運作
18:55，4台冷機恢複到正常制冷量
21:36，大部分機房包廂伺服器陸續啟動并完成檢查
22:50，被噴淋的包廂逐漸供電和伺服器啟動。
存在幾個明顯問題：
1、處理過程問題1：響應和到場時間太晚，香港不大，三個半小時才到。
2、處理過程問題2：沒有預案要靠現場排查現場改邏輯，三個小時才查到并解鎖群控邏輯。
3、處理過程問題3：處理過程忽視了溫度持續升高及噴淋系統的自動化邏輯，觸發了噴淋程式，造成部分硬體損壞，導緻一個包廂故障時長被延長。
4、架構設計問題1：制冷裝置容災沒有經過演練，以為有了4+4容災，實際上主備裝置共用了水路循環系統。導緻容災切換失敗。在書中也舉了網絡專線的共用單一節點導緻故障的例子。
5、架構設計問題2：冷機群控邏輯導緻隻能批量啟動冷機，而沒法單台獨立啟動。架構設計脫離實際或是考慮不周。架構設計中容易出現這樣的問題，過度設計而脫離實際或主次不分。
6、可能的問題：處理冷機故障過程沒有做好協同管理，涉及衆多客戶、阿裡雲本部人員（基礎設施及各個雲産品人員）、現場代維人員、冷機公司人員，導緻故障被拉長。比如到其他AZ申請資源的高峰是比較晚的時候了，早做遷移其實問題更小。
冷機故障并非個例，做好處理預案才是王道。今年7月，由谷歌和甲骨文營運的倫敦東部資料中心在該地區有記錄以來最強烈的熱浪中遭受了崩潰。該國部分地區氣溫甚至高于40攝氏度。
阿裡雲在基礎設施層面的管理失責問題
機房制冷故障不完全是阿裡雲責任，但他們也出現了幾個問題：
1、選擇機房時沒有發現制冷裝置存在風險，也沒有要求驗證和巡檢發現
2、處理人員在修複過程風險評估不準，機房多方溝通協同過程可能存在不夠順暢的問題
3、現場工程師對噴淋系統的工作機制不太清楚或忙中疏忽
書中也有詳細探讨如何應對災難型故障。見書中5.2 災難型故障快速修複，部分内容如下圖3所示。
圖3：災難型故障快速修複
（二）部分雲産品及管控系統有明顯缺陷
本次故障影響時間較長跟阿裡雲産品及管控系統也有關系。
雲産品架構和配套系統問題。
- 有雲産品依賴故障AZ（Available Zone可用區）的服務
自定義鏡像資料服務依賴了故障AZ的OSS服務，部分RDS執行個體依賴了部署在故障AZ的代理服務。很明顯這部分産品架構設計存在問題，不僅要考慮産品自身的高可用，還有考慮依賴的配套服務是否高可用。
- 有多個雲産品是單AZ的。
VPN、Privatelink、部分GA執行個體、SLB、NAT服務。沒有很快實作跨AZ容災逃逸。
管控系統是個容易被忽視的問題。
在書中第6章有詳細讨論。部分單AZ産品的容災切換或遷移工具不夠完備，管控工具在災難發生時是救命稻草，管控系統不可用或不好用，會造成主備切換不成功的問題。
1.管控系統架構設計有問題
ECS管控服務、RDS管控服務、Dataworks、k8s使用者控制台、操作API都出現了故障，且完全修複時間最晚。API的是核心服務，是管控系統和客戶調用的核心服務，不應該這麼容易挂，而且我認為應該有更高的優先級。
2.管控系統依賴配套的部署架構有問題
本故障中新擴容的ECS管控系統啟動時依賴的中間件服務部署在故障AZ，導緻較長時間内無法擴容，這點容易被忽視。
3.管控系統容量設計不足的問題
沒有考慮到單AZ挂了後，客戶湧入到其他AZ造成管控請求打爆。客戶發起的管控請求再多，估計也不會特别大，管控系統的容量到底達到了多少而被打爆的，阿裡雲沒有詳述。這裡有另外一個可能是其他AZ的資源不足或開資源要等待，造成請求的擁塞。
管控系統是故障後的救命稻草，應該有更高的可靠性。在書中6.2.2脆弱性因素分析一節有詳細讨論，部分内容見下圖4。
圖4：管控平台脆弱性分析
在第7章工程師工作内容小節，有專門讨論工程師要負責管控系統的可靠性。
（三）業務方要負主體責任：明确可靠性核心保障對象是業務
首先要明确，可靠性保障的真正對象是業務，業務不能把可靠性責任都托付給公有雲。首先要在業務層負起可靠性的主體責任。機房故障無法絕對避免，機房網絡、電力、制冷總有機率出問題，或遭遇火災、雷劈、地震、洪水、老鼠等天災人禍。如何才能AZ故障發生後而不影響業務呢？
1、首先，應制定RTO(Recovery Time Objective，修複時間目标)。明确業務容災需求，設計對應的可靠性架構方案，這涉及一定的資源成本投入。為消除單點災難型故障，可以有多種架構：單機群多副本架構、容災備份架構、同城雙活架構、兩地三中心架構、異地多活架構、多雲/混合雲/融合雲架構。
2、即使不做備援部署，也應建立符合RPO（Recovery Point Objective，恢複點目标）的備份，并異地存儲。如在本次故障中如果知道會挂20幾個小時，通過異地重新部署系統也可能是更好方案。
其實不僅有單AZ故障，容易出現災難風險的點很多，如果不提前關注并解決，出問題是大機率的，書中有詳細梳理并提出如何實作業務層的高可用。
三、故障處理與指揮協同的混亂
災難型故障是一場遭遇戰，指揮協同得當可最短時間結束戰鬥，取得勝利。我不是内部人士，以下部分内容憑經驗猜測和業界回報，認為可能存在以下問題：
1、内部溝通協作過程的問題。
可能存在對風險評估不足，沒有在比較早的時候把風險級别提到最高，處理過程可能也存在誤判，延誤了故障處理。有些雲産品服務響應較快，出現故障苗頭（知道制冷故障但伺服器還沒大面積故障時）就開始處理了，有些雲産品就比較遲緩，沒有意識到風險正在到來。
2、對外資訊通報問題、沒有及時引導的問題。
這點被業界吐槽比較多，沒有告知完整資訊，而僅告知是盈科機房制冷裝置故障，有推卸責任的嫌疑，且Status Page（服務可用性頁面）更新不及時，受影響雲産品不清晰，這讓很多客戶蒙圈。其實客戶希望看到的是故障起因和具體影響範圍、嚴重程度、可能恢複時長、建議方案、官方修複進展時間線等。
3、跟客戶的協同混亂、幫助客戶恢複業務無序低效。
從業界回報來看，很多客戶沒有被告知準确的故障影響而是被雲産品故障短信轟炸。沒有很好組織使用者有序遷移。很多客戶到當天很晚還在抱怨沒有恢複，其中是否都是用了單AZ産品的業務。
把雲伺服器和雲産品啟動了就算恢複了是不夠的。有點遺憾，阿裡雲在12.25（故障一周後）發出的詳細報告沒有從客戶角度分析恢複的過程。從微網誌回報看，有不少客戶恢複得比雲的修複更晚很多。
在書中第5章介紹了如何進行一個大型故障的應急協同，也讨論了各種類型故障修複的方案，以及預案平台的建設等，值得網際網路業務服務的工程師團隊參考。
四、總結與複盤
深入複盤、有效整改、重建信任是重點工作。故障帶來的損失無疑是巨大的，不僅是直接經濟價值，也可能損失了客戶對雲的信任、客戶企業可能可能損失了使用者對他們的信任。按照SLA進行賠償并不是客戶最想要的，更需要深入複盤和有效整改，才能逐漸重建信任。從受影響雲客戶角度也應該進行深入複盤，業務不能把可靠性責任都托付給公有雲。使用單AZ備援的産品是劃算的嗎？成本與風險的平衡點把握是否準确？最後要問，誰要對這次故障承擔責任？誰要整改？怎麼改？如何做好複盤可以閱讀本書的第7章，複盤過程、複盤問題、根因分析、有效整改等方面都有深入讨論，提出了複盤“五條歸零”的科學要求。
發生如此嚴重故障，阿裡雲的SLA肯定不好看，阿裡雲部分員工的年終估計也會 受到影響，更重要的是衆多客戶對阿裡雲甚至公有雲的信任也可能大打折扣，依賴阿裡雲的企業将承受很大壓力，他們同樣也受到市民與客戶的質疑。他們的2022年總結和2023年開局都不會很輕松。