混沌工程 ChaosMeta 的全新版本 V0.5 現已正式發佈！該版本包含了許多新特性和增強功能，為用户提供了支撐混沌工程各個階段的平台能力，以及降低使用門檻的用户界面。

ChaosMeta V0.5 核心新特性介紹

當前版本主要是發佈了平台界面組件（chaosmeta-platform）、度量組件（chaosmeta-measure-operator）以及流量注入組件（chaosmeta-flow-operator）。

▌平台界面

提供產品層操作界面方便用户更友好地使用 ChaosMeta 產品功能，當前產品層功能主要有：

1. 空間管理：根據組織或活動隔離數據，確保數據的安全性和隱私性。
   
2. 用户權限管理：為不同角色提供訪問權限的控制，可有效管理混沌工程實驗的使用。
   
3. 編排實驗：通過拖拉拽可視化操作，使實驗編排更加友好和靈活，提高用户的工作效率。
   

4. 實驗結果：提供實驗執行詳情的追溯功能，讓用户隨時瞭解實驗的執行情況和結果，方便用户進行數據分析和決策。
   

   ▌度量引擎

   當前包括 4 種度量能力：

   • monitor：對監控項的值進行預期判斷，比如某個機器的 cpu 使用率監控值是否大於90%，默認支持prometheus
   • pod：對 pod 相關數據進行預期判斷，比如某個應用的 pod 實例數是否大於3
   • http：對 http 請求進行預期判斷，比如進行指定的 http 請求時，返回狀態碼是否為200
   • tcp：對 tcp 請求進行預期判斷，比如測試某個服務器的 8080 端口是否能通

   ▌流量引擎

   當前流量注入的能力只實現了 HTTP 流量類型的注入，後續會逐步補充 RPC、DB client、redis client 等其他類型的流量注入能力。底層實現是基於開源組件 jmeter 實現的，每個流量注入任務啓動一個 jmeter 的 job 執行。
   

   ChaosMeta 核心設計理念

   ChaosMeta 設計上主要是想要解決下面幾個業界內普遍存在的問題：

   混沌工程演練各個階段的能力整合

   當前業界主流混沌工程項目主要都是隻關注如何製造故障的問題，而經常做演練相關工作的工程師，應該明白每次演練還有以下重複性工作的痛點：檢測當前環境是否符合演練預設條件（演練准入）、業務流量是否滿足（流量注入）、注入後判斷故障效果是否符合預期（故障度量）、是否在預設時間內恢復了業務服務（恢復度量）、覆盤分析總結風險點。
   基於業界現狀和上面的問題分析，結合螞蟻集團在混沌工程領域的多年經驗，ChaosMeta 平台從設計上覆蓋了“准入檢測”、“流量注入”、“故障注入”、“故障度量”、“恢復度量”、“注入恢復”等各個階段的技術支撐，解放各階段的人力。
   

   故障實驗設計的經驗可複用性

   我們在做混沌工程演練前，還有一個會消耗大量人力的工作，那就是在演練實驗的設計上。這一部分當前主要還是得依靠人的設計能力，目前很難完全依賴機器去自動設計。但是我們可以把其中的可複用經驗系統化抽象出來，整理成冊，在對同一類組件進行混沌工程演練的時候，就可以快速複用起來，這個就是風險目錄的設計初衷。
   風險目錄前期主要是以理論的方式開源，後期會以平台能力的方式內置到 ChaosMeta 項目中。
   

   雲原生基礎設施的環境複雜性

   當前大部分公司的基礎設施環境都是在 Kubernetes 上的，無論是雲自身還是雲原生應用的穩定性都是至關重要的，傳統的故障注入手段可能難以解決問題。為此我們希望 ChaosMeta 能從設計上解決以下問題：

   對 Kubernetes 自身穩定性的故障注入能力

   主要是圍繞 Kubernetes 自身的穩定性，比如 APIServer、Scheduler 等核心組件，各類資源的狀態異常處理流程，Operator 應用的異常等- 平台支持雲原生部署ChaosMeta 設計上是基於 operator 開發的雲原生架構（詳見用户文檔），因此天然支持雲原生環境的部署
   

   平台支持管理雲上容器並進行故障注入

   如果使用傳統的方式對容器進行故障注入，需要把單機故障注入工具傳輸到目標容器內並執行命令，但是一般的業務容器的基礎鏡像都是極簡版的，很多命令工具比如 tc、fallocate等都不支持，導致容器故障注入被環境因素受限過大。ChaosMeta 使用“容器化注入”的方式對集羣內的 Pod 以及 Node 進行故障注入，單機故障注入工具chaosmetad 支持對宿主機上的容器進行故障注入，而不需要把 chaosmetad 拷貝到容器內，通過在宿主機上選擇性進入目標容器的目標 linux namespace，達到使用宿主機的工具對容器的相應 namespace 產生異常的效果
   

   平台支持管理雲下容器並進行故障注入

   每個公司都還有很多還沒上雲的業務，這類業務要麼是在普通的物理機/虛擬機上部署，要麼是在此基礎上裸容器啓動的（比如 docker 容器）。這個時候也需要平台能支持管理這部分集羣外的目標，ChaosMeta 的單機故障注入工具 chaosmetad 支持以 agent 模式啓動，定時上報機器的容器信息到平台中，平台可以直接選擇集羣外的目標下發故障注入任務。
   

   多集羣管理

   雖然我們推薦每個集羣部署一個管控平台，但是仍然有很多用户換機是希望能集中式管理的，ChaosMeta 的平台能力設計上也是支持管理不同集羣的 kubeconfig 以及跨集羣進行故障注入的。

   可自動化的道路

   平台技術的最後目標都是希望能解放人力，往自動化、智能化的方向演進的，或許當前還沒能完全做到，但是至少需要走在正確的道路上。
   ChaosMeta 的自動化混沌工程思想主要是以混沌工程演練的各階段平台能力為技術支撐，“風險目錄”作為理論支撐，使 ChaosMeta 朝着自動化混沌工程的方向逐步演進。

   2023 年 roadmap

   今年的目標主要是把平台能力進行完善，並且各階段的基本能力都補全，還會跟其他開源社區（比如 OceanBase、SOFA 等）進行進一步的合作，爭取達到 1.0 完整版。

   平台能力

   • 支持全部編排節點類型的能力
   • 內置一些開源組件的通用實驗模板
   • 提供 Agent 管理界面，管理雲上以及雲下的物理機以及容器
   • 支持跨集羣管理

   各階段基本能力

   • 流量注入能力，基於 jmeter 提供更多的流量注入能力
   • 度量能力，提供更多雲原生方向的狀態度量能力
   • 故障注入能力，主要往組件級別的故障注入能力上演進，比如集成對 OceanBase、MySQL、Redis、Etcd 等開源組件的故障注入能力
   • 風險目錄正式對外開源理論版本，內置到 ChaosMeta 平台中的能力主要以上述的“通用實驗模版”以及“組件級別的故障注入能力”兩種方式。

   加入我們

   作為一個開放的項目，我們認可開源的研發模式，並致力於將 ChaosMeta 社區打造成一個開放和有創造力的社區。後續，所有的研發、討論等相關工都會在社區透明運行。
   我們歡迎任何形式的參與，包括且不限於提問、代碼貢獻、技術討論、需求建議等。期待收到社區想法和反饋，以推動項目往前進一步發展。
   如果對我們的項目或者設計理念感興趣，請 star 我們的項目給予支持。

   項目 GitHub 地址：https://github.com/traas-stack/chaosmeta
   官方文檔：https://chaosmeta.gitbook.io/chaosmeta-cn

微信羣：請添加負責人好友（微信號：KingsonKai）邀請入羣

釘釘羣：21765030887

也歡迎大家關注 ChaosMeta 公眾號，項目最新動態我們都會在這裏發佈。