這是一篇較為詳細的混沌工程調研報告，包含了背景，現狀，京東混沌工程實踐，希望幫助大家更好的了解到混沌工程技術，通過混沌工程實驗，更好的為系統保駕護航。
一、概述
1.1 研究背景
Netflix 公司最早系統化地提出了混沌工程的概念。2008 年 8 月，Netflix 公司由于資料庫發生故障，導緻了三天時間的停機，使得 DVD 線上租賃業務中斷，造成了巨大的經濟損失。于是 Netflix 公司開始嘗試利用混沌工程優化穩定性保障體系。2010 年，Netflix 公司開發了混沌工程程式 Chaos Monkey，于 2012 年在 Simain Army 項目中開源，該程式的主要功能是随機終止在生産環境中運作的虛拟機執行個體和容器，模拟系統基礎設施遭到破壞的場景，進而檢驗系統服務的健壯性。2019 年，阿裡巴巴開源了 ChaosBlade 混沌工程程式，該程式可以結合阿裡雲進行混沌工程實驗。2020 年，PingCap 作為國内優秀的資料庫領域開源公司，開源了其公司内部的混沌工程實踐平台 ChaosMesh。
基于以上開源項目，混沌工程項目在國内受到了多家公司的關注，越來越多的公司開始引入混沌工程進行系統穩定性保障工作，通過混沌工程主動注入故障的方式，避免軟體系統帶來的未知危機。圖 1.1 展示了軟體系統穩定性危機與對策發展時間線的對應關系，可以發現，随着軟體系統規模的擴大，系統複雜度的增長及開發周期縮短，陸續爆發了多次軟體危機，同時，每次的軟體危機都促進了軟體系統穩定性保障措施的不斷完善。而當下的軟體系統的規模，複雜度和開發靈活程度再次邁入了一個新的階段，導緻系統的穩定性面臨着新的挑戰。此時，主動發現系統穩定性缺陷的混沌工程應運而生，再次彌補了當下系統穩定性保障方式的短闆。
圖 1.1 軟體系統穩定性危機和對策發展時間線圖 [來源：中國資訊通信研究院]
1.2 研究目的
塔勒布曾經在《反脆弱》一書中闡述了 “系統如何在不确定性中獲益” 的思想，混沌工程基于這一偉大思想，提倡使用一系列實驗來真實地驗證系統在各類故障場景下的表現，通過頻繁地進行大量實驗，使得系統本身的反脆弱性持續增強。每一次故障中的獲益，讓系統不斷進化，形成正向循環，逐漸提高系統的品質，保證系統的健壯性。是以，混沌工程研究的首要目的就是主動發現系統的穩定性缺陷。表 1-1 列舉了近幾年比較嚴重的幾個系統穩定性故障事件，從側面反映了系統穩定性保障的重要性。
表 1-1 系統穩定性故障事件
| 公司名稱 | 發生時間 | 持續時長 | 影響範圍 | 故障原因 |
| 哔哩哔哩 | 2021 年 7 月 | 約 1 小時 | 影響了視訊播放、直播等多個核心服務 | 機房故障，災備系統失效 |
| 滴滴 | 2021 年 2 月 | 約 1 小時 | 滴滴打車 APP | 系統内部錯誤 |
| 谷歌 | 2020 年 12 月 | 約 1 小時 | 谷歌旗下多個業務 | 存儲超出限額 |
| 亞馬遜 | 2020 年 11 月 | 約 5 小時 | 部分伺服器無法通路 | 不當的運維操作觸發了系統漏洞 |
| 微軟 | 2020 年 9 月 | 約 5 小時 | Microsoft Office 36 辦公軟體和 Azure 雲産品 | 流量激增導緻服務中斷 |
當混沌工程成為常态化的系統穩定性的保障手段後，系統的整體穩定性将得到進一步提升。通過混沌工程平台，主動向系統注入故障，驗證和評估系統抵抗故障并保持正常運作的能力，提前識别未知的缺陷并進行修複，保障系統更好得抵禦生産環境中的失控條件，有效提升系統的整體穩定性。
1.3 研究意義
混沌工程的主要研究意義在于提高系統的穩定性，通過主動向系統中注入故障的方式，研究和提高系統的健壯性，在一定程度上彌補了系統發生故障時被動響應的短闆，降低了系統應對故障的風險和成本。表 1-2 列舉了使用混沌工程前後的系統穩定性保障方式的對比，可以發現，使用混沌工程後，系統穩定性的保障方式更加出色。
表 1-2 使用混沌工程前後的系統穩定性保障方式對比
| 對比内容 | 使用混沌工程前 | 使用混沌工程後 |
| 發現缺陷的方式 | 線上缺陷發生時才開始識别 | 主動注入故障發現系統缺陷 |
| 應對缺陷的方式 | 被動響應，缺陷應對的開始時間取決于故障何時發生 | 主動響應，缺陷應對的開始時間取決于混沌工程的實驗時間 |
| 識别缺陷的效率 | 較低，對于觸發條件苛刻的潛在缺陷可能需要很長時間 | 較高，通過主動注入故障，使得潛在缺陷盡快暴露 |
| 響應缺陷的成本 | 可控性較差 | 可控性良好 |
另外，實踐混沌工程對不同職位的從業人員也有着各自的意義。如表 1-3 所示，混沌工程有助于幫助系統相關人員發現潛在的脆弱點，降低系統穩定性缺陷可能造成的損失。同時，通過混沌工程注入故障，可以有效鍛煉團隊發現和定位問題并快速恢複系統的能力。
表 1-3 實踐混沌工程對不同職位的意義
| 職位 | 實踐混沌工程的意義 |
| 軟體開發工程師 | 進一步加深對系統的了解，驗證系統架構的容錯能力 |
| 測試開發工程師 | 彌補傳統測試方法留下的空白，更主動的方式發現系統的問題 |
| 運維開發工程師 | 提高系統故障的應急效率，實作故障告警、定位、恢複的有效應對 |
| 産品經理 | 了解産品在突發情況下的表現，提升客戶在突發情況下的産品使用體驗 |
1.4 研究方法
圖 1.2 混沌工程實踐體系和軟體開發一般流程聯系圖 [來源：中國資訊通信研究院]
根據調研的混沌工程實踐經驗，混沌工程的研發方法可以概括為圖 1.2 中的混沌工程實踐體系。其中，混沌工程實踐配套是混沌工程成功實踐的關鍵，是以要求實踐團隊做好混沌工程實踐的戰略規劃，培養混沌工程實踐相關人員，形成混沌工程文化，識别應對潛在的風險并對混沌工程實踐做出有效的評估。
在此基礎上，混沌工程實驗是混沌工程研究的核心工作，即混沌工程以實驗為最小單元研究發現系統的穩定性缺陷，實驗的一般流程是：實驗設計、實驗實施和結果分析。具體内容一般包括：實驗需求和對象、實驗可行性評估、觀測名額設計、實驗場景環境設計、實驗工具平台架構選擇、實驗計劃和溝通、實驗執行及名額收集、環境清理與恢複、實驗結果分析、問題追蹤、自動化持續進行驗證。當通過混沌工程發現了系統穩定性缺陷時，需要根據實際情況給出對應的解決方案，如果存在架構的缺陷，則需針對性得采用韌性設計對穩定性缺陷進行改進，其他如邊界條件和極端情況未考慮或者編碼錯誤的缺陷，若占比較高且反複出現，則需要評估是否需要在制度規範上對軟體開發過程進行更好的管控。
關于更加具體理的論和混沌工程的一般實驗步驟，可以從該書《混沌工程：Netflix 系統穩定性之道》中擷取到，電子版書籍見本報告附錄。該書對混沌工程進行了非常詳細的闡述，圖 1.3 為該書的目錄結構。
圖 1.3 《混沌工程：Netflix 系統穩定性之道》目錄
二、研究現狀
2.1 業界混沌工程工具
目前業界使用的混沌工程工具的種類很多，表 2-1 彙總了本次調研中發現的業内保持維護更新的幾個工具，不同工具側重于不同種類的故障注入。
表 2-1 混沌工程工具彙總
| 工具名稱 | 最新版本 | 核心語言 | 包含場景 | 特定依賴 |
| ChaosBlade | 1.7.0 | Go | 實驗架構，支援系統資源、網絡、應用層面等多種故障的注入 | 無特定依賴 |
| ChaosMesh | 2.3.1 | Go | 實驗架構，支援系統資源、網絡、應用層面等多種故障的注入 | 依賴于 K8s 叢集 |
| ChaosToolkit | 1.12.0 | Python | 實驗架構，可內建多個 IaaS 或 PaaS 平 台，可使用多個故障注入工具定制場景， 可與多個監控平台合作觀測和記錄名額資訊 | 通過插件形式支援多個 IaaS、PaaS，包括 AWS/Azure/Goog le/K8s |
| orchestrator | 3.2.6 | Go | 純 MySQL 叢集故障場景 | 無特定依賴 |
| powerfulseal | 3.3.0 | Python | 終止 K8s、Pods，終止容器，終止虛拟機 | 支援 OpenStack/AWS/ 本地機器 |
| toxiproxy | 2.5.0 | Go | 網絡代理故障，網絡故障 | 無特定依賴 |
2.2 業界混沌工程實踐平台
業内的混沌工程平台一般由：使用者界面、任務排程子產品、故障注入、監控告警系統四個部分組成。
使用者界面： 為實驗平台提供混沌工程實驗任務的編排和配置服務，使得使用者友善管理各類混沌工程實驗任務。當混沌工程實驗開始後，使用者可以通過任務進度條、伺服器名額等展示圖實時的檢視實驗進度和系統名額情況。當混沌工程實驗結束後，使用者可以看到最後的混沌工程實驗報告。
任務排程子產品： 該子產品負責使用者界面和故障注入之間的互動，核心功能是實作混沌工程任務的批量下發和排程。
故障注入： 故障注入負責接收任務排程子產品下發的故障注入任務，實作相應的故障注入事件，并回報故障注入任務的執行狀态。
監控告警系統： 該系統負責記錄和管理系統産生的所有資料，生成告警和相關統計并回報給使用者。
2.3 混沌工程實踐能力評估
混沌工程實踐能力的評估可以幫助團隊更好地了解混沌工程實踐的狀況，表 2-2 列舉了混沌工程實驗成熟度的等級，該等級可以用來評估目前系統進行混沌工程實踐的能力，主要反映執行混沌工程實踐的可行性、有效性和安全性，等級越高則說明可實踐混沌工程的能力越強。
表 2-2 混沌工程實驗成熟度等級
三、京東混沌工程實踐
泰山混沌工程平台是基于業界成熟解決方案 ChaosBlade 并結合京東業務特色設計并落地實作的一款自助式故障演練平台。使用者可根據自身服務特點有針對性的場景編排、故障注入，對服務容災能力進行評估，通過實驗探究的方式建立對系統行為重新的認知了解。推動建立混沌文化，通過主動探索的方式發現系統中潛在的、可以導緻災難的、讓我們的客戶受損的脆弱環節，消滅它們，讓我們的系統更加健壯有韌性。
圖 3.1 展示了泰山混沌工程演練的流程圖，基于泰山混沌平台，紅方的任務是：
（1）建立演練計劃：通過通路泰山平台，進入路徑：安全生産 - 混沌工程頁面，頁面提供 “建立演練計劃” 按鈕，點選即可進入演練配置頁面。
（2）演練配置：點選建立演練計劃按鈕後，進入演練配置頁面，可錄入演練基本資訊及任務配置項（演練配置 - 應用相關（類型、方式、場景）、演練配置 - 執行相關），圖 3.1 中紅色字型為本次演練重點配置項。
（3）執行演練：演練任務建立儲存後，生成一條待執行的演練任務，手工點選執行按鈕執行演練。
藍方的任務是：
（1）故障排查：在演練執行中，藍方通過報警資訊，先下掉報警機器，進行排查。
（2）恢複方案：演練中發現問題要及時恢複，演練後要重新開機恢複演練機器，確定機器正常運作
實驗完成後需要進行演練複盤，即對演練中發現問題總結及分析，確定不再出現類似風險問題。
圖 3.1 泰山混沌工程演練流程圖【來源：全管道混沌工程實踐文章】
3.1 核心能力
平台的核心能力可以用四化一靈活概括，即：
一、自動化：演練過程全程自動排程、插件部署、故障注入、現場恢複。
二、可視化：演練期間，可實時觀測 MDC 名額變化、UMP 業務監控名額變化以及故障注入進度等。
三、精準化：可通過指定 IP、分組、機房、網絡 POD，針對演練影響範圍進行明确限制，演練效果更貼合實際場景。
四、規模化：平台設計目标支援單任務 1000 + 演練目标、多演練任務同時排程的能力，為集團範圍内各種預案演練、攻防演練、常态化混沌測試提供強有力的支援。
五、靈活控制：在演練過程中可靈活進行取消、終止、全部終止等操作；針對故障場景可多元度進行配置提調整；演練時長、排程方式執行時可調整。
3.2 支援故障注入類型
泰山混沌工程實驗平台支援豐富的混沌場景能力，表 3-1 列舉了平台支援的基礎資源類故障場景，主要驗證基礎資源或者業務監控告警的及時性、有效性（幹預手段），進而優化資源規格、部署規模和跨機房部署，同時希望增加程序存活、URL 存活的監控。表 3-2 列舉了平台支援的 JAVA 程序故障和中間件依賴故障場景，主要驗證業務、JVM 監控告警的及時性、有效性（幹預手段），進而調整 JVM 參數、使用合理垃圾回收器等，同時調整中間件叢集配置、治理降級方案、優化緩存政策等，通過演練也可以進一步了解系統架構，梳理強弱依賴、治理服務性能和評估下遊服務能力。
表 3-1 基礎資源類故障場景
| 混沌場景 | 演練目的 | 實作原理 |
| CPU 高負載 | 關注對業務處理吞吐率的影響 | 消耗 CPU 時間片 |
| 記憶體占用 | - | 采用代碼申請記憶體實作 |
| 磁盤 IO 高負載 | 評估對磁盤讀寫敏感的業務的影響 | 使用 dd 指令實作 |
| 磁盤填充 | 主要驗證如日志目錄打滿對服務的影響 | 使用 fallocate、dd 指令實作 |
| 網絡延遲 | 評估業務對網絡延遲的容忍程度，評估逾時、重試機制設定是否合理，防止級聯事故 | 使用 tc 指令實作 |
| 網絡丢包 | 評估業務對網絡丢包的容忍程度 | 使用 tc 指令實作 |
| 程序假死 | 觀測負載均衡時效性、業務敏感性 | kill -STOP {pids} |
| 程序終止 | 觀測負載均衡時效性、業務敏感性（Nginx&Tomcat） | kill -9 {pids} |
表 3-2 JAVA 程序故障和中間件依賴故障場景
| 類型 | 混沌場景 | 演練目的 |
| JAVA 程序故障 | 程序 CPU 滿載 | 評估服務節點 CPU 滿載時對服務的影響 |
| 記憶體溢出 | 評估 GC 對服務的影響 | |
| 接口延遲 | 評估接口故障對整體 SLA 的影響 | |
| 接口抛異常 | 評估接口故障對整體 SLA 的影響 | |
| 接口傳回值篡改 | 評估針對非預期接口傳回的處理 | |
| 線程池打滿 | 評估線程池打滿對服務的影響 | |
| 中間件依賴故障 | JSF 請求延遲 | 評估中間件故障對自身的影響 |
| JSF 請求抛異常 | 評估中間件故障對自身的影響 | |
| JIMDB 請求延遲 | 評估中間件故障對自身的影響 | |
| JIMDB 請求抛異常 | 評估中間件故障對自身的影響 | |
| MYSQL 請求延遲 | 評估中間件故障對自身的影響 | |
| MYSQL 請求抛異常 | 評估中間件故障對自身的影響 |
表 3-3 彙總了泰山混沌實驗平台的故障使用統計表，從使用情況上可以看出，目前基礎資源類故障場景使用居多。圖 3.2 更加直覺的展示出泰山混沌工程實踐平台的故障使用類型為基礎資源類故障。
表 3-3 泰山混沌工程實驗平台故障類型使用統計表
| 故障類型 | 演練占比 |
| 網絡故障 | 31% |
| 記憶體耗盡 | 13% |
| CPU 打滿 | 23% |
| 磁盤故障 | 9% |
| 程序異常 | 3.5% |
| Java 程序故障 | 6.5% |
| 外部依賴故障 | 14% |
3.3 常見問題
通過調研泰山混沌工程的實踐，可以彙總一些常見問題如下：
（1）報警未配置（MDC、UMP、存活）；
（2）報警門檻值不合理、間隔時長不合理、聯系人缺失、聯系人授權不足；
（3）程序假死未報警，需配置 URL 存活報警；
（4）暫停了告警，未及時開啟；
（5）值班人員對預案處理不熟練，内部系統工具使用不熟練（加強内部教育訓練）；
（6）群組内回報問題後，未有相關同僚進行處理，職責分工不明确；
（7）内部工具設計不合理，無法應對不同場景（比如：多機房分組出異常）；
（8）忽視偶發問題，後期範圍擴大不易處理（比如：低版本 Linux 核心處理）。
四、總結和思考
4.1 調研總結和思考
本次調研涵蓋了混沌工程的起源，發展，以及在京東的落地情況。通過研究，我進一步體會到：（1）混沌工程最先進的，是它大膽超前的思維理念和安全受控的方法論。（2）故障注入隻是手段，而不是混沌工程的全部。場景再多，也不代表韌性就夠好。（3）如果隻是根據穩态假說，寫測試用例，然後再使用故障注入工具進行試驗，最後結果驗證，這隻能算是混沌工程最基本的内容。（4）混沌工程的使命是探索問題，而不僅僅是驗證問題。總體而言，混沌工程的核心就是增強系統信心，保證系統在某個場景下的能力不退化。
4.2 混沌工程未來發展
混沌工程的目标是主動發現問題，是以，未來依然離不開這個核心目标，但是在未來，可以使得這個目标更加智能化的實作。通過調研發現，業界中部分企業已經開始探索将混沌工程和人工智能、機器學習等領域相結合，通過注入故障時系統名額的變化和定位的曆史資料進行相關模型的訓練，使得模型可以通過名額變化自動識别故障，這将有助于解決混沌工程在結果分析和故障恢複環節的自動化問題。其次，當下的混沌工程演練平台的互動性和可視化等能力在未來可以做到更好。此外，混沌工程的量化名額也需要進一步完善。
參考文獻
1.ChaosMesh https://github.com/chaos-mesh/chaos-mesh
2.ChaosBlade https://github.com/chaosblade-io/chaosblade
3.ChaosToolkit https://github.com/chaostoolkit/chaostoolkit
4.orchestrator https://github.com/openark/orchestrator
5.powerfulseal https://github.com/powerfulseal/powerfulseal
6.toxiproxy https://github.com/Shopify/toxiproxy
7. 混沌工程深度實戰專場 https://live.juejin.cn/4354/xdc2021-01
作者：京東零售 賈安
來源：京東雲開發者社群