阿裡巴巴在混沌工程領域的實踐和思考

APM

文章摘自知乎專欄 知乎-應用高可用 https://zhuanlan.zhihu.com/p/52505917 導讀：

混沌工程（Chaos Engineering）：是在分布式系統上進行實驗的學科, 目的是建立對系統抵禦生産環境中失控條件的能力以及信心。最早由Netflix及相關團隊提出。

故障演練（MonkeyKing）：是阿裡巴巴在混沌工程領域的産品，目标是沉澱通用的故障模式，以可控成本線上上重放，以持續性的演練和回歸方式營運來暴露問題，不斷推動系統、工具、流程、人員能力的不斷前進。

通過本文，您将了解到：

• 為什麼需要混沌工程
• 阿裡巴巴在該領域的實踐和思考
• 未來的計劃
• 時間線和參考資料

關鍵詞：混沌工程、故障演練、最小化爆炸半徑

一、為什麼需要混沌工程（翻譯自Chaos Engineering電子書）

1.1 混沌工程與測試的差別

混沌工程、故障注入和故障測試在關注點和工具中都有很大的重疊。

混沌工程和其他方法之間的主要差別在于，混沌工程是一種生成新資訊的實踐，而故障注入是測試一種情況的一種特定方法。當您想要探索複雜系統可能出現的不良行為時，注入通信延遲和錯誤等失敗是一種很好的方法。但是我們也想探索諸如流量激增，激烈競争，拜占庭式失敗，以及消息的計劃外或不常見的組合。如果一個面向消費者的網站突然因為流量激增而導緻更多收入，我們很難稱之為錯誤或失敗，但我們仍然對探索系統的影響非常感興趣。同樣，故障測試以某種預想的方式破壞系統，但沒有探索更多可能發生的奇怪場景，那麼不可預測的事情就可能發生。

測試和實驗之間可以有一個重要的差別。在測試中，進行斷言：給定特定條件，系統将發出特定輸出。測試通常是二進制态的，并确定屬性是真還是假。嚴格地說，這不會産生關于系統的新知識，它隻是将效價配置設定給它的已知屬性。實驗産生新知識，并經常提出新的探索途徑。我們認為混沌工程是一種實驗形式，可以産生關于系統的新知識。它不僅僅是一種測試已知屬性的方法，可以通過內建測試更輕松地進行驗證。

混沌實驗的輸入示例：

• 模拟整個區域或資料中心的故障。
• 部分删除各種執行個體上的Kafka主題。
• 重新建立生産中發生的問題。
• 針對特定百分比的交易服務之間注入一段預期的通路延遲。
• 基于函數的混亂（運作時注入）：随機導緻抛出異常的函數。
• 代碼插入：向目标程式添加指令和允許在某些指令之前進行故障注入。
• 時間旅行：強制系統時鐘彼此不同步。
• 在模拟I/O錯誤的驅動程式代碼中執行例程。
• 在 Elasticsearch 叢集上最大化CPU核心。

混沌工程實驗的機會是無限的，可能會根據您的分布式系統的架構和您組織的核心業務價值而有所不同。

1.2 實施混沌工程的先決條件

要确定您的組織是否已準備好開始采用Chaos Engineering，您需要回答一個問題：您的系統是否能夠适應現實世界中的事件，例如服務故障和網絡延遲峰值？

如果您知道答案是“否”，那麼在應用本書中的原則之前，您還有一些工作要做。Chaos Engineering非常适合揭露生産系統中未知的弱點，但如果您确定混沌工程實驗會導緻系統出現嚴重問題，那麼運作該實驗就沒有任何意義。先解決這個弱點。然後回到Chaos Engineering，它将發現你不了解的其他弱點，或者它會讓你更有信心你的系統實際上是有彈性的。混沌工程的另一個基本要素是可用于确定系統目前狀态的監控系統。如果不了解系統的行為，您将無法從實驗中得出結論。

1.3 混沌工程原則

為了具體地解決分布式系統在規模上的不确定性，可以把混沌工程看作是為了揭示系統弱點而進行的實驗。破壞穩态的難度越大，我們對系統行為的信心就越強。如果發現了一個弱點，那麼我們就有了一個改進目标。避免在系統規模化之後問題被放大。以下原則描述了應用混沌工程的理想方式，這些原則來實施實驗過程。對這些原則的比對程度能夠增強我們在大規模分布式系統的信心。

image

二、阿裡巴巴在混沌工程領域的實踐 - 故障演練

**混沌工程 **屬于一門新興的技術學科，行業認知和實踐積累比較少，大多數IT團隊對它的了解還沒有上升到一個領域概念。阿裡電商域在2010年左右開始嘗試故障注入測試的工作，開始的目标是想解決微服務架構帶來的強弱依賴問題。後來經過多個階段的改進，最終演進到 MonkeyKing（線上故障演練平台）。從發展軌迹來看，阿裡的技術演進和Netflix的技術演進基本是同時間線的，每個階段方案的誕生都有其獨特的時代背景和業務難點，也可以看到當時技術的局限性和突破。

為了讓更多的朋友了解這門新興學科，接下來我們會在 “知乎 - 應用高可用” 推出系列文章，結合混沌工程原則來分析我們解決的問題和其演進過程，便于做穩定性的朋友做技術選型。

2.1 建立一個圍繞穩定狀态行為的假說

目前阿裡巴巴集團範圍内的實踐偏向于故障測試，即在一個具體場景下實施故障注入實驗并驗證預期是否得到滿足。這種測試的風險相對可控，壞處是并沒有通過故障注入實驗探索更多的場景，暴露更多的潛在問題，測試結果比較依賴實施人的經驗。目前故障測試的預期比較兩級分化，要麼過于關注系統的内部細節，要麼對于系統的表現完全沒有預期，與混沌工程定義的穩态狀态行為差異比較大。

引起差異的根本原因還是組織形态的不同。2014年，Netflix團隊建立了一種新的角色，叫作混沌工程師（Chaos Enigneer），并開始向工程社群推廣。而阿裡目前并沒有一個專門的職位來實施混沌工程，項目目标、業務場景、人員結構、實施方式的不同導緻了對于穩定狀态行為的定義不太标準。

2.2 多樣化真實世界的事件

阿裡巴巴因為多元化的業務場景、規模化的服務節點及高度複雜的系統架構，每天都會遇到各式各樣的故障。這些故障資訊就是最真實的混沌工程變量。為了能夠更體感、有效率的描述故障，我們優先分析了P1和P2的故障（P是阿裡對故障等級的描述），提出一些通用的故障場景并按照IaaS層、PaaS層、SaaS層的角度繪制了故障畫像。

從故障的完備性角度來看，上述畫像隻能粗略代表部分已出現的問題，對于未來可能會出現的新問題也需要一種手段保持相容。在更深入的進行分析之後，我們定義了另一次元的故障畫像：

• 任何故障，一定是硬體如IaaS層，軟體如PaaS或SaaS的故障。 并且有個規律，硬體故障的現象，一定可以在軟體故障現象上有所展現。
• 故障一定隸屬于單機或是分布式系統之一，分布式故障包含單機故障。
• 對于單機或同機型的故障，以系統為視角，故障可能是目前程序内的故障，比如：如FullGC，CPU飙高；程序外的故障，比如其他程序突然搶占了記憶體，導緻目前系統異常等。
• 同時，還可能有一類故障，是人為失誤，或流程失當導緻，這部分我們今天不做重點讨論。

從故障注入實作角度，我們也是參照上述的畫像來設計的。之前我們是通過Java位元組碼技術和作業系統層面的工具來分别模拟程序内和程序外的故障。随着Serverless、Docker等新架構、新技術的出現，故障實作機制和承接載體也将會有一些新的變化。

2.3 在生産環境中運作實驗

從功能性的故障測試角度來看，非生産環境去實施故障注入是可以滿足預期的，是以最早的強弱依賴測試就是在日常環境中完成的。不過，因為系統行為會根據環境和流量模式有所不同，為了保證系統執行方式的真實性與目前部署系統的相關性，推薦的實施方式還是在生産環境（仿真環境、沙箱環境都不是最好的選擇）。

很多同學恐懼在生産環境執行實驗，原因還是擔心故障影響不可控。實施實驗隻是手段，通過實驗對系統建立信心是我們的目标。關于如何減少實驗帶來的影響，這點在"最小化爆炸半徑"部分會有闡述。

2.4 持續自動化運作實驗

2014年，線下環境的強弱依賴測試用例是預設在每次釋出後自動執行的。2015年，開始嘗試線上上進行自動化回歸。不過發展到最近兩年，手動實驗的比例逐漸變高。原因也不複雜，雖然故障注入自動化了，業務驗證的成本仍然比較高。在業務高速發展、人員變化較快的環境之下，保持一套相對完善的線上回歸用例集對是見非常難的事情。雖然也出現了流量錄制技術，不過因為混沌工程實驗本身會打破系統已有的行為，基于入口和出口的流量比對的參考度就下降許多。

為了解決測試成本問題，2017年初開始推進線上微灰階環境的建設。基于業務、比例來篩選特征流量，通過真實的流量來替換原來的測試流量，通過監控&報警資料來替代測試用例結果。目前已經有部分業務基于微灰階+故障演練的模式來做演練驗證（比如：盒馬APOS容災演習）。

因為故障演練之前是作為一個技術元件被嵌入到常态和大促的流程中，是以在系統建構自動化的編排和分析方面的産品度并不高。演練可視化編排和能力開放會是我們團隊未來的一個重點，下文中的規劃部分會有所闡述。

2.5 最小化爆炸半徑

在生産中進行試驗可能會造成不必要的客戶投訴，但混沌工程師的責任和義務是確定這些後續影響最小化且被考慮到。對于實驗方案和目标進行充分的讨論是減少使用者影響的最重要的手段。但是從實際的實施角度看，最好還是通過一些技術手段去最小化影響。Chaos Monkey和FIT的核心差別在于：是否可以進一步減小故障的影響，比如微服務級别、請求級别甚至是使用者級别。在EOS的3.0~4.0階段（詳細請見最後時間線部分），已經可以實作請求級别的微服務故障注入。雖然那個時候演練實施的主要位置在測試環境，但初衷也是為了減少因為注入故障而導緻的環境不穩定問題。除了故障注入，流量路由和資料隔離技術也是減少業務影響的有效手段。

三、未來的計劃

線上故障演練發展到今天是第三年，随着阿裡安全生産的大環境、業務方的訴求、研發疊代模式的變化，以及大家對混沌工程的接受和認識程度的提高。集團的演練領域會向着未來的幾個目标發力：

• 建立高可用專家庫，結構化提高應用容錯能力（解決"穩定狀态定義"的問題）
• 建設故障注入實作标準，集團内開源，提升故障模拟的廣度和深度（拓寬"多樣化真實世界的事件"的廣度）
• 規模化覆寫核心業務（提升"在生産環境中運作實驗"的規模）
• 以産品化、平台化思路開放演練能力（探索"自動化運作實驗"的方式）

四、其他

4.1 混沌工程的行業發展時間線

• 2010年，Netflix Eng Tools團隊開發出了Chaos Monkey。當時Netflix從實體基礎設施遷移到AWS上，為了保證AWS執行個體的故障不會給Netflix的使用者體驗造成影響，他們開發了這個工具，用來測試系統。
• 2011年，Simian Army誕生，在Chaos Monkey的基礎上增加了故障注入模式，可以測試更多的故障場景。Netflix 認為，雲的特點是備援和容錯，但沒有哪個元件能夠保證100%的可用性，是以他們必須設計出一種雲架構，在這種架構裡，個體元件的故障不會影響到整個系統。
• 2012年，Netflix在 GitHub上開源了Chaos Monkey，并聲稱他們“已經找到了應對主要非預期故障的解決方案。通過經常性地制造故障，我們的服務是以變得更有彈性。”
• 2014年，Netflix團隊建立了一種新的角色，叫作混沌工程師。Bruce Wong 發明了這個角色，并由 Dan Woods 在 Twitter上向廣大的工程社群推廣。

• 2014年，Chaos Monkey的更新版本FIT誕生，實作微服務級别的故障注入。

  2016年，混沌工程(Chaos Engineering)的概念通過《Principles Of Chaos》這本書被提出。面向失敗設計也逐漸成為建構一個高可用架構産品的基本要求，混沌工程也在更多公司進行實踐。

• 2017年，Chaos Monkey的3.0版本ChAP（Chaos Automation Platform）誕生，可以配合環境、監控實作部分場景的自動化演練。

  概念：強弱依賴系統（EOS），主要為通過程式自動化的幫助應用依賴梳理、系統降級提供基礎資料，減少人肉成本，定位是線下環境的測試工具。

• 2017年，Chaos Engineering被收錄到ThoughtWorks Technology Radar。
• 2018年，混沌工程（Chaos Engineering）成為CNCF的一個新的技術領域。

4.2 阿裡巴巴實踐的發展時間線

• 2012年，Eos 1.0(強弱依賴系統統)開發完成，線上下環境進行應用依賴的檢測。
• 2013年2月，Eos 2.0，嘗試在二套環境下面進行檢測，通過SCM腳本自動化安裝應用，減少人工安裝應用成本。
• 2013年5月，完成二套環境下面的改造，應用檢測的自動化完成。
• 2013年7月，開始和持續內建團隊合作，複用測試用例，做接口級别的依賴檢測。
• 2014年7月，進入Eos 3.0，基于RPC進行故障模拟，不依賴具體的環境，更加豐富的注解，實作強弱依賴的自動化。
• 2015年8月，Eos 4.0，全部基于ASM位元組碼技術進行故障模拟，不依賴具體的環境，豐富的注解，支援根據使用者ID進行屏蔽和檢測，主要圍繞自動化、常态化、降低成本幾個方面發展，實作強弱依賴的常态化運作。
• 2015年12月，與線上測試團隊産品進行合作，識别壓測資料，嘗試線上上進行故障演練。
• 2016年，故障演練項目立項（GOC+中間件），重新設計架構和産品流程，确定産品名為MonkeyKing，在交易和中間件鍊路嘗試演練。
• 2016年11月，開始籌備和推進線上微灰階環境的建設。
• 2017年3月，具備前後端灰階隔離的能力，可以基于業務、比例來篩選特征流量，通過真實的流量來替換原來的測試流量。
• 2017年，成立雙11故障演練項目組（GOC+中間件），優化産品流程和使用體驗，把演練推廣到更多業務線，演練場景3.9k個。
• 2018年，演練場景7.6k個。
• 2018年9月，應用高可用服務（AHAS）在阿裡雲公測，故障演練服務面向公有雲客戶輸出。
• 2018年10月，阿裡巴巴實踐混沌工程的實踐産品AHAS也被列入CNCF混沌工程雲原生全景圖中。

4.3 參考資料

• Chaos Engineering（O'Reilly出版）
• Principles Of Chaos
• 超全總結 | 阿裡電商故障治理和故障演練實踐
• 國外實踐Chaos Engineering的一些公司
• Chaos Engineering 的曆史、原則以及實踐
• ChAP: Chaos Automation Platform
• FIT: Failure Injection Testing
• Fault injection Wikipedia Page
• 阿裡雲應用高可用服務AHAS

編輯于 2018-12-17

Aliware APM 沙龍的一些活動圖檔

Aliware APM