對所有的技術人員來說，業務可靠性提升是一個系統工程，涉及網絡管理、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設計
和對應產品的負責人一起確定用哪些指標來描述服務的穩定狀態，常見的指標可以參考服務的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以及不斷積累的異常場景知識庫，我們便可以在仿真環境下驗證并給出量化的評估結果，而這些不但可以提早幫云產品發現潛在的隱患而且可以給出優化的建議和方向。有一個很重要的場景就是業務上云以后其所在的運行環境已經發生了巨變，而用戶的業務需要提早適應新的環境以及應對新的挑戰，最有效的方式之一就是通過容災演練在業務無流量或仿真環境下模擬異常發生并觀測業務的應激能力，對發現的問題及早推動改進和優化，提前消除隱患。
現在還有一個難點就是針對不同的云產品我們該建立哪些異常場景？這還需要繼續實踐。非常歡迎各位云產品的負責人和技術同學一起參與進來共建，一同攜手提升產品的可靠性。

附錄：
[1].?https://blog.codecentric.de/en/2018/07/chaos-engineering/
[2]. 混沌（Chaos theory）一詞原指宇宙未形成之前的混沌狀態，混沌現象起因于物體不斷以某種規則復制前一階段的運動狀態而產生無法預測的隨機效果，易發生于變動的系統中，該系統在行動之初極為單純，但經過一定時間連續變動之后卻產生始料未及的后果，也就是混沌狀態。
[3]. Airflow:http://airflow.incubator.apache.org/
[4]. Jenkins:?https://jenkins.io/