不爲人知的混沌工程，到底哪裏好？

時間 2019-11-06

標籤不爲人知混沌工程到底哪裏简体版

原文原文鏈接

阿里妹導讀：混沌工程屬於一門新興的技術學科，行業認知和實踐積累比較少，大多數IT團隊對它的理解尚未上升到一個領域概念。阿里電商域在2010年左右開始嘗試故障注入測試的工做，但願解決微服務架構帶來的強弱依賴問題。經過本文，你將瞭解到：爲何須要混沌工程，阿里巴巴在該領域的實踐和思考、將來的計劃。安全

1、爲何須要混沌工程？

（翻譯自Chaos Engineering電子書）網絡

1.1 混沌工程與故障測試的區別架構

混沌工程是在分佈式系統上進行實驗的學科, 目的是創建對系統抵禦生產環境中失控條件的能力以及信心，最先由Netflix及相關團隊提出。less

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

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

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

測試和實驗之間能夠有一個重要的區別。在測試中，進行斷言：給定特定條件，系統將發出特定輸出。測試一般是二進制態的，並肯定屬性是真仍是假。嚴格地說，這不會產生關於系統的新知識，它只是將效價分配給它的已知屬性。實驗產生新知識，並常常提出新的探索途徑。咱們認爲混沌工程是一種實驗形式，能夠產生關於系統的新知識。它不只僅是一種測試已知屬性的方法，能夠經過集成測試更輕鬆地進行驗證。工具

混沌實驗的輸入示例：測試

模擬整個區域或數據中心的故障。網站

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

從新建立生產中發生的問題。

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

基於函數的混亂（運行時注入）：隨機致使拋出異常的函數。

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

時間旅行：強制系統時鐘彼此不一樣步。

在模擬I/O錯誤的驅動程序代碼中執行例程。

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

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

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

要肯定是否已準備好開始採用混沌工程，須要回答一個問題：你的系統是否可以適應現實世界中的事件，例如服務故障和網絡延遲峯值？

若是答案是「否」，那麼你還有一些工做要作。

混沌工程很是適合揭露生產系統中未知的弱點，但若是肯定混沌工程實驗會致使系統出現嚴重問題，那麼運行該實驗就沒有任何意義。先解決這個弱點，而後回到混沌工程，它將發現你不瞭解的其餘弱點，或者它會讓你發現你的系統其實是有彈性的。混沌工程的另外一個基本要素是可用於肯定系統當前狀態的監控系統。

1.3 混沌工程原則

爲了具體地解決分佈式系統在規模上的不肯定性，能夠把混沌工程看做是爲了揭示系統弱點而進行的實驗。破壞穩態的難度越大，咱們對系統行爲的信心就越強。若是發現了一個弱點，那麼咱們就有了一個改進目標。避免在系統規模化以後問題被放大。如下原則描述了應用混沌工程的理想方式，這些原則來實施實驗過程。對這些原則的匹配程度可以加強咱們在大規模分佈式系統的信心。

2、阿里巴巴在混沌工程領域的實踐：故障演練

混沌工程屬於一門新興的技術學科，行業認知和實踐積累比較少，大多數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 Engineering和Fault Injection Test的核心區別在於：是否能夠進一步減少故障的影響，好比微服務級別、請求級別甚至是用戶級別。在MonkeyKing演進的中期階段，已經能夠實現請求級別的微服務故障注入。雖然那個時候演練實施的主要位置在測試環境，但初衷也是爲了減小由於注入故障而致使的環境不穩定問題。除了故障注入，流量路由和數據隔離技術也是減小業務影響的有效手段。