阿里雲馬勁：保證雲產品持續擁有穩定性的實踐和思考

對全部的技術人員來講，業務可靠性提高是一個系統工程，涉及網絡管理、IDC管理、服務器管理、交付管理、變動管理、故障管理、監控管理、預案管理、根因分析、容量規劃、容災演練、標準化建設、集成測試、泛操做管理、權限管理、數據安全管理等方方面面，隨着先進技術的應用、業務雲化、微服務化等，業務架構變得更加複雜，任何一個環節出現問題，哪怕是一個小問題均可能演變成大故障，咱們更加迫切須要一種新的方式提高業務可靠性。

業界作法和阿里雲的探索

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

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

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

該如何量化評估雲產品的可靠性，是否存在隱患，優化建議是什麼
該如何幫助雲用戶提高其業務可靠性**
經過混沌工程提高可靠性包括以下圖示幾大部分：

一、SSRD設計
和對應產品的負責人一塊兒肯定用哪些指標來描述服務的穩定狀態，常見的指標能夠參考服務的SLA、SLO設計。這些指標主要用來描述系統的可靠性設計以及衡量的指標。在這個過程當中，咱們會和雲產品的負責人一塊兒經過歷史故障分析討論咱們的雲產品可靠性該如何設計，是否須要增長進而逐漸完善雲產品的可靠性體系。

二、FMEA分析
針對雲產品的特性、所運行的環境、強弱依賴分析、故障頻次、發生後影響、歷史故障等因素創建故障關聯模型，諸如系統是否可冗餘單點異常、發生頻率是什麼、若是發生對用戶影響有多大等等。

三、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平臺第1、二大類異常仿真的基礎上開發了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不斷挖掘潛在隱患並打磨故障處理的整個閉環，以下圖：

在整個實驗過程當中，咱們不斷觀測並採集系統的核心指標：
一、監控是否能及時發現，是否有報警
二、出現的故障，全鏈路監控是否能及時發現
三、對應的預案是否生效
四、系統的自愈能力是否符合設計預期
五、若是系統沒有達到預期，該如何優化
對任何環節存在缺失或者不完善的隱患，持續推進優化
雲產品的可靠性量化評估一直比較棘手，傳統方式更多依靠經驗來評估。有了ACP以及不斷積累的異常場景知識庫，咱們即可以在仿真環境下驗證並給出量化的評估結果，而這些不但能夠提前幫雲產品發現潛在的隱患並且能夠給出優化的建議和方向。有一個很重要的場景就是業務上雲之後其所在的運行環境已經發生了鉅變，而用戶的業務須要提前適應新的環境以及應對新的挑戰，最有效的方式之一就是經過容災演練在業務無流量或仿真環境下模擬異常發生並觀測業務的應激能力，對發現的問題及早推進改進和優化，提早消除隱患。
如今還有一個難點就是針對不一樣的雲產品咱們該創建哪些異常場景？這還須要繼續實踐。很是歡迎各位雲產品的負責人和技術同窗一塊兒參與進來共建，一同攜手提高產品的可靠性。

附錄：
[1]. https://blog.codecentric.de/e...
[2]. 混沌（Chaos theory）一詞原指宇宙未造成以前的混沌狀態，混沌現象原由於物體不斷以某種規則複製前一階段的運動狀態而產生沒法預測的隨機效果，易發生於變更的系統中，該系統在行動之初極爲單純，但通過必定時間連續變更以後卻產生始料未及的後果，也就是混沌狀態。
[3]. Airflow:http://airflow.incubator.apac...
[4]. Jenkins: https://jenkins.io/