主動發現系統穩定性缺陷：混沌工程
這是一篇較為詳細的混沌工程調研報告，包含了背景，現狀，京東混沌工程實踐，希望幫助大家更好的瞭解到混沌工程技術，通過混沌工程實驗，更好的為系統保駕護航。
一、概述
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 |
| 程序終止 | 觀測負載均衡時效性、業務敏感性（Nginx&Tomcat） | kill -9 |
表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
作者：京東零售 賈安
來源：京東雲開發者社群