混沌工程-初識

• 2020 年 2 月 19 日
• 筆記

公司新成立了一個穩定性團隊，20年的重要目標之一就是開展混沌工程。為了後續更好的開展工作，記錄關於「混沌工程」相關的知識以及工程實踐。

內容來源：《混沌工程：Netflix系統穩定性之道》摘錄以及個人思考總結。

概要

定義：主動發現系統中脆弱點的一整套方法論。

目的：如何讓系統在不確定性中獲益？

接受「系統越複雜，越脆弱」的事實，讓系統在每一次失敗中獲益，然後不斷進化。在實踐中，用一系列的實驗來真實的驗證系統在各類故障場景下的表現，通過頻繁大量的實驗，使得系統本身的「反脆弱性」持續增強，讓組織建立對系統抵禦生產環境中失控條件的能力以及信心。

初衷：通過實驗性的方法，讓人們建立複雜分散式系統能夠在生產中抵禦事件能力的資訊。

出現：最早由Netflix的技術團隊提出，現已經演變成電腦科學的一門新興學科，即「混沌工程」。

現狀：目前業內的認知和實踐積累較少，但它實際上是一種提高技術架構彈性能力的複雜技術手段。

挑戰：服務規模不斷增長，服務間依賴帶來的不確定性指數級增長。軟體可用性面臨兩大挑戰：

1）自身複雜度激增；

2）開發者引入複雜性的同時對風險的低估和忽視；

方法：通過一系列可控實驗和執行實驗原則，揭示出系統中隨時發生的各類事件是如何逐步導致系統整體不可用的。

書籍：《混沌工程：Netflix系統穩定性之道》

工具

Chaos Dingo：支援在Azure相關服務上進行實驗。

Chaos-http-proxy：向http注入故障的代理服務工具。

Tugbot：可在基於docker的生產環境中進行測試的框架。

Chaos Lambda：辦公期間可隨機關閉AWS ASG節點的工具。

Blockade：基於docker，可測試網路故障和網路分區的工具。

Pumba：基於docker的混沌工程測試工具以及網路模擬工具。

Simoorg：LinkedIn開發的故障注入工具，以擴展，很多關鍵組件可插拔。

Chaos Lemur：測試高可用性系統彈性的工具，可本地部署，允許隨機關閉BOSH虛擬機。

Monkey-Ops：Go語言實現，可在OpenShift V3.X上部署並在其中生成混沌工程實驗。可隨機停止OpenShift組件。

ChaosBlade：阿里開源的一款遵循混沌工程原理和混沌實驗模型的實驗注入工具，是內部MonkeyKing對外開源的項目，結合了阿里各業務的最佳創意和實踐。

鏈接：https://github.com/chaosblade-io/chaosblade/blob/master/README_CN.md

背景

由很多微服務組成的分散式系統中，永遠難以全面掌握什麼事件會導致系統局部不可用，甚至全面崩潰。主要因素：

1）系統架構演進：服務集群→分散式→微服務→容器化（K8S&docker）→上雲；

2）版本迭代增速：CICD、敏捷、devops、ABtest；

3）用戶需求變更：複雜化、多樣化、快速化、小眾化；

對系統的要求：擴展性、穩定性、彈性能力、容錯災備能力；

軟體系統現狀：系統複雜性提高、問題定位成本高；

要解決的問題：生產環境下的分散式系統在面對失控條件時依然具備較強的「可觀測性」和故障恢復能力；

主要驗證方式：故障注入；

開展「混沌工程」的意義

開發者的能力和認知水平有邊界，不可能所有的細節都可以預估到，系統很脆弱，各種潛在不可預期的突發事件在所難免。

我們需要在異常觸發之前，儘可能地去篩選出會導致出現有異常問題的、容易造成故障的、系統中明顯裂痕的環節，這也是混沌工程所肩負的意義。

能讓複雜系統中根深蒂固的混亂和不穩定性浮出水面，讓我們更全面了解系統中固有的現象，然後進行及時修復、加固和防患於未然，才能打造更具彈性的軟體工程系統。

思考

1、設計良好的系統，需要考慮哪些因素？

可靠性、安全性、可擴展性、可訂製化、可伸縮性、可維護性、用戶體驗等。

2、混沌工程解決什麼問題？

生產環境下，分散式系統在面對失控條件時是否具備較強的「可觀測性」和故障恢復能力。

3、開展混沌工程要考慮的維度有哪些？

1）建立穩定狀態的假設（清晰可衡量的指標）

2）用多樣的生產事件做驗證（多樣性降低誤差）

3）在生產環境做驗證（真實場景）

4）自動化開展實驗（持續運行）

5）控制最小化爆炸半徑（影響範圍）

4、Netflix開展混沌工程總結的三點經驗

1）建立面向失敗設計和擁抱失敗的技術文化（技術文化）

思想上，引入混沌工程的核心是通過引入一些風險去暴露已有的不易發現的問題，而不是創造問題。這樣有助於問題的發現和處理，降低潛在故障帶來的影響。

2）定義一個清晰可度量的目標（定義目標）

前期：對歷史故障的復現率以及解決率，確保故障改進的有效性；

中期：監控發現率，驗證故障發現能力的全面性和監控的完備程度；

後期：故障的「發現-定位-恢復」市場這種綜合性指標；

3）在控制風險的前提下不斷提升混沌工程效率（技術推廣）

先從簡單的場景開始嘗試，逐漸增加組織對系統的信心（要明白準備工作比落地執行更重要）。

混沌工程是一種實踐思想，方法論，本身不綁定任何工具或者技術。不過在進行推廣和實施時，考慮到真實性、容錯性、開發成本、運維效率等因素，建議復用成熟的開源組件或者商業化工具。