Labs 導讀

混沌工程(Chaos Engineering)不是一個新概念，從Netflix的工程師創(chuàng)建混沌猴子開始，已經默默發(fā)展了數(shù)年，隨著近年云原生的興起，混沌工程開始頻繁地出現(xiàn)在我們面前。作為一種提高技術架構彈性能力的復雜技術手段，混沌工程在分布式系統(tǒng)上進行隨機的故障注入實驗，和云原生規(guī)模宏大、結構復雜、可靠性要求高的特點完美匹配，為云原生的發(fā)展提供較強助力。

[[424743]]

“今年要搞云原生，混沌工程也要考慮了。”“聽說某某公司建了個混沌工程平臺呢。”“我最近也在研究混沌工程。”

最近是不是經常聽到這樣的對話?

混沌工程到底是什么?

為什么要實施混沌工程?

怎么實施?

如果你還不太了解

那就聽我給你介紹一下吧

Part 01 什么是混沌工程

有一只猴子，非常調皮，上躥下跳地到處搞破壞，不知道什么時候就把系統(tǒng)內哪臺服務給搞掛了，可是IT人們不僅不想辦法消滅它，還非常歡迎它，甚至任由它的隊伍發(fā)展壯大，成立了“猴子軍團”!是不是特別匪夷所思?其實，這就是混沌工程的始祖，由Netflix公司開發(fā)的Chaos Monkey，讓我們來了解一下吧。

根據(jù)這只猴子的特性，想必大家也能猜個幾分了，在系統(tǒng)內隨機搞破壞，制造一些正常手段難以設計的故障，驗證系統(tǒng)的恢復能力，提高系統(tǒng)的可靠性，如果給個定義的話，混沌工程就是一種提高技術架構彈性能力的復雜技術手段。是不是感覺跟我們常說的“故障注入”有點像呢?沒錯，“故障注入”是混沌工程最重要的組成部分，“故障演練”和混沌工程確實有一部分重疊，只是混沌工程的內涵更豐富，有自己的通用準則，在實施層面上看，混沌工程更像是一種實驗，并不預設實驗結果。

Part 02 為什么要實施混沌工程

按照目前云原生時代流行的持續(xù)測試的理念，測試人員在軟件生命周期的需求分析階段就介入了，更有自動化測試、測試左移/后移等手段的保駕護航，難道還會有發(fā)現(xiàn)不了的bug?還需要引入混沌工程?答案是肯定的。因為目前的測試手段都是基于制定好的測試用例來執(zhí)行測試，測試結果是有預期的，對于復雜的系統(tǒng)，尤其是動輒成千上萬臺服務器的云環(huán)境，我們很難預計到系統(tǒng)內會發(fā)生什么故障，更無法預期發(fā)生一個小小的故障對整個系統(tǒng)會產生多大的影響?；煦绻こ叹褪菫榱私鉀Q這個問題而產生的，盡可能產生隨機故障，監(jiān)控系統(tǒng)的表現(xiàn)，為加固系統(tǒng)提供參考和建議，這樣就能不斷提高系統(tǒng)的健壯性。

Part 03 怎么實施混沌工程

作為混沌工程的基礎，肯定要先了解下故障注入，其實業(yè)界已經有了相對通用的按照等級劃分的故障畫像了。

有了故障畫像，混沌工程的實施就有了基礎，Netflix也給出了混沌工程的實施步驟以及設計原則，經過多年的發(fā)展，阿里巴巴、亞馬遜等巨頭公司都有了自己的混沌工程平臺，同時開源了很多故障注入工具，站在巨人的肩膀上，我們再來實施混沌工程就容易了很多。

目前比較受歡迎的開源工具見下表，大部分的工具是在chaos monkey的基礎上衍生出來的：

我們研究了部分開源工具，并在項目上進行了實踐。不管是在虛擬機環(huán)境還是容器環(huán)境，這些工具的使用都非常簡單，覆蓋的故障場景也相對比較全面，從底層服務器級別，到代碼的方法級別，常規(guī)的故障都可以模擬。當然了，目前支持的故障場景比較簡單，很多常用的中間件也暫不支持，留給我們很大的二次開發(fā)空間。

這些開源工具存在的通用問題整理如下：

• 功能分散、單薄。每種工具在功能上都有局限性，只具備模擬部分故障的能力;
• 重點都在故障注入，在混沌工程的其他設計原則方面比較欠缺。不能自動化執(zhí)行，沒有可視化管理界面，對實驗的爆炸半徑控制不夠等。

那什么樣的才是完整的混沌工程平臺呢?除了故障類型的支持，權限管理、資源管理、演練推薦、流程編排等 都是一個成熟的混沌工程平臺的必要組成部分，甚至可以提供攻防演練等上層能力。所以說，搭建一個成熟的混沌工程平臺不是一件容易的事情。

Part 04 總結

混沌工程發(fā)展了這么多年，前人已經在故障畫像、故障注入工具、混沌工程平臺搭建思路等方面打好了堅實的基礎，進而推動混沌工程技術持續(xù)進步與完善，隨著云原生技術的發(fā)展，混沌工程的價值也將更加顯現(xiàn)。

【本文為51CTO專欄作者“移動Labs”原創(chuàng)稿件，轉載請聯(lián)系原作者】

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