摘要：通過本文，你將了解到為什么需要混沌工程，阿里巴巴在該領域的實踐和思考未來的計劃。而阿里目前并沒有一個專門的職位來實施混沌工程，項目目標業(yè)務場景人員結(jié)構(gòu)實施方式的不同導致了對于穩(wěn)定狀態(tài)行為的定義不太標準。

阿里妹導讀：混沌工程屬于一門新興的技術(shù)學科，行業(yè)認知和實踐積累比較少，大多數(shù)IT團隊對它的理解還沒有上升到一個領域概念。阿里電商域在2010年左右開始嘗試故障注入測試的工作，希望解決微服務架構(gòu)帶來的強弱依賴問題。通過本文，你將了解到：為什么需要混沌工程，阿里巴巴在該領域的實踐和思考、未來的計劃。

（翻譯自Chaos Engineering電子書）

1.1 混沌工程與故障測試的區(qū)別

混沌工程是在分布式系統(tǒng)上進行實驗的學科, 目的是建立對系統(tǒng)抵御生產(chǎn)環(huán)境中失控條件的能力以及信心，最早由Netflix及相關團隊提出。

故障演練是阿里巴巴在混沌工程領域的產(chǎn)品，目標是沉淀通用的故障模式，以可控成本在線上重放，以持續(xù)性的演練和回歸方式運營來暴露問題，不斷推動系統(tǒng)、工具、流程、人員能力的不斷前進。

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

混沌工程和其他方法之間的主要區(qū)別在于，混沌工程是一種生成新信息的實踐，而故障注入是測試一種情況的一種特定方法。當想要探索復雜系統(tǒng)可能出現(xiàn)的不良行為時，注入通信延遲和錯誤等失敗是一種很好的方法。但是我們也想探索諸如流量激增，激烈競爭，拜占庭式失敗，以及消息的計劃外或不常見的組合。如果一個面向消費者的網(wǎng)站突然因為流量激增而導致更多收入，我們很難稱之為錯誤或失敗，但我們?nèi)匀粚μ剿飨到y(tǒng)的影響非常感興趣。同樣，故障測試以某種預想的方式破壞系統(tǒng)，但沒有探索更多可能發(fā)生的奇怪場景，那么不可預測的事情就可能發(fā)生。

測試和實驗之間可以有一個重要的區(qū)別。在測試中，進行斷言：給定特定條件，系統(tǒng)將發(fā)出特定輸出。測試通常是二進制態(tài)的，并確定屬性是真還是假。嚴格地說，這不會產(chǎn)生關于系統(tǒng)的新知識，它只是將效價分配給它的已知屬性。實驗產(chǎn)生新知識，并經(jīng)常提出新的探索途徑。我們認為混沌工程是一種實驗形式，可以產(chǎn)生關于系統(tǒng)的新知識。它不僅僅是一種測試已知屬性的方法，可以通過集成測試更輕松地進行驗證。

混沌實驗的輸入示例：

模擬整個區(qū)域或數(shù)據(jù)中心的故障。

部分刪除各種實例上的Kafka主題。

重新創(chuàng)建生產(chǎn)中發(fā)生的問題。

針對特定百分比的交易服務之間注入一段預期的訪問延遲。

基于函數(shù)的混亂（運行時注入）：隨機導致拋出異常的函數(shù)。

代碼插入：向目標程序添加指令和允許在某些指令之前進行故障注入。

時間旅行：強制系統(tǒng)時鐘彼此不同步。

在模擬I/O錯誤的驅(qū)動程序代碼中執(zhí)行例程。

在 Elasticsearch 集群上最大化CPU核心。

混沌工程實驗的機會是無限的，可能會根據(jù)分布式系統(tǒng)的架構(gòu)和組織的核心業(yè)務價值而有所不同。

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

要確定是否已準備好開始采用混沌工程，需要回答一個問題：你的系統(tǒng)是否能夠適應現(xiàn)實世界中的事件，例如服務故障和網(wǎng)絡延遲峰值？

如果答案是“否”，那么你還有一些工作要做。

混沌工程非常適合揭露生產(chǎn)系統(tǒng)中未知的弱點，但如果確定混沌工程實驗會導致系統(tǒng)出現(xiàn)嚴重問題，那么運行該實驗就沒有任何意義。先解決這個弱點，然后回到混沌工程，它將發(fā)現(xiàn)你不了解的其他弱點，或者它會讓你發(fā)現(xiàn)你的系統(tǒng)實際上是有彈性的?；煦绻こ痰牧硪粋€基本要素是可用于確定系統(tǒng)當前狀態(tài)的監(jiān)控系統(tǒng)。

1.3 混沌工程原則

為了具體地解決分布式系統(tǒng)在規(guī)模上的不確定性，可以把混沌工程看作是為了揭示系統(tǒng)弱點而進行的實驗。破壞穩(wěn)態(tài)的難度越大，我們對系統(tǒng)行為的信心就越強。如果發(fā)現(xiàn)了一個弱點，那么我們就有了一個改進目標。避免在系統(tǒng)規(guī)?；髥栴}被放大。以下原則描述了應用混沌工程的理想方式，這些原則來實施實驗過程。對這些原則的匹配程度能夠增強我們在大規(guī)模分布式系統(tǒng)的信心。

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

2.1 建立一個圍繞穩(wěn)定狀態(tài)行為的假說

目前阿里巴巴集團范圍內(nèi)的實踐偏向于故障測試，即在一個具體場景下實施故障注入實驗并驗證預期是否得到滿足。這種測試的風險相對可控，壞處是并沒有通過故障注入實驗探索更多的場景，暴露更多的潛在問題，測試結(jié)果比較依賴實施人的經(jīng)驗。當前故障測試的預期比較兩級分化，要么過于關注系統(tǒng)的內(nèi)部細節(jié)，要么對于系統(tǒng)的表現(xiàn)完全沒有預期，與混沌工程定義的穩(wěn)態(tài)狀態(tài)行為差異比較大。

引起差異的根本原因還是組織形態(tài)的不同。2014年，Netflix團隊創(chuàng)建了一種新的角色，叫作混沌工程師（Chaos Enigneer），并開始向工程社區(qū)推廣。而阿里目前并沒有一個專門的職位來實施混沌工程，項目目標、業(yè)務場景、人員結(jié)構(gòu)、實施方式的不同導致了對于穩(wěn)定狀態(tài)行為的定義不太標準。

2.2 多樣化真實世界的事件

阿里巴巴因為多元化的業(yè)務場景、規(guī)?；姆展?jié)點及高度復雜的系統(tǒng)架構(gòu)，每天都會遇到各式各樣的故障。這些故障信息就是最真實的混沌工程變量。為了能夠更體感、有效率地描述故障，我們優(yōu)先分析了P1和P2的故障（P是阿里對故障等級的描述），提出一些通用的故障場景并按照IaaS層、PaaS層、SaaS層的角度繪制了故障畫像。

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

任何故障，一定是硬件如IaaS層，軟件如PaaS或SaaS的故障。并且有個規(guī)律，硬件故障的現(xiàn)象，一定可以在軟件故障現(xiàn)象上有所體現(xiàn)。

故障一定隸屬于單機或是分布式系統(tǒng)之一，分布式故障包含單機故障。

對于單機或同機型的故障，以系統(tǒng)為視角，故障可能是當前進程內(nèi)的故障，比如：如FullGC，CPU飆高；進程外的故障，比如其他進程突然搶占了內(nèi)存，導致當前系統(tǒng)異常等。

同時，還可能有一類故障，是人為失誤，或流程失當導致，這部分我們今天不做重點討論。

從故障注入實現(xiàn)角度，我們也是參照上述的畫像來設計的。之前我們是通過Java字節(jié)碼技術(shù)和操作系統(tǒng)層面的工具來分別模擬進程內(nèi)和進程外的故障。隨著Serverless、Docker等新架構(gòu)、新技術(shù)的出現(xiàn)，故障實現(xiàn)機制和承接載體也將會有一些新的變化。

2.3 在生產(chǎn)環(huán)境中運行實驗

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

很多同學恐懼在生產(chǎn)環(huán)境執(zhí)行實驗，原因還是擔心故障影響不可控。實施實驗只是手段，通過實驗對系統(tǒng)建立信心是我們的目標。關于如何減少實驗帶來的影響，這點在"最小化爆炸半徑"部分會有闡述。

2.4 持續(xù)自動化運行實驗

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

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

因為故障演練之前是作為一個技術(shù)組件被嵌入到常態(tài)和大促的流程中，所以在系統(tǒng)構(gòu)建自動化的編排和分析方面的產(chǎn)品度并不高。演練可視化編排和能力開放會是我們團隊未來的一個重點，下文中的規(guī)劃部分會有所闡述。

2.5 最小化爆炸半徑

在生產(chǎn)中進行試驗可能會造成不必要的客戶投訴，但混沌工程師的責任和義務是確保這些后續(xù)影響最小化且被考慮到。對于實驗方案和目標進行充分的討論是減少用戶影響的最重要的手段。但是從實際的實施角度看，最好還是通過一些技術(shù)手段去最小化影響。Chaos Engineering和Fault Injection Test的核心區(qū)別在于：是否可以進一步減小故障的影響，比如微服務級別、請求級別甚至是用戶級別。在MonkeyKing演進的中期階段，已經(jīng)可以實現(xiàn)請求級別的微服務故障注入。雖然那個時候演練實施的主要位置在測試環(huán)境，但初衷也是為了減少因為注入故障而導致的環(huán)境不穩(wěn)定問題。除了故障注入，流量路由和數(shù)據(jù)隔離技術(shù)也是減少業(yè)務影響的有效手段。

線上故障演練發(fā)展到今天是第三年，隨著阿里安全生產(chǎn)的大環(huán)境、業(yè)務方的訴求、研發(fā)迭代模式的變化，以及大家對混沌工程的接受和認識程度的提高。集團的演練領域會向著未來的幾個目標發(fā)力：

建立高可用專家?guī)欤Y(jié)構(gòu)化提高應用容錯能力（解決"穩(wěn)定狀態(tài)定義"的問題）

建設故障注入實現(xiàn)標準，集團內(nèi)開源，提升故障模擬的廣度和深度（拓寬"多樣化真實世界的事件"的廣度）

規(guī)模化覆蓋核心業(yè)務（提升"在生產(chǎn)環(huán)境中運行實驗"的規(guī)模）

以產(chǎn)品化、平臺化思路開放演練能力（探索"自動化運行實驗"的方式）

MonkeyKing已經(jīng)提供商業(yè)化產(chǎn)品，歡迎在阿里云官網(wǎng)搜索“AHAS”，進行免費公測。地址：https://www.aliyun.com/product/ahas

本文作者：中亭

閱讀原文

本文來自云棲社區(qū)合作伙伴“阿里技術(shù)”，如需轉(zhuǎn)載請聯(lián)系原作者。