對所有的技術人員來說，業務可靠性提升是一個系統工程，涉及網路管理、IDC管理、伺服器管理、交付管理、變更管理、故障管理、監控管理、預案管理、根因分析、容量規劃、容災演練、標準化建設、整合測試、泛操作管理、許可權管理、資料安全管理等方方面面，隨著先進技術的應用、業務雲化、微服務化等，業務架構變得更加複雜，任何一個環節出現問題，哪怕是一個小問題都可能演變成大故障，我們更加迫切需要一種新的方式提升業務可靠性。

業界做法和阿里雲的探索

先跟大家聊聊業界是怎麼多的？諸如Netflix探索通過異常注入的方式提升其視訊服務的可靠性[1]，已經演進成獨立的“混沌自動化平臺”（ChAP，Chaos Automation Platform）；Microsoft Azure 在Netflix之後也研發了自己的異常注入平臺；Google通過研發自動化平臺來替代傳統模型中的人工操作，在業務可靠性提升的重要方向都有對應的平臺實現，參考《Site. Reliability. Engineering》；在阿里雲已經有了Monkey King 平臺，實現系統級別諸如宕機、磁碟掉盤、網絡卡丟包等異常注入。Netflix ChAP關注的是業務自身可靠性提升，不太適合專有云以及公共雲這種模式；Google很多平臺基於其強大的研發能力，在產品內部實現大量可靠性設計與程式碼嵌入，我們現在還比較難直接照搬；Monkey King已經能很好的實現異常注入的功能，但該注入哪些異常，該如何評估雲產品的可靠性還在探索中。結合綜上實踐和思考，我們在業界經驗的基礎上，結合雲特點正在探索通過混沌工程理念[2]提升系統可靠性。

混沌工程理念：指在系統可靠性設計範圍內實踐一些可在系統（對專有云是在模擬系統）內引發失效的實驗,在進行每個實驗之前工程師會提出一個導致系統失效的假設場景，進而設計一個實驗去引發或模擬該場景，並以受控、自動化的方式開展實驗。通過觀測系統的反饋，對不符合預期的結果進行深入分析並持續改進。在我們的實踐中重點關注系統可靠性提升的三個問題：

**1. 該如何降低故障頻度、重複故障比例、提升監控有效性與故障處理效率

1. 該如何量化評估雲產品的可靠性，是否存在隱患，優化建議是什麼
2. 該如何幫助雲使用者提升其業務可靠性**

通過混沌工程提升可靠性包括如下圖示幾大部分：

1、SSRD設計

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以及不斷積累的異常場景知識庫，我們便可以在模擬環境下驗證並給出量化的評估結果，而這些不但可以提早幫雲產品發現潛在的隱患而且可以給出優化的建議和方向。有一個很重要的場景就是業務上雲以後其所在的執行環境已經發生了鉅變，而使用者的業務需要提早適應新的環境以及應對新的挑戰，最有效的方式之一就是通過容災演練在業務無流量或模擬環境下模擬異常發生並觀測業務的應激能力，對發現的問題及早推動改進和優化，提前消除隱患。
現在還有一個難點就是針對不同的雲產品我們該建立哪些異常場景？這還需要繼續實踐。非常歡迎各位雲產品的負責人和技術同學一起參與進來共建，一同攜手提升產品的可靠性。

原文連結
本文為雲棲社群原創內容，未經允許不得轉載。