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

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

（翻譯自Chaos Engineering電子書）

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

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

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

混沌工程、故障注入和故障測試在關(guān)注點(diǎn)和工具中都有很大的重疊。

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

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

混沌實(shí)驗(yàn)的輸入示例：

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

部分刪除各種實(shí)例上的Kafka主題。

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

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

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

代碼插入：向目標(biāo)程序添加指令和允許在某些指令之前進(jìn)行故障注入。

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

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

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

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

1.2 實(shí)施混沌工程的先決條件

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

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

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

1.3 混沌工程原則

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

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

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

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

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

2.2 多樣化真實(shí)世界的事件

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

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

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

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

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

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

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

2.3 在生產(chǎn)環(huán)境中運(yùn)行實(shí)驗(yàn)

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

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

2.4 持續(xù)自動化運(yùn)行實(shí)驗(yàn)

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

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

因?yàn)楣收涎菥氈笆亲鳛橐粋€技術(shù)組件被嵌入到常態(tài)和大促的流程中，所以在系統(tǒng)構(gòu)建自動化的編排和分析方面的產(chǎn)品度并不高。演練可視化編排和能力開放會是我們團(tuán)隊未來的一個重點(diǎn)，下文中的規(guī)劃部分會有所闡述。

2.5 最小化爆炸半徑

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

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

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

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

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

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

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

本文作者：中亭

閱讀原文

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