背景

起源

2008年8月，Netflix的服務器因為數(shù)據(jù)庫問題導致宕機了整整3天。此后，Netflix開始將整個Netflix應用從單體架構遷移到AWS上的分布式云架構，以此來消除單點故障，但同時也引入了新的問題。為了建設更加可靠和容錯性更強的系統(tǒng)，為此， Netflix 工程師創(chuàng)建了 Chaos Monkey ，會隨機終止在生產(chǎn)環(huán)境中運行的 EC2 實例。工程師可以快速了解他們正在構建的服務是否健壯，有足夠的彈性，可以容忍計劃外的故障。至此，混沌工程開始興起。

image.png

• 2010年 Netflix 內部開發(fā)了 AWS 云上隨機終止 EC2 實例的混沌實驗工具：Chaos Monkey
• 2011年 Netflix release了其猴子軍團工具集：Simian Army
• 2012年 Netflix 向社區(qū)開源由 Java 構建 Simian Army，其中包括 Chaos Monkey V1 版本
• 2014年 Netflix 開始正式公開招聘 Chaos Engineer
• 2014年 Netflix 提出了故障注入測試（FIT），利用微服務架構的特性，控制混沌實驗的爆炸半徑
• 2015年 Netflix release了 Chaos Kong ，模擬AWS區(qū)域（Region）中斷的場景
• 2015年 Netflix 和社區(qū)正式提出混沌工程的指導思想 – Principles of Chaos Engineering
• 2016年 Kolton Andrus（前 Netflix 和 Amazon Chaos Engineer ）創(chuàng)立了 Gremlin ，正式將混沌實驗工具商用化
• 2017年 Netflix 開源 Chaos Monkey 由 Golang 重構的 V2 版本，必須集成 CD 工具 Spinnaker（持續(xù)發(fā)布平臺）來使用
• 2017年 Netflix release了 ChAP （Chaos Automation Platform, 混沌實驗自動平臺），可視為應用故障注入測試（FIT）的加強版
• 2017年 由Netflix 前混沌工程師撰寫的新書“混沌工程”在網(wǎng)上出版
• 2017年 Russell Miles 創(chuàng)立了 ChaosIQ 公司，并開源了 chaostoolkit 混沌實驗框架

為什么需要混沌工程

隨著公有云市場的高速增長和云原生技術的發(fā)展，企業(yè)用戶逐步向云原生架構遷移，系統(tǒng)內的微服務進一步朝著分布式的架構演進，微服務數(shù)量呈爆炸式增長，各服務間相互調用關系也變得更為繁雜，這對軟件的可靠性提出了更高的要求，而傳統(tǒng)的質量工程和軟件測試已無法檢測出生產(chǎn)環(huán)境中的意外故障和性能問題。為了應對愈發(fā)復雜的實際生產(chǎn)問題，混沌工程應運而生，它可以幫助用戶提前檢測出生產(chǎn)環(huán)境中可能潛在的故障和性能問題。

近期重大宕機事故

混沌工程是什么

混沌工程是一套通過在系統(tǒng)基礎設施上進行實驗，主動找出系統(tǒng)中脆弱環(huán)節(jié)的方法學。通過實驗性的方法，發(fā)現(xiàn)系統(tǒng)中潛在的、可以導致災難性故障、或讓用戶受損的薄弱環(huán)節(jié)，并推動研發(fā)自主地進行問題修復、代碼優(yōu)化，最終建設成為真正意義上的韌性架構，增加用戶抵御突發(fā)事件的能力與信心。

混沌工程與傳統(tǒng)測試

總的來說，傳統(tǒng)測試是對預期結果進行驗證****，混沌測試是****對未知結果進行探索。

混沌工程實施

實施先決條件

• 系統(tǒng)具備一定的彈性來應對破壞性演練中的一些異常事件——混沌工程非常適合揭露生產(chǎn)系統(tǒng)中的未知缺陷，但如果確定混沌工程實驗會導致系統(tǒng)出現(xiàn)嚴重的問題，那么運行這樣的實驗是沒有任何意義的
• 具備一套破壞性演練的環(huán)境——理想實踐是直接在生產(chǎn)環(huán)境中進行實驗，其次是在離生產(chǎn)環(huán)境越近的地方進行實驗（如預發(fā)環(huán)境）。如在預發(fā)環(huán)境進行演練，確保預發(fā)和生產(chǎn)環(huán)境保持一致很重要，只有這樣才能體現(xiàn)演練意義
• 具備配套的監(jiān)控系統(tǒng)——用于判斷系統(tǒng)當前的各項狀態(tài)如果沒有對系統(tǒng)行為的可見能力，那么也就無法從實驗中得出有效的結論

混沌工程應用原則

netflix對于混沌工程的實施提出以下5個原則：

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

“穩(wěn)定狀態(tài)”是指系統(tǒng)正常運行時的狀態(tài)。具體來說，系統(tǒng)的穩(wěn)定狀態(tài)可以通過一些指標來定義，當系統(tǒng)指標在測試完成后，無法快速恢復穩(wěn)態(tài)要求，可以認為這個系統(tǒng)是不穩(wěn)定的。
定義好指標并理解其穩(wěn)定狀態(tài)的行為之后，****我們****可以使用它們來建立對實驗的假設。思考****當****向系統(tǒng)注入不同類型的事件時，穩(wěn)定狀態(tài)行為會發(fā)生什么變化。
我們的假設可以是實驗措施不會使系統(tǒng)行為偏離穩(wěn)定狀態(tài)，比如：向我們的系統(tǒng)中注入的事件不會導致系統(tǒng)穩(wěn)定狀態(tài)發(fā)生明顯的變化。

多樣化真實世界的事件

在真實的世界中，我們可能遇到各種各樣的問題，任何能夠破壞穩(wěn)態(tài)的事件都是混沌實驗中的一個潛在變量。例如：

?硬件故障；

?云服務功能不可用（例如AWS某個區(qū)域不可用）；

?系統(tǒng)本身的功能缺陷（例如功能未實現(xiàn)或者實現(xiàn)錯誤）；

?網(wǎng)絡延遲或隔離（例如微服務之間延遲過大）；

?依賴故障（例如所依賴的第三方服務不可用）。

無窮無盡的系統(tǒng)事件、觸發(fā)條件、未知的問題等著我們去探索，但我們無法窮盡這些問題，所以我們在決定開始混沌工程實驗之前，需要劃定實驗的范圍，之后根據(jù)劃定的范圍和業(yè)務場景，最終決定要引入哪些事件或注入哪些錯誤，并且對這些影響作出大略的估算，如這些事件在系統(tǒng)中發(fā)生的頻率與影響范圍，最后考慮這些引入的影響需要耗費的成本以及實驗的復雜度。

在生產(chǎn)環(huán)境中運行實驗

根據(jù)環(huán)境與流量模式的不同，系統(tǒng)運行效果亦將受到影響。由于運行效果可能隨時改變，因此我們應將對實際流量進行采樣作為獲取可靠請求路徑的惟一方法。為了保證系統(tǒng)運行方式的真實性以及同現(xiàn)有部署系統(tǒng)間的關聯(lián)性，混沌工程原則強烈建議您直接面向生產(chǎn)流量進行實驗。

即便不能在生產(chǎn)環(huán)境中執(zhí)行實驗，也要盡可能的在離生產(chǎn)環(huán)境最接近的環(huán)境中運行。越接近生產(chǎn)環(huán)境，對實驗外部有效性的威脅就越少，對實驗結果的信心就越足。

持續(xù)自動化運行實驗

現(xiàn)在系統(tǒng)越來越復雜，這意味著我們無法預先地知道生產(chǎn)環(huán)境的哪些變動會改變混沌工程實驗的結果?；谶@個原因，我們必須假設所有變動都會改變實驗結果。在共享狀態(tài)、緩存、動態(tài)配置管理、持續(xù)交付、自動伸縮、時間敏感的代碼等等的作用之下，生產(chǎn)環(huán)境實際上處在一個無時不在變化的狀態(tài)。

最開始執(zhí)行混沌實驗，可能就是手動執(zhí)行，但是實驗的手動運行工作屬于勞動力密集型任務，因此難以長久持續(xù)。相反的，我們應該自己投入精力來開發(fā)混沌工程的工具和平臺，以期不斷降低創(chuàng)建新實驗的門檻，并能夠完全自動運行這些實驗。

最小化爆炸半徑

在生產(chǎn)進行混沌試驗的時候，一定要注意影響的范圍，如果影響太大會造成不必要客戶投訴。要確保實驗能隨時終止，環(huán)境能在很短的時間內恢復，我們需要通過了解業(yè)務和技術架構來探索故障造成的未知影響，以及影響的范圍與功能，并將影響控制在我們能夠處理的范疇，這個范疇我們稱之為最小化“爆炸半徑”。

場景設計

實驗是混沌工程的基礎，大多依靠模擬異常注入系統(tǒng)來實現(xiàn)。在設計場景時，首先要分析系統(tǒng)的架構，把技術架構中的組件全部列出來，并分析可能產(chǎn)生異常的點，再列出異常場景，根據(jù)分析的異常點來設計對應的場景。異常點通常參考每一層的影響點，也可以根據(jù)混沌測試工具提供的異常實驗。

image.png

實施步驟

完整的混沌工程實驗是一個持續(xù)性迭代的閉環(huán)體系，大致分為以下幾個步驟：

1. 確定初步的實驗需求和實驗對象；

2. 通過實驗可行性評估，確定實驗范圍；

3. 設計合適的觀測指標；

4. 設計合適的實驗場景和環(huán)境；

5. 選擇合適的實驗工具和平臺框架；

6. 建立實驗計劃，和實驗對象的干系人充分溝通，進而聯(lián)合執(zhí)行實驗過程；

7. 搜集預先設計好的實驗指標；

8. 待實驗完成后，清理和恢復實驗環(huán)境；

9. 對實驗結果進行分析；

10. 追蹤根源并解決問題；

11. 將以上實驗場景自動化，并入流水線，定期執(zhí)行；之后，便可開始增加新的實驗范圍，持續(xù)迭代和有序改進。

image.png

故障演練工具

chaosblade.png

ChaosBlade是一個云原生混沌工程平臺，支持多種環(huán)境、集群和語言。

包含混沌工程實驗工具 chaosblade 和混沌工程平臺 chaosblade-box，旨在通過混沌工程幫助企業(yè)解決云原生過程中高可用問題。

chaosmesh.png

Chaos Mesh 是一個開源的云原生混沌工程平臺，提供豐富的故障模擬類型，具有強大的故障場景編排能力，方便用戶在開發(fā)測試中以及生產(chǎn)環(huán)境中模擬現(xiàn)實世界中可能出現(xiàn)的各類異常，幫助用戶發(fā)現(xiàn)系統(tǒng)潛在的問題。Chaos Mesh 提供完善的可視化操作，旨在降低用戶進行混沌工程的門檻。用戶可以方便地在 Web UI 界面上設計自己的混沌場景，以及監(jiān)控混沌實驗的運行狀態(tài)。

擴展閱讀

https://chaos-mesh.org/zh/
https://chaosblade.io/docs/
https://cloud.tencent.com/developer/article/1622874
https://www.infoq.cn/article/gsqtykoa3uvrtqi1kkmo