本文來自阿裡巴巴高可用架構團隊進階開發工程師肖長軍（花名穹谷）在 GIAC（全球網際網路架構大會）上的分享，包含三部分内容：（阿裡巴巴中間件公衆号對話框發送“混沌工程”，擷取分享PPT）
- 混沌工程的定義、價值、原則和流程；
- 混沌工程如何在企業中落地，以及 ChaosBlade 和混沌實驗平台 AHAS Chaos 架構設計；
- 結合兩個具體案例介紹了分布式服務下的混沌工程實踐；
大家好，我是來自阿裡的肖長軍，今天給大家分享混沌工程在分布式服務架構下的具體實踐。
先做個自我介紹，我來自于阿裡高可用架構團隊，花名穹谷，做過分布式系統設計和 APM 研發相關工作，現在專注于高可用架構和混沌工程領域，是阿裡雲産品 AHAS 底層技術負責人和開源項目 ChaosBlade 負責人，并且承擔集團内故障演練、突襲演練、攻防演練相關的研發工作。今天分享的内容包含以下三個方面。
先從混沌工程的定義、價值、原則和實施步驟介紹混沌工程，然後分享混沌工程如何在企業中落地，最後介紹分布式服務下混沌工程實踐案例。我們先來看一下什麼是混沌工程。
混沌工程理論一文中提到，其是在分布式系統上進行實驗的學科，核心目的是提高生産環境中系統的容錯性和可恢複性。尼采的這句話: "打不倒我的必使我強大"，也很好的诠釋了混沌工程反脆弱的思想。除了這裡提到的目的，實施混沌工程還有哪些價值呢？
這裡我從四個角色來說明，對于架構師來說，可以驗證系統架構的容錯能力，比如驗證現在提倡的面向失敗設計的系統；對于開發和運維，可以提高故障的應急效率，實作故障告警、定位、恢複的有效和高效性。對于測試來說，可以彌補傳統測試方法留下的空白，之前的測試方法基本上是從使用者的角度去做，而混沌工程是從系統的角度進行測試，降低故障複發率。對于産品和設計，通過混沌事件檢視産品的表現，提升客戶使用體驗。是以說混沌工程面向的不僅僅是開發、測試，擁有最好的客戶體驗是每個人的目标。我們知道，系統發生故障的那一刻不是由你來選擇的，而是那一刻選擇你，你所能做，隻能是為之做好準備。了解了混沌工程的價值，我們再來看一下實施混沌工程的一些原則。
前面 Vilas 老師也提到了，我這裡重點來介紹一下這五項原則。第一條：”建立一個圍繞穩定狀态行為的假說“，其包含兩個含義，一個是定義能直接反應業務服務的監控名額，需要注意的是這裡的監控名額并不是系統資源名額，比如CPU、記憶體等，這裡的監控名額是能直接衡量系統服務品質的業務監控。舉個例子，一個調用延遲故障，請求的 RT 會變長，對上層交易量造成下跌的影響，那麼這裡交易量就可以作為一個監控名額。這條原則的另一個含義是故障觸發時，對系統行為作出假設以及監控名額的預期變化。第二個指模拟生産環境中真實的或有理論依據的故障，第三個建議在生産環境中運作實驗，但也不是說必須在生産環境中執行，隻是實驗環境越真實，混沌工程越有價值。持續的執行才能持續的降低故障複發率和提前發現故障，是以需要持續的自動化運作試驗，最後一個，混沌工程很重要的一點是控制爆炸半徑，也就是試驗影響面，防止預期外的資損發生，後面會介紹控制爆炸半徑的方式。依據這些指導原則可以更有效實施混沌工程，那麼混沌工程的實施步驟是什麼？
主要細分為這 8 步，指定試驗計劃，定義穩态名額，做出系統容錯假設，執行實驗，檢查穩态名額，記錄、恢複 實驗，修複發現的問題，然後做持續驗證。以上是對混沌工程理論相關的介紹，那麼如何在企業中落地混沌工程呢?
我這裡分為三個階段，首先要堅定價值，因為你會受到來自多方面的挑戰，其次引入混沌工程技術，最後在企業中推廣混沌工程文化。在實施混沌工程之前，必須能說清楚混沌工程的價值，而且當受到挑戰時，意志要堅定。
比如來自老闆的挑戰，”如何衡量混沌工程的價值？“，可以向老闆表達出，”從故障的應急效率、故障複發率、線上故障發現數來衡量“等等。是以這些問題自己要想清楚。有了堅定的意志，就要開始落地，首先要先了解自己的系統。
這裡系統成熟度分 5 個等級，也可以說是業務系統所處的階段，列出了每個階段适合什麼故障場景。剛才也有聽衆問，”我的服務就是單點的，還有沒有實施混沌工程的必要？“，有必要，可以實施簡單的實驗場景，比如 CPU 滿載等，來驗證監控告警，如果發現沒有監控告警，就要去推動完善它，然後再推動服務多執行個體部署，通過混沌工程一級一級的去推動系統的演進，最終實作具有韌性的系統。根據系統成熟度了解自己系統所适合的場景，接下來就要選擇一款合适的混沌實驗工具。
這裡列舉了五個次元：場景豐富度、工具類型、易用性等。可以從 awesome-chaos-engineering github 項目查找或者從 CNCF Landscpage 中檢視混沌實驗工具。阿裡今年開源的 ChaosBlade 也已經加入到 CNCF Landscape 中，後面會對此項目做重點介紹，先來看阿裡混沌工程技術的演進。
2012 年阿裡内部就上線了 EOS 項目，用于梳理分布式服務強弱依賴問題，同年進行了同城容災的斷網演練。 15 年 實作異地多活，16 年内部推出故障演練平台 MonkeyKing，開始線上上環境實施混沌實驗，然後 18 年輸出了 ACP 專有雲産品 和 AHAS 公有雲産品，其中 AHAS 旨在将阿裡的高可用架構經驗以産品的形式對外輸出，服務于外部。19 年推出 ChaosBlade 項目，将底層的故障注入能力對外開源，同年也推出混沌實驗平台專有雲版本 AHAS Chaos，接下來重點介紹一下 ChaosBlade 項目。
ChaosBlade 中文名混沌之刃，是一款混沌實驗實施工具，支援豐富的實驗場景，比如應用、容器、基礎資源等。工具使用簡單，擴充友善，其遵循社群提出的混沌實驗模型。
該模型分四次，層層遞進，很清晰的表達出對什麼元件做實驗，實驗範圍是什麼，實驗觸發的比對規則有哪些，執行什麼實驗。該模型簡潔、通用，語言領域無關、易于實作。阿裡集團内的 C++、NodeJS、Dart 應用以及容器平台的實驗場景都基于此模型實作。此模型具有很重要的意義，依據此模型可以更精準的描述、更好的了解、更友善沉澱實驗場景以及發掘更多的場景。依據此模型實作的工具更加規範、簡潔，我們具體看下 ChaosBlade 基于此模型的架構設計。
我将 ChaosBlade 的設計總結為這六點。使用 Golang 建構，實作跨平台，并且解壓即用；工具使用采用 CLI 的方式，使用簡單，具備完善的指令提示；遵循混沌實驗模型定義場景接口，所有場景基于此接口實作，将模型轉換為 cobra 架構所支援的指令參數，實作變量參數化、參數規範化，并且通過實驗模型 Yaml 描述，可以很友善的實作多語言、多領域的場景擴充。而且将整個實驗對象化，每個實驗對象都會有個 UID，友善管理。左下角是 chaosblade 工具的使用事例，可以看出使用簡潔、清晰。介紹完工具設計，我們再來談實施混沌工程很重要的一點，如何控制爆炸半徑，減小實施風險。
環境越往下，實施風險越高，實驗越真實，越具有價值。我們通過兩種方式來控制爆炸半徑，一是實驗場景粒度，從 IDC 到使用者，影響範圍越來越低，另一個是從生産環境隔離出一部分機器，通過錄制流量，對線上流量重放，進行請求打标，實作流量路由到隔離出的環境，對這些機器和請求做實驗，這樣可控制的爆炸半徑更大。
具備了控制爆炸半徑的能力，我們可以通過平台，标準化實驗流程，實作自動化執行。中間部分的圖檔是阿裡雲産品 AHAS Chaos 混沌實驗平台的截圖，該平台将實施混沌工程分為四個階段。首先是準備階段，此階段可以定義監控名額，準備實驗環境等，比如 ChaosBlade 執行 Java 應用實驗，必須先執行 Prepare 操作挂載 Agent，則可放到此階段執行。第二個階段是執行階段，此階段用于執行混沌實驗。第三個檢查階段，用于檢查監控名額，記錄問題等，第四階段是還原階段。此四個階段囊括了前面提到的混沌工程實施的八個步驟，大家看到每個階段下的每項都是一個小程式，大家可以基于規範開發自己的小程式來擴充自身實驗所需要的能力，比如對接自己的業務監控，做實驗前通知等。接下來看一下該平台的架構設計。
這是集團和雲上混沌實驗平台的架構圖，通過流程引擎規範混沌工程實施步驟，對外開放平台 OpenAPI，便于上層業務建設，并且提供小程式的機制，可以對接監控平台或做一些實驗前的準備操作等，将故障注入能力收斂到 ChaosBlade。基于此混沌實驗平台承載了集團突襲演練、攻防演練、新零售演練等業務。此平台已經對外輸出，包含公有雲和專有雲版本，阿裡雲網站搜尋 AHAS 即可。具備了完善的混沌實驗平台，可以在企業中推廣混沌工程文化
比如建立門戶網站，宣傳好的架構，并且推送演練紅黑榜。制訂攻防制度，如故障分、演練分來推動并量化演練。可以設定固定的攻防日，全企業參與，以戰養戰，培養混沌文化。介紹完混沌工程在企業落地的流程，我們最後分享下分布式服務下的混沌工程實踐，先來看一下分布式服務所面臨的問題。
系統日益龐大，服務間的依賴錯綜複雜，很難評估單個服務故障對整個系統的影響，并且請求鍊路長，監控告警不完善，導緻發現問題、定位問題難度增大，同時業務和技術疊代快，如何持續保障系統的穩定性受到很大的挑戰。那麼一個高可用的分布式服務應該具備哪些能力呢？
這裡列舉了分布式系統的高可用原則，前面的講師伍道長提到系統的好模式和壞模式，我這裡列舉出的都是好模式。比如入口請求負載均衡，對異常的節點進行流量排程，通過請求限流來控制通路量，防止打垮系統，提供逾時重試，當單個服務執行個體通路逾時時，可以将請求路由到其他服務執行個體進行重試，梳理強弱依賴，對占用資源高的弱依賴服務進行降級，對下遊出問題的服務進行熔斷等等。還有系統運維方面，系統要做到可監控、可灰階、可復原，具備彈性伸縮的能力，能快速擴容或者線下有問題的節點。這些高可用原則都可以作為混沌實驗場景，從中挑選兩個來講下具體的混沌工程實踐。先來看一下 Demo 拓撲圖。
此拓撲圖來自于阿裡雲 AHAS 産品架構感覺功能，可自動感覺架構拓撲，并且可以展示程序、網絡、節點等資料。這個分布式服務 Demo 分三級調用，consumer 調用 provider，provider 調用 base，同時 provider 還調用 mk-demo 資料庫，provider 和 base 服務具有兩個執行個體，在 AHAS 架構拓撲圖上，我們點選一個執行個體節點，可以到非常清晰的調用關系。我們後面結合這個 Demo 去講解案例。
案例一，我們驗證系統的監控告警性有效性。按照前面提到的混沌工程實施步驟，那麼這個案例執行的實驗場景是資料庫調用延遲，我們先定義監控名額：慢 SQL 數和告警資訊，做出期望假設：慢 SQL 數增加，釘釘群收到慢 SQL 告警。接下來執行實驗。我們直接使用 ChaosBlade 工具執行，可以看下左下角，我們對 demo-provider 注入調用 mysql 查詢時，若資料庫是 demo 且表名是 d_discount，則對 50% 的查詢操作延遲 600 毫秒。我們使用阿裡雲産品 ARMS 做監控告警。大家可以看到，當執行完混沌實驗後，很快釘釘群裡就收到了報警。是以我們對比下之前定義的監控名額，是符合預期的。但需要注意的是這次符合預期并不代表以後也符合，是以需要通過混沌工程持續性的驗證。出現慢 SQL，可通過 ARMS 的鍊路根據來排查定位，可以很清楚的看出哪條語句執行慢。
前面講了一個符合預期的案例，我們再來看一個不符合預期的。此案例是驗證系統異常執行個體隔離的能力，我們的 Demo 中 consumer 調用 provider 服務，provider 服務具有兩個執行個體，我們對其中一個注入延遲故障，監控名額是 consumer 的 QPS，穩态在 510 左右。我們做的容錯假設是系統會自動隔離或下線出問題的服務執行個體，防止請求路由的此執行個體，所有 QPS 會有短暫的下跌，但很快會恢複。這個案例，我們使用阿裡雲 AHAS 混沌實驗平台來執行，我們對 demo-provider-1 注入延遲故障，基于此平台可以很友善的執行混沌實驗。執行混沌實驗後，QPS 下跌到 40 左右，很長時間沒有自動恢複，是以不符合預期，我們通過人工的方式對該異常的執行個體做下線處理，很快就看到，consumer 的 QPS 恢複正常。是以我們通過混沌工程發現了系統問題，我們後面需要做就是記錄此問題，并且推動修複，後續做持續性的驗證。
我這次分享從介紹混沌工程到如何在企業中落地，并且通過具體的分布式服務的例子介紹混沌工程的實踐。我們做一下回顧總結。一是混沌工程是一種主動防禦的穩定性手段，展現了反脆弱的思想；二，落地混沌工程會遇到很多挑戰，堅持原則不能退讓；很重要的一點是實施混沌工程不能隻是把故障制造出來，需要有明确的驅動目标；最後選擇合适的工具和平台，控制演練風險，實作常态化演練。
這個是部門内部部分高可用架構相關的産品圖，以及對應的對外輸出的阿裡雲産品，如包含架構感覺、故障演練、限流降級的 AHAS，具備監控告警和鍊路跟蹤的 ARMS，以及性能測試服務 PTS，歡迎大家使用。我的分享到此結束，謝謝大家。