鲜为人知的混沌工程,到底哪里好?
混沌工程屬于一門新興的技術學科,行業認知和實踐積累比較少,大多數IT團隊對它的理解還沒有上升到一個領域概念。阿里電商域在2010年左右開始嘗試故障注入測試的工作,希望解決微服務架構帶來的強弱依賴問題。通過本文,你將了解到:為什么需要混沌工程,阿里巴巴在該領域的實踐和思考、未來的計劃。
一、為什么需要混沌工程?
(翻譯自Chaos Engineering電子書)
1.1 混沌工程與故障測試的區別
混沌工程是在分布式系統上進行實驗的學科, 目的是建立對系統抵御生產環境中失控條件的能力以及信心,最早由Netflix及相關團隊提出。
故障演練是阿里巴巴在混沌工程領域的產品,目標是沉淀通用的故障模式,以可控成本在線上重放,以持續性的演練和回歸方式運營來暴露問題,不斷推動系統、工具、流程、人員能力的不斷前進。
混沌工程、故障注入和故障測試在關注點和工具中都有很大的重疊。
混沌工程和其他方法之間的主要區別在于,混沌工程是一種生成新信息的實踐,而故障注入是測試一種情況的一種特定方法。當想要探索復雜系統可能出現的不良行為時,注入通信延遲和錯誤等失敗是一種很好的方法。但是我們也想探索諸如流量激增,激烈競爭,拜占庭式失敗,以及消息的計劃外或不常見的組合。如果一個面向消費者的網站突然因為流量激增而導致更多收入,我們很難稱之為錯誤或失敗,但我們仍然對探索系統的影響非常感興趣。同樣,故障測試以某種預想的方式破壞系統,但沒有探索更多可能發生的奇怪場景,那么不可預測的事情就可能發生。
測試和實驗之間可以有一個重要的區別。在測試中,進行斷言:給定特定條件,系統將發出特定輸出。測試通常是二進制態的,并確定屬性是真還是假。嚴格地說,這不會產生關于系統的新知識,它只是將效價分配給它的已知屬性。實驗產生新知識,并經常提出新的探索途徑。我們認為混沌工程是一種實驗形式,可以產生關于系統的新知識。它不僅僅是一種測試已知屬性的方法,可以通過集成測試更輕松地進行驗證。
混沌實驗的輸入示例:
模擬整個區域或數據中心的故障。
部分刪除各種實例上的Kafka主題。
重新創建生產中發生的問題。
針對特定百分比的交易服務之間注入一段預期的訪問延遲。
基于函數的混亂(運行時注入):隨機導致拋出異常的函數。
代碼插入:向目標程序添加指令和允許在某些指令之前進行故障注入。
時間旅行:強制系統時鐘彼此不同步。
在模擬I/O錯誤的驅動程序代碼中執行例程。
在 Elasticsearch 集群上最大化CPU核心。
混沌工程實驗的機會是無限的,可能會根據分布式系統的架構和組織的核心業務價值而有所不同。
1.2 實施混沌工程的先決條件
要確定是否已準備好開始采用混沌工程,需要回答一個問題:你的系統是否能夠適應現實世界中的事件,例如服務故障和網絡延遲峰值?
如果答案是“否”,那么你還有一些工作要做。
混沌工程非常適合揭露生產系統中未知的弱點,但如果確定混沌工程實驗會導致系統出現嚴重問題,那么運行該實驗就沒有任何意義。先解決這個弱點,然后回到混沌工程,它將發現你不了解的其他弱點,或者它會讓你發現你的系統實際上是有彈性的。混沌工程的另一個基本要素是可用于確定系統當前狀態的監控系統。
1.3 混沌工程原則
為了具體地解決分布式系統在規模上的不確定性,可以把混沌工程看作是為了揭示系統弱點而進行的實驗。破壞穩態的難度越大,我們對系統行為的信心就越強。如果發現了一個弱點,那么我們就有了一個改進目標。避免在系統規模化之后問題被放大。以下原則描述了應用混沌工程的理想方式,這些原則來實施實驗過程。對這些原則的匹配程度能夠增強我們在大規模分布式系統的信心。
二、阿里巴巴在混沌工程領域的實踐:故障演練
混沌工程屬于一門新興的技術學科,行業認知和實踐積累比較少,大多數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演進的中期階段,已經可以實現請求級別的微服務故障注入。雖然那個時候演練實施的主要位置在測試環境,但初衷也是為了減少因為注入故障而導致的環境不穩定問題。除了故障注入,流量路由和數據隔離技術也是減少業務影響的有效手段。
三、未來的計劃
線上故障演練發展到今天是第三年,隨著阿里安全生產的大環境、業務方的訴求、研發迭代模式的變化,以及大家對混沌工程的接受和認識程度的提高。集團的演練領域會向著未來的幾個目標發力:
建立高可用專家庫,結構化提高應用容錯能力(解決"穩定狀態定義"的問題)
建設故障注入實現標準,集團內開源,提升故障模擬的廣度和深度(拓寬"多樣化真實世界的事件"的廣度)
規模化覆蓋核心業務(提升"在生產環境中運行實驗"的規模)
以產品化、平臺化思路開放演練能力(探索"自動化運行實驗"的方式)
?
原文鏈接
本文為云棲社區原創內容,未經允許不得轉載。
總結
以上是生活随笔為你收集整理的鲜为人知的混沌工程,到底哪里好?的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: X-Pack Spark归档POLARD
- 下一篇: “有趣”的投影:当PCA失效时怎么办?