《北京金融科技產業聯盟：2023金融級混沌測試能力平臺建設要求研究報告（34頁）.pdf》由會員分享，可在線閱讀，更多相關《北京金融科技產業聯盟：2023金融級混沌測試能力平臺建設要求研究報告（34頁）.pdf（34頁珍藏版）》請在三個皮匠報告上搜索。

1、金融級混沌測試平臺建設能力研究報告北京金融科技產業聯盟2023 年 10 月版權聲明本報告版權屬于北京金融科技產業聯盟，并受法律保護。轉載、編摘或利用其他方式使用本白皮書文字或觀點的，應注明來源。違反上述聲明者，將被追究相關法律責任。I編制委員會主任聶麗琴編委會成員王璐張海燕編寫組成員崔杰杜昆鵬李博文李振欒琪肖晶王耀強毋文濤張翔葉強林編審黃本濤張蕾參編單位：北京金融科技產業聯盟中國建設銀行股份有限公司平凱星辰（北京）科技有限公司北京國家金融科技認證中心有限公司北京同創永益科技發展有限公司II摘要摘要混沌工程是通過主動向系統中引入軟件或者硬件的異常狀態（擾動），制造故障場景并根據系統在各種壓力下

2、的行為表現確定優化策略的一種系統穩定性保障手段。應用混沌工程可以對系統抵抗擾動并保持正常運作的能力（穩定性）進行校驗和評估，提前識別未知隱患并進行修復，進而保障系統更好地抵御生產環境中的失控條件，提升整體穩定性。本報告以混沌測試工具集為基礎，采用開源云原生模式構建自動化混沌工程平臺，針對分布式系統的復雜性特點，設計不同層次的故障進行模擬。平臺除提供應用層以及實際物理環境故障模擬外，還提供較為完善的故障編排功能，以便監控分布式系統狀態，找出項目潛在的風險。本報告所述的混沌工程平臺相對完整，可為國內金融行業構建混沌測試驗證平臺，提供實踐經驗和可行的參考方案。III目錄一、混沌測試平臺建設背景與目標

3、.1.1（一）建設背景.1（二）建設目標.2二、混沌測試平臺建設要求.3（一）功能要求.3（二）適配性要求.7（三）集成要求.7三、混沌測試平臺建設情況.8（一）系統構成.8（二）技術架構.9（三）功能模塊.10（四）故障種類.12四、混沌平臺測試方案與測試實踐.13（一）測試目標.13（二）測試內容.14（三）測試過程.15五、混沌測試平臺建設實踐.271一、混沌測試平臺背景與目標（一）建設背景隨著數字化轉型，金融行業加快了新一代架構轉型的步伐，由傳統的 SOA 架構向分布式架構、去中心化發展，當前還進階到注重云化支持和異構化微服務支持的服務網格模式。系統規模日益龐大，交易鏈路長、數據流轉復

4、雜，微服務架構由于技術異構性、具備彈性伸縮、可擴展性等優勢，得到廣泛推廣；同時微服務架構在使用過程中又面臨諸多挑戰，由于系統級依賴增多而帶來的不確定性風險指數級增長；通過傳統手段進行高可用驗證、代碼健壯性審查、加大測試范圍、提高監控敏感度等手段，都無法有效發現系統潛在風險。在微服務架構下，系統的風險管理越來越重要，提高系統韌性成為必然發展趨勢。微服務架構轉型的驅動下，“混沌工程”實踐可以通過規范化，流程化的方案對系統進行一定程度的“隨機破壞”，讓故障在可控范圍內頻繁發生，在此過程中可以深入地認知故障和系統，并達到持續改進的效果?；煦绻こ淌峭ㄟ^向系統中引入軟件或硬件的異常狀態（擾動），制造故障場

5、景并根據系統在各種壓力下的行為表現確定優化策略的一種系統穩定性保障手段。其原則是可量化的穩定狀態、可反映真實場景，但風險未知的假設、影響最小化?；煦绻こ汤脤嶒炋崆疤街到y風險，通過架構優化和運維模式的改進來解決系統風險，真正提升系統架構韌性，增強故障免疫力。2混沌工程是在分布式系統上進行實驗的學科，首次提出是在2008 年 8 月，由網飛公司（Netflix）提出。2012 年 Chaos Monkey在 Simain Army 項目中開源，Simian Army 成為首個開源的混沌工程工具集。2019 年開始，國內企業紛紛引入并實踐混沌工程?；煦绻こ掏ㄟ^主動向系統中引入軟件或者硬件的異常狀

6、態（擾動），制造故障場景并根據系統在各種壓力下的行為表現確定優化策略。應用混沌工程可以對系統抵抗擾動并保持正常運作的能力進行校驗和評估，還可以提前識別未知隱患并進行修復，進而保障系統更好地抵御生產環境中的失控條件。目前國內混沌工程領域主要集中在一些大型互聯網企業，應用領域和范圍較小，商業化程度不高。金融行業建行、興業、中原、浦發、招行等國有和商業銀行均成立了內部的混沌工程團隊，并開展混沌實驗。例如，建信金科混沌工程故障演練平臺應用于分布式平臺相關組件，如應用路由、配置中心、分布式緩存、分布式消息、索引維護服務、分布式數據庫等；在場景方面，建信金科在兩地三中心多 AZ 故障、銀行核心沖正交易異常

7、時序、代收代付慢交易、應用路由服務治理、應用路由堵塞問題模擬等場景中。（二）建設目標1.業務目標1.業務目標為豐富微服務和分布式系統的故障測試手段，解決分布式系統故障高發且難以預測的問題，通過研發自動化水平高、通用性3好、易用性強的混沌工程測試平臺，幫助金融機構提升開展混沌實驗的效率，降低開展混沌實驗的成本，不斷提升分布式系統的穩定性和容錯能力。在現有研究基礎上，重點突破全類型故障模擬、可視化操作、串并行故障編排、自動化監測告警等關鍵技術，在金融行業不同業務場景開展示范應用，進一步推動混沌工程方法普及，促進軟件產業健康發展?；煦鐚嶒炇侵冈诨煦绻こ虦y試平臺上面向復雜系統開展故障模擬、故障編排、故

8、障注入、狀態監測和故障恢復等一系列操作的集合。2.技術目標2.技術目標研究故障編排引擎、深入底層的故障注入、有效控制最小爆炸半徑等關鍵技術，在混沌測試平臺上提供混沌實驗設計、實驗編排、故障注入、狀態檢查、監控告警、實驗報告等功能，實現高度自動化和可視化的操作，做到故障對應用無侵入，減少組件依賴，構建完整的混沌工程閉環生態。二、混沌測試平臺建設要求（一）功能要求主要功能應包括混沌實驗模塊、故障模擬發壓模塊、可觀測性模塊、權限管理模塊、專家庫模塊 5 大部分?；煦鐚嶒災K支持對待測底層設施物理機/虛擬機、容器進行管理；故障模擬發壓模塊支持對混沌實驗的過程進行管理，同時還對演練過程混沌實驗事件進行標

9、注；可觀測性模塊支持對實驗全過程的監測和分析；權限管理模塊支持進行混沌實驗人員管理。專家庫模塊支持4沉淀典型故障業務場景，提供平臺人員使用產品的效率。各個功能模塊具體如下描述：1.混沌實驗模塊1.混沌實驗模塊混沌實驗調度組件。該組件基于自定義資源對象 CRD 設計，可以用來創建、配置和管理多種類型的混沌實驗，組件接收到混沌實驗對象的創建、更新等事件后，獲取到具體混沌實驗的最新配置。在通過解析調度規則以及實驗配置后，執行具體的混沌實驗。使用該組件，用戶可以通過 YAML 文件的方式自定義混沌實驗的目標、攻擊對象、調度規則等。組件使用完全云原生的方案，實現完全無侵入的故障注入，并且提供了很強的拓展

10、性，用戶可以直接在此組件上增加新的故障注入類型。故障注入組件。組件提供不同類型原子故障的注入和恢復功能，以 DaemonSet 方式運行在每一個物理節點上，在接受來自調度組件的故障注入請求后，按照故障請求的配置，修改具體容器的 cgroup，或者進入具體 Pod 命名空間下，通過 tc、iptables、ipset 等工具干擾具體的網絡資源對象。同時該組件使用 eBPF提供了內核故障注入的能力。物理節點（虛擬機）編排引擎。該引擎提供多節點混沌實驗編排的能力，用戶將目標節點注冊到該組件后，可以使用該引擎對已注冊的節點執行各類故障注入。用戶可以直接使用該引擎自定義混沌實驗的步驟，配置檢查程序等，并

11、且提供復用已有的混沌實驗場景能力。該引擎包含任務定義、任務調度、任務執行模5塊，將基于 Kubernetes CRD 事件機制和 Golang 語言開發，將每個可調度的物理節點和編排任務抽象為具體的 CRD 對象并使用 Watch 機制監控任務的具體變化，并實現特有的 controller組件去處理具體的事件變化，并按照具體的配置解析成具體的任務交給任務執行模塊，任務由入口任務和節點任務組成，入口任務會被最先調度，后根據入口任務內定義的子任務調度具體的節點任務，直到所有的任務都被執行過后，整個編排任務執行結束。插件系統。不同應用由于環境不同會產生完全不同的故障場景，很難在一個平臺中涵蓋所有可能

12、的故障。為了能夠重復利用社區的力量，以及收集實現世界中可能出現的場景，插件系統提供了用戶自定義故障類型能力。用戶可以使用此插件系統來定制化自己的混沌故障類型，如 RabbitMQChaos、TiDBChaos 等。插件系統是整個混沌工程生態中關鍵部分，用戶將自定義的插件提交到插件庫，這樣其他用戶可以直接復用此插件，很大程度降低了用戶使用混沌實驗的成本，避免重復的工作。2.故障模擬發壓模塊2.故障模擬發壓模塊故障模擬發壓模塊以命令行工具方式提供服務，用戶可以在物理節點或者虛擬機節點上直接運行相關命令，該工具會根據提供的命令配置，解析成對應的故障規則，隨后執行具體操作。使用該組件，用戶可以方便的在

13、單物理節點或者虛擬機節點上，隨機殺或者暫停指定的進程，模擬各種網絡異常，模擬磁盤壓力，CPU 繁忙，內存壓力等，同時提供歷史查詢，故障恢復等功能，6方便用戶快速的實現故障的模擬。該故障工具基于 Golang 語言和 SQLite3 開發。3.可觀測性模塊3.可觀測性模塊可觀測性模塊進一步降低簡化混沌實驗的步驟和提供對混沌實驗的可觀測性，讓用戶可以通過鼠標和填寫簡單的表單實現混沌實驗和場景的設計，并且在可觀測性模塊上提供方便的混沌實驗檢查機制和完整的實驗報告。整個可觀測性模塊包括獨立混沌實驗的定義，需要支持定義混沌實驗范圍，實驗具體行為，并且支持暫停和恢復操作?？捎^測性模塊還包含設計整個混沌實驗

14、場景，需要滿足應用狀態定義，展示應用監控信息，多個混沌實驗場景的編排，以及告警規則設置和報告信息設置等?？捎^測性模塊同時還提供服務監控和健康檢查服務。在進行混沌實驗過程中，首先需要確認系統的穩態，并且基于穩定狀態提出假設。為了簡化用戶進行混沌實驗操作步驟，本方案計劃在混沌工程平臺中提供定義應用系統穩定狀態方式，支持用戶在自定義任務通過 HTTP 狀態接口或者訪問健康系統的指標方式判斷系統的穩定狀態。具備的應用系統穩態的判斷能力，標志著混沌系統平臺具備了混沌工程操作閉環的能力。4.權限管理模塊4.權限管理模塊權限管理模塊?；煦鐚嶒炓竽軌蛴行У目刂谱钚”?，并且不同用戶之間有一定的隔離，只有提供

15、有效的安全保障，用戶才能放心的開展自己的混沌實驗。為了達到此目標，權限管理模7塊構建自己的權限機制，用戶可以根據混沌實驗的范圍分配實驗人員和實驗環境的權限，有效的控制混沌實驗的范圍和保障混沌實驗的安全。同時用戶可以使用此權限系統進行混沌實驗人員管理，可以創建不同角色的實驗人員，如可以分配至具有查看權限的觀察者角色等。5.專家庫模塊5.專家庫模塊專家故障庫模塊?？梢跃庉嬇c展示錄入實驗過程中發現的問題，作為平臺的知識積累；具有實驗流程說明，可指導進行實驗設置與執行演練計劃。沉淀各種典型故障測試場景，用戶在創建場景時可以直接導入故障場景，降低故障創建復雜度和提供產品使用效率。（二）適配性要求混沌測試

16、平臺運行環境應該運行在開放的軟硬件平臺之上，更加貼近國內客戶生產環境需求，適配多種架構與類型分布式數據庫，支持 X86、C86、ARM 硬件平臺，支持 Windows、統信、麒麟等軟件平臺。（三）集成要求混沌工程與被測系統、監控系統、上層應用、底層設施等模塊的整體集成部署邏輯分為管控組件和執行組件，管控組件需要獨立部署，支持集成部署在獨立的物理環境和 Kubernetes 環境，執行組件需要部署在應用運行環境，并且與控制組件保持網絡互通，測試人員只需要通過控制組件即可完成混沌實驗。8三、混沌測試平臺建設情況（一）系統構成混沌測試平臺各個模塊之間通過一定的調用關系來完成每次故障的演練模擬。其中，

17、權限管理模塊是一個比較獨立的模塊，主要管理整個平臺的用戶權限；場景管理模塊是整個故障演練的入口，串聯起發壓監控、混沌實驗一系列故障演練的步驟；對于有價值的故障場景則可以通過推送沉淀到專家庫，并開放給所有用戶共享使用；實驗報告模塊為已結束的實驗提供了可視化的聚合報告；環境管理模塊則是發壓監控的前置工作，用戶可以在此上傳壓測腳本、被測環境以及發壓插件，保證后續發壓步驟的順利執行。通過打造混沌測試平臺，可以實現混沌實驗與壓測、監控的集成整合，通過專家庫中的實際案例沉淀與調用，使混沌實驗具備更好的操作性與可觀測性，從而達到混沌實驗能方便進行常態化全鏈路壓測與監控的目的。整體系統構成情況如下圖 1 所示

18、：9圖 1：混沌測試平臺系統構成圖（二）技術架構混沌測試平臺基于 Kubernetes 進行部署。主要包含管理系統、監控報表系統、JMeter 發壓系統、混沌實驗系統和部署在待測系統中的故障注入執行介質和監控代理。其中，管理系統部署在物理機環境，監控報表系統、JMeter 發壓系統、混沌實驗系統部署在 k8s 集群，故障注入執行介質和監控代理的部署方式則根據待測系統的不同而不同。平臺技術架構如下圖 2 所示：10圖 2：混沌測試平臺技術架構圖（三）功能模塊整個混沌測試平臺主要包含權限管理、發壓監控、混沌實驗、實驗報告、專家庫五個核心功能模塊。1.權限管理1.權限管理對平臺的登錄進行權限級別、環

19、境使用、混沌實驗各個維度的權限管理，大的不同程度的隔離。2.發壓監控2.發壓監控11發壓提供了整個故障演練過程的背景壓力用以模擬真實生產環境的流量，監控則對整個發壓過程中涉及的服務器資源、壓力機資源、業務指標、系統指標、錯誤信息等各種指標進行實時的監控展示，同時還對演練過程中的混沌實驗事件進行標注。3.混沌實驗3.混沌實驗支持各種常見類型的故障，覆蓋物理機/虛擬機、容器不同底層基礎設施，同時利用實驗編排可以自動定時實現故障的并行/串行/掛起模擬注入以及故障的自我恢復。通過編排的能力可以構造復雜的故障場景而非只能完成單一故障任務的模擬。以串行場景編排為例，可以在該場景的 workflow 中添加

20、多個故障子任務，同時每個子任務又可以嵌套多層的子任務，從而能夠更真實地模擬生產環境中遇到的故障。4.實驗報告4.實驗報告為整個故障演練過程提供了可視化的聚合報告，包含了壓測的數據（TPS、響應時間、失敗數等），監控數據（CPU、內存、IO、網絡等），混沌實驗數據（實驗事件、執行事件、執行狀態等）。5.專家庫5.專家庫用以沉淀各種高可用典型故障測試場景，用戶在創建場景時可直接導入這些典型場景進行演練，降低了故障演練的難度同時提升了故障演練的效率。功能模塊如下圖 3 所示：12圖 3：混沌測試平臺功能模塊圖（四）故障種類混沌工具支持虛擬機/K8s 容器不同底層基礎設施的故障模擬，同時覆蓋了磁盤、網

21、絡、進程、文件、JVM、壓力、IO、DNS、內核、HTTP、生命周期等多種故障類型。具體到每種故障類型，又包含了常見的磁盤讀寫、磁盤填充、殺死進程、CPU 打滿、網絡延遲、網路丟包等典型故障?；煦绻ぞ咧С值墓收项愋拓S富，同時還可以借助混沌測試平臺的實驗編排功能，構建復雜的故障演練場景，滿足模擬生產環境中真實復雜場景的需求。故障種類如下圖 4 所示：13圖 4：混沌測試平臺故障種類圖四、混沌平臺測試方案與測試實踐（一）測試目標分布式數據庫是重要的基礎軟件，數據庫發生故障所引發的一系列的后果是無法想象的，對于分布式數據庫而言，其故障有可能是多種情況組合下才發生，從而引發嚴重的生產事故。傳統的高可用

22、測試，很難對各種情況進行同時或不同排列組合的模擬，難以在測試中進行系統性驗證。通過引入混沌測試的方式可以增強和補充整個分布式數據庫系統的健壯性。根據分布式數據庫產品架構和銀行業務交易場景，混沌測試平臺針對分布式數據庫產品做以下故障驗證測試：1.模擬分布式數據庫計算和存儲節點進程故障。2.模擬分布式數據庫數據盤讀寫負載故障。3.模擬分布式數據庫數據節點、控制節點、計算節點網絡延遲丟包故障。4.模擬分布式數據庫節點 CPU 和內存負載高故障。145.模擬分布式數據庫系統負載高故障場景。6.模擬分布式數據庫混合故障場景。故障演練平臺通過觸發預先設置的故障用例，在生產環境發生故障之前把問題暴露出來，分

23、布式數據庫產品盡可能提早地處理這類故障，再加上自動化、冗余、回滾策略，以及其他健壯性設計的最佳實踐，分布式數據庫產品很快就可以讓自身的服務，在發生故障時保持正常運行。聚焦在業務指標上來衡量問題發生與否，造成業務問題的事件都應該排查定位，記錄觸發條件，繼而在修復后回歸測試，并將修復代碼上線到持續運行的混沌測試平臺中。（二）測試內容測試內容如表 1 所示。表 1：混沌測試平臺測試內容表序號序號測試分類測試分類用例用例1進程故障注入進程被殺故障注入2進程掛起故障注入3磁盤故障注入讀寫負載過高故障注入4多進程讀負載故障注入5寫負載過高故障注入6指定目錄寫負載過高故障注入7指定文件填充過多故障注入8IO

24、 壓力高故障注入159網絡故障注入網絡延遲故障注入10網絡包損壞故障注入11網絡丟包故障注入12網絡抖動故障注入13壓力故障注入CPU 耗盡故障注入14內存耗盡故障注入15系統 load 高故障注入16混合場景故障注入混合容量測試17穩定性測試混合編排 workload 長穩測試（三）測試過程1.進程故障注入1.進程故障注入1）進程被殺故障注入檢測內容檢測內容：分布式數據庫在進行賬戶查詢、更新、插入、轉賬等聯機交易業務過程中，數據庫計算進程被殺異常故障的自愈性以及對業務的QPSTPS 影響范圍和時長。檢測流程檢測流程：啟動銀行模擬交易場景程序，模擬賬戶查詢、更新、插入操作；將編排好的進程被殺故

25、障模板加載到故障測試平臺，執行測試；測試結束后，統計故障演練期間交易成功率，QPS，平均延遲等指標；生成測試報告。16通過標準通過標準：各步驟執行成功，分布式數據庫能夠完成自動故障轉移，在故障解除后能夠恢復完整的服務能力，執行結果符合廠商聲明。進程被殺時 QPS 會有下降，延遲有所上升，但不會造成嚴重影響。在進程恢復后各項指標恢復正常。2）進程掛起故障注入檢測內容：檢測內容：分布式數據庫在進行賬戶查詢、更新、插入、轉賬等聯機交易業務過程中，數據庫存儲進程掛起異常故障的自愈性以及對業務的QPSTPS 得的影響范圍和時長。檢測流程：檢測流程：啟動銀行模擬交易程序，模擬賬戶查詢、更新、插入操作；將編

26、排好的進程掛起故障模板加載到故障測試平臺，執行測試；測試結束后，統計故障演練期間交易成功率，QPS，平均延遲等指標；生成測試報告。通過標準：通過標準：執行成功，分布式數據庫在所描述的故障注入下，能夠完成自動故障轉移，在故障解除后能夠恢復完整的服務能力，執行結果符合廠商聲明。進程被殺時 QPS 會有下降，延遲有所上升，但不會造成嚴重影響。在進程恢復后各項指標恢復正常。2.磁盤故障注入2.磁盤故障注入171）讀寫負載過高故障注入檢測內容：檢測內容：分布式數據庫在進行賬戶查詢、更新、插入、轉賬等聯機交易業務過程中，讀寫負載故障的自愈性以及對業務的 QPSTPS 的影響范圍和時長。檢測流程：檢測流程：

27、啟動銀行交易程序，模擬賬戶轉賬操作；將編排好的主機故障模板加載到故障測試平臺，執行測試；測試結束后，統計故障演練期間交易成功率，QPS，平均延遲等指標；生成測試報告。通過標準：通過標準：執行成功，分布式數據庫在所描述的故障注入下，能夠完成自動故障轉移，在故障解除后能夠恢復完整的服務能力，執行結果符合廠商聲明，未出現非預期結果。2）多進程讀負載故障注入檢測內容：檢測內容：分布式數據庫在進行賬戶查詢、更新、插入、轉賬等聯機交易業務過程中，多進程讀負載故障的自愈性以及對業務的 QPSTPS 的影響范圍和時長。檢測流程：檢測流程：啟動銀行模擬交易場景程序，模擬賬戶查詢、更新、插入語操18作；將編排好的

28、主機故障模板加載到故障測試平臺，執行測試；測試結束后，統計故障演練期間交易成功率，QPS，平均延遲等指標；生成測試報告。通過標準：通過標準：執行成功，分布式數據庫在所描述的故障注入下，能夠完成自動故障轉移，在故障解除后能夠恢復完整的服務能力，執行結果符合廠商聲明，未出現非預期結果。3）寫負載過高故障注入檢測內容：檢測內容：分布式數據庫在進行賬戶查詢、更新、插入、轉賬等聯機交易業務過程中，寫負載故障的自愈性以及對業務的 QPSTPS 的影響范圍和時長。檢測流程：檢測流程：啟動銀行模擬交易場景程序，模擬賬戶查詢、更新、插入語操作；將編排好的主機故障模板加載到故障測試平臺，執行測試；測試結束后，統計

29、故障演練期間交易成功率，QPS，平均延遲等指標；生成測試報告。通過標準：通過標準：19執行成功，分布式數據庫在所描述的故障注入下，能夠完成自動故障轉移，在故障解除后能夠恢復完整的服務能力，執行結果符合廠商聲明，未出現非預期結果。4）指定目錄寫負載過高故障注入檢測內容：檢測內容：分布式數據庫在進行賬戶查詢、更新、插入、轉賬等聯機交易業務過程中，指定目錄寫負載故障的自愈性以及對業務的 QPSTPS的影響范圍和時長。檢測流程：檢測流程：啟動銀行模擬交易場景程序，模擬賬戶查詢、更新、插入語操作；將編排好的主機故障模板加載到故障測試平臺，執行測試；測試結束后，統計故障演練期間交易成功率，QPS，平均延遲

30、等指標；生成測試報告。通過標準：通過標準：執行成功，分布式數據庫在所描述的故障注入下，能夠完成自動故障轉移，在故障解除后能夠恢復完整的服務能力，執行結果符合廠商聲明，未出現非預期結果。5）指定文件填充過多故障注入檢測內容：檢測內容：分布式數據庫在進行賬戶查詢、更新、插入、轉賬等聯機交易20業務過程中，指定目錄文件填充過多導致寫負載故障的自愈性以及對業務的 QPSTPS 的影響范圍和時長。檢測流程：檢測流程：啟動銀行交易程序，模擬賬戶轉賬操作；將編排好的主機故障模板加載到故障測試平臺，執行測試；測試結束后，統計故障演練期間交易成功率，QPS，平均延遲等指標；生成測試報告。通過標準：通過標準：執行

31、成功，分布式數據庫在所描述的故障注入下，能夠完成自動故障轉移，在故障解除后能夠恢復完整的服務能力，執行結果符合廠商聲明，未出現非預期結果。6）IO 壓力高故障注入檢測內容：檢測內容：分布式數據庫在進行賬戶查詢、更新、插入、轉賬等聯機交易業務過程中，數據庫存儲節點 IO 壓力高故障的自愈性以及對業務的QPSTPS 的影響范圍和時長。檢測流程：檢測流程：啟動銀行交易程序，模擬賬戶轉賬操作；將編排好的主機故障模板加載到故障測試平臺，執行測試；測試結束后，統計故障演練期間交易成功率，QPS，平均延遲等指標；21生成測試報告。通過標準：通過標準：執行成功，分布式數據庫在所描述的故障注入下，能夠完成自動故

32、障轉移，在故障解除后能夠恢復完整的服務能力，執行結果符合廠商聲明，未出現非預期結果。3.網絡故障注入3.網絡故障注入1）網絡延遲故障注入檢測內容：檢測內容：分布式數據庫在進行賬戶查詢、更新、插入、轉賬等聯機交易業務過程中，數據庫集群存儲、計算、控制節點網絡延遲故障的自愈性以及對業務的 QPSTPS 的影響范圍和時長。檢測流程：檢測流程：啟動銀行業務交易程序，模擬賬戶查詢、更新、插入操作；將編排好的主機故障模板加載到故障測試平臺，執行測試；測試結束后，統計故障演練期間交易成功率，QPS，平均延遲等指標；生成測試報告。通過標準：通過標準：執行成功，分布式數據庫在所描述的故障注入下，能夠完成自動故障

33、轉移，在故障解除后能夠恢復完整的服務能力，執行結果符合廠商聲明，未出現非預期結果。2）網絡丟包故障注入22檢測內容：檢測內容：分布式數據庫在進行賬戶查詢、更新、插入、轉賬等聯機交易業務過程中，數據庫集群存儲、計算、控制節點網絡包丟失故障的自愈性以及業務的對 QPSTPS 的影響范圍和時長。檢測流程：檢測流程：啟動銀行業務交易程序，模擬賬戶查詢、更新、插入操作；將編排好網絡丟包故障注入異常模板加載到故障測試平臺；持續測試 10 分鐘；測試結束后，統計故障演練期間交易成功率，QPS，平均延遲等指標；生成測試報告。通過標準：通過標準：執行成功，分布式數據庫在所描述的故障注入下，能夠完成自動故障轉移，

34、在故障解除后能夠恢復完整的服務能力，執行結果符合廠商聲明，未出現非預期結果。3）網絡包損壞故障注入檢測內容：檢測內容：分布式數據庫在進行賬戶查詢、更新、插入、轉賬等聯機交易業務過程中，集群計算、存儲、控制節點網絡包損失對故障的自愈性以及業務的 QPSTPS 的影響范圍和時長。檢測流程：檢測流程：啟動銀行業務交易程序，模擬賬戶查詢、更新、插入操作；23將編排好的主機故障模板加載到故障測試平臺，執行測試；測試結束后，統計故障演練期間交易成功率，QPS，平均延遲等指標；生成測試報告。通過標準：通過標準：執行成功，分布式數據庫在所描述的故障注入下，能夠完成自動故障轉移，在故障解除后能夠恢復完整的服務能

35、力，執行結果符合廠商聲明，未出現非預期結果。4）網絡抖動故障注入檢測內容檢測內容：分布式數據庫在進行賬戶查詢、更新、插入、轉賬等聯機交易業務過程中，集群計算、存儲、控制節點網絡通信出現抖動故障的自愈性以及對業務的 QPSTPS 的影響范圍和時長。檢測流程檢測流程：啟動銀行業務交易程序，模擬賬戶查詢、更新、插入操作；將編排好網絡抖動故障異常模板加載到故障測試平臺；測試結束后，統計故障演練期間交易成功率，QPS，平均延遲等指標；生成測試報告；通過標準通過標準：執行成功，分布式數據庫在所描述的故障注入下，能夠完成自動故障轉移，在故障解除后能夠恢復完整的服務能力，執行結果符24合廠商聲明，未出現非預期

36、結果。4.壓力故障注入4.壓力故障注入1）CPU 耗盡故障注入檢測內容：檢測內容：分布式數據庫在進行賬戶查詢、更新、插入、轉賬等聯機交易業務過程中，集群計算、存儲節點出現 CPU 負載過高故障的自愈性以及對業務的 QPSTPS 的影響范圍和時長。檢測流程：檢測流程：啟動銀行模擬交易程序，模擬賬戶查詢更新操作；將編排好的主機故障模板加載到故障測試平臺，執行測試；測試結束后，統計故障演練期間交易成功率，QPS，平均延遲等指標；生成測試報告。通過標準：通過標準：執行成功，分布式數據庫在所描述的故障注入下，能夠完成自動故障轉移，在故障解除后能夠恢復完整的服務能力，執行結果符合廠商聲明，未出現非預期結果

37、。2）內存耗盡故障注入檢測內容：檢測內容：分布式數據庫在進行賬戶查詢、更新、插入、轉賬等聯機交易業務過程中，集群計算、存儲節點出現內存負載過高故障的自愈性以及對業務的 QPSTPS 的影響范圍和時長。25檢測流程：檢測流程：啟動銀行模擬交易程序，模擬賬戶查詢、更新操作；將編排好的主機故障模板加載到故障測試平臺，執行測試；測試結束后，統計故障演練期間交易成功率，QPS，平均延遲等指標；生成測試報告。通過標準：通過標準：執行成功，分布式數據庫在所描述的故障注入下，能夠完成自動故障轉移，在故障解除后能夠恢復完整的服務能力，執行結果符合廠商聲明，未出現非預期結果。3）系統 load 高故障注入檢測內容

38、：檢測內容：分布式數據庫在進行賬戶查詢、更新、插入、轉賬等聯機交易業務過程中，集群計算、存儲節點出現系統 load 負載過高故障的自愈性以及對業務的 QPSTPS 的影響范圍和時長。檢測流程：檢測流程：啟動銀行交易程序，模擬賬戶轉賬操作將編排好的主機故障模板加載到故障測試平臺，執行測試測試結束后，統計故障演練期間交易成功率，QPS，平均延遲等指標生成測試報告通過標準：通過標準：26執行成功，分布式數據庫在所描述的故障注入下，能夠完成自動故障轉移，在故障解除后能夠恢復完整的服務能力，執行結果符合廠商聲明，未出現非預期結果。5.混合場景故障注入5.混合場景故障注入檢測內容：檢測內容：分布式數據庫在

39、進行賬戶查詢、更新、插入、轉賬等聯機交易業務過程中，混合編排注入不同故障的自愈性以及對業務的 QPSTPS的影響范圍和時長。檢測流程：檢測流程：啟動銀行交易程序，模擬賬戶轉賬操作；將編排好的主機故障模板加載到故障測試平臺，執行測試；測試結束后，統計故障演練期間交易成功率，QPS，平均延遲等指標；生成測試報告。通過標準：通過標準：執行成功，分布式數據庫在所描述的故障注入下，能夠完成自動故障轉移，且需保證在故障注入后各有效數據節點的數據分布是均勻的；在故障解除后能夠恢復完整的服務能力，執行結果符合廠商聲明，未出現非預期結果。6.穩定性測試6.穩定性測試檢測內容檢測內容：分布式數據庫在進行賬戶查詢、

40、更新、插入、轉賬等聯機交易27業務過程中，混合編排長時間周期性注入不同故障的自愈性以及對業務的 QPSTPS 的影響范圍和時長。檢測流程：檢測流程：啟動銀行交易程序，模擬賬戶轉賬操作；將編排好的主機故障模板加載到故障測試平臺，執行測試；測試結束后，統計故障演練期間交易成功率，QPS，平均延遲等指標；生成測試報告。通過標準：通過標準：執行成功，分布式數據庫在所描述的故障注入下，能夠完成自動故障轉移，且需保證在故障注入后各有效數據節點的數據分布是均勻的；在故障解除后能夠恢復完整的服務能力，執行結果符合廠商聲明，未出現非預期結果。五、混沌測試平臺建設實踐總結銀行機構在 IT 系統架構轉型的同時，都同

41、時面臨運行安全保障的巨大壓力。實際生產運行過程中，應用級別的生產故障時而發生，對業務連續性和生產安全產生威脅較大。限于銀行業務的安全級別及合規要求，難以在生產環境對此類故障場景進行應急處置演練，應急預案無法執行，處置措施的有效性無法驗證。銀行同業一般采取桌演或者仿真環境演練的方式，提高組織應對應用級故障的能力。金融級混沌測試能力平臺在模擬應用級故障方面具有天然優勢，平臺側可以模擬及編排各種故障場景，包括：進程故障、主機28故障、磁盤故障、讀寫負載高故障、網絡故障、壓力負載故障、混合故障場景等，驗證了在業務負載下分布式數據庫遇到各類故障對產品冗余處理機制的有效性以及故障對數據庫處理能力的影響。平

42、臺故障編排和故障注入可以將其作為常態化手段來驗證銀行業務場景下分布式數據庫產品的穩定性，整個故障演練過程和結果符合預期。金融級混沌測試能力平臺同樣適用于應用系統的開發、測試、上線、運維等各個階段：在應用系統開發階段，對非功能性測試的重視程度通常不及功能性測試，一個重要的原因是非功能性測試通常對測試環境的要求較高，利用金融級混沌測試能力平臺可以對穩定性、擴展性、彈性縮放部署等非功能性需求是否能夠實現進行檢驗。在新建或經歷重大變更后的應用系統上線環節中，為了提升應用系統上線質量，豐富和完善應用上線質量門禁的內容，可利用金融級混沌測試能力平臺對目標系統的合規性進行針對性的測試，以確定部署后的應用系統

43、能夠滿足業務需求，主要測試方向為系統穩定運行能力和抗干擾能力。在資源規范環節中，合理的資源容量是服務性能的保障，利用金融級混沌測試能力平臺具備的產生背景訪問流量的能力可以協助進行壓力測試，或者驗證應用正常運行（承載正常訪問流量）時所需資源的臨界值在運維監控方面，監控能力與指標的覆蓋范圍直接影響系統異29?；蚬收系陌l現與定位能力?？梢詫⒔鹑诩壔煦鐪y試能力平臺作為檢驗監控系統效能的重要工具，通過控制故障注入的強度和范圍發現監控能力方面的不足與缺陷在應急響應方面，通過金融級混沌測試能力平臺的故障注入可以不但可以檢驗告警配置的合理性和有效性，同時能夠檢驗運維團隊的應急響應能力與應急處置能力，可以成為應急演練的重要支撐工具。