隨着雲原生概念的興起，越來越多的系統服務在往雲原生演進，在演進階段如何保障系統的穩定性和高可用性，是每個系統負責人都要關注的問題，通過混沌工程可以很好的解決這個問題。ChaosBlade 是阿里巴巴開源的一款混沌工程實驗執行工具，其易用性和豐富的場景受到大家的廣泛關注。本文整理自阿里巴巴技術專家肖長軍（穹谷）在 QCon 全球軟件開發大會（上海站）2019 上的演講，他圍繞雲原生架構介紹了 ChaosBlade 的設計、特性與實踐，以及如何基於 ChaosBlade 搭建一個自動化的混沌實驗平臺。點此下載完整幻燈片。
大家好，歡迎大家來聽混沌專場，我是來自阿里巴巴的肖長軍，花名穹谷，之前對外分享過什麼是混沌工程以及如何實施混沌工程。雲原生和混沌工程在今年都是比較火的概念，混沌工程在阿里巴巴實施也近十年的時間，我今天主要圍繞 ChaosBlade 分享，ChaosBlade 是阿里巴巴在 2019 年 4 月份開源的一款混沌工程的實驗工具，我今天的講的內容包含這三點：一是 ChaosBlade 是什麼，ChaosBlade 的定位及它的特性有哪些，然後再重點會介紹 ChaosBlade 的詳細設計；接下來會介紹 ChaosBlade 在雲原生架構下具體的設計，以及使用案例；最後再分享一下基於 ChaosBlade 搭建的，在阿里雲上輸出的混沌實驗平臺 AHAS Chaos，一個簡單易用的故障演練平臺。接下來我們先來看一下混沌工程在阿里巴巴內部的演進。
在 2012 年阿里內部就上線了 EOS 項目，用於梳理分佈式服務強弱依賴問題，同年進行了同城容災的斷網演練。2015 年實現異地多活，2016 年內部推出故障演練平臺 MonkeyKing，開始在線上環境實施混沌實驗，然後是 2018 年，這一年輸出了兩個產品，一個是阿里雲內部專有云，就專門對專有云，阿里的一些產品做高可用測試的 ACP，還有對外將阿里雲，在阿里的高可用架構經驗輸出的一個 AHAS 應用高可用服務產品，該產品包含架構感知，能自動感知你的架構拓撲，系統拓撲；還有限流降級功能，就是應用防護這一塊；另外一個就是故障演練，也就是 AHAS-Chaos 平臺，後面也會重點介紹。2019 年 4 月份剛纔也提到開源了 ChaosBlade，然後下半年我們開始做專有云的混沌實驗平臺的一個輸出。我們爲什麼要做開源呢？因爲當時已經開源的工具存在以下問題。
例如場景能力分散，大家熟知的 Chaos Monkey，混沌猴子，只殺 EC2 實例；Kube Monkey 只殺 K8s pod。除了能力分散之外，還有上手難度大，因爲不同的工具它的使用方式也不一樣。還有缺少實驗模型，難以實踐，並且場景難以沉澱。這些問題就會導致很難實現平臺化，你很難通過一個平臺去囊括這些工具。我們當時提出了一套混沌實驗模型，很好的解決了這些問題，ChaosBlade 也是基於混沌實驗模型來研發的，而且混沌工程在阿里已實踐多年，所以我們將沉澱的場景開源出來，服務於混沌工程社區。
ChaosBlade 是一款遵循混沌實驗模型的混沌實驗執行工具，具有場景豐富度高，簡單易用等特點，而且擴展場景也特別方便，開源不久就被加入到 CNCF Landspace 中，成爲主流的一款混沌工具。ChaosBlade 這些特點得益於以下這個混沌實驗模型。
此模型很簡潔，這個倒三角模型供分爲四層：第一個是 Target，我們演練的目標是什麼；然後是 Scope，定義了我們實驗範圍；其次是 Matcher，我們實驗場景觸發匹配的規則有哪些；最後一個是 Action，我們執行的實驗行爲，也就是我們要做什麼演練。舉個例子，比如我們要對一臺機器上的 double 應用調用 serviceA 服務做調用延遲實驗。那麼我們來對齊一下實驗模型，首先 Target 就是 double，我們要對 double 服務做演練。Scope 是本機，就是這一臺機器上 double 應用。然後匹配規則是服務名 serviceA，那麼它的 action 是什麼？是延遲，通過實驗模型描述之後，層次清晰，而且該模型覆蓋目前所有的實驗場景。我們再來看一下基於混沌實驗模型 ChaosBlade 目前所具備的場景。
我把 ChaosBlade 的場景分爲四大類，前面這一列綠色字體是項目工程，後面的綠色字體代表已經實現的組件，後面的綠框框起來的白字的，就是它所支持的實驗場景舉例。第一大類場景是基礎資源，包含的實驗場景如 CPU 滿載、內存佔用，網絡延遲，進程 Hang 等。另外一類是應用服務，應用服務的場景取決於你應用的構建語言，我們目前支持的是 JAVA、C++ 和 NodeJS，每一個應用服務下面又細分了這些組件，後面列舉的這些綠色字體的是我們已經支持的組件。再一類場景涉及到容器服務，容器服務的話，我們目前支持 Docker 和 K8s。我們支持的 K8s 場景例如殺 Pod，Kubelet 異常，刪容器等。最後的一類是雲平臺，待實現中。這個是 ChaosBlade 故障場景大圖。在這豐富的場景下，ChaosBlade 的易用性也非常強。
重點介紹一下，ChaosBlade 是個直接下載解壓就可以使用的工具，不需要安裝，然後它支持的調用方式包含 CLI 方式，直接執行 blade 命令，比如這裏舉的做網絡延遲的例子，你添加 -h 參數就可以看到非常完善的命令提示，比如我要一個 9520 端口調用做網絡丟包，對齊前面的實驗模型，我們就可以看到，它的演練目標是 network，它的 action 是丟包，它的 matcher 就是調用遠程的一個服務端口 9520。執行成功後會返回實驗結果，每一個實驗場景我們都會作爲一個對象，它會返回一個實驗對象的 UID，此 UID 用於後續的實驗管理，比如銷燬、查詢實驗都是通過此 UID 來做的。要銷燬實驗，也就是恢復實驗，直接執行 blade destroy 命令就可以了。ChaosBlade 另一種調用方式是 Web 方式，通過執行 server 命令對外暴露 HTTP 服務，那麼在上層，你如果自己構建混沌實驗平臺的話，你直接可以通過 HTTP 請求去調用就可以了。所以說 ChaosBlade 具有很好的易用性，那麼它是如何設計的呢？
我將 ChaosBlade 的設計總結爲這六點。使用 Golang 構建，實現跨平臺，並且解壓即用；工具使用採用 CLI 的方式，使用簡單，具備完善的命令提示；遵循混沌實驗模型定義場景接口，所有場景基於此接口實現，將模型轉換爲 cobra 框架所支持的命令參數，實現變量參數化、參數規範化，並且通過實驗模型 Yaml 描述，可以很方便的實現多語言、多領域的場景擴展。而且將整個實驗對象化，每個實驗對象都會有個 UID，方便管理。這個是 ChaosBlade 的一個整體設計。那麼我們再通過一個例子來看一下 ChaosBlade 如何使用。
這個例子的是主要驗證服務調用數據庫延遲。在講這個例子之前，先看一下右上角 demo 的應用拓撲圖，這個拓撲圖來自於 AHAS 架構感知，從這個拓撲圖中我們可以看出 consumer 服務調用 provider，provider 調用 mk-demo RDS 數據庫，同時也調用下游的 base 服務，這個是三層的微服務調用。這裏我們 provider 服務有兩個實例，所做的實驗就是 provider 調用數據庫 mk-demo 發生延遲。在執行混沌實驗之前，就要有明確的監控指標，因爲執行混沌實驗的步驟包含要執行的實驗計劃是什麼，我們執行的預期是什麼，然後執行實驗，我們執行實驗如果不符合預期，我們的下一步的推進計劃是什麼，後面再做持續的驗證，所以說我們這裏定義了一個監控指標，我們監控慢 SQL 數以及監控報警。那麼我們的期望假設就是慢 SQL 數增加，釘釘羣收到相關的報警信息。我們執行的實驗是對其中一個 provider 服務實例注入調用 mk-demo 數據庫延遲的故障，大家可以看到左下角，這個就是對 demo 數據庫注入延遲的命令，可以看出命令非常簡潔清晰，比如很明確的表達出我們的實驗目標是 mysql，我們的實驗場景是做延遲，後面這些都是這些數據庫的匹配器，比如表，查詢類型，還有控制實驗的影響條數等等。ChaosBlade 可以很有效的控制實驗的爆炸半徑，可以控制到影響的條數，控制影響百分比，而且還有各種匹配器來匹配，控制粒度很細。那麼我執行完這條命令，就開始對這臺機器的 provider 服務注入故障，大家可以看到我注入故障之後，這裏這個圖就是我立刻收到了釘釘的報警，那麼這個 case 是符合預期的 case，但是即使符合預期的 case，也是有價值的，需要相關的開發和運維人員是要去排查延遲的問題根因並恢復。這裏的監控告警使用的是阿里雲的 ARMS 產品，除了監控告警功能，還可以抓取到詳細的鏈路調用堆棧，這裏很清晰的展示出哪條 SQL 語句執行慢。這個是整個的一個 ChaosBlade 使用案例，它可以驗證系統的告警是否有效，開發和運維的響應速度是否達到要求，那麼除了剛纔提到的告警和開發和人員響應速度之外，混沌實驗的價值我總結爲三部分。
第一部分就是人員，人員的話這裏列舉了四個角色，比如對於架構師來說，那麼架構師他要做系統設計，比如設計高容錯的系統或者是面向失敗的系統，那麼可以通過混沌工程去驗證系統的韌性和容錯容災的能力。對於開發和運維來說，通過混沌工程，可以提高故障的應急效率，或完善排查問題的工具。對於測試來說的話，之前的測試涉及到從功能測試、性能測試，這些都是從用戶的角度去來測試系統的。那麼通過混沌工程可以從系統的角度來驗證系統中潛在的問題，可以提早暴露線上的問題，然後降低故障的複發率。對於產品和設計來說，他們可以通過混沌工程來演練頁面上的一些事件，比如商品詳情頁，哪項出現問題，用戶體驗度如何。所以說混沌工程是適用於每一個人的。另一部分是系統，系統的話，前面也提到了可以通過混沌工程提升系統的容錯、容災能力。還有就是基礎能力和運維高可用，就是通過混沌工程去驗證你的基礎服務，比如你的監控體系，你的告警體系，是不是高可用的，如果這些不是高可用的，那麼當故障出現的時候，你有可能不能及時發現系統的故障，不能及時收到故障報警，排查問題也有可能遇到阻礙，所以說你要保證你的基礎設施是高可用的，它可以通過混沌工程去驗證你這些基礎服務。最後一個是流程，就通過混沌工程，你可以驗證整個故障發生的處理流程，比如阿里的話，故障都有明確的等級劃分，通過混沌工程可以推進故障等級的劃分，驗證你的聯繫人的有效性，比如經過多年有可能這些人都離職了，但是他還在告警聯繫人裏，該在的而不在，這都是問題。這是在流程方面，除了故障應急還有一個故障管理，故障管理的話主要是做故障沉澱，後面的話故障統計以及故障覆盤，以及故障場景沉澱，持續做演練，防止故障再次發生。這裏是對混沌工程價值的一個總結，除了這些，在雲原生時代，混沌工程的價值是什麼？
我們在講價值之前先看一下目前雲原生架構所包含的技術及相關的穩定性挑戰。以下列舉了雲原生相關的技術。
雲設施指公有云、專有云和混合雲等，是雲原生系統的基礎設施，基礎實施的故障可能對整個上層業務系統造成很大影響，所以說雲設施的穩定性是非常重要的。容器服務的挑戰可以分兩大類，一類是面向 k8s 服務提供商，服務是否穩定，另一類是面向用戶，配置的擴縮容規則是否有效，實現的 CRD 是否正確，容器編排是否合理等問題。微服務，分佈式服務的複雜性，單個服務的故障很難判斷對整個系統的影響；service mesh，sidecar 的服務路由、負載均衡等功能的有效性，還有 sidecar 容器本身的可用性。serverless，現在基本上都是函數加事件的形式，資源調度是否有效，而且 serverless 服務提供商屏蔽了一些中間件，你能掌控的是函數這些服務，那麼你可以通過混沌工程去驗證你函數調用的一些配置，比如超時配置，還有相關的一些降級策略，這些是否合理。以上這些雲原生架構穩定性相關的挑戰，再來看雲原生本身的的特點，談到雲原生，可以說雲原生是一個理念，包含我這裏列舉的雲原生相關的技術，但是他們都有相同的共性，比如彈性可擴展、鬆耦合、容錯性高、還有一些易於管理，便於觀察這些特性。所以說在雲原生時代，混沌工程對雲原生系統的價值我總結爲——雲原生時代下，通過混沌工程能推進系統”雲原生“化。
這句話的意思就是能讓你的系統通過混沌工程能達到雲原生的極致，就是剛纔提到的那些特點，具有非常高的容錯能力，具有非常高的彈性。這是我對混沌工程在雲原生架構下價值的總結。
我們再來看一下 ChaosBlade 在雲原生架構下場景的實現方案。
ChaosBlade 通過 Operator 創建了自定義控制，通過 Helm 等方式可一鍵安裝，用來管理實驗資源對象，大家可以看到左邊這些聲明式的實驗場景配置，它也是嚴格遵循前面的混沌實驗模型，配置非常的方便。這裏舉個例子，比如我對集羣中的節點做負載實驗，負載 50%，那麼我就可以定義好這個資源，通過 kubectl 去執行。也可以使用 chaosblade 自身的 blade 命令去執行。ChaosBlade Operator 除了定義控制器之外，會以 daemonset 的方式在每個節點上部署一個 chaosblade-tool pod 來執行混沌實驗。不同的實驗場景內部實現方式不同，比如 Node 實驗場景，其上面部署的 chaosblade-tool 內部執行即可，而 Container 內的實驗場景，控制器會將 chaosblade 包拷貝到目標 Container 中執行。技術實現核心的話就是將混沌實驗定義爲 K8s 資源，傳遞給 operater 來識別並執行資源。這個是 ChaosBlade 的一個整體的實驗方案。ChaosBlade 非常友好的支持 K8s 實驗場景，目前包含 Node、Pod、Container 資源場景。我們來看具體的一個案例。
這個例子是隨機刪除業務 Pod，然後驗證業務的穩定性，右邊是對實驗場景 yaml 描述，這裏的 case 是隨機篩選實例進行刪除，每一個服務只殺一臺實例，通過 system=demo 標籤隨機的篩選這些服務實例，然後指定刪除的每個服務 Pod 實例數量。可以看到我這邊的監控指標是業務指標，就是下方的頁面截圖，另一個是 Pod 數。這裏的期望假設是業務不受影響，Pod 的副本數在預期之內。這是一個實驗假設。我們來看實驗的結果。我執行完實驗之後，我通過查詢 Pod 來驗證，然後大家可以看到每一類服務，它會被刪掉一個 Pod 實例，然後會被 K8s 重新拉起。但是刪不是我們的目的，混沌工程有一點非常重要，就是我們做故障演練的目的不是觸發故障，我們目的是通過故障來驗證系統的架構的缺陷，發現問題並迭代修復這些缺陷，來提高系統的韌性。所以說我們這邊要去驗證這個結果。這邊是拿 K8s 官方的一個 guestbook 這個 demo 去做的演示，那麼我執行完這個實驗之後，大家可以看下方截圖，整個實驗的前後的頁面展示是不一樣的，之前提交的數據不存在了。那麼這個 demo 就存在數據持久化高可用的問題。我後面分析了一下，它爲什麼會造成這個問題，因爲如果刪除掉 master 之後，它沒有做數據持久化存儲，你前面提交的這些數據就會丟失。它會把數據同步到 slave 節點，由於沒有數據，它會覆蓋掉原有保存的這些數據。所以說大家通過這個 case 可以看到，隨機殺 Pod 去可以驗證你整個的業務的穩定性和容錯能力，這個 case 是不符合我們預期的，所以說我們後面要去推動業務，去修復，去完善這個問題。前面是對 ChaosBlade 的整體介紹，包括什麼是 ChaosBlade，ChaosBlade 的易用性，ChaosBlade 支持哪些場景，ChaosBlade 的架構設計，還有拿具體的案例去講混沌工程的價值，然後包括 ChaosBlade 在面向雲原生的系統，我們該如何去做。接下來我們講一下混沌實驗平臺。爲什麼要做平臺？因爲前面也提到了混沌實驗執行步驟，你執行混沌工程，很重要的一點是要做持續化驗證，如果只是工具的話，那麼你很難去做自動化的持續驗證，所以說你需要使用平臺。這裏重點介紹一下阿里雲 AHAS 這個雲產品下面的 AHAS Chaos 故障演練平臺。會先介紹平臺的設計理念，然後拿一個案例去講該如何去使用。
我們先來看一下 AHAS Chaos 平臺設計理念。AHAS Chaos 具有開放性，它可以集成和被集成，它可以通過小程序來拓展，可以集成別的服務，比如你可以調用第三方監控，或者你自身的服務來做一些事前的準備，或者是做一些結果驗證，這是它的集成能力。它的被集成就是它提供一些 OpenAPI，你可以基於這些 OpenAPI 去查詢、創建、執行混沌實驗，而且你可以基於它去做一些自己業務相關的一些處理。這個是被集成。操作簡潔，它把整個的前面提到的混沌實驗執行的步驟，它分成了四個階段。第一個階段就是準備階段，比如我可以做一些事情的準備，還有執行階段，就是執行實驗。檢查階段就是做驗證，還有恢復階段。所以說操作是非常簡潔。而且前面提到的那些實驗場景，會有很多參數，那麼你要通過 ChaosBlade 的話，你要查這個命令幫助才能看到這些實驗參數是什麼，平臺的話它會自動解析出這個參數來展示，並有詳細的說明，你只需要下拉框選擇或自己填就可以了，它的操作非常簡潔。編排靈活，它具有拖拽的一些編排能力。還有專家經驗，就是我們把一些我們內部的，或者是雲上的一些高考用的經驗，會通過引演練模板的形式給提供給大家，大家可以套用這個模板來進行相關的實驗。這個是 AHAS Chaos 平臺設計理念。我們再來看一下 AHAS Chaos 平臺的架構設計。
這個是 AHAS Chaos 平臺架構圖，你可以部署在阿里雲的 ACK 或自建的 K8s 集羣，以及 ECS 或非 ECS。基於 AHAS 底座運行，前面也提到了，AHAS Chaos 有小程序的能力，你可以自定義擴展，它底層集成了 ChaosBlade，具有 ChaosBlade 這些豐富的場景。在往上平臺模塊，前面也提到了它的演練管理，演練運行，還有演練空間、演練計劃、演練報表等，這些平臺都是提供功能。然後它的開放式的能力，它開放 openAPI，你可以基於這個平臺去構建自己的平臺，比如這裏提到的阿里巴巴目前的演練，第一個日常演練，就是你可以做一些服務的日常演練，那麼你也可以做突襲，所謂突襲的話就是在不通知業務方的情況下，去對他們的系統注入故障，來驗證他們故障的告警、故障的響應速度、故障的恢復能力，這是突襲演練。攻防演練的話就是大家商量好，一起來做一個攻防對抗。這是攻防演練。還有資損演練、上雲演練等。這是 AHAS Chaos 平臺的架構設計。下面我們通過一個 case 來分享平臺的使用。
面向於原生架構的一個 AHAS Chaos 平臺使用的例子，右下角的話是寵物商店的 Demo，右上方是這個 Demo 的架構拓撲圖，是基於 AHAS 產品架構感知的能力，此產品一鍵安裝，安裝完之後，不需要做任何事情，它就會自動感知出整個系統應用的架構拓撲圖，還有非常詳細的進程、網絡、機器、容器等信息。所以說這邊的話，我通過 AHAS 架構感知去做一個數據庫延遲實驗，驗證 Pod 的水平擴容能力。Demo 運行在阿里雲 ACK 上，對 provider Pod 數據庫做網絡延遲實驗，然後去驗證預期。發生了網絡延遲，一個具備容錯能力的系統，它會水平擴展新的 Pod。因爲數據庫延遲之後，RT 會升高，RT 升高之後就會影響用戶，那麼一個容錯的一個韌性比較好的系統，它會水平擴展 Pod，來降低這個延遲的負載，把原有 Pod 隔離或者是刪除掉。所以監控指標就是 RT 和 Pod 數，我期望的假設是 RT 會短暫的升高，但是很快會恢復。左下角是 AHAS Chaos 平臺頁面，大家可以看到，通過平臺可以把這些參數暴露出來，你只需要去做簡單的配置就可以了，無需去寫 Yaml 文件。平臺還提供了演練編排和演練計劃，你只需要保存這個實驗，點擊立即運行，就可以方便的去執行實驗，你可以結合架構感知驗證 Pod 容器的變化。這是對 AHAS Chaos 故障演練平臺的介紹。
右上方的圖片是 ChaosBlade 的開源討論羣和應用高可用服務（AHAS）的交流羣，這兩個都是釘釘羣。ChaosBlade 的一些技術文檔也都會在羣裏分享，關於 AHAS 的問題可以在羣裏諮詢。
以上是我對今天分享的總結。基於實驗模型實現的 ChaosBlade 不僅場景豐富，而且使用簡單，很友好的支持雲原生場景。如果企業想去試用或者是落地混沌工程的話，AHAS Chaos 是個不錯的選擇。
以上就是我這次的分享，謝謝大家。
演講嘉賓：肖長軍，阿里巴巴技術專家，花名穹谷，多年應用性能監控研發和分佈式系統高可用架構經驗，現專注於混沌工程領域，具備多年混沌工程研發和實踐經驗。開源項目 ChaosBlade 的負責人，阿里雲應用高可用服務（AHAS）和應用服務發現（APDS）產品研發，混沌工程佈道師。
活動推薦
QCon 北京 2020 精彩繼續，大會策劃了業務中臺、AIOps、基礎設施、雲原生、微服務、實時計算、邊緣計算、雲時代架構演進、人工智能、數據架構等多個專題，點擊瞭解詳情。