1、何謂混沌工程？

混沌工程由 Netflix 率先提出并應用，其業務高度依賴分布式系統，為確保系統在面對各種故障時仍能穩定運行，其組織開發了混沌工程工具集 ——Chaos Monkey 等，通過隨機地關閉生產環境中的服務器來驗證系統彈性。

混沌工程是一種在分布式系統上進行實驗的方法，目的是提升系統的彈性和穩定性。它通過主動向系統注入故障，觀察系統在各種壓力情況下的行為，以發現系統中的潛在問題并加以改進。

2、混沌工程實驗的核心原則

a、建立穩定性指標

建立系統穩定性指標，是觀測混沌工程實驗效果的關鍵手段。在混沌工程啟動前，必須明確系統穩定性狀態的定義，穩定性狀態可以是系統的技術指標、業務指標或用戶體驗指標等。例如，系統TP99指標范圍、可用率指標范圍、頁面響應時間范圍、訂單處理成功率范圍等。

b、多樣化故障注入

多樣化的故障注入，是驗證系統故障應急能力的前提。混沌工程應盡可能模擬真實世界中可能發生的各種故障或異常情況。包括不限于，硬件故障、軟件故障、網絡故障、人為錯誤等。例如，服務器宕機、網絡延遲、數據庫故障、配置錯誤等。

c、生產環境接納度

生產環境對演練實驗的接納度，是確保故障演練實驗精度和有效性的基礎要素。混沌工程實驗最好在生產環境中進行，因為生產環境是最真實的系統運行環境，能夠反映出系統在實際使用中的各種情況。當然，在生產環境中進行實驗務必謹慎操作，確保實驗不會對生產運營及用戶造成不良影響。

d、常態化運轉

混沌工程實驗的常態化運轉，是確保系統健壯性得以持續鞏固的基礎。混沌工程實驗應該持續自動化運行，以便及時發現系統中的潛在問題。自動化實驗可以定期進行，也可以在系統發生變化時進行。通過持續自動化運行實驗，可以不斷提高系統的彈性和穩定性。

3、混沌工程實驗的關鍵步驟及落地

快遞快運技術部，自2024年11月起，針對分揀揀攬派及C端、B端核心業務線，0-1落地研測聯動紅藍攻防機制，完成共兩輪，87個核心接口架構分析，覆蓋31個核心應用（79個場景），識別攔截5類36處風險（監控、流程、代碼、預案、依賴），持續鞏固快快應急預案體系，在此基礎上，25年持續推動演練線上化實踐、成熟度評估體系建設、落地及能力升維。

a、實驗范圍圈定

通過對核心系統的架構分析，梳理系統鏈路的關鍵指標（系統規模、SLA及限流指數等）和關鍵依賴（應用、存儲及其他中間件），明確要進行實驗的系統或服務范圍，標記故障注入點。

實驗范圍可以是一個或多個單體應用、某個業務場景下的應用鏈路、某個數據中心或整個分布式系統。

b、穩定性指標定義

定義明確的穩定性指標，用以衡量系統在實驗過程中的狀態，穩定性指標可以是技術監控指標、業務監控指標或用戶體驗指標等。

1）技術監控指標

技術監控指標，一般從技術視角監控系統穩定性，通常分為幾個維度監控。

指標名稱	指標描述
UMP（JD術語）	監控方法調用的TP99，響應時間等
日志異常關鍵字	監控日志中的，有無異常關鍵字，報錯信息等
容器指標監控	監控CPU，數據庫等使用情況是否有異常
調用鏈監控	監控整個上下游調用鏈路，是否有可用率下降等問題
JVM監控	監控內存，線程等使用情況

2）業務監控指標

業務監控指標，是整個監控體系的“頂層”，能夠直接反映用戶使用業務的真實情況。在快遞快運分揀業務域，體現如下（例如，發貨環節，設置【發貨環節成功率】作為監控指標，通過配置規則：當前時間的發貨成功數據與上周同比下降超過30%，如果5分鐘內連續出現3次告警，則觸發嚴重級別的告警）。

?

c、實驗場景構建

根據系統的架構及技術特點，以及可能出現的故障情況，參考設計各種實驗場景。實驗場景應該盡可能地模擬真實世界中可能發生的各種故障和異常情況（可參考 歷史存量線上故障）。

故障分類	描述
服務器硬件故障	模擬服務器 CPU、內存、硬盤等硬件組件故障。例如，通過設置硬件監控軟件模擬 CPU 使用率瞬間達到 100%，或模擬內存出現壞塊導致部分內存無法正常讀寫，又或者模擬硬盤空間滿溢，影響應用數據存儲和讀取
網絡設備故障	包括網絡交換機、路由器故障。如設置網絡交換機某個端口故障，造成部分服務器網絡連接中斷；模擬路由器丟包，導致應用網絡通信延遲或數據傳輸錯誤
操作系統故障	如操作系統內核崩潰、系統資源耗盡（如文件描述符用盡）。可通過編寫腳本消耗系統資源，觸發文件描述符不足的情況，觀察應用在這種操作系統故障下的表現
應用程序自身故障	例如代碼邏輯錯誤導致空指針異常、內存泄漏、死鎖等。可以在應用代碼中特定位置人為插入引發空指針異常的代碼片段，進行局部模擬；對于內存泄漏，可通過工具模擬對象未正確釋放內存的情況；通過編寫存在競爭條件的代碼模擬死鎖場景
中間件故障	若應用使用數據庫中間件、消息隊列中間件等，可模擬中間件故障。比如數據庫中間件連接池耗盡，導致應用無法獲取數據庫連接；消息隊列中間件消息堆積、消息丟失等。以數據庫中間件為例，可通過修改配置參數，限制連接池大小，快速創建大量數據庫連接請求，使連接池耗盡
高并發壓力	利用性能測試工具模擬大量用戶同時訪問應用，造成系統負載過高。例如，使用 JMeter 模擬每秒數千個并發請求，測試應用在高并發場景下的穩定性和故障應對能力
環境變量錯誤	修改應用運行所需的環境變量，如配置錯誤的數據庫連接字符串、錯誤的系統路徑等，觀察應用能否正確識別并處理這些錯誤

1）一般場景構建

①CPU使用率（單個故障場景樣例及核心參數解釋）

?演練目的：CPU混沌實驗用于在主機模擬CPU負載情況，通過搶占CPU資源，模擬CPU在特定負載情況下，驗證其對服務質量、監控告警、流量調度、彈性伸縮等應用能力的影響。

?核心參數解釋

?使用率：根據研發配置的MDC告警閾值決定（例：研發配置60%。80%-90%）

?搶占模式：故意運行占用大量 CPU 資源的進程，使得系統的 CPU 使用率飆升，從而觀察其他服務和進程在資源競爭下的表現。（勾選代表打開該模式）

?滿載核數：核心滿載個數（如果一個系統在正常運行時很少有核心達到滿載，但在混沌工程測試中有多個核心持續滿載，那么可能表明系統在極端情況下的資源分配存在問題，或者系統并沒有正確地平衡負載。）

?滿載核索引：每個 CPU 核心在操作系統中都有一個唯一的索引號，這些索引號通常從 0 開始計數。（例：0,1 / 0-2） 參數優先級：使用率 > 滿載核數 > 滿載核索引 建議：第一次演練優先使用【使用率】

②更多場景及選型原則：混沌工程-故障演練場景選型及實施說明?

2）復雜場景構建

①單應用單故障場景“多參數”組合構建

場景構建說明

構建參數	故障類型
接口參數：請求類型（GET/POST）、數據格式（JSON/XML）、請求體大小（1KB/10KB）	資源耗盡（CPU / 內存）
配置參數：線程池大小（5/10）、超時閾值（1s/5s）、緩存 TTL（30s/60s）	網絡異常（延遲 / 丟包）
環境參數：CPU 利用率（50%/80%）、內存占用（60%/90%）、網絡延遲（100ms/500ms）	數據異常（錯誤碼 / 空值）

（場景樣例）連接庫請求延遲&業務的異常流量注入

?場景描述：依據場景構建的基本原則，我們在構建數據庫請求延遲的情況前提下，向系統注入帶有異常業務數據的流量，以檢查應急預案對應的處理能力。

攻擊接口	http://xxxxx.forcebot.jdl.com/services/xxxxx/getWaybillChute
攻擊步驟		預期結果	結論
10*10個QPS將壓測流量灌入（正常流量）		事務成功率100%	pass
植入故障，觀察（故障占比：80%，A分組5臺打掛，B分組3臺打掛）		5分鐘內觸發數據庫請求告警，守方報備到備戰群	pass
調節壓測流量，QPS增加到60*10（值逐步增加）		服務可用率降低，TP99上升	pass
調節壓測流量，QPS增加到80*10（值逐步增加）		服務可用率降低，TP99上升	pass
觀察到守方通過防守動作止損 較長時間內服務沒起來		事務成功率100%，連接數據庫請求正常，TP99恢復正常（TCP重傳、數據庫連接、下線機器、擴容）	pass
停止故障任務		集群下所有機器事務成功率100%，CPU使用率60%以下，TP99恢復正常，連接數據庫請求正常	pass
停止壓測腳本		流量停止灌入	pass

②單應用多故障場景組合構建

?場景構建說明：可參考如下組合方式，構建單應用多故障場景。

組合方式	組合描述
基于故障影響范圍組合	局部與全局故障組合：先設置一個局部故障，如某個模塊的代碼邏輯錯誤導致該模塊功能不可用，同時再設置一個影響全局的故障，如服務器內存耗盡，使整個應用運行緩慢甚至崩潰。這樣可以測試應用在局部問題和整體資源危機同時出現時的應對策略
	上下游故障組合：如果應用存在上下游依賴關系，模擬上游服務故障（如數據提供方接口異常）與下游服務故障（如數據存儲服務不可用）同時發生
基于故障發生時間順序組合	先后發生故障組合：設定故障按特定順序出現。比如，先模擬網絡短暫中斷，導致部分數據傳輸失敗，緊接著由于數據處理異常，引發應用內部的緩存雪崩問題。通過這種順序組合，測試應用在連鎖故障場景下的恢復能力和數據一致性
	周期性故障組合：設置周期性出現的故障，如每隔一段時間（如 10 分鐘）網絡出現一次短暫擁塞，在擁塞期間，同時出現應用程序的內存泄漏問題逐漸加重。這種組合可以觀察應用在長期面對周期性故障和持續惡化的內部故障時的表現
基于業務流程關鍵節點組合	核心業務流程故障組合：針對應用的核心業務流程設置故障。以在線支付流程為例，在用戶輸入支付信息階段，模擬輸入校驗模塊出現故障，接受錯誤格式的支付信息；同時在支付確認階段，模擬與支付網關通信故障，測試支付流程在多個關鍵節點故障下的健壯性
	業務高峰與故障組合：結合業務使用高峰時段，疊加多種故障。例如，一個視頻播放應用在晚上用戶觀看高峰期，同時出現服務器 CPU 負載過高、視頻源文件損壞、CDN 節點故障等多種故障，測試應用在高業務壓力和復雜故障環境下能否保障用戶基本體驗

（場景樣例）核心依賴中間件MySQL請求延遲&CPU使用率增加場景

?場景描述：該場景主要在單應用模式下，在數據庫和CPU維度，參考故障的一般發生順序，進行組合注入，并同步觀察系統恢復能力。

?實際執行層面，在植入CPU使用率和數據庫延遲故障時，預期觸發CPU和接口可用利率告警，但實際情況中，CPU告警按預期觸發，但接口可用率報警并未觸發。

攻擊接口	com.jdl.xxxxx.xxxxx.api.gather.xxxxx#queryWayGather
攻擊步驟		預期結果	結論
20個QPS將流量灌入對應機器（接口單機線上最大QPS 66）		事務成功率100%	pass
植入故障1【cpu 使用率70%+MYSQL延遲2000ms】		期望：觸發cpu告警，觸發接口可用率告警	fail
觀察到守方通過防守動作止損		事務成功率100%，CPU使用率60%以下，TP99恢復正常	pass
植入故障2【針對擴容新增機器 植入cpu 使用率70%】		新機器持續cpu告警，持續擴容，保證分組下集群數量	pass
觀察到守方通過防守動作止損		集群下所有機器事務成功率100%，CPU使用率60%以下，TP99恢復正常	pass
調節壓測流量，QPS增加到1980（線上峰值3倍）		服務可用率降低，CPU使用率持續增加，TP99上升 觸發方法調用次數告警	pass
停止壓測腳本		流量停止灌入	pass

③多應用多故障場景組合構建

場景構建說明：多應用多故障場景的構建，可基于單應用單故障的場景進行組合，可參考如下組合方式。目前針對該類型場景還未進行覆蓋，后續基于上下游系統的架構分析和調用關系，進行組合。如應用A調用應用B，在給應用A植入故障的同時，B應用也進行故障植入。

組合方式	組合描述
基于業務流程的組合	串聯業務流程故障組合：業務場景 A發生一個故障，同時業務場景B也發生也一個故障，同時 A和B 是不同應用，業務流程串聯
	并發業務流程故障組合：業務場景 A發生一個故障，同時業務場景B也發生也一個故障，同時 A和B 是不同應用，業務流程并發
基于故障影響范圍的組合	局部與全局故障組合：局部故障可以是某個內部使用的特定應用出現功能故障，全局故障則可以是影響整個企業的網絡故障或核心數據庫故障
	關鍵與非關鍵應用故障組合：設置故障場景為核心業務系統出現數據庫連接池耗盡的故障，非核心應用發生另一個故障
基于故障發生時間順序的組合	先后發生故障組合：先設置一個應用的故障，待其產生一定影響后，再觸發另一個應用的故障
	周期性故障組合：設置某些故障周期性出現，如每隔一段時間（如每天凌晨）出現故障A，同時，在每周的特定時間段（如周五下午業務高峰時段）出現故障B，組合參考

?

3）計劃外場景構建

故障演練計劃外場景通常是指在沒有預先計劃或通知的情況下，模擬系統或服務出現故障的情境，以測試和提高系統的可靠性和團隊的應急響應能力。其主要特點包括：突發性、真實感、壓力測試、團隊協作。以下是在研發毫無防備的情況，進行的一次突襲式的故障演練例子：

混沌工程與傳統的故障引入測試，在注入場景和工具使用方面存在重疊。故障注入測試，是混沌工程實驗的一種驗證策略。 其本質區別，是思維方式的差異 ，故障注人測試是通過已知故障和應急預案，確認系統對已知風險的承載能力。而混沌工程，是通過構造諸如應急預案范圍外的故障場景，確認系統對未知風險的承載能力。

（場景樣例）JAVA進程線程池滿（未在演練劇本內的故障，觀察系統應急能力）

通常在劇本評審階段，測試團隊會與架構團隊完成全量場景評估，同時會提取部分場景，在約定演練時間計劃外執行，研發團隊對此類故障的執行計劃不知情，以此強化驗證其應急處理能力。

例如：在某計劃外場景演練過程中，發現2個問題，①當植入JAVA進程線程池滿的故障時，預期觸發CPU告警，研發團隊并未第一時間同步報備。②在故障停止時，預期所有機器及事務恢復正常，并由研發接口人報備同步恢復信息，但研發團隊并未第一時間同步報備。

由此可見，計劃外的場景，在識別系統應急能力之外，可更多反映研發團隊，在故障處理過程中的組織協同能力。

演練執行
攻擊接口	com.jdl.xxxxx.resource.api.message.xxxxx#isNeedVerificationCode
攻擊步驟		預期結果	結論
1個QPS將流量灌入對應機器		事務成功率100%	pass
植入JAVA進程線程池滿故障，觀察		10分鐘內觸發CPU使用率告警，守方報備到備戰群，業務全部失敗	fail
故障生效后立即調節壓測流量，QPS增加到10筆/s(日常量)		服務可用率降低，CPU使用率持續增加，TP99上升	pass
觀察到守方通過防守動作止損		集群下所有機器事務成功率100%，CPU使用率60%以下，TP99恢復正常	pass
停止故障任務		集群下所有機器事務成功率100%，CPU使用率60%以下，TP99恢復正常	fail
停止壓測腳本		流量停止灌入	pass

?

4）流量沖擊融合場景構建

?系統在故障發生時，例如，C端用戶在響應卡滯情況下，如系統未給予明確的故障提示、降級方案或恢復預期，往往會通過重復操作，確認系統恢復進展，請求量存在倍增可能。

?后端平臺類系統對接，請求方往往會通過自動重試，嘗試重建成功請求，同時在長鏈路業務場景下，如鏈路各應用重試策略未統一，請求量存在倍增可能。以上，在故障恢復過程中，已部分恢復的服務，大概率會被倍增流量快速擊潰，造成系統可用性雪崩。有必要通過融合流量沖擊場景的混沌實驗，確認系統的極端風險承載能力。

（場景樣例）應用CPU滿載混合單機流量激增

?場景描述：在CPU滿載的情況下，模擬接口流量激增。首先植入CPU滿載，再調節注入流量，觀察整個處理過程。

演練執行
攻擊接口	整個應用
攻擊步驟		預期結果	結論
小流量注入		事務成功率100%	pass
植入故障CPU占用率80%，植入比例：70%，觀察		CPU滿載，5分鐘內觸發CPU使用率告警，守方報備到備戰群	pass
調節壓測流量，單機QPS增加到1倍壓測流量（梯度），單機CPU占有率>60%		CPU使用率持續增加，TP99上升	pass
調節壓測流量，單機QPS增加到2倍壓測流量（梯度），單機CPU占有率>80%		CPU使用率持續增加，TP99上升	pass
觀察到守方通過防守動作止損		事務成功率100%，CPU使用率60%以下，TP99恢復正常	pass
觀察到守方通過防守動作止損		集群下所有機器事務成功率100%，CPU使用率60%以下，TP99恢復正常	pass
停止故障任務		集群下所有機器事務成功率100%，CPU使用率60%以下，TP99恢復正常	pass
停止壓測腳本		流量停止注入	pass

d、實驗劇本構建

1）劇本設計詳解

故障注入過程，尤其是在生產或準生產環境實驗，未經評估的故障場景，極易造成線上生產異動，對實驗方案的嚴謹性以及人員的專業性，提出了更高的要求。實驗劇本構建主要包括以下幾個要素。

劇本構建核心要素	關鍵事項	準入標準	準出標準
明確實驗目標	·定義實驗目的：識別實驗的核心目的，例如提高系統的彈性、驗證故障處理機制、評估服務降級策略等。 ·選擇關鍵性能指標（KPIs）：確定用于評估實驗結果的關鍵性能指標，如系統的響應時間、可用性、吞吐量、錯誤率等。 ·設定具體目標：制定具體的、可衡量的目標。例如，“在網絡延遲增加的情況下，系統響應時間不超過2秒”。 ·業務影響考量：確保實驗目標與業務目標相一致，評估實驗對業務連續性和用戶體驗的潛在影響。	·團隊準備：確保參與實驗的團隊成員了解實驗目的、流程和應急響應計劃。 ·確保業務影響最小化：制定策略，確保實驗不會對關鍵業務功能造成重大影響。可以通過選擇非高峰時段進行實驗或在實驗前進行業務影響評估。 ·風險識別：系統地識別實驗可能帶來的所有潛在風險，包括對系統穩定性、數據完整性和業務連續性的影響。	·設定實驗范圍和條件：明確實驗的范圍（例如哪些服務或組件會受到影響）和條件（例如故障的持續時間、強度等）。
選擇故障場景	·識別潛在故障：通過對系統架構、依賴關系和歷史故障記錄的分析，識別潛在的故障類型。包括網絡延遲、服務宕機、資源耗盡、數據庫故障、磁盤故障，超時、服務不存活等。 ·優先級排序：根據故障對業務的影響程度進行排序。優先選擇那些對關鍵業務流程影響較大的故障；考慮故障發生的可能性，優先演練那些較高概率發生的故障。 ·場景細化：將故障場景具體化，包括故障的觸發條件、影響范圍和預期結果；考慮組合多個故障場景，模擬復雜環境下的系統行為。	·場景驗證：確保所選故障場景經過驗證，可以在實驗環境中安全地注入和控制。 ·團隊準備：團隊成員應了解故障場景的細節、實驗步驟和應急響應計劃。 ·審批流程：實驗需要獲得相關方的批準，特別是涉及到關鍵業務系統時。	·可行性完成：評估故障場景的實施難度，包括技術可行性和資源需求，確保實驗能夠在現有條件下順利進行。 ·影響評估完成：預估故障場景可能對系統和用戶造成的影響，并確保其在可控范圍內，避免對生產環境造成嚴重影響。
設計實驗方案	·場景描述：詳細描述每個故障場景，包括故障類型、注入方式和預期影響。 ·步驟規劃：制定實驗的具體步驟，包括故障注入的時間、地點和方式。 ·成功標準：定義實驗的成功標準，即在故障條件下系統應達到的性能水平。	·風險評估：完成對實驗的風險評估，識別可能的風險和影響，并制定相應的緩解措施。 ·團隊準備：團隊成員已接受必要的培訓，了解實驗步驟、應急響應計劃和溝通渠道。 ·溝通計劃：確保所有相關方已被告知實驗的時間、范圍和可能的影響，并制定溝通計劃以便在實驗過程中及時更新信息。	·方案風險評估完成：評估實驗對系統和用戶的實際影響，確保實驗沒有導致不可接受的中斷或損害。
風險評估與應急預案	·風險識別：識別實驗可能帶來的風險，包括對系統穩定性和業務運營的影響。 ·應急預案：制定緩解措施，如快速回滾計劃和應急響應方案。	·風險識別：系統地識別實驗可能帶來的所有潛在風險，包括對系統穩定性、數據完整性和業務連續性的影響。 ·應急響應計劃：制定詳細的應急響應計劃，明確角色和責任，以便在實驗過程中快速響應任何突發問題。 ·審批和溝通：風險評估報告和緩解計劃需要獲得相關方的審核和批準。確保所有相關方都了解可能的風險和緩解措施。	·風險評估完成：完成對實驗風險的評估，并制定相應的應急預案。
實驗環境準備	·環境搭建：準備實驗環境，確保其與生產環境盡可能相似，以提高實驗結果的可靠性。 ·工具配置：配置必要的故障注入和監控工具，確保能夠實時收集和分析數據。	·環境驗證：驗證實驗環境的準備情況，包括配置、數據和工具的可用性。 ·溝通確認：確認所有相關方（如開發、運維、業務團隊）已收到實驗通知并同意進行實驗。	·環境隔離：確保實驗環境與生產環境適當隔離（成熟度高的可以不隔離），以避免實驗對生產系統造成不必要的影響。 ·環境一致性：驗證實驗環境的配置與生產環境盡可能一致，包括硬件、軟件版本、網絡配置等，以確保實驗結果的可用性和相關性。 ·資源可用性：確保實驗所需的所有資源（如計算資源、存儲、網絡帶寬）已準備就緒，并能夠支持實驗的順利進行。
實驗執行與數據分析	·實時監控：在實驗過程中，實時監控系統狀態和關鍵指標，確保能夠快速識別和響應異常情況。 ·故障注入：按照實驗方案注入故障，觀察系統的反應。 ·數據收集：收集實驗期間的所有相關數據，包括日志、監控指標和用戶反饋。 ·結果分析：分析實驗結果，評估系統在故障條件下的表現，并識別改進機會。	·風險評估完成：確保已進行全面的風險評估，識別潛在風險，并制定相應的緩解措施。 ·團隊準備就緒：所有相關團隊（如開發、運維、安全）已準備好，并了解各自的職責和應對措施。 ·應急計劃確認：確保應急計劃已制定并經過驗證，所有團隊成員都清楚如何在緊急情況下快速恢復系統。 ·環境驗證：實驗環境已被驗證為與生產環境相似，并且所有必要的工具和配置已準備就緒。 ·溝通與批準：獲得所有相關方（包括管理層和業務團隊）的批準，確保他們了解實驗計劃和可能的影響。 ·監控和日志系統在線：確保監控和日志系統正常運行，以便實時追蹤實驗過程中系統的狀態和行為。	·實驗結果評估：對照預定的成功標準評估實驗結果，確保實驗目標已實現。 ·系統恢復確認：確保系統已恢復到正常運行狀態，所有故障注入的影響已完全消除。 ·數據完整性驗證：檢查實驗期間的數據完整性，確保沒有數據丟失或損壞。 ·報告生成：生成詳細的實驗報告，包括實驗過程、結果、發現的問題和改進建議。 ·經驗總結與分享：召開經驗總結會議，分享實驗中的經驗教訓，并更新相關的操作文檔和策略。 ·后續行動計劃：確定并記錄需要改進的領域和后續行動計劃，以提升系統的彈性和可靠性。
復盤與成熟度評估	·報告撰寫：撰寫詳細的實驗報告，記錄實驗過程、結果和發現的問題。 ·改進計劃：根據實驗結果制定系統改進計劃，并計劃后續步驟。 ·知識共享：將實驗結果和經驗教訓分享給相關團隊，促進組織內部的知識積累。 ·復盤會議：召開復盤會議，討論實驗中的亮點和不足，優化未來的實驗流程。 ·成熟度改進：評估被演練系統服務成熟度。	·數據完整性：確保所有相關數據和日志已收集完畢，并且數據質量足以支持有效分析。 ·參與者準備：確保所有關鍵參與者（如開發、運維、安全團隊成員）已準備好參與復盤會議，并了解實驗的背景和結果。 ·目標明確：復盤的目標和預期成果已明確，并傳達給所有參與者 ·成熟度評估：已完成對當前混沌工程實踐的成熟度評估，識別出需要改進的領域。	·問題識別與分析：已識別并分析實驗中的所有關鍵問題和挑戰。 ·成功與不足記錄：記錄實驗中的成功經驗和不足之處，并分析其原因。 ·改進措施制定：制定具體的改進措施和后續行動計劃，并獲得相關方的認可。 ·文檔更新：更新相關文檔，包括操作手冊、實驗報告和改進計劃。 ·經驗分享：將復盤結果和經驗分享給更廣泛的團隊或組織，以促進知識共享。

2）劇本構建樣例

?故障演練方案-快遞快運-分揀條線-2024年12月?

e、工具選型

1）工具選型原則

①功能特性

?復雜場景構建：對于復雜的分布式系統，尤其是包含多種技術棧（如同時有微服務、數據庫、消息隊列等）的系統，需要選擇能夠模擬多種故障類型的工具，以更全面地測試系統的彈性。

?實驗場景定制化：混沌工程工具應該允許用戶根據自己的系統特點和需求定制實驗場景，提供豐富的實驗模板，并可通過修改這些模板或編寫自己的實驗腳本來定制實驗。這種靈活性使得用戶能夠模擬特定的業務場景下可能出現的故障，如模擬電商系統在購物高峰期時數據庫查詢緩慢的情況。

?系統集成能力：實驗工具需要能夠與企業現有的系統和工具集成，如監控系統、日志系統等。通過插件或者 API 的方式實現與其他系統的集成，增強工具的實用性。

②環境適配

?容器化基礎設施兼容性：隨著容器技術和 Kubernetes 的廣泛應用，混沌工程工具需要加強對以上基礎環境的支持，更充分地兼容 Kubernetes（Pod、Deployment、Service 等），并進行有效的故障注入。

?云平臺兼容性：對于部署在云平臺（如 京東云、阿里云、騰訊云、華為云、百度云、GCP、IBM Cloud、Oracle Cloud、AWS、Azure、Ali 等）上的系統，需要考慮工具是否與這些云平臺兼容，是否能夠提供針對特定云平臺的故障模擬功能，。例如，AWS S3 存儲桶故障、Azure 虛擬機故障等特定故障情況，以適應云環境下的實驗需求。

?跨平臺支持：對于同時在多種操作系統（如 Linux、Windows、Android、IOS、MacOS 等）和硬件架構（如 x86、ARM）上運行的系統，確保所選工具能夠在所有相關平臺上正常工作，避免出現因平臺差異導致實驗無法進行的情況。

③易用性和學習成本

?用戶界面友好程度

?直觀、易于操作的用戶界面可以降低用戶的學習成本和操作難度。例如，Gremlin 有一個相對直觀的 Web 界面，用戶可以通過簡單的操作（如選擇故障類型、目標系統等）來設置和啟動實驗。對于非技術人員或者剛接觸混沌工程的團隊成員來說，這樣的界面更容易上手。

?文檔和社區支持

?完善的文檔和活躍的社區可以幫助用戶更快地學習和使用工具。工具的官方文檔應該包括詳細的安裝指南、實驗設置說明、故障模擬類型介紹等內容。同時，一個活躍的社區可以讓用戶分享經驗、解決問題，例如在開源的混沌工程工具社區中，用戶可以找到其他使用者分享的自定義實驗場景案例，幫助自己更好地開展實驗。

④安全性和可靠性

?實驗風險控制

?混沌工程工具在進行故障注入時可能會對生產系統造成一定的風險，因此需要選擇能夠有效控制實驗風險的工具。一些工具提供了諸如 “安全模式” 或 “沙箱模式” 的功能，在這些模式下，故障注入的強度和范圍可以得到限制，并且可以提前設置好終止實驗的條件，以確保在系統出現異常時能夠及時停止實驗，避免對生產系統造成嚴重破壞。

?工具自身的可靠性

?工具本身應該是可靠的，不會因為自身的故障而導致實驗結果不準確或者對系統造成額外的干擾。可以查看工具的版本更新記錄、用戶評價等信息來了解工具的可靠性情況。例如，經過多個企業長時間使用且更新頻繁的工具，通常在可靠性方面有更好的保障。

2）業界混沌工程解決方案

在混沌工程實踐里，通過模擬各類故障場景，像是模擬服務器崩潰、制造網絡延遲，或是觸發數據丟失狀況等方式，能夠極為精準地挖掘出系統中潛藏的薄弱環節。目前，市面上既有開源性質的解決方案，也不乏商業化的專業工具。接下來，我們將著重對京東（JD）的混沌解決方案，以及其他具有代表性的開源方案展開詳細介紹。

①JD泰山混沌工程平臺（快快技術-首選解決方案平臺）

?簡介：是一款遵循混沌工程原理和混沌實驗模型的實驗注入工具，幫助用戶檢驗系統高可用、提升分布式系統的容錯能力，平臺使用簡單、調度安全。是基于 ChaosBlade 底座進行打造，并增加了JIMDB、JSF、JED等中間件類故障場景，讓大家可以精細地控制演練影響范圍（爆炸半徑）。

?特點：支持多種類型的故障，如基礎資源故障：CPU、 內存、網絡、磁盤、進程；Java進程故障：進程內CPU滿載、內存溢出、類方法延遲/拋異常/篡改返回值、MYSQL請求故障、JIMDB請求故障、JSF請求故障；JED集群故障：集群分片主從切換、集群分片節點重啟

?適用場景：適用于復雜分布式系統和微服務架構中的故障模擬，另外針對JD特有的服務可支持故障植入。

②業界工具平臺及能力對標

平臺/能力	特點	適用場景
云原生計算基金會托管項目，專注于 Kubernetes 環境中進行混沌工程實踐，可編排多種混沌實驗	·支持多種類型的故障注入，如 Pod 故障、網絡故障、文件系統故障、時間故障、壓力故障等 ·提供了直觀的 Web 界面 ChaosDashboard，方便用戶管理、設計和監控混沌實驗	適用于云原生架構下的系統，幫助開發人員、運維人員在 Kubernetes 環境中測試應用程序和基礎設施的可靠性與穩定性，如基礎資源故障，Java應用故障等
Kubernetes 原生的混沌工程開源平臺，以其強大的故障創建與編排能力著稱	·擁有故障注入實驗市場 ChaosHub，提供大量可定制的實驗模板，支持多種故障注入類型，涵蓋通用、各大云平臺及 Spring Boot 等多種場景 ·可與 Prometheus 等可觀測性工具原生集成，方便監控故障注入實驗的影響	適用于不同技術背景的團隊，在 Kubernetes 環境中進行混沌工程實踐，幫助識別系統中的弱點和潛在停機隱患。如可模擬存儲故障，CICD管道層面故障等
阿里巴巴開源的混沌工程工具，可針對主機基礎資源、容器、Kubernetes 平臺、Java 應用、C++ 應用、阿里云平臺及其他服務等多達 7 個場景開展故障注入實驗	·支持在多種環境中進行故障注入，能夠模擬各種復雜的故障場景，如 CPU 滿載、內存泄漏、網絡延遲等資源層面的故障，還能深入到應用層對特定方法進行故障注入 ·具有易用性和靈活性，通過簡單的 CLI 命令行工具進行故障注入 ·支持動態加載和無侵入式的實驗設計	適用于復雜分布式系統和微服務架構中的故障模擬，幫助團隊提前發現系統中的薄弱環節。能夠模擬一些中間件的故障，如云原生故障等
輕量級、靈活且易于集成的混沌工程工具，允許用戶以聲明式的方式定義各種故障注入場景	·支持使用 YAML 文件定義混沌實驗，內置多種故障模型，如 Pod Kill、Network Latency、Disk IO Stress 等 ·深度集成 Kubernetes，提供友好的 Web 界面和 RESTful API，方便操作與集成	適用于開發者和運維人員在 Kubernetes 環境中進行混沌工程實驗，可作為新功能上線前的測試、持續集成 / 持續交付流程的一部分，以及故障恢復訓練等
功能全面的混沌工程工具，提供了直觀的 Web 界面，可模擬多種故障場景，包括服務器故障、網絡延遲、丟包、數據庫故障、容器故障等	·具備強大的故障模擬能力和靈活的實驗配置選項，可與多種監控和日志工具集成，方便用戶在實驗過程中觀察系統的狀態變化 ·提供了 “安全模式” 或 “沙箱模式” 等風險控制功能，確保實驗的安全性	適用于各種規模和架構的分布式系統，幫助企業提升系統的彈性和穩定性，尤其適合對安全性和風險控制要求較高的生產環境
亞馬遜推出的混沌工程工具，專門用于在 AWS 云平臺上進行故障注入實驗	·可模擬 AWS 云服務的各種故障情況，如 EC2 實例故障、S3 存儲桶故障、RDS 數據庫故障等 ·與 AWS 的其他服務和工具集成緊密，方便用戶在云環境中進行全面的系統測試	適用于使用 AWS 云平臺的企業和開發者，幫助他們在云環境中評估系統的可靠性和彈性，確保應用程序能夠在 AWS 云服務出現故障時正常運行

?

f、執行實驗

1）系統架構分析

①架構分析的必要性

系統級架構分析，是所有穩定性保障工作開展的首要條件。通過對系統機構的充分理解和分析，才能準確識別故障演練的切入點（可能的弱點），以下，是系統架構分析的必要環節和目的。

②識別關鍵組件和依賴關系

系統架構分析幫助識別系統中關鍵的組件和服務，以及它們之間的依賴關系。這有助于確定哪些部分對系統的整體功能至關重要，并需要優先進行故障演練。

③理解數據流和通信路徑

分析架構可以揭示數據在系統內的流動路徑和通信模式。這有助于設計針對網絡延遲、帶寬限制或通信中斷的故障演練。

④識別單點故障

系統架構分析可以幫助識別系統中的單點故障，這些是可能導致整個系統崩潰的薄弱環節。通過故障演練，可以測試這些點的冗余性和故障恢復能力。

⑤優化故障演練設計

了解系統架構可以幫助設計更加真實和有針對性的故障場景，從而提高故障演練的有效性和相關性。

⑥評估故障影響范圍

系統架構分析可以幫助預測故障可能影響的范圍和程度，從而為故障演練設定合理的范圍和目標。

⑦加強團隊的協作與溝通

通過架構分析，團隊成員可以更好地理解系統的整體設計和各自的角色。這有助于在故障演練中提高團隊的響應能力和協作效率。

⑧支持持續改進：

架構分析提供了一個基準，用于在故障演練后評估系統的改進效果。通過反復的分析和演練，可以不斷優化系統架構，提高系統的彈性。

?

總之，系統架構分析是故障演練的基礎，它確保演練的設計和實施是有針對性的，并能有效地提高系統的可靠性和穩定性。

?

2）架構分析案例

①架構分析要求

?梳理系統全局架構圖，標注演練（壓測同理）入口。

?梳理演練（壓測同理）接口調用架構圖，標識調用鏈路強弱依賴、調用層級關系以及演練（壓測同理）切入點。

?沉淀調用鏈路信息文檔。

（圖例）系統總架構圖

（圖例）單接口調用架構圖

②調用鏈梳理文檔（樣例）：快快接口梳理（常態化演練）?

3）實驗方案

在生產環境或測試環境中執行實驗，觀察系統在各種故障情況下的行為。在執行實驗過程中，應嚴格遵照劇本要求明確分工及實驗步驟，密切關注系統的穩定狀態指標，確保實驗不會對用戶造成不良影響。故障演練劇本?

①方案樣例

實驗方案實施過程中，應嚴格按照分工和劇本執行，第一時間留存關鍵證據，記錄關鍵步驟結論。

演練過程記錄
環節	時間線		舉證
故障開始注入時間 （攻方填寫）	2024-12-26 17:54:55
故障停止注入時間（攻方填寫）	2024-12-26 18:16:15
告警觸發及識別時間（守方填寫）	2024-12-26 17:58:00
定位時間（守方填寫）	2024-12-26 18:05:00
止損時間（守方填寫）	2024-12-26 18:09:00
故障恢復時間（守方填寫）	2024-12-26 18:10:00
MTTR（攻方填寫）	22min

?

g、結果分析

?對實驗結果進行分析，找出系統中的潛在問題和薄弱環節。分析實驗結果可以使用數據分析工具、監控工具或日志分析工具等。針對實驗結果總結經驗并后續做針對性改進。

?樣例：如針對某一個應用，演練完成之后，會從以下維度評估，并總結經驗。

?應用：workbench-xxxxx-backend-xxxxx

?故障場景：強依賴JSF超時不可用+弱依賴JSF超時不可用

?故障時間：2025-01-02 21:14:38 ~ 2025-01-02 21:35:00

?問題現象

?下游強依賴接口（計費系統）持續響應3S，TP99飚高，可用率未下降，仍100%

?從植入故障到引起監控報警，間隔13min，該接口性能告警配置建議調整時間（現狀：5次/分鐘超過配置的閾值則報警，并在10分鐘內不重復報警）

?問題原因

?針對強依賴接口，下游超時未上報可用率下降

?告警時間配置10min，告警配置不敏感

?改進措施

?針對強依賴接口，下游超時上報可用率下降

?更改UMP告警配置，更改為5min告警1次

?

h、問題修復及重復實驗

?根據實驗結果，修復系統中的潛在問題和薄弱環節。之后重復進行實驗，以驗證修復效果并進一步提高系統的彈性和穩定性。

?目前快快技術團隊，在演練過程中，關鍵問題修復之后，會針對性進行二次驗證。

?

i、成熟度評估

1）什么是混沌工程成熟度模型

混沌工程成熟度模型是一種框架，用于評估和指導組織在實施混沌工程實踐中的發展階段和成熟度。這個模型幫助組織理解它們在混沌工程實踐中的位置，并為進一步改進提供路線圖。

通常，混沌工程成熟度模型會分為幾個階段，每個階段代表不同的能力和實踐水平，通常包括初始階段、基礎階段（初級）、標準化階段（發展中）、優化階段（成熟）、創新階段（卓越）。

混沌工程成熟度模型的演變可以幫助組織系統化地實施混沌實驗，并逐步提高其混沌工程實踐的成熟度。通過系統化的成熟度評估，組織可以更有效地實施混沌工程實踐，提升其整體系統的穩健性和響應能力。

混沌工程成熟度模型的演變反映了組織在復雜系統環境中不斷追求更高彈性和可靠性的努力，結合業內對成熟度模型理解和京東實際情況，對成熟度框架進行剪裁（去掉接納度維度和初始階段），剪裁后的成熟度框架如下。

成熟度等級	1級（初級）	2級（發展中）	3級（成熟）	4級（卓越）
架構抵御故障的能力（系統維度）	一定冗余 統中存在備份或多個實例，以防單點故障。在硬件層面，可以有多個服務器或數據中心；在軟件層面，可以有多個服務實例或數據庫副本。（多機房無單點）	冗余且可擴展 除了具備一定的冗余之外，系統還應該能夠根據需求進行水平或垂直擴展。水平擴展是指增加更多的服務器或實例，垂直擴展是指升級現有服務器的硬件配置。可擴展性允許系統在面臨高負載或增長時繼續提供服務。	已使用可避免級聯故障技術 級聯故障是指一個故障導致一系列其他故障的連鎖反應。為了避免這種情況，可以使用技術如熔斷（Circuit Breaker）、隔離（Bulkhead）和限流（Rate Limiting）。（垂直部署）	已實現韌性架構 韌性架構是指系統在面臨異常情況（如高負載、網絡中斷或硬件故障）時仍能保持一定的功能和性能。實現韌性架構通常需要設計和實施多種策略，包括上述的冗余、可擴展性和避免級聯故障技術，以及其他技術如自動恢復（自動重啟、自動回滾等）、自適應負載平衡和實時監控等。
指標監控能力（系統維度）	實驗結果只反映系統狀態指標 實驗結果主要關注系統的基礎健康狀態指標，例如CPU使用率、內存使用率、磁盤空間等。這些指標可以幫助你了解系統在故障情況下的表現（具備MDC監控）	實驗結果反應健康狀態指標 除了基礎系統狀態指標外，實驗結果還會考慮更高級別的健康狀態指標，例如服務可用性、響應時間、錯誤率等。這些指標可以提供關于系統整體健康狀況的更深入的見解。（具備UMP和Pfinder監控，應用健康度評分90分以上）	實驗結果反應聚合的業務指標 實驗結果會聚焦于與業務相關的指標，例如訂單處理速度、用戶會話數、轉化率等。這些指標可以幫助你了解故障對業務流程和用戶體驗的影響。（具備業務監控能力）	有對照組比較業務指標差異 除了上述指標外，還會設置一個對照組（即沒有故障的基線組）來與實驗組進行比較。通過比較兩組的業務指標差異，可以更準確地評估故障對業務的實際影響。
實驗環境選擇（系統維度）	可在預生產環境運行試驗 在接近生產環境的設置中進行試驗，預生產環境通常與生產環境具有相似的配置和數據，可以幫助你在不影響實際用戶的情況下評估系統的彈性。	復制生產流量在灰度環境運行 在一個專門設計的灰度環境中模擬生產環境的流量和負載。通過這種方式，你可以在真實的生產條件下測試系統的彈性，而不直接影響到實際用戶。	在生產環境中運行實驗 需要非常小心和謹慎，只有當你有足夠的信心和準備工作時，才應該考慮在生產環境中進行混沌工程實驗。這種方法可以提供最真實的結果，但也存在最大的風險。	包含生產在內的任意環境都可進行實驗 這種說法并不完全正確。雖然理論上可以在任何環境中進行混沌工程實驗，但在實踐中，需要根據具體的系統和業務需求來選擇合適的環境。例如，對于關鍵系統或高風險應用，可能不適合直接在生產環境中進行實驗。
故障注入場景和爆炸半徑范圍（系統維度）	進行一些基礎的演練場景注入 選擇注入一些基本的故障場景，例如突然終止一個進程、關閉一個服務或者模擬機器崩潰等。這些場景可以幫助你了解系統在面對單一故障時的反應。	注入較高級的故障場景 注入更復雜的故障場景，例如網絡延遲、數據庫延遲或者是第三方服務不可用等。這些場景可以模擬更真實的生產環境中的問題。	引入服務級別的影響和組合式演練場景 注入涉及多個服務的復雜故障場景，例如同時模擬多個微服務的故障、網絡分區或者是負載均衡器失效等。這些場景可以幫助你了解系統在面對多個故障同時發生時的行為。	基于業務注入故障 注入更高級別的故障，例如模擬用戶的不同使用模式、返回結果的變化或者是異常結果的出現等。這些場景可以幫助你理解系統在面對非標準輸入或輸出時的彈性。
試驗自動化（基礎設施維度）	利用工具進行半自動化試驗 使用工具來輔助試驗的某些步驟，但仍需要人工干預。例如，使用腳本來模擬故障或生成負載，而人工負責啟動和監控試驗。	自動創建、運行實驗，但需要手動監控和停止 試驗的創建和運行可以被自動化，例如使用CI/CD流程來部署和執行試驗。然而，仍然需要人工監控試驗的進展和結果，并在必要時手動停止試驗。	自動結果分析，自動終止試驗 系統可以自動檢測到試驗的結果，并根據預設的規則自動終止試驗。例如，如果系統的性能下降超過某個閾值，試驗將被自動停止。	自動設計、實現、執行、終止實驗 整個混沌工程流程都被自動化。系統可以自主設計試驗、選擇適當的環境、執行試驗、分析結果，并根據結果自動調整或終止試驗。這種級別的自動化需要高度復雜的系統和算法支持。
工具使用（基礎設施維度）	采用試驗工具 選擇一款專門設計用于混沌工程的試驗工具，例如Chaos Monkey、Gremlin、Pumba等。這些工具可以幫助你模擬各種故障和壓力測試，評估系統的彈性。（泰山—風險管理—混沌工程）	使用試驗框架 選擇使用一個更全面的試驗框架，例如Chaos Toolkit或Litmus。這些框架提供了更豐富的功能，包括試驗設計、執行、監控和結果分析等。（泰山—風險管理—混沌工程）	實驗框架和持續發布工具集成 將混沌工程工具與持續發布（CI/CD）工具集成，例如Jenkins、GitLab CI/CD或CircleCI。這樣可以實現自動化的混沌工程流程，例如在每次代碼部署后自動運行一系列混沌工程試驗。	工具支持交互式的比對實驗 工具不僅可以執行混沌工程試驗，還可以提供交互式的比對實驗功能。例如，你可以使用工具來比較兩種不同的系統配置或版本在面對相同的故障情況下的表現差異。這種功能可以幫助你更深入地理解系統的彈性和性能。
環境恢復能力（基礎設施維度）	可手動恢復環境 需要手動介入來恢復環境。這可能涉及到重新啟動服務、清理日志文件、調整配置等步驟。雖然這種方法可以解決問題，但它通常需要更多的時間和人力資源。	可半自動恢復環境 系統具備一些自動化的恢復功能，例如自動重啟服務或者自動清理日志文件。然而，仍然需要系統管理員的介入來執行其他恢復步驟（比如手動恢復數據、手動回滾代碼等）。這種方法可以加快恢復過程，但仍然依賴于人工干預	部分可自動化恢復環境 系統的恢復過程可以被大部分自動化。例如，系統可以自動檢測故障并嘗試恢復，或者在出現問題時自動切換到備用系統。雖然仍然可能需要人工干預來解決某些問題（比如未知類型故障、數據一致性問題、安全問題等），但自動化程度已經大大提高。	韌性架構自動恢復 系統可以自動檢測和響應任何類型的故障，包括那些在設計時未被預見的故障。這種能力通常需要一個高度彈性和自適應的架構，例如微服務架構、容器化環境或者云原生應用。系統可以自動擴展、縮小、重啟服務或者重新路由流量，以確保服務的連續性。
實驗結果整理（基礎設施維度）	可以通過實驗工具得到實驗結果，需要人工整理、分析和解讀 實驗工具會生成大量的數據，包括系統指標、錯誤日志、用戶行為等。這些數據需要人工進行整理、分析和解讀，以便從中提取有用的信息和洞察。	可以通過實驗工具持續收集實驗結果，但需人工分析和解讀 實驗工具不僅可以在實驗期間收集數據，還可以在日常運營中持續監控系統的狀態。這樣可以幫助團隊更早地發現問題并進行修復。然而，仍然需要人工分析和解讀這些數據，以便理解系統的行為和性能。	可以通過實驗持續收集實驗結果和報告，并完成簡單的故障分析 實驗結果處理已經具備了一定的自動化能力。實驗工具可以自動收集數據、生成報告，并進行初步的故障分析。這樣可以大大減輕人工的工作量。但是，對于復雜的故障或深入的分析，仍然需要人工的介入。	實驗結果可預測收入損失、并完成容量規劃、區分出不容服務實際的關鍵程度 通過對實驗結果的深入分析和建模，可以預測系統故障可能帶來的收入損失，并據此進行容量規劃和資源優化。同時，可以通過實驗結果來區分哪些服務或功能是關鍵的，哪些是非關鍵的，從而有針對性地進行改進和優化。

2）成熟度評估案例

基于成熟度模型的關鍵維度，我們對多個研發團隊，進行了實際的落地評估工作，具體某個團隊的評估過程，詳見下表。

成熟度等級	最終評級	舉證	待提升項（距離下一等級）
架構抵御故障的能力	二級	擴容，有水平擴展的能力	具備技術熔斷能力
指標監控能力	三級	除了ump等基本監控之外，具備業務監控的能力	設置對照組，針對演練的分組和實際分組做業務監控對比，找出差異
實驗環境選擇	二級	生產環境無生產流量演練	可在生產環境帶生產流量進行演練
故障注入場景和爆炸半徑范圍	三級	多個場景混合注入故障	基于業務場景構造故障，在通用故障的基礎上，加入業務的場景

4、移動端混沌實驗

結合移動端特性與現有穩定性測試基礎，以下為混沌工程在移動端的系統性實施框架，涵蓋設計原則、核心要素、工具鏈及落地步驟。

a、核心原則

核心原則	描述
以業務場景為中心	故障注入圍繞核心業務流程，如物流中的攬收、派送子域，確保關鍵路徑的韌性
漸進式風險暴露	從單點可控故障開始，如模擬API超時，逐步升級至復雜故障鏈，如網絡中斷、服務端熔斷
可觀測性驅動	故障注入需同步監控業務指標，如成功率、耗時，和系統指標，如崩潰率、資源占用率
安全邊界控制	通過環境隔離，如僅限測試環境、預發環境隔離，和熔斷機制，如自動終止破壞性實驗規避生產事故

b、核心要素

1）故障場景庫設計

故障類型	典型場景	注入手段
網絡層	5G/弱網切換、DNS劫持、TCP丟包	Charles弱網模擬、OkHttp MockWebServer
設備層	強制殺進程、模擬內存泄漏、電池耗盡	ADB命令（adb shell am force-stop）、Xcode工具鏈
應用層	主線程阻塞、依賴服務（如地圖SDK）超時	代碼插樁（AOP）、第三方SDK Mock工具
數據層	本地數據庫損壞、緩存過期、時間篡改	文件系統操作、SQLite注入異常
安全層	中間人攻擊、證書校驗繞過、敏感數據明文存儲	Wireshark抓包篡改、Frida動態Hook

2）實驗優先級矩陣

業務影響	發生概率	實驗優先級
高	高	P0（立即修復）
高	低	P1（灰度驗證）
低	高	P2（監控優化）
低	低	P3（長期規劃）

c、工具鏈與自動化集成

1）分層工具矩陣

層級	推薦工具	適用場景
網絡模擬	Charles、ATC、Facebook Augmented Traffic Control	弱網、斷網、協議級攻擊測試
設備控制	ADB、iOS Simulator CLI、Google Espresso	進程終止、傳感器模擬、自動化操作注入
故障注入	Chaos Mesh、Pumba、自研SDK	容器級資源限制、服務端聯調故障
監控分析	Firebase Crashlytics、Prometheus+Grafana	崩潰追蹤、性能指標實時可視化

2）自動化流水線設計

d、落地實施步驟

1）設備覆蓋計劃

測試設備根據一線使用頻率較高的系統版本和設備類型的TOP3來選擇。

2）常態化落地機制（弱網與斷網故障注入深度實踐）

弱網與斷網測試，是驗證應用網絡韌性的核心環節。通過Charles工具鏈與深度業務場景結合，系統性驗證了移動端在極端網絡條件下的行為，為后續自動化混沌工程流水線建設提供了實踐范本。未來可進一步與mpaas監控、灰度發布聯動，實現“故障注入-監控告警-自動修復”閉環。以小哥工作臺APP為例，其測試實施過程如下：

測試方法與工具鏈	工具選型：基于Charles Proxy實現網絡故障注入，通過抓包攔截與網絡參數動態配置，模擬2G/3G/4G等網絡類型，支持自定義帶寬（如上行50kbps/下行100kbps）、延時（300ms~5s）、丟包率（10%~30%）及穩定性（周期性斷網）
	前置條件：開通測試設備與Charles的網絡互訪權限，確保流量可被代理捕獲；構建Debug包以繞過證書校驗限制，支持HTTPS請求解析。
場景覆蓋與問題挖掘	業務場景：圍繞攬收、派送等核心流程，覆蓋100+關鍵交互節點，包括：訂單提交時的網絡閃斷重試；離線模式下地址信息本地緩存與同步；弱網環境下的圖片上傳降級策略
	問題發現：累計識別20+韌性缺陷，如以下3類。 ①網絡切換容錯缺失：Wi-Fi與蜂窩網絡切換時，偶現任務狀態丟失； ②重試風暴：斷網恢復后，客戶端未采用指數退避策略，導致服務端瞬時流量激增； ③離線數據沖突：多設備離線操作后，數據合并邏輯異常引發業務臟數據。
優化方向	流程提效：推動去Debug包依賴，采用OkHttp MockWebServer或Charles Map Local功能，直接劫持線上包API響應，減少構建成本； 構建自動化弱網場景庫，將典型配置（如電梯、樓宇網絡）預設為腳本，一鍵觸發測試。

?

5、AI大模型與混沌工程的雙向融合

a、AI場景下的混沌實驗

1）AI大模型系統與傳統系統的差異

隨著AI大模型技術的快速發展，各行各業的傳統系統都在逐步融合AI大模型能力，那么由此給混沌實驗帶來了新的挑戰，與傳統系統的混沌實驗相比，融合了AI大模型能力的系統則會有一定的差異性，如下：

維度	傳統系統	AI大模型融合系統
實驗原理	基于確定性規則（如手動觸發服務宕機、模擬流量激增）。	結合AI生成對抗性故障（如動態調整故障參數、模擬數據分布偏移）。
實驗目標	驗證系統對已知故障（如網絡延遲、服務宕機）的容錯能力，確保預設的冗余、熔斷等機制有效。	包括傳統系統既有的實驗目標以外，還需： 1、驗證AI模型的動態適應能力（如故障預測、自愈決策），驗證系統在復雜、動態環境中的智能響應能力。 2、評估AI模型的魯棒性（如對抗數據擾動、模型漂移）、AI與人類決策的協作效率
場景設計	硬件/網絡故障、服務中斷	數據異常、模型推理瓶頸、算力動態調度
監控指標	基礎資源、接口調用、服務可用性（SLA）、平均恢復時間（MTTR）、錯誤率。	保留傳統指標，并新增AI相關指標： - 模型推理延遲、決策準確率； - 異常檢測召回率； - 動態策略調整效率。 -數據質量（如特征分布偏移）、模型置信度、AI與人類決策一致性。
結果分析	單點故障定位、容錯機制驗證	模型魯棒性評估、數據鏈路風險、業務影響量化

因此，在對AI大模型融合系統實施混沌實驗時，在滿足傳統系統混沌實驗關注點的同時，還需要更加關注模型服務可靠性（如推理延遲、數據異常影響），覆蓋數據噪聲、GPU資源爭用及模型輸出漂移等復雜場景，指標監控上應額外追蹤模型性能（如準確率）、數據分布偏移及GPU利用率。在進行結果分析時需量化模型魯棒性、數據鏈路風險及業務間接損失（如用戶信任）。

?

2）AI大模型混沌工程實驗

①實驗目標

?驗證大模型服務降級/熔斷策略的有效性

?測試模型服務與業務系統的異常協同能力

?檢測數據流-模型-業務鏈路的健壯性

?驗證模型性能監控與自動恢復機制。

②實驗原則

?最小化爆炸半徑：從非核心業務開始，逐步擴大范圍

?可觀測性：確保所有操作可監控、可記錄、可回滾

?穩態假設：明確定義系統正常運行的指標（如成功率、延遲、QPS等）

?生產環境優先：優先在生產環境進行（需嚴格規劃）

③實驗標準

實驗準入	實驗準出
演練前，研測雙方，未完成演練分組確認、數據隔離確認，禁止啟動演練	故障識別效率：守方在5分鐘內識別故障，同時在“常態化備戰群”報備故障
演練場景，未通過研測聯合評審，并發出評審紀要，禁止啟動演練	故障定位效率：守方在10分鐘內定位故障，同時在“常態化備戰群”同步故障原因
演練周期內，指定攻守人員未在指定場所準備就緒，禁止啟動演練	止損效率：守方在15分鐘內通過自動或手動方式，降級止損
演練平臺任務，未與演練劇本及觀察員，二次對齊確認，禁止啟動演練	弱依賴有效性：弱依賴類故障，不影響核心業務流轉
演練集群申請列表檢查完畢	故障修復效率：如演練場景為有損故障、或故障注入過程對線上業務產生影響，需要在20分鐘內修復
	演練退出標準：故障注入超過5分鐘未被識別、超過10分鐘未被定位、超過15分鐘未止損，對應場景終止故障注入，并完成環境初始化，標記演練未通過

④場景設計原則

針對AI大模型工程系統的混沌實驗設計，需結合核心業務場景和底層依賴（算力、數據、模型、網絡），重點驗證系統的容錯性、自適應能力和用戶體驗魯棒性。

故障分類	具體場景	實驗步驟	過程監控	預期結果
基礎設施層	GPU節點故障	1. 選擇1個GPU計算節點 2. 模擬硬件故障（如nvidia-smi注入故障代碼） 3. 持續10分鐘	- GPU利用率/溫度實時監控 - 節點存活狀態檢測 - 服務自動遷移日志追蹤	- 服務自動遷移至備用節點 - 業務中斷時間<30秒 - GPU資源池利用率波動<15%
	顯存溢出攻擊	1. 逐步增加推理請求的輸入尺寸 2. 監控顯存使用率 3. 觸發OOM后記錄恢復流程	- 顯存分配/釋放速率監控 - OOM錯誤日志捕獲 - 關聯服務健康狀態檢測	- 觸發熔斷機制自動重啟服務 - 錯誤日志記錄完整率100% - 未影響其他模型服務
服務層	模型API高延遲	1. 在API網關注入10000ms延遲 2. 維持15分鐘 3. 監控降級策略觸發情況	- 請求響應時間分布監控 - 客戶端重試次數統計 - 降級策略觸發狀態	- 客戶端超時重試機制生效 - 備用模型啟用率>90% - 整體錯誤率上升≤5%
	模型熱切換失敗	1. 推送新模型版本 2. 強制中斷切換過程 3. 驗證回滾機制	- 模型版本哈希校驗 - 切換過程耗時監控 - 請求成功率波動檢測	- 10秒內檢測到切換失敗 - 自動回退至穩定版本 - 業務請求成功率>99.5%
數據流層	特征存儲中斷	1. 切斷特征存儲服務網絡 2. 持續5分鐘 3. 恢復后驗證數據一致性	- 特征服務健康檢查 - 本地緩存命中率監控 - 數據一致性校驗	- 自動切換本地特征緩存 - 數據恢復后差異率<0.1% - 業務決策準確率下降≤3%
	實時數據亂序	1. 注入10%亂序數據流 2. 逐步提升至50%亂序率 3. 監控處理延遲	- 數據流處理延遲監控 - 窗口計算偏差檢測 - 亂序告警觸發統計	- 流處理引擎亂序容忍機制生效 - 最終計算結果偏差<1% - 告警系統在30秒內觸發
模型層	模型精度下降	1. 修改在線模型權重參數 2. 注入5%對抗樣本 3. 監控模型輸出穩定性	- 模型輸出分布偏移檢測 - 對抗樣本識別率 - 業務決策錯誤率波動	- 模型監控系統30秒內告警 - 自動切換備用模型 - 業務決策錯誤率<警戒閾值(如2%)
	多模型投票失效	1. 關閉1個投票模型實例 2. 注入矛盾樣本 3. 驗證決策一致性	- 投票結果置信度監控 - 模型間結果差異率 - 人工干預請求量統計	- 投票機制自動降級為權重模式 - 最終決策置信度>85% - 人工復核請求觸發率<5%

?

b、快遞快運小哥AI智能助手-混沌工程探索

1）系統簡介

快遞快運終端系統是服務于一線快遞小哥及站點管理者的日常工作作業實操系統，是京東物流作業人員最多、物流攬派作業最末端以及作業形態多元化的系統。

AI大模型具有超強自然語言處理、泛化能力、意圖理解、類人推理以及多元化結果輸出的獨特能力，基于此，快遞快運小哥AI智能助手通過結合AI大模型工程系統、大數據、GIS、語音SDK等分別在攬收、派送、站內、輔助、問答服務五大類作業環節上實現了如小哥攬收信息錄入、打電話、發短信、查詢運單信息、小哥攬派任務信息聚合查詢、知識問答及攬派履約時效精準化提示等場景。提升小哥作業效率和攬派實操體驗。

2）系統架構分析

快遞快運小哥AI智能助手【產品架構圖】快遞快運小哥AI智能助手故障演練【系統架構圖】

3）實驗場景

針對AI大模型工程系統的混沌實驗設計，需結合核心功能（智能提示、智能問答、智能操作）和底層依賴（算力、數據、模型、網絡），重點驗證系統的容錯性、自適應能力和用戶體驗魯棒性。

故障分類	具體場景	實驗步驟	預期結果
服務層	模型API高延遲 (AI大模型工程系統提供給小哥后臺服務系統的API高延遲)	·從泰山平臺注入10000ms延遲故障場景 ·故障維持15分鐘 ·停止故障場景注入，恢復大模型能力	·小哥工作臺APP客戶端檢測到大模型服務接口超時（如攬收數據錄入時，無法得到響應數據），啟動降級策略機制，切斷大模型服務，兜底回到五大模型服務模式，小哥可以正常繼續標準化作業 ·小哥工作臺APP持續在無大模型服務下運轉 ·小哥工作臺APP客戶端檢測大模型能力恢復，啟動大模型能力服務
模型層	模型精度下降	·修改在線模型權重參數 ·注入5%對抗樣本數據（線上已錄制的大模型訪問數據流量） ·恢復大模型參數	·大模型監控系統30秒內告警，識別到模型參數異常變更，預警通知開發人員，開發人員發現模型參數異常 ·客戶端發現大模型使用能力下降，開發啟動自動切換備用模型（參數已經適配好的模型），開發下線參數異常模型 ·開發發現參數異常模型恢復，重新啟動上線

?

c、混沌工程的AI智能化演進展望

混沌實驗的AI化演進是系統穩定性測試與人工智能技術深度融合的重要趨勢。這一演進不僅體現在實驗工具的智能化升級上，更體現在實驗設計、執行與分析的全鏈路優化中。以下分別從技術融合、工具創新及場景擴展三個維度展開論述：

1）技術融合：AI賦能混沌實驗的核心環節

混沌實驗包含了實驗設計、實驗執行及實驗監控與根因分析三大核心環節，具體而言。

?

①實驗設計智能化

傳統混沌實驗依賴于人工假設（如“當網絡延遲增加時，系統可用性應保持在99.99%以上”），而AI可通過歷史故障數據與系統日志，自動識別潛在脆弱點并生成實驗假設。

例如，基于強化學習的AI模型可模擬復雜故障場景的組合，優化實驗參數（如故障注入的強度、范圍），提升測試覆蓋率。AI可分析服務調用鏈，預測依賴服務失效后的級聯影響，并自動設計針對性的網絡分區實驗。在驗證電商大促場景下的訂單支付鏈路韌性時，通過AI驅動的智能實驗設計，系統可自動化發現潛在風險組合并生成針對性實驗方案，具體而言

實驗設計關鍵環節	實驗設計關鍵流程
歷史數據挖掘與脆弱點識別	數據輸入： ·歷史故障日志：比如過去3年大促期間記錄的168次服務降級事件（如庫存超賣、優惠券死鎖）。 ·系統拓撲：服務依賴關系（如支付網關調用訂單數據庫的頻率為5000次/秒）。 ·性能基線：日常與大促期間的CPU/內存/延遲指標對比數據 AI分析： ·使用圖神經網絡（GNN）分析服務調用鏈，識別高頻依賴且資源消耗高的節點（如優惠券服務在流量峰值時CPU利用率達90%）。 ·基于關聯規則挖掘（Apriori算法）發現故障組合模式（如“庫存服務響應延遲>200ms”與“支付網關連接池耗盡”共同發生的概率為72%）。
強化學習生成實驗參數	強化學習模型（PPO算法）配置： ·狀態空間：優惠券服務線程池使用率、支付網關活躍連接數、訂單數據庫寫入延遲。 ·動作空間： ·故障類型：線程阻塞（阻塞比例10%~100%）、連接池限制（50%~20%容量）。 ·注入時機：流量爬坡期（0%~100%峰值）。 ·獎勵函數： ·正向獎勵：實驗觸發系統熔斷/降級（如訂單服務自動切換為本地緩存）。 ·負向獎勵：訂單失敗率>0.1%或實驗引發級聯故障。 ·訓練過程： 在仿真環境中模擬10萬次實驗，AI學習到最優策略： “在流量達到峰值的70%時，先注入優惠券服務50%線程阻塞，待系統觸發自動擴容后，再限制支付網關連接池至30%容量”
實驗執行與動態調控	初始注入：AI按策略在流量爬坡期注入優惠券服務50%線程阻塞。 動態響應： ·系統檢測到線程池滿載，自動擴容優惠券服務實例（從10個擴展到15個）。 ·AI監控到擴容完成，立即觸發支付網關連接池限制至30%。 異常檢測： ·訂單數據庫寫入延遲突增至800ms（超過基線300%），AI通過LSTM模型預測5秒內可能觸發死鎖，立即停止實驗并回滾故障。

通過借助AI智能實驗方案設計，獲得以下收益。

優勢項	描述
風險發現效率提升	提前識別出4個高危漏洞
驗證成本降低	實驗耗時從人工方案的48小時縮短至6小時，資源消耗減少60%
韌性增強	優化后系統在真實大促中訂單失敗率從0.15%降至0.02%，且故障平均恢復時間（MTTR）從8分鐘縮短至90秒

以上，AI不僅替代了人工設計中的重復勞動，更重要的是通過系統化挖掘隱性關聯與動態博弈式測試，將混沌工程從“已知-已知”測試升級為“已知-未知”甚至“未知-未知”風險探索。

?

②執行與調控動態化

AI的動態決策能力使得混沌實驗從“預設故障”向“自適應故障注入”演進。例如，通過實時監控系統指標（如CPU負載、請求延遲），AI可動態調整故障注入的強度或終止實驗，避免超出系統容災閾值。通過AI驅動的動態實驗調控，可以使混沌工程實現更多的突破，例如：實現動態適應性，從“固定劇本”升級為“實時博弈”，更貼近真實故障場景；實現精準調控，避免因過度測試導致業務受損，平衡實驗風險與價值；實現多目標優化，同時驗證性能、穩定性、安全性的綜合影響，例如：驗證系統在流量激增時自動擴縮容的能力。

實驗場景	在大促期間實施彈性伸縮混沌實驗
實驗目標	驗證系統在流量激增時自動擴縮容的能力
AI調控策略	初始故障：模擬流量突增50%，觸發自動擴容 動態調整： ·若系統擴容速度過慢（如新實例啟動時間>3分鐘），AI自動追加CPU負載故障（如占用80% CPU），資源爭用下的擴容極限。 ·若擴容成功但負載均衡異常（如某些實例請求量超標），AI注入節點宕機故障，驗證服務遷移能力。 終止條件：當訂單失敗率超過1%時，立即停止實驗并觸發告警
預期結果	AI發現擴容策略在CPU高負載時延遲增加2倍，推薦優化預熱腳本并增加冗余實例池

?

③智能監控與智能根因分析

傳統監控工具（如Prometheus）依賴人工設置告警閾值，而AI可通過異常檢測算法（如LSTM、自編碼器）實時識別系統行為的偏離，并關聯故障注入事件，快速定位根因。例如，南京大學利用AI分析古生物大數據揭示復雜系統的演化模式，類似方法可用于預測分布式系統中的故障傳播路徑。

智能監控與根因分析通過AI技術實現從“被動告警”到“主動預測-定位”的跨越，其核心是通過多維度數據融合與因果推理，快速定位復雜系統中的故障根源。其技術原理可以從以下幾個方面深入展開：

異常檢測：動態閾值與模式識別	傳統監控缺陷：人工設置靜態閾值（如“CPU使用率>90%觸發告警”），無法適應業務波動（如大促期間CPU正常使用率可能長期維持在85%）
	AI解決方案： 1）時序預測模型（LSTM/Prophet）：基于歷史數據預測指標正常范圍（如預測大促期間訂單服務的請求延遲基線為50ms±10ms），動態調整告警閾值； 2）無監督異常檢測（自編碼器/Isolation Forest）：通過對比實時數據與正常模式的特征差異（如請求成功率的分布偏移），識別未知異常類型（如特定API接口的偶發超時）
根因定位：因果圖與傳播路徑推理	傳統方法缺陷：人工排查需逐層檢查日志、指標和鏈路追蹤，耗時長且易遺漏隱性依賴
	AI解決方案： 1）服務拓撲建模（圖神經網絡/GNN）：將微服務調用關系建模為圖結構，分析節點（服務）與邊（依賴）的異常傳播權重。 2）因果推理（貝葉斯網絡/結構方程模型）：結合故障注入實驗數據（如“當Redis緩存失效時，數據庫QPS增加300%”），構建故障因果鏈，量化各因素對目標異常（如訂單失敗率）的貢獻度。
故障傳播預測：復雜系統仿真	仿生學啟發：借鑒南京大學分析古生物演化的方法（如模擬環境劇變對物種多樣性的影響），通過數字孿生技術構建系統仿真模型，預測故障傳播路徑
	關鍵技術： 1）故障注入+強化學習：模擬隨機或組合故障（如“數據庫主從延遲+緩存擊穿”），觀察系統響應并生成故障傳播概率圖。 2）傳播路徑預測：若檢測到A服務異常，AI基于歷史數據預測其下游影響（如A服務故障有70%概率在30秒內導致B服務超時）

AI驅動的智能監控與根因分析通過動態異常檢測-因果推理-傳播預測的三層技術架構，將故障定位從“人工地毯式排查”升級為“秒級精準定位”。此能力不僅大幅縮短了故障恢復時間，更重要的是通過預測潛在連鎖反應（如“緩存失效→數據庫過載→服務雪崩”），推動系統架構從“容災”向“抗災”演進。未來，結合故障注入實驗的閉環驗證，AI監控有望實現“自愈推薦”，即自動生成修復策略并驗證其有效性，真正實現系統的智能韌性。

?

2）AI驅動的混沌工程平臺能力升級

①混沌工程工具AI能力建設焦點

以下針對目前的發展方向，混沌工程平臺，可基于以下幾個方面拓展能力升級。

故障類型	故障描述	參數說明
GPU節點故障	故障注入平臺的配置需要結合硬件特性、分布式訓練框架的容錯機制以及業務場景需求，包含：硬件級故障、軟件級故障以及環境級故障	參數類別 示例參數 說明 故障類型 gpu_failure_type 顯存錯誤/驅動崩潰/NVLink中斷等 持續時間 duration 瞬時故障（毫秒級）或持續故障（分鐘級） 影響范圍 gpu_index 指定GPU卡序號（如0-3） 錯誤概率 error_rate 顯存訪問錯誤的發生頻率（如1e-6次/操作）
顯存溢出攻擊	模擬惡意或異常顯存占用行為，驗證系統對顯存資源耗盡場景的防御能力、容錯機制及恢復效率，包含： 顯存暴力搶占：持續分配顯存直至耗盡（模擬惡意進程）。 顯存泄漏攻擊：周期性分配顯存但不釋放（模擬代碼缺陷）。 梯度爆炸攻擊：注入異常梯度值導致反向傳播顯存需求激增。 多任務資源競爭：并行啟動多個高顯存任務（測試調度策略的健壯性）。	參數項 可選值/示例 說明 fault_type gpu_memory_overflow 故障類型（顯存溢出攻擊） injection_method direct_allocation（直接分配） gradient_attack（梯度爆炸） multi_task（多任務競爭） 顯存溢出的具體實現方式 target_gpu 0（GPU卡序號） 指定攻擊的目標GPU設備 memory_fill_rate "90%" 或 "10GB" 顯存占用目標閾值（百分比或絕對值） leak_speed "100MB/s" 顯存泄漏速率（僅對泄漏攻擊有效） attack_duration "5m"（5分鐘） 攻擊持續時間（瞬態攻擊或持續攻擊）
模型熱切換失敗	在不停機的情況下切換模型版本時，因資源競爭、依賴沖突或狀態同步錯誤導致新模型加載失敗或舊模型殘留，引發服務中斷或預測結果混亂。例如：新模型加載時顯存不足、舊模型卸載不徹底（如未釋放GPU資源）、版本元數據（如輸入輸出格式）不兼容	參數項 可選值/示例 說明 fault_type model_hotswap_failure 故障類型（模型熱切換失敗） injection_method resource_lock（資源鎖定） metadata_corruption（元數據損壞） 模擬資源競爭或版本元數據錯誤 failure_point pre_load（加載前） post_unload（卸載后） 指定故障注入階段（加載前/卸載后） rollback_strategy auto_rollback（自動回滾） manual_intervention（人工介入） 切換失敗后的恢復策略 retry_threshold 3（最大重試次數） 加載失敗后的自動重試次數
實時數據亂序	數據流因網絡延遲、分片傳輸錯誤或消息隊列故障導致時序數據亂序，影響時間敏感型模型（如LSTM、Transformer）的預測準確性。例如：時間窗口內數據順序錯亂、數據延遲超過模型允許的時序容忍度、亂序數據觸發模型狀態異常（如狀態機崩潰）	參數項 可選值/示例 說明 fault_type data_out_of_order 故障類型（實時數據亂序） disorder_rate "30%" 亂序數據比例（如30%的數據順序被打亂） max_latency "5s" 最大延遲時間（模擬數據遲到） window_size 1000 受影響的時間窗口大小（單位：數據條目數或時間范圍） distribution uniform（均勻分布） burst（突發亂序） 亂序分布模式
模型精度下降	因輸入數據漂移、模型參數篡改或計算單元異常（如GPU浮點運算錯誤），導致模型預測精度顯著下降且未被監控系統及時捕獲。例如：輸入數據分布偏移（如傳感器數據偏差）、模型權重文件被部分覆蓋或損壞、浮點計算靜默錯誤（如CUDA核函數異常）	參數項` 可選值/示例 說明 fault_type model_accuracy_drop 故障類型（模型精度下降） noise_level "10%" 輸入數據噪聲強度（如添加10%高斯噪聲） weight_corruption random（隨機擾動） targeted（定向攻擊） 模型參數篡改方式 error_type float_error（浮點錯誤） quantization（量化異常） 計算單元錯誤類型 detection_threshold 0.95（置信度閾值） 觸發告警的精度下降閾值（如置信度低于0.95時告警）
多模型投票失效	在多模型投票決策系統中，因部分模型故障、通信中斷或投票邏輯缺陷，導致最終決策結果與真實多數投票結果不一致。如：單個模型輸出異常（如返回空值或極端值）、投票結果聚合邏輯錯誤（如加權投票權重未生效）、模型間通信超時或數據丟失	參數項` 可選值/示例 說明 fault_type ensemble_voting_failure 故障類型（多模型投票失效） failure_mode silent（靜默失敗） noisy（輸出噪聲） 模型故障類型 target_models ["model_a", "model_c"] 指定需要注入故障的模型列表 communication_delay "2s" 模擬模型間通信延遲 voting_algorithm majority（多數表決） weighted（加權投票） 投票算法類型（驗證算法容錯性）

②自動化工具鏈的升級

當前的各類工具主要依賴手動配置，通過AI的引入使得工具能夠從以下幾個維度升級

自動化配置點	配置描述
智能選擇靶點	基于系統拓撲和負載情況，優先測試高風險的組件
生成實驗劇本	結合強化學習模擬多故障疊加場景，如“同時觸發數據庫延遲與容器資源耗盡
自動修復建議	根據實驗結果推薦冗余設計或負載均衡策略

③應用層故障注入的精細化

應用級故障注入工具通過“坐標系統”，精確定位實驗范圍（如特定用戶或服務版本），而AI可進一步擴展這一能力。例如，通過自然語言處理解析日志，自動生成針對特定API接口的異常返回規則

④場景擴展

?智能化場景推薦

包括不限于，基于系統架構特性、基于既往線上故障、基于系統核心指標異動的智能化場景推薦，具體而言：

智能化場景推薦	技術原理	設計方案
基于系統架構特性的場景推薦	·拓撲結構分析： ·通過服務注冊中心（如Nacos、Consul）獲取微服務依賴關系，構建系統調用拓撲圖。 ·使用**圖神經網絡（GNN）**計算節點中心性（如介數中心性），識別核心鏈路（如“訂單創建→支付→庫存扣減”路徑）。 ·資源依賴建模： ·分析服務與底層資源（數據庫、緩存、消息隊列）的綁定關系，定位資源競爭熱點（如多個服務共享同一Redis集群）。	·輸入：系統拓撲圖、服務QPS、資源使用率（如數據庫連接數）。 ·算法： ·關鍵路徑識別：基于PageRank算法標記高權重節點（如支付網關）。 ·瓶頸預測：結合資源水位預測模型（如ARIMA），推斷未來壓力點。 ·輸出： ·推薦實驗場景： ·針對核心鏈路：模擬支付網關高延遲。 ·針對共享資源：注入Redis主節點宕機。
基于既往線上故障的場景推薦	·故障模式挖掘： ·對歷史故障日志進行NLP解析（如BERT模型），提取故障類型、影響范圍、修復措施。 ·使用**關聯規則挖掘（Apriori算法）**發現高頻故障組合（如“緩存雪崩+數據庫連接池耗盡”）。 ·時序模式分析： ·基于LSTM構建故障時序模型，預測周期性風險（如大促前1小時庫存服務易出現超賣）。	·輸入：歷史故障數據庫、修復記錄、時間戳。 ·算法： ·故障關聯圖譜：構建故障-服務-資源的關聯網絡。 ·相似度匹配：通過余弦相似度匹配當前系統狀態與歷史故障特征。 ·輸出： ·推薦實驗場景： ·復現歷史高頻故障：優惠券服務線程池滿。 ·預測性場景：模擬大促開始后30分鐘的緩存擊穿。
基于系統核心指標異動的場景推薦	·動態基線計算： ·使用Prophet時序模型預測指標正常范圍（如日常CPU使用率40%→大促期間允許80%）。 ·多維度異常檢測： ·通過**多變量自編碼器（MAE）**分析指標組合異常（如“CPU 85% + 數據庫鎖等待數激增”）。	·輸入：實時監控指標流（Prometheus）、業務日志（ELK）。 ·算法： ·異常模式聚類：對異常事件進行K-means聚類，識別典型模式（如“突增流量型”“資源泄漏型”）。 ·根因映射：將異常模式映射至預設故障場景庫。 ·輸出： ·推薦實驗場景： ·當檢測到訂單服務延遲突增時，推薦測試“庫存服務緩存失效”。 ·當數據庫鎖等待數超標時，推薦測試“分布式鎖服務故障”。

?云原生與邊緣計算

在動態的云原生環境中，AI可預測容器編排（如Kubernetes）的故障恢復效率，并驗證自動擴縮容策略的有效性。

?跨學科復雜系統模擬

混沌實驗的理念正被引入生物、氣候等復雜系統研究。例如，南京大學團隊利用AI模擬元古宙生命演化中的“雪球地球”事件對生物多樣性的沖擊這種“環境混沌實驗”為評估極端條件下的系統韌性提供了新范式。

隨著AI技術的不斷發展和應用場景的落地實施，混沌實驗正從“被動容災”轉向“主動韌性構建”，其核心是通過智能算法提升實驗的精準度與系統自愈能力。未來，隨著AI與量子計算、生物模擬等領域的交叉，混沌實驗或將突破工程范疇，成為探索復雜系統普適規律的科學工具。

6、【積微成著】專業分享

??【積微成著】性能測試調優實戰與探索（存儲模型優化+調用鏈路分析）：http://xingyun.jd.com/shendeng/article/detail/24444?forumId=174&jdme_router=jdme://web/202206081297?url%3Dhttp%3A%2F%2Fsd.jd.com%2Farticle%2F24444?

??【積微成著】規模化混沌工程體系建設及AI融合探索：http://xingyun.jd.com/shendeng/article/detail/44438?forumId=99&jdme_router=jdme://web/202206081297?url%3Dhttp%3A%2F%2Fsd.jd.com%2Farticle%2F44438?

??【積微成著】“泰山變更管控”在物流技術的深入實踐：http://xingyun.jd.com/shendeng/article/detail/45193?forumId=1414&jdme_router=jdme%3A%2F%2Fweb%2F202206081297%3Furl%3Dhttp%3A%2F%2Fsd.jd.com%2Farticle%2F45193

審核編輯 黃宇