超全總結 | 阿里電商故障治理和故障演練實踐

寫在前面

近日，在 QCon北京2017大會上，來自阿里巴巴中間件團隊的技術專家周洋（花名中亭）發表了題爲《阿里電商故障治理和故障演練實踐》專題演講。在會後官方組織的評選中，本次演講的內容獲得了一致好評，中亭獲選爲本次大會的明星講師。這次演講總體上分享了從 2011 年至今，阿里巴巴電商平臺遇到的諸多有表明性的故障，以及在此過程當中積累的很是多的高可用保障經驗和解決方案。

本次分享包括兩個部分：第一部分會從分佈式系統經典依賴故障出發，剖析故障成因，介紹治理方案和技術演進；第二部分從宏觀視角探討構建一套」防故障」設施的重要性，並探討如何設計一套故障演練系統，介紹故障演練的基本原則和最佳經驗。

演講全文

你們好，今天來的人很多，可見對於故障耿耿於懷的人，不止我本身。今天分享的內容主要仍是圍繞故障治理有關。衆所周知，故障治理自己就是一個比較大的話題，幾乎涉及到運維、研發、故障運行管理的所有崗位，奇葩一點的故障還可能涉及到運營和產品經理。聊到故障的苦與淚，相信45分鐘絕對連開頭都沒講完。今天的分享，主要仍是迴歸故障發生的本質，故障緣由角度切入。看是否有一些方法論和通用性的手段能夠沉澱出來。但願能夠對你們有所幫助。

今天演講的主要包括兩個部分：第一部分會從分佈式系統經典依賴故障出發，剖析故障成因，介紹治理方案和技術演進；第二部分從宏觀視角探討構建一套」防故障」設施的重要性，並探討如何設計一套故障演練系統，介紹故障演練的基本原則和最佳經驗。考慮演講時間和內容關聯度，以前報給大會提綱中的」經過灰度發佈提早發現故障」的章節被隱去，有興趣的同窗能夠會後交流。

首先介紹一下我本身，姓名周洋，花名中亭。2011年加入阿里，接觸穩定性領域，開始作一些穩定性產品的研發，同時也會承擔一些架構演進的推動工做，好比HTTPS改造，電商交易鏈路升配等。2015年開始搞雙11大促，作爲共享事業部的大促負責人，保障了雙11的穩定。也得到雙11老A也就是雙11特種兵的稱號。

共享事業部，對於你們可能比較陌生。若是我換一個說法，商品、交易、會員、優惠、評價、中間件，你們應該就都知道了，雙11當天最具挑戰的鏈條之一。右邊是中間件核心做戰室成員，在過了雙11業務高峯後的一張合影。2016年至今，工做的重點在常態穩定性的肯定性方面，今天分享主要也是圍繞這部份內容。

分佈式系統常見依賴故障治理及技術演進

拋一個問題，什麼狀況下，你會認爲淘寶網掛了？ 這個問題，相信關注的人不少，不過能給出確切答案的人並很少。由於這個看似簡單的問題，真要回答起來好像也不是那麼容易。今天的分享，試着先回答一下這個問題。

從一張「簡單」的頁面提及。這張頁面叫作商品詳情頁，相信在坐的各位對這張頁面不會陌生，由於對於大部分的人，這張頁面是他們在淘寶完成一筆訂單的第一步。而商品詳情的使命就是把商品的信息沒有保留的展現給你們，勾起你們的興趣，引導你們完成購買或是收藏。從信息展現的角度來說，商品詳情頁面確實是一張很是簡單的頁面。

咱們再來看一下商品詳情應用的後臺架構。商品詳情是阿里最先實現靜態化應用之一。那些與瀏覽者無關信息，好比商品標題、圖片信息、銷售屬性組合等信息均直接進入緩存，其餘和用戶相關的，如優惠、庫存、物流、服務等動態信息則經過異步調用方式填充至靜態化後的頁面框架內。爲了在一張頁面展現足夠多可供決策信息，撩起用戶的購買慾望。詳情後臺必須去依賴很是多的服務應用，聚合足夠多的信息。少則幾十，多則成百。從這個角度來說，商品詳情頁面又是阿里依賴最複雜的應用之一。

互聯網業務的一個主要特色是，業務迭代很是快，天天有新需求，每週都有新發布，每一年都有大重構，每一次變化都有可能致使情況的發生。越是貼近用戶的系統，受下游服務影響越大。那麼咱們不只好奇，對於詳情這個阿里最複雜的應用，下游發生一些情況時，系統會變成怎樣？
咱們經過兩個實驗來觀察一下。

實驗一：假設後端的優惠、庫存、物流發生故障，咱們來觀察一下商品詳情頁的表現。

乍一看，好像沒什麼問題。只是以爲頁面清爽了一些。或許在這個信息過暴的時代，看着這麼清新脫俗的頁面，還有一點點暗爽。

在現場作了兩個調查，觀察你們對實驗一的反映。調查1：認爲詳情頁故障了的同窗請舉手。結果是現場沒有人舉手（也多是現場氛圍還比較冷）；調查2：你們來找茬，先後兩個詳情頁有多少處不一樣？結果：最後有一個妹子說出了正確的答案（你們的熱情被調動起來了，由於答對的同窗有《盡在雙11》的書贈送）

沒有對比就沒有傷害，一共有6處不一樣。從功能角度，這鐵定是一個故障頁面。不過從用戶體驗和業務角度講，少了這些信息也不影響商品購買，不影響核心用戶體驗。好像又是沒故障？有點糾結，對吧？ 您先糾結一下子，咱們來進行第二個實驗。

實驗二：當商品詳情的」商品」出了問題，商品詳情會怎樣？

詳情仍是那個詳情，只不過是商品詳情變成了錯誤詳情。
第一張頁面：很抱歉，你查看的商品找不到了。有多是你訪問的方式不對，好比URL上面少了一些參數，也多是後臺真的出問題，對於用戶還算是比較溫柔的一種方式。
第二張頁面：極可能就是網站真的出問題了。比較可能的緣由是後臺沒有合理的處理超時致使前端異常。不過說實話，這個頁面我也很是少的見到。若是真的出現了，那基本就是一次很是嚴重的事故。

經過經過上面的兩個實驗，相信你們應該對於咱們今天要介紹的一個概念」強弱依賴」有一些模糊的感受了。 從感性的角度來說，就是當下遊依賴服務出現問題時，當前系統會受到一些影響，讓用戶有感受的是強依賴，沒感受的是弱依賴。不過這種定義不夠嚴謹，由於總不能說沒有用戶訪問時，就不算故障吧。因此也須要從理性角度定義一下：首先應該發生情況，其次應該是核心業務，最後是否帶來損失。不影響核心業務流程，不影響系統可用性的依賴均可以叫作弱依賴，反之就是強依賴。

終於解釋解釋清楚強弱依賴，那麼作好強弱依賴到底有什麼意義？拋開依賴模型來看強弱，意義不大。嚴謹的依賴模型應該包括關係、流量、強弱三個組成部分。依賴關係定義依賴的方向，我依賴誰，誰依賴我。流量定義着每一個應用、服務、方法調用的次數，強弱則定義着依賴的鬆緊程度。依賴治理就是經過科學的手段持續穩定的拿到關係、流量、強弱的數據。強弱依賴主要能夠被應用到下面的場景：

• 系統改造驗收：對於分佈式系統，至少應該作到運行態中不會由於我依賴的系統，後臺出現故障引發當前應用出現系統級可用性的故障，好比進程掛掉，頻繁GullGC，負載飆高等，合適何地都具有快速止血的能力。
• 限流降級參考：對於弱依賴，通常都要配置限流或是自動降級策略，比起經過拍腦殼或是經驗值來設定，到不如經過實際的故障測試來進行微調，好比對於下游出現超時狀況，就能夠經過實驗得出基於線程池限流到底要填寫多少數值。
• 應用啓動順序：理想狀況下，應用啓動更應該作到0強依賴啓動。不過有一些狀況，沒法作到。所以應用啓動的依賴順序也須要實時關注。特別是新IDC、機房建站時，那個蜘蛛網同樣的依賴關係，最好是經過系統方式得到。
• 故障根源定位：後臺系統的故障，每每經過上一級的業務故障表現出來。故障處理講究的是爭分多秒，良好的強弱依賴，對於系統自動化診斷有很是大的助力做用。
• 依賴容量評估：正常調用鏈路下系統容量須要評估，當某個弱依賴掛掉時，總體的容量是否有變化。

說完背景，終於能夠聊一下強弱依賴的技術實現。強弱依賴的技術演進，總體上分了3個階段。每一個階段的方案的誕生都有其獨特的時代背景和業務難點，如今回頭看來，也能夠看到當時技術的侷限性和突破。

熟悉淘寶技術發展史的同窗都知道，2008年阿里剛剛經過一個代號爲五彩石的項目，完成從巨石系統向服務化系統的改造。業務和開發開發模式上有了較大的發展，不過網狀的依賴關係也帶來了很是多的問題。這個紀元的主要特色是：故障頻發，技術路和方法都是以結果爲導向，糙一點、結果精度差一點能夠忍受。

模擬依賴故障技術上有三招，改代碼+發佈，遠程Debug+重啓，登錄機器去執行一些shell命令操做。 好處是，靈活隨意，能夠必定程度達到效果。壞處是成本高，影響環境穩定，你測試的時候，其餘人屬於沒法工做狀態，影響效率。此外，這個階段，由於分佈式鏈路追蹤技術還沒起步，因此常常會漏掉一下服務服務。故障的粒度也比較粗，對於一些linux的命令，都是主機級別的。

阿里內部有一套平常環境，主要作上線前的集成測試。爲了儘可能減小對環境的影響。咱們經過修改服務版本的方式，造成一個獨立的測試環境。記得11年下半年，我開始作初版的時候，我搭了淘寶12個核心應用，踩坑無數，純體力活，也算前無古人，後無來者了。

經過這套環境跑了幾回結果，發給核心的業務TL，你們很興奮，貌似找到一條治理的路子。
不過很快暴露問題，好比環境的運維歸屬問題，開發機器的干擾問題，以及對於業務的瞭解程度和測試粒度問題。因此在很長一段時間測試的範圍都侷限在交易核心鏈路。

第二個階段的核心就是提效，從第一個階段的痛點入手，解決人的成本和環境的問題。這個階段以後，基本能夠擺脫手工的方式，效率上有大幅度提高。

這個階段引入了一些測試技術，其中用的比較多的是Selenium，經過這種技術能夠提早錄製用戶行爲並轉化爲測試腳本的技術，而且每個步驟均可以截圖記錄，方便問題複查。

在這個時期，中間件的技術有必定發展，分佈式追蹤技術出現，能夠把用戶訪問的鏈條串聯起來，排查問題的效率有了必定提高。同時全部的中間件，如nginx,消息，分佈式服務調用，分佈式數據庫，軟負載，配置中心等都作了改造，支持用戶流量的標記，追蹤，路由控制。基於這項技術，環境的問題有很是大的突破。

在內部，咱們稱爲叫二套環境。它的核心原理是在基礎環境之上，動態區分出一些小環境，他們分別是某個業務的子集。項目之間彼此獨立，不會互相調用，只有當依賴的服務不在時，纔會去訪問基礎環境的服務。數據庫和緩存是公用的。

在這個階段，咱們沒必要再去修改代碼的服務版本，每次發佈後，代碼的版本等可以自動化的保持一致，運維成本有下降，野服務干擾的狀況也有所緩解，人的介入很是的少。不過仍是有一些問題待解決，首先二套環境的路由策略是和用戶綁定的，也就是說須要提早去作一些配置。其次，域名上也有一些限制，加了second等前綴，測試路徑中URL等複用率低的問題沒有徹底解決。第三，測試的粒度仍然很粗，獨佔機器，規模化推廣時機器成本，用例運行的成本仍是很高。第四，功能性缺失。不被二套環境的基礎設施故障無法模擬，好比數據庫故障，緩存故障等。

2014年的時候，咱們的思惟方式有了比較大的突破。咱們再也不糾結於環境和外部手段的改進，而是迴歸到強弱依賴關注最核心的部分。那就是業務影響和系統設計。可否實現一種只與代碼設計和業務相關，而與外部環境無關的方案呢？

這期間有兩個關鍵思路或是推論：

推論1：咱們要的是下游依賴出現故障現象，沒必要真的是下游服務提供方出現故障。只要消費方感受下游出現故障便可。從這個思路來說，商品詳情端若是要作強弱依賴測試，只要本身玩就夠了，不須要去折騰下游依賴的幾十個應用。

推論2：咱們之因此須要單獨搭建環境，爲的就是控制故障的影響範圍。那麼咱們能夠換一下思路，就是咱們隻影響要發生故障的請求，其餘的業務流量都放過。是否是就達到目的了。本質上是一種對業務流量的篩查能力。

有了上面的思路，第一問題就是如何攔截用戶的請求？攔截用戶請求，讓用戶改形成本最低，沒有什麼地方比中間件更適合了。每一個通用的遠程調用接口，都是能夠作文章的點，而且中間上層的業務系統不用作任何改造。

下一個問題就是故障規則和業務識別，咱們曾考慮在用戶請求的入口就打上標記，置入故障規則，不過發現對於post請求，異步js請求，定時任務等都有比較大的改形成本，有安全隱患。 因此就增長了一個服務端，直接下發故障規則到依賴插件上。故障插件經過對流量的調用攔截+業務識別惟一肯定影響哪個請求，而後經過故障規則判斷是注入異常仍是超時。從而達到模擬故障的效果。 由於插件可擴展的設計，因此咱們默認是能夠同時注入多種故障場景的。同時插件也會把影響到請求的詳細信息異步上報給服務端作分析。

理論上經過上述的方案，在業務流量輸入方面，咱們沒有任何要求。不管是人的自發測試行爲，仍是機器的測試行爲，都沒有任何限制。只不過爲最大限度複用已有的測試用例積累，提升自動化程度，咱們設計了一套用例註解，封裝了和強弱依賴服務端的通訊。利用Junit生命週期的特色完成故障規則的下發和清除。任何一個測試用例，20秒以內改形成一個強弱依賴的測試用例。在結果輸出方面，會詳細的展現一次強弱依賴檢測的過程，以及測試用例涉及到的鏈路的依賴變化。到此階段，強弱依賴真正達到了一個相對里程碑的版本，2014年開始，強弱依賴也做爲雙11必作的一個橫向項目。

下面是強弱依賴註解和依賴系統的示例：



小結部分，從新回顧了強弱依賴的定義、意義。整個強弱依賴技術演進歷史，就是對數據準確性，穩定性，成本、效率的追求和平衡。

故障演練的基本原則和最佳系統設計實踐

衆所周知，2017年不大太平，業界出現了不少大故障。

2017-03-01 弗吉尼亞州數據中心出現故障，亞馬遜S3 服務出現了較高的錯誤率，直接影響到成千上萬個在線服務
2017-1-31 GibLab同窗線上數據庫變動時，遇到突發了一個狀況。由於操做失誤，致使整個生產數據庫被誤刪除，丟失6個小時的數據。
2017年 2月份國內的一家常常被測試網絡連通性的友商也出現了故障，引發工信部的關注，並緊急約談了相關公司。同時，下發緊急通知，要求BAT等各重點互聯網企業吸收教訓。業界一片譁然。

這時候，有一家公司顯得特別淡定，那就是Netflix。 Netflix是一家服務全球的在線影片租賃提供商，他的核心業務徹底架設在AWS上面。據新聞揭露，Netflix在亞馬遜故障時能夠很快的恢復正常（前文的新聞稿是針對早些時候AWS的故障，非2017S3故障），由於他們內部有一個」防故障」的基礎設施。聽起來，好像是咱們須要的東西。

深刻調查以後，發現防故障基礎設施背後是一個猴子軍團。

早在2012年，Netflix就發佈了Chaos Monkey。用來在隨機殺死實例，據官方數據指出，到目前累計殺死65,000個節點。他們的測試策略也比較有趣：在工做時間在生產和測試環境運行，目標測試系統的健壯性，訓練後備人員，讓恢復更簡潔、快速、自動；Latency Monkey的做用就是讓某臺機器的請求或返回變慢，觀察系統的表現； Chaos Gorilla，大猩猩。他的能力是搞掛一個機房，宏觀驗證業務容災和恢復的能力。

Netflix發佈猴子軍團的緣由是由於，他們很早就吃過雲故障的虧，因此本能是認爲雲設施是不可靠的，必須在經過演練來驗證軟件層面的容災。

古代有個哲學家說過」沒有人曾經兩次踏進同一條河流」，由於不管是這條河仍是這我的都已不一樣。故障也是相似的，故障發生的時間地點，影響流量，與故障打交道的人都無法徹底相同。從這個角度看，故障治理自己是一個僞命題，都是在解決過去某一個時刻的問題。不過從程序員視角（我習慣叫上帝視角），任何故障的緣由都是可被定位的，避免相同緣由重複引起故障，是每一個程序員應該執着追求的目標。電商曆史上遇到了很是多有表明性的故障，爲了避免讓故障重複發生，阿里內部也打造了一套」防故障」的基礎設施。

2015年5月27日，由於光纖電纜的問題，支付寶大規模宕機事故，公司內部得出一個結論：任何基礎設施、生產系統、任何流程均可能出現問題，沒有通過重大災難驗證的容災設施都是耍流氓。 啓動了代號爲虎虎虎的生產突襲項目，用來驗證異地多活的質量。
2012年，完成交易的同城雙活後，就啓動了同城容災演練，也叫斷網演練。驗證核心系統的同城一個機房掛掉的狀況下，是否還能夠正常工做。
2011年，開始作強弱依賴的治理和建設，但願提早發現由於依賴問題致使的系統故障，系統的代號是EOS（出處是古希臘神話中的黎明女神，語意是可以把紛亂的依賴關係梳理清楚）

能夠看到，這三大件和Netflix的猴子軍團從功能上基本上是對標的。那是否是就應該沒有故障，安枕無憂了呢？ 答案鐵定是否是。

阿里巴巴由於其多元化的業務場景和日益複雜的技術架構，會遇到各式各樣的故障，故障治理的難度相比流媒體服務故障治理，難度是也增量了幾個臺階。前面介紹過的強弱依賴和容災演練只能覆蓋到部分故障。若是對故障總體作初步畫像，故障總體能夠分爲IaaS層、PaaS層、SaaS層的故障，每一層均可能有不少故障出發緣由和表現。那麼對於這麼多種類繁雜的故障，心裏必定是懵逼的。咱們要如何重現進而避免這麼多繁雜的故障呢？

熟悉三體的同窗應該據說過」降維攻擊」這個詞，不妨讓咱們把維度下降一下，換一個視角看故障：

• 任何故障，必定是硬件如IaaS層，軟件如PaaS或SaaS的故障。 而且有個規律，硬件故障的現象，必定能夠在軟件故障現象上有所體現。
• 故障必定隸屬於單機或是分佈式系統之一，分佈式故障包含單機故障
• 對於單機或同機型的故障，以系統爲視角，故障多是當前進程內的故障，好比：如FullGC，CPU飆高； 進程外的故障，好比其餘進程忽然搶佔了內存，致使當前系統異常等。
• 同時，還可能有一類故障，多是人爲失誤，或流程適當致使，這部分咱們今天不作重點討論。

任何故障均可以套入到這個故障模型中。有了這個模型，咱們就能夠開始來設計模擬故障的演練系統了。

因此在內部，咱們起了一個代號叫作」大聖歸來」的項目，項目名叫作」故障演練」，承載的產品叫作MonkeyKing。MonkeyKing是中國美猴王的意思，看重的是孫悟空高強的本領（火眼精金、七十二變）和極具反叛的精神來，但願用一種創新的思路來保證穩定性。

咱們的系統實現，也是圍繞前文討論的故障模型來設計的：

• 在客戶機器部署OS層的故障插件，用來模擬硬件層的故障和單機進程外的故障。
• 對於應用進程內的故障，提供插拔式的故障插件，也能夠用戶按照咱們的故障API作本身的實現。
• 對於分佈式故障，則經過服務端按照IP來控制故障的範圍。
• 對於一些由於各類緣由沒法觸及的應用，好比數據庫。咱們提供了一個故障三方實現的標準，供故障服務接入。

經過上面的方式，基本上就把技術型故障的模型就cover全了。

在去年的雙11中，故障演練的應用場景主要應用在圖中的幾個場景。 按照業務流量、壓測流量的峯值能夠劃爲4個象限。具體案例以下（這部分現場由於時間關係，沒有展開說，爲新增部分）：

• 預案有效性：過去的預案測試的時候，線上沒有問題，因此就算測試結果符合預期，也有多是有意外可是現象被掩藏了。
• 監控報警：報警的有無、提示消息是否準確、報警實效是5分鐘仍是半小時、收報警的人是否轉崗、手機是否欠費等，都是能夠check的點。
• 故障復現：故障的後續Action是否真的有效，完成質量如何，只有真實重現和驗證，才能完成閉環。發生過的故障也應該時常拉出來練練，看是否有劣化趨勢。
• 架構容災測試：主備切換、負載均衡，流量調度等爲了容災而存在的手段的時效和效果，容災手段自己健壯性如何。
• 參數調優：限流的策略調優、報警的閾值、超時值設置等。
• 故障模型訓練：有針對性的製造一些故障，給作故障定位的系統製造數據。
• 故障突襲、聯合演練：經過藍軍、紅軍的方式鍛鍊隊伍，以戰養兵，提高DevOps能力。

故障演練宣言：把故障以場景化的方式沉澱，以可控成本在線上模擬故障，讓系統和工程師平時有更多實戰機會，加速系統、工具、流程、人員的進步。

關於將來

故障演練的後續工做主要會關注在如下方向：演練常態化、故障標類化、演練智能化。用常態化的演練驅動穩定性進步，而不是大促前進行補習；豐富更多的故障場景，定義好最小故障場景和處理手段；基於架構和業務分析的智能化演練，沉澱行業故障演練解決方案。

企業級互聯網架構Aliware，讓您的業務能力雲化：https://www.aliyun.com/aliware