對所有的技術(shù)人員來說，業(yè)務(wù)可靠性提升是一個系統(tǒng)工程，涉及網(wǎng)絡(luò)管理、IDC管理、服務(wù)器管理、交付管理、變更管理、故障管理、監(jiān)控管理、預案管理、根因分析、容量規(guī)劃、容災演練、標準化建設(shè)、集成測試、泛操作管理、權(quán)限管理、數(shù)據(jù)安全管理等方方面面，隨著先進技術(shù)的應用、業(yè)務(wù)云化、微服務(wù)化等，業(yè)務(wù)架構(gòu)變得更加復雜，任何一個環(huán)節(jié)出現(xiàn)問題，哪怕是一個小問題都可能演變成大故障，我們更加迫切需要一種新的方式提升業(yè)務(wù)可靠性。

業(yè)界做法和阿里云的探索

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

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

**1. 該如何降低故障頻度、重復故障比例、提升監(jiān)控有效性與故障處理效率

1. 該如何量化評估云產(chǎn)品的可靠性，是否存在隱患，優(yōu)化建議是什么

2. 該如何幫助云用戶提升其業(yè)務(wù)可靠性**

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

1、SSRD設(shè)計
和對應產(chǎn)品的負責人一起確定用哪些指標來描述服務(wù)的穩(wěn)定狀態(tài)，常見的指標可以參考服務(wù)的SLA、SLO設(shè)計。這些指標主要用來描述系統(tǒng)的可靠性設(shè)計以及衡量的指標。在這個過程中，我們會和云產(chǎn)品的負責人一起通過歷史故障分析討論我們的云產(chǎn)品可靠性該如何設(shè)計，是否需要增加進而逐漸完善云產(chǎn)品的可靠性體系。

2、FMEA分析
針對云產(chǎn)品的特性、所運行的環(huán)境、強弱依賴分析、故障頻次、發(fā)生后影響、歷史故障等因素建立故障關(guān)聯(lián)模型，諸如系統(tǒng)是否可冗余單點異常、發(fā)生頻率是什么、如果發(fā)生對用戶影響有多大等等。

3、ACP(Apsara Chaos Platform)?
實現(xiàn)基礎(chǔ)異常注入、復雜任務(wù)編排以及異常任務(wù)自動調(diào)度功能
本文將重點介紹FMEA分析以及ACP平臺

FMEA分析和ACP平臺介紹

為了發(fā)現(xiàn)業(yè)務(wù)存在的隱患，我們首先需要想清楚需要構(gòu)建哪些異常，為此我們從公共云以及專有云海量故障入手，通過對這些故障的分析、聚類，我們抽取了第一版云平臺下的105種故障模式，通過這些基礎(chǔ)故障及其組合我們可以構(gòu)建超萬種異常場景。

另外20%左右故障基于現(xiàn)有技術(shù)無法有效的模擬，比如第三方依賴引入的問題、程序BUG以及特殊機型硬件等異常。

回顧這些基于上千種CASE抽取的故障模式，感慨萬深，每一次故障都是血的教訓，我們努力的避免并預防故障的發(fā)生。而如今恰恰也是這些寶貴的經(jīng)驗與知識再一次指引我們未來的方向。在一期我們還是大量依靠人工來分析和提煉這些異常模式，難免有遺漏和不準確，目前在進行中的二期我們正探索通過AI方式抽取更復雜的故障模式進而覆蓋更廣的異常場景，未來有了新成果也會和各位讀者共同探討

在ACP設(shè)計中，Scene用來描述異常場景，每個異常Pattern可以創(chuàng)建一個單一的異常場景。也可以由一個或幾個基礎(chǔ)異常組合而成，組合的方式見下文異常立方體模型。任務(wù)調(diào)度引擎實現(xiàn)對Scene的調(diào)度，每次異常注入對應一個JOB（任務(wù)），當前系統(tǒng)為了保證Scene不會被反復調(diào)度，全局控制保證一個Scene只能被調(diào)度一次。每個JOB提供若干操作原語（CREATE、DELETE、START、STOP、SUSPEND）提供人工干預接口。同步后臺會有Service Check模塊，主動關(guān)注SSRD中涉及的核心指標，如果發(fā)現(xiàn)異常會自動觸發(fā)JOB暫停。我們嘗試進行一場場景的仿真，比如 Gray failures異常，它是諸如服務(wù)器假死、網(wǎng)絡(luò)抖動、IO hang、某個硬件設(shè)備單核CPU被打滿、流量陡增等異常。這些看似小問題系統(tǒng)稍微處理不當便可能演變成大故障。

如下圖我們預期隨著業(yè)務(wù)量增漲資源消耗是線性增漲，但實際上可能是業(yè)務(wù)量增漲到某個節(jié)點，資源還沒有達到瓶頸的時候，性能確急劇下降而出現(xiàn)嚴重的雪崩點。如果我們不能及時發(fā)現(xiàn)這些隱患點，那么在生產(chǎn)系統(tǒng)高峰期發(fā)生的時候會是非常可怕的。

因此在ACP平臺上，我們在集成集團Monkey King平臺第一、二大類異常仿真的基礎(chǔ)上開發(fā)了Gray failures異常仿真引擎，支持諸如通過線性方式模擬CPU消耗自然增長、通過正弦方式模擬網(wǎng)絡(luò)抖動式丟包、通過高斯方式模擬流量陡增等異常仿真，如下圖所示：

為了能支持更復雜的組合類異常場景，我們調(diào)研了Airflow[3]以及Jenkins[4]等工作流引擎，都能滿足需求，但Jenkins偏重，每次流創(chuàng)建和生成都需要分鐘以上，難以滿足時效性要求。Airflow依賴第三方庫非常多，會偶爾出現(xiàn)流夯住的問題，雖然是開源的，但代碼量巨大，出現(xiàn)問題定位和修復成本非常高。為此我們實現(xiàn)了類似Airflow一樣的輕量級流編排引擎，可以滿足簡單任務(wù)的編排需求。但從長期來看，我們更傾向于切換到Airflow進而支持更高并發(fā)量、更復雜的流描述能力。

除此之外，為了能支撐超萬種異常場景自動調(diào)度，我們自研了分布式任務(wù)調(diào)度框架，消除單點隱患以及解決未來高吞吐場景的需求。當前在任務(wù)調(diào)度引擎中已經(jīng)引入優(yōu)先級的概念，支持三種任務(wù)級別，同級別中的任務(wù)無優(yōu)先級，采用FIFO的方式調(diào)度，支持并發(fā)度控制。

ACP 交互界面展示分享

為了更好管理異常組合，我們引入了數(shù)據(jù)立方體概念，每個小方塊代表一類基礎(chǔ)異常，對于數(shù)據(jù)立方體，我們可以通過切片、切塊、上卷（roll-up）、下鉆（drill-down）等方式生成更復雜的組合類異常。異常立方體中我們會對異常進行分級：

Low級別：系統(tǒng)對于這些異?？梢詢?yōu)雅自動恢復無需人工干預；
Medium級別：系統(tǒng)可以從這些異常中優(yōu)雅恢復，但可能會導致一些業(yè)務(wù)降級或者服務(wù)可靠性的影響；
High級別：這個級別的異常注入對服務(wù)可靠性存在較大的影響，需要較多的人工干預才能恢復。

樣例：對任意一個異常事件 Ae =F(X=1，Y=1，Z=1) 表示RDS的Low程度的Hardware Failure（Low級別諸如宕機故障）

ACP任務(wù)創(chuàng)建PORTAL

通過如下多種隨機模式可以覆蓋盡可能多的異常模擬

Mode：Single：指定異常注入對象；Random One：隨機選擇一個操作對象；Sequence：順序選擇所有操作對象
Device：Single：指定操作設(shè)備；Random One：隨機選擇一個操作設(shè)備；
Pattern：Linear：線性模擬；Sine：正弦模擬；Gaussian：高斯模擬
ACP異常模式四象限

用來描述這些異常PATTERN對用戶的潛在影響，目標不斷通過技術(shù)、管理、流程等手段將第一象限中高風險、高影響的隱患優(yōu)化到第三象限（更低的風險以及更小的影響）

云產(chǎn)品可靠性設(shè)計與隱患消除
專有云有它的特殊性，故障在專有云的環(huán)境下往往影響更大，一個單一的故障在幾百朵云內(nèi)可能就是幾百次故障.....更需要我們在產(chǎn)品設(shè)計過程中消除隱患，而這個過程可行方式之一就是啟動SSRD設(shè)計，在產(chǎn)品構(gòu)建之初啟動可靠性設(shè)計并通過FMEA分析以及ACP不斷挖掘潛在隱患并打磨故障處理的整個閉環(huán)，如下圖：

在整個實驗過程中，我們不斷觀測并采集系統(tǒng)的核心指標：
1、監(jiān)控是否能及時發(fā)現(xiàn)，是否有報警
2、出現(xiàn)的故障，全鏈路監(jiān)控是否能及時發(fā)現(xiàn)
3、對應的預案是否生效
4、系統(tǒng)的自愈能力是否符合設(shè)計預期
5、如果系統(tǒng)沒有達到預期，該如何優(yōu)化
對任何環(huán)節(jié)存在缺失或者不完善的隱患，持續(xù)推動優(yōu)化
云產(chǎn)品的可靠性量化評估一直比較棘手，傳統(tǒng)方式更多依靠經(jīng)驗來評估。有了ACP以及不斷積累的異常場景知識庫，我們便可以在仿真環(huán)境下驗證并給出量化的評估結(jié)果，而這些不但可以提早幫云產(chǎn)品發(fā)現(xiàn)潛在的隱患而且可以給出優(yōu)化的建議和方向。有一個很重要的場景就是業(yè)務(wù)上云以后其所在的運行環(huán)境已經(jīng)發(fā)生了巨變，而用戶的業(yè)務(wù)需要提早適應新的環(huán)境以及應對新的挑戰(zhàn)，最有效的方式之一就是通過容災演練在業(yè)務(wù)無流量或仿真環(huán)境下模擬異常發(fā)生并觀測業(yè)務(wù)的應激能力，對發(fā)現(xiàn)的問題及早推動改進和優(yōu)化，提前消除隱患。
現(xiàn)在還有一個難點就是針對不同的云產(chǎn)品我們該建立哪些異常場景？這還需要繼續(xù)實踐。非常歡迎各位云產(chǎn)品的負責人和技術(shù)同學一起參與進來共建，一同攜手提升產(chǎn)品的可靠性。

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