[[256849]]

 一、為什么需要混沌工程?

(翻譯自Chaos Engineering電子書)

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

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

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

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

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

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

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

• 模擬整個(gè)區(qū)域或數(shù)據(jù)中心的故障。
• 部分刪除各種實(shí)例上的Kafka主題。
• 重新創(chuàng)建生產(chǎn)中發(fā)生的問題。
• 針對(duì)特定百分比的交易服務(wù)之間注入一段預(yù)期的訪問延遲。
• 基于函數(shù)的混亂(運(yùn)行時(shí)注入)：隨機(jī)導(dǎo)致拋出異常的函數(shù)。
• 代碼插入：向目標(biāo)程序添加指令和允許在某些指令之前進(jìn)行故障注入。
• 時(shí)間旅行：強(qiáng)制系統(tǒng)時(shí)鐘彼此不同步。
• 在模擬I/O錯(cuò)誤的驅(qū)動(dòng)程序代碼中執(zhí)行例程。
• 在 Elasticsearch 集群上***化CPU核心。

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

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

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

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

混沌工程非常適合揭露生產(chǎn)系統(tǒng)中未知的弱點(diǎn)，但如果確定混沌工程實(shí)驗(yàn)會(huì)導(dǎo)致系統(tǒng)出現(xiàn)嚴(yán)重問題，那么運(yùn)行該實(shí)驗(yàn)就沒有任何意義。先解決這個(gè)弱點(diǎn)，然后回到混沌工程，它將發(fā)現(xiàn)你不了解的其他弱點(diǎn)，或者它會(huì)讓你發(fā)現(xiàn)你的系統(tǒng)實(shí)際上是有彈性的。混沌工程的另一個(gè)基本要素是可用于確定系統(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)的難度越大，我們對(duì)系統(tǒng)行為的信心就越強(qiáng)。如果發(fā)現(xiàn)了一個(gè)弱點(diǎn)，那么我們就有了一個(gè)改進(jìn)目標(biāo)。避免在系統(tǒng)規(guī)模化之后問題被放大。以下原則描述了應(yīng)用混沌工程的理想方式，這些原則來(lái)實(shí)施實(shí)驗(yàn)過(guò)程。對(duì)這些原則的匹配程度能夠增強(qiáng)我們?cè)诖笠?guī)模分布式系統(tǒng)的信心。

二、阿里巴巴在混沌工程領(lǐng)域的實(shí)踐：故障演練

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

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

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

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

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

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

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

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

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

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

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

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

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

從功能性的故障測(cè)試角度來(lái)看，非生產(chǎn)環(huán)境去實(shí)施故障注入是可以滿足預(yù)期的，所以最早的強(qiáng)弱依賴測(cè)試就是在日常環(huán)境中完成的。不過(guò)，因?yàn)橄到y(tǒng)行為會(huì)根據(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)只是手段，通過(guò)實(shí)驗(yàn)對(duì)系統(tǒng)建立信心是我們的目標(biāo)。關(guān)于如何減少實(shí)驗(yàn)帶來(lái)的影響，這點(diǎn)在"最小化爆炸半徑"部分會(huì)有闡述。

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

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

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

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

2.5 最小化爆炸半徑

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

三、未來(lái)的計(jì)劃

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

建立高可用專家?guī)欤Y(jié)構(gòu)化提高應(yīng)用容錯(cuò)能力(解決"穩(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)品化、平臺(tái)化思路開放演練能力(探索"自動(dòng)化運(yùn)行實(shí)驗(yàn)"的方式)

四、觸手可及的混沌工程

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

參考資料：

Chaos Engineering(O'Reilly出版)

【本文為51CTO專欄作者“阿里巴巴官方技術(shù)”原創(chuàng)稿件，轉(zhuǎn)載請(qǐng)聯(lián)系原作者】

戳這里，看該作者更多好文