導讀
混沌工程（Chaos Engineering）不是一個新概念，從Netflix的工程師創建混沌猴子開始，已經默默發展了數年，隨著近年云原生的興起，混沌工程開始頻繁地出現在我們面前。作為一種提高技術架構彈性能力的復雜技術手段，混沌工程在分布式系統上進行隨機的故障注入實驗，和云原生規模宏大、結構復雜、可靠性要求高的特點完美匹配，為云原生的發展提供較強助力。
云原生 × 混沌工程
“今年要搞云原生，混沌工程也要考慮了。”
“聽說某某公司建了個混沌工程平臺呢。”
“我最近也在研究混沌工程。”
最近是不是經常聽到這樣的對話？
混沌工程到底是什么？
為什么要實施混沌工程？
怎么實施？
如果你還不太了解❓
那就聽我給你介紹一下吧👇
Part 01
● 什么是混沌工程 ●
有一只猴子，非常調皮，上躥下跳地到處搞破壞，不知道什么時候就把系統內哪臺服務給搞掛了，可是IT人們不僅不想辦法消滅它，還非常歡迎它，甚至任由它的隊伍發展壯大，成立了“猴子軍團”！是不是特別匪夷所思？其實，這就是混沌工程的始祖，由Netflix公司開發的Chaos Monkey，讓我們來了解一下吧。
根據這只猴子的特性，想必大家也能猜個幾分了，在系統內隨機搞破壞，制造一些正常手段難以設計的故障，驗證系統的恢復能力，提高系統的可靠性，如果給個定義的話，混沌工程就是一種提高技術架構彈性能力的復雜技術手段。是不是感覺跟我們常說的“故障注入”有點像呢？沒錯，“故障注入”是混沌工程最重要的組成部分，“故障演練”和混沌工程確實有一部分重疊，只是混沌工程的內涵更豐富，有自己的通用準則，在實施層面上看，混沌工程更像是一種實驗，并不預設實驗結果。
Part 02
● 為什么要實施混沌工程 ●
按照目前云原生時代流行的持續測試的理念，測試人員在軟件生命周期的需求分析階段就介入了，更有自動化測試、測試左移/后移等手段的保駕護航，難道還會有發現不了的bug？還需要引入混沌工程？答案是肯定的。因為目前的測試手段都是基于制定好的測試用例來執行測試，測試結果是有預期的，對于復雜的系統，尤其是動輒成千上萬臺服務器的云環境，我們很難預計到系統內會發生什么故障，更無法預期發生一個小小的故障對整個系統會產生多大的影響。混沌工程就是為了解決這個問題而產生的，盡可能產生隨機故障，監控系統的表現，為加固系統提供參考和建議，這樣就能不斷提高系統的健壯性。
Part 03
● 怎么實施混沌工程 ●
作為混沌工程的基礎，肯定要先了解下故障注入，其實業界已經有了相對通用的按照等級劃分的故障畫像了。
有了故障畫像，混沌工程的實施就有了基礎，Netflix也給出了混沌工程的實施步驟以及設計原則，經過多年的發展，阿里巴巴、亞馬遜等巨頭公司都有了自己的混沌工程平臺，同時開源了很多故障注入工具，站在巨人的肩膀上，我們再來實施混沌工程就容易了很多。
目前比較受歡迎的開源工具見下表，大部分的工具是在chaos monkey的基礎上衍生出來的：
我們研究了部分開源工具，并在項目上進行了實踐。不管是在虛擬機環境還是容器環境，這些工具的使用都非常簡單，覆蓋的故障場景也相對比較全面，從底層服務器級別，到代碼的方法級別，常規的故障都可以模擬。當然了，目前支持的故障場景比較簡單，很多常用的中間件也暫不支持，留給我們很大的二次開發空間。
這些開源工具存在的通用問題整理如下：
1、功能分散、單薄。每種工具在功能上都有局限性，只具備模擬部分故障的能力；
2、重點都在故障注入，在混沌工程的其他設計原則方面比較欠缺。不能自動化執行，沒有可視化管理界面，對實驗的爆炸半徑控制不夠等。
那什么樣的才是完整的混沌工程平臺呢？除了故障類型的支持，權限管理、資源管理、演練推薦、流程編排等 都是一個成熟的混沌工程平臺的必要組成部分，甚至可以提供攻防演練等上層能力。所以說，搭建一個成熟的混沌工程平臺不是一件容易的事情。
● 總結 ●
混沌工程發展了這么多年，前人已經在故障畫像、故障注入工具、混沌工程平臺搭建思路等方面打好了堅實的基礎，進而推動混沌工程技術持續進步與完善，隨著云原生技術的發展，混沌工程的價值也將更加顯現。
