對所有的技術人員來說，業務可靠性提公升是乙個系統工程，涉及網路管理、idc管理、伺服器管理、交付管理、變更管理、故障管理、監控管理、預案管理、根因分析、容量規劃、容災演練、標準化建設、整合測試、泛操作管理、許可權管理、資料安全管理等方方面面，隨著先進技術的應用、業務雲化、微服務化等，業務架構變得更加複雜，任何乙個環節出現問題，哪怕是乙個小問題都可能演變成大故障，我們更加迫切需要一種新的方式提公升業務可靠性。
業界做法和阿里雲的探索
混沌工程理念：指在系統可靠性設計範圍內實踐一些可在系統（對專有雲是在**系統）內引發失效的實驗,在進行每個實驗之前工程師會提出乙個導致系統失效的假設場景，進而設計乙個實驗去引發或模擬該場景，並以受控、自動化的方式開展實驗。通過觀測系統的反饋，對不符合預期的結果進行深入分析並持續改進。在我們的實踐中重點關注系統可靠性提公升的三個問題：
**1. 該如何降低故障頻度、重複故障比例、提公升監控有效性與故障處理效率
該如何量化評估雲產品的可靠性，是否存在隱患，優化建議是什麼
該如何幫助雲使用者提公升其業務可靠性**
通過混沌工程提公升可靠性包括如下圖示幾大部分：
1、ssrd設計
和對應產品的負責人一起確定用哪些指標來描述服務的穩定狀態，常見的指標可以參考服務的sla、slo設計。這些指標主要用來描述系統的可靠性設計以及衡量的指標。在這個過程中，我們會和雲產品的負責人一起通過歷史故障分析討論我們的雲產品可靠性該如何設計，是否需要增加進而逐漸完善雲產品的可靠性體系。
2、fmea分析
針對雲產品的特性、所執行的環境、強弱依賴分析、故障頻次、發生後影響、歷史故障等因素建立故障關聯模型，諸如系統是否可冗餘單點異常、發生頻率是什麼、如果發生對使用者影響有多大等等。
3、acp(apsara chaos platform)
實現基礎異常注入、複雜任務編排以及異常任務自動排程功能
本文將重點介紹fmea分析以及acp平台
fmea分析和acp平台介紹
為了發現業務存在的隱患，我們首先需要想清楚需要構建哪些異常，為此我們從公共雲以及專有雲海量故障入手，通過對這些故障的分析、聚類，我們抽取了第一版雲平台下的105種故障模式，通過這些基礎故障及其組合我們可以構建超萬種異常場景。
另外20%左右故障基於現有技術無法有效的模擬，比如第三方依賴引入的問題、程式bug以及特殊機型硬體等異常。
回顧這些基於上千種case抽取的故障模式，感慨萬深，每一次故障都是血的教訓，我們努力的避免並預防故障的發生。而如今恰恰也是這些寶貴的經驗與知識再一次指引我們未來的方向。在一期我們還是大量依靠人工來分析和提煉這些異常模式，難免有遺漏和不準確，目前在進行中的二期我們正探索通過ai方式抽取更複雜的故障模式進而覆蓋更廣的異常場景，未來有了新成果也會和各位讀者共同**
在acp設計中，scene用來描述異常場景，每個異常pattern可以建立乙個單一的異常場景。也可以由乙個或幾個基礎異常組合而成，組合的方式見下文異常立方體模型。任務排程引擎實現對scene的排程，每次異常注入對應乙個job（任務），當前系統為了保證scene不會被反覆排程，全域性控制保證乙個scene只能被排程一次。每個job提供若干操作原語（create、delete、start、stop、suspend）提供人工干預介面。同步後台會有service check模組，主動關注ssrd中涉及的核心指標，如果發現異常會自動觸發job暫停。我們嘗試進行一場場景的**，比如 gray failures異常，它是諸如伺服器假死、網路抖動、io hang、某個硬體裝置單核cpu被打滿、流量陡增等異常。這些看似小問題系統稍微處理不當便可能演變成大故障。
如下圖我們預期隨著業務量增漲資源消耗是線性增漲，但實際上可能是業務量增漲到某個節點，資源還沒有達到瓶頸的時候，效能確急劇下降而出現嚴重的雪崩點。如果我們不能及時發現這些隱患點，那麼在生產系統高峰期發生的時候會是非常可怕的。
因此在acp平台上，我們在整合集團monkey king平台第
一、二大類異常**的基礎上開發了gray failures異常**引擎，支援諸如通過線性方式模擬cpu消耗自然增長、通過正弦方式模擬網路抖動式丟包、通過高斯方式模擬流量陡增等異常**，如下圖所示：
為了能支援更複雜的組合類異常場景，我們調研了airflow[3]以及jenkins[4]等工作流引擎，都能滿足需求，但jenkins偏重，每次流建立和生成都需要分鐘以上，難以滿足時效性要求。airflow依賴第三方庫非常多，會偶爾出現流夯住的問題，雖然是開源的，但**量巨大，出現問題定位和修復成本非常高。為此我們實現了類似airflow一樣的輕量級流編排引擎，可以滿足簡單任務的編排需求。但從長期來看，我們更傾向於切換到airflow進而支援更高併發量、更複雜的流描述能力。
除此之外，為了能支撐超萬種異常場景自動排程，我們自研了分布式任務排程框架，消除單點隱患以及解決未來高吞吐場景的需求。當前在任務排程引擎中已經引入優先順序的概念，支援三種任務級別，同級別中的任務無優先順序，採用fifo的方式排程，支援併發度控制。
acp 互動介面展示分享
為了更好管理異常組合，我們引入了資料立方體概念，每個小方塊代表一類基礎異常，對於資料立方體，我們可以通過切片、切塊、上捲（roll-up）、下鑽（drill-down）等方式生成更複雜的組合類異常。異常立方體中我們會對異常進行分級：
low級別：系統對於這些異常可以優雅自動恢復無需人工干預；
medium級別：系統可以從這些異常中優雅恢復，但可能會導致一些業務降級或者服務可靠性的影響；
high級別：這個級別的異常注入對服務可靠性存在較大的影響，需要較多的人工干預才能恢復。
樣例：對任意乙個異常事件 ae =f(x=1，y=1，z=1) 表示rds的low程度的hardware failure（low級別諸如宕機故障）
acp任務建立portal
通過如下多種隨機模式可以覆蓋盡可能多的異常模擬
mode：single：指定異常注入物件；random one：隨機選擇乙個操作物件；sequence：順序選擇所有操作物件
device：single：指定操作裝置；random one：隨機選擇乙個操作裝置；
pattern：linear：線性模擬；sine：正弦模擬；gaussian：高斯模擬
acp異常模式四象限
用來描述這些異常pattern對使用者的潛在影響，目標不斷通過技術、管理、流程等手段將第一象限中高風險、高影響的隱患優化到第三象限（更低的風險以及更小的影響）
雲產品可靠性設計與隱患消除
專有雲有它的特殊性，故障在專有雲的環境下往往影響更大，乙個單一的故障在幾百朵雲內可能就是幾百次故障.....更需要我們在產品設計過程中消除隱患，而這個過程可行方式之一就是啟動ssrd設計，在產品構建之初啟動可靠性設計並通過fmea分析以及acp不斷挖掘潛在隱患並打磨故障處理的整個閉環，如下圖：
在整個實驗過程中，我們不斷觀測並採集系統的核心指標：
1、監控是否能及時發現，是否有報警
2、出現的故障，全鏈路監控是否能及時發現
3、對應的預案是否生效
4、系統的自癒能力是否符合設計預期
5、如果系統沒有達到預期，該如何優化
對任何環節存在缺失或者不完善的隱患，持續推動優化
雲產品的可靠性量化評估一直比較棘手，傳統方式更多依靠經驗來評估。有了acp以及不斷積累的異常場景知識庫，我們便可以在**環境下驗證並給出量化的評估結果，而這些不但可以提早幫雲產品發現潛在的隱患而且可以給出優化的建議和方向。有乙個很重要的場景就是業務上雲以後其所在的執行環境已經發生了巨變，而使用者的業務需要提早適應新的環境以及應對新的挑戰，最有效的方式之一就是通過容災演練在業務無流量或**環境下模擬異常發生並觀測業務的應激能力，對發現的問題及早推動改進和優化，提前消除隱患。
現在還有乙個難點就是針對不同的雲產品我們該建立哪些異常場景？這還需要繼續實踐。非常歡迎各位雲產品的負責人和技術同學一起參與進來共建，一同攜手提公升產品的可靠性。
閱讀原文
阿里雲產品分析（6） 馬雲談阿里雲戰略
馬雲談阿里雲戰略 馬雲是阿里系的精神領袖，不了解馬雲在說什麼，以及不了解馬雲怎麼想，是無法明白阿里雲是怎樣的公司的。2011年 年會馬雲講話 我想感恩這個時代給了我們這些人機會，網際網路 中國的開放 電子商務以及商務環境的不完善，讓我們有可能創造b2c c2c b2b打成統一平台的機會。美國已經不可...
阿里雲CDN產品介紹
本方介紹阿里雲cdn產品介紹 什麼是阿里雲cdn，功能優勢，使用場景，節點分布等。阿里雲內容分發網路 alibaba cloud content delivery network，簡稱cdn 將您源站資源快取至阿里雲遍布全球的加速節點上。當終端使用者請求訪問和獲取這些資源時，無需回源，系統將就近呼叫...
阿里雲產品公測 雲引擎ACE初體驗
第一步，在阿里雲管理控制台頁面申請公測許可權！耐心等待許可權通過，進入雲引擎管理控制台jgn2ql 進入應用列表 點選右上交的按鈕xj jdch 這是我建立的例項 hx p4 l 建立實體 i h9v 然後是建立版本，上傳 包an lk 上傳成功後，就可以到 應用中心，部署應用了。需要等幾分鐘。我上...