突遭斷網斷電！阿里雙11最驚險一幕曝光...
2020 年 11 月 11 日晚，又一年天貓雙 11 狂歡接近尾聲。新交易紀錄、新流量峰值，一切都是十全十美的樣子。
圖片來自 Pexels
此時，阿里巴巴 CTO 程立(魯肅)才將一段實錄視頻公之于眾：
11 月 5 日凌晨，阿里技術上下完成雙 11 大考期間最后一次全鏈路壓測后休息和交接間隙……服務器連續遭遇了兩次攻擊。
第一次，凌晨兩點左右，監控大屏顯示四個地區數據中心數值迅速下跌，技術保障團隊啟動緊急響應處理，確定遭遇了斷網攻擊。
緊接著第二次，2:10，更兇猛直接的攻擊來了。華東區域某個數據中心，直接被拉閘斷了電……
但最令人震驚的是，這一切居然是阿里巴巴合伙人、雙 11 新零售技術負責人吳澤明(花名范禹)干的。
突然襲擊，實彈攻擊
這不是事先明確的一次突襲。
甚至只有范禹和霜波——阿里雙 11 技術大隊長、技術安全生產負責人陳琴“小范圍”知道。
但是即便如此，陳琴看到這次斷網攻擊時還是嚇了一跳，因為與之前商定的攻擊量級并不符合。
當時，明面上壓測已經結束，參與的阿里技術工程師們，有的在進行夜宵補給，有的在工位上小憩休息，對于這次意料之外的實彈攻擊，沒有一點點防備。
慶幸的是，技術保障上下訓練有序。迅速鎖定故障源頭，啟動應急方案，緊急展開修復……
僅 1 分 28 秒，一切如故。
甚至如果恰好有在那時下單的用戶，都難以察覺有過“抖動”。
對于阿里技術上下，雖然事出突然毫無防備，但對于這樣的突襲應對，已然肌肉記憶一樣……因為在阿里，這種突襲早已普遍而日常，還有專門因此形成的紅藍軍對抗。
藍軍負責設計突襲彈藥，常在不經意間發起突襲。紅軍則需要在極短時間內修復故障。
對外，這種技術突襲和紅藍對抗一直不為人知。
對內，無數次突襲和演練之后，連故障恢復機制都形成了“1-5-10”的方法論，即在 1 分鐘內發出警報、5 分鐘內定位故障、10 分鐘內修復故障。
這也是阿里敢將可用性目標提升到達 99.9999% 的底氣所在。之所以能如此精確，就是因為一次次突襲演練之后得出的結果。
阿里內部，還將這種紅藍軍的偷襲與防守，類比為對系統打疫苗。
故意在可控半徑內將故障注入系統以測試系統的響應，類似于將少量有害物質注入體內激發免疫反應以防止未來疾病。
這似乎很瘋狂，但能讓公司提前為包括宕機在內的各種故障做好準備，將其影響降至最低。
甚至還有更瘋狂的舉動。阿里為這種突襲專門設計了 App，簡化成一個“按鈕”，串聯了阿里巴巴經濟體的各種技術架構和業務手段。
方便隨時隨地，按下按鈕完成突襲。
它可能發生在任何時候，比如，某一次會議結束后所有人都處于放松狀態時。
這次雙 11 前的突襲攻擊，就出現在范禹閑庭信步走出“光明頂”時——雙 11 核心作戰室內沒人察覺異常。
有內部工程師把這種偷襲演練與馬斯克 SpaceX 那次知名的“事故逃逸”演習類比。
核心都是以真實可能發生的事故，來實際檢驗自身的技術和應急保障機制。
你聽過混沌工程嗎?
Chaos Engineering，混沌工程。
被稱為“故意破壞的藝術”，主要通過主動制造故障，測試系統在各種壓力下的行為，從而識別并修復故障問題，以此提高生產環境中系統的容錯性和可恢復性，最終實現系統彈性的提升。
在硅谷科技公司中，混沌工程已經有過實踐。
2010 年，Netflix 團隊開發出了 Chaos Monkey——混沌猴子這個工具用于測試系統。
模擬一只討厭的猴子，在系統中隨機位置上蹦下竄，不停搗亂，直到搞掛你的系統。
隨后的幾年里，Netflix 還將混沌猴子在 GitHub 上開源分享，并指出這種隨機故障測試，對測試分布式系統的穩定性有傳統方式難以超越的優勢。
在這樣一整套原理基礎上，混沌工程師這樣的崗位開始在硅谷出現，角色和功能如這次阿里對外公開的藍軍，把這種隨機破壞性攻擊，變成一種日常測試手段來提升自身的抗災能力。
混沌工程是一種專門的理論，本質上是一種反脆弱的思想。
如果再往上追溯，哲學源頭可以找到尼采——殺不死我的必使我更強大。
而對于阿里來說，混沌工程思想理念，與技術穩定體系需求不謀而合，與阿里異地多活、容災容錯的發展需求契合在一起。
實際上從 2010 年左右，阿里電商域開始嘗試故障注入測試的工作，開始的目標是想解決微服務架構帶來的強弱依賴問題。
后來經過多個階段的改進，最終演進到 MonkeyKing 線上故障演練平臺。
作為阿里集團使用廣泛的混沌工程平臺，MonkeyKing 不但幫助很多業務團隊進行故障演練，提升了業務穩定性，同時也支撐阿里集團內部定期的聯合演練活動。
2019 年開始，還開始在小范圍生產環境內推進突襲演練，并對外開源了阿里巴巴混沌工程工具 ChaosBlade。
而這次雙 11 前夜的突然襲擊、斷網斷電，本質也是混沌工程的一次實踐。
即便雙 11 這樣的節點里，顯得異常驚險，但對于阿里來說，擁抱「混沌工程」，搞出「紅藍演練」，也是業務倒逼的結果。
被逼出來的阿里
阿里歷史上很多業務改革，都與雙 11 密切相關。
比如「異地多活」，起初就是因為雙 11 很火，流量帶來擴容需求。
阿里集團 CTO 程立就回憶說，2009 年第一次雙 11，因為是淘寶商城臨時決定搞的活動，技術側還不太有感覺。
但 2010 年，雙 11 流量一下子漲了好幾倍，服務器根本不夠用……當時在支付寶的程立，親身經歷了把支付寶系統一再瘦身，只留下核心的支付鏈路，才總算扛過了那次交易洪峰。
而其后對于每年迎來新紀錄流量洪峰挑戰的雙 11，阿里開始在平時倒逼改革。
另外，也有一些意想不到的天災人禍，帶來容災警醒。
2013 年夏天，因為杭州 40° 高溫酷暑，全城電力供應極度緊張，而阿里的服務器機房又是耗電大戶，拉閘限電的威脅迫在眉睫，一旦機房停電，業務就關門大吉了……
上述等等經歷，讓阿里技術意識到，不能再等到下一個高溫酷暑的夏天，不能再等到下一次天災教訓，再來思考如何保障業務穩定性。
也不能忽視地域中的物理災害，影響到線上數以億計的用戶。更不能因為基礎設施的限制，阻礙快速增長的業務。
所以先是解決同城多活的挑戰，其后又進一步解決異地多活的世界難題。
都是面對問題和挑戰，倒逼出來的創新。
實際上，這種倒逼出創新的案例，在阿里發展歷史上比比皆是，例如支付寶研發 OceanBase，阿里云研發飛天云操作系統……
當年為了支撐雙 11 的流量，支付寶一個不到 100 人的團隊，研發出可代替甲骨文數據庫的 OceanBase 數據庫。
今年，在去年雙 11 核心系統 100% 上云后，程立透露——阿里把全副身家性命放到云上，飛天云操作系統、神龍服務器集群、中臺等數字新基建還在不斷升級，技術的溝溝坎坎幾近解決，應對峰值不再是最大技術挑戰。
消費者的熱情越來越高，倒逼阿里技術持續進化。而混沌工程和突襲計劃，也是這種倒逼著進化的一部分。
互聯網本身就充滿了未知和不確定性，例如高溫、洪水、臺風、暴雨、地震、雷電等自然災害以及人為操作失誤等種種黑天鵝事件，都可能對業務造成嚴重打擊。
阿里敢在雙 11 期間對業務系統發起各種高危故障，這種自信源自成熟的突襲機制，而底氣則來自阿里云十年來搭建的災備體系。
Gartner 就曾預測過，2020 年，90% 的容災操作會發生在云端。尤其是大型云服務商，數據中心都遍布全球，是企業天然的異地災備中心。
而阿里云的云災備能力無疑處于云廠商第一陣營。
阿里云曾率先在業內提出數據中心的“四個不”原則，即不在同一火山地震帶，不在同一水系，不在同一電網，不在同一運營商網絡出口。這是傳統企業所不具備的硬實力。
另一方面，阿里云的災備能力全面涵蓋了網絡、數據庫、存儲等領域，這是能應對各種故障的軟實力。
舉個栗子，在存儲領域，阿里云憑借存儲高可用等能力，持續三年入選 Gartner 全球云存儲魔力象限，并且被列為全球領導者地位。
所以只有兼具軟硬實力，才能最大程度地保障業務和數據穩定安全。這也是阿里敢把全副身家性命都放在云上的原因之一。
甚至這種「最大程度保障」，還需要考慮到被斷網斷電的極端場景……
所以，拉閘斷電的攻擊成功了嗎?
11 月 5 日凌晨 02:10，阿里華東區域某一數據中心被內部拉閘斷電。
瞬間，蓄電系統啟動……服務器供能無縫切換，未受一絲影響。
4 秒鐘后，柴油發電機群啟動。電力完全恢復供應，數據中心運轉如常。
阿里云災備體系，至此交了滿分答卷。
混沌工程 ChaosBlade 項目地址：
- https://github.com/chaosblade-io/chaosblade
作者：雷剛
編輯：陶家龍
出處：轉載自公眾號量子位(ID：QbitAI)
