作者 | 吳冕冠
來源|阿里巴巴雲原生公眾號
互聯網金融時代下，金融產品和服務模式不斷創新，交易量大幅攀升。面對互聯網金融的全新發展態勢，傳統的單體 IT 架構暴露出很多不適應的地方，為此業界廣泛應用雲計算、分布式等新技術，構建分布式架構和運維體系，以支撐金融業務的快速發展。這些新技術的應用使得基礎設施復雜性日益增加，不可預見的用戶行為和事件交織在一起，對系統、應用架構的可靠性提出了更高要求。為解決分布式系統的不確定性，確保生產穩定運行，混沌工程應運而生。根據《Chaos Engineering》書中的定義：混沌工程是在分布式系統上進行實驗的學科，目的是建立系統抵御生產環境中湍流條件的能力。通常來說，混沌工程指對分布式系統中的服務器隨機注入不同類型的故障，發現並修復系統中的潛在問題，從而提升整個分布式系統的高可用能力。
傳統系統高可用測試的痛點
中國工商銀行從 2015 年啟動了 IT 架構轉型工程，基於分布式、雲計算初步構建了開放平台核心銀行系統，目前分布式體系已承載 150 余個應用，累計部署容器超過 2 萬套，日均服務調用量超 70 億，消息發送峰值每秒逾 150 萬筆，實現了遠超主機性能容量的集群處理能力。但與此同時，在分布式體系下支撐服務的底層技術架構和平台系統日益復雜，生產運行不確定因素相較於主機明顯增多，網絡異常、磁盤 IO 夯等系統層面故障導致的生產問題呈現增長趨勢。由於傳統項目測試人員針對系統高可用相關場景的測試意識和能力相對缺乏，且目前該領域暫無統一的測試工具，測試人員需耗費較高的學習成本去篩選和學習各類測試工具，導致項目測試主要集中在業務功能測試，缺乏對系統可用性的測試。
故障注入工具選型
為提升工行分布式體系的穩定性，降低測試人員學習和使用相關工具的門檻，我們着重分析了 Chaosblade、Litmus、Choas Monkey 等優秀開源工具在各類故障注入場景中的能力。這些故障注入工具既有專用於雲平台環境，也有適用於操作系統層面，還有針對如服務異常等應用層面的故障注入。但這些工具大多僅提供了基本的故障注入能力，還需進一步擴展完善，實現企業級的平台能力。
表 1 業界主流故障注入工具能力情況
ChaosBlade 支持目前主流的故障注入場景，相對其他幾個故障注入工具，ChaosBlade 故障注入覆蓋的場景最全，支持四大類、幾十種常用的故障注入能力，且提供了統一的 CLI 交互界面，學習成本相對較低，其技術棧與我行分布式體系和雲計算體系兼容性也較好。
圖 1 ChaoBlade 故障注入能力
因此，ChaosBlade 各方面基本滿足我行技術體系的需求。為保障故障注入工具能力的可擴展性，實現與上層調度平台的解耦，降低調用方的使用難度，我們基於 ChaosBlade 進行了二次開發，擴展了 ChaosBlade 的故障注入能力。
-
一是將故障注入的調用能力封裝成 Rest 接口（當時 ChaosBlade 還不支持通過 http 與之交互）。
-
二是增加服務器系統指標收集模塊，可實時收集服務器的 CPU、內存、網絡等系統硬件使用情況。
-
三是增加了故障注入任務解析模塊，該模塊可將混沌工程故障演練管理平台下發的故障演練任務解析成多個故障注入事件，然后根據各個故障注入事件的開始和結束時間分別調用 ChaosBlade 故障注入工具實施故障注入和撤銷操作。
基於 ChaosBlade 的系統高可用測試解決方案
基於 ChaosBlade 故障注入工具，我們建設了一套功能完備的企業級混沌工程故障演練平台。
1. 平台架構
平台主要由門戶、任務調度框架、故障注入介質、高可用專家庫四部分組成。
門戶提供各類混沌實驗任務的編排和配置服務，借助演練流程編排面板，用戶可以便捷地管理各類混沌實驗任務；混沌實驗開始實施后，用戶可通過任務進度條、服務器指標展示圖等實時查看混沌實驗任務的進度和服務器各項系統指標情況；混沌實驗執行結束后，門戶會收集混沌實驗過程中的所有數據，並對數據進行分析和加工，生成混沌工程實驗報告供后續分析和歸檔。
任務調度框架負責門戶和故障注入介質之間的交互，核心功能是實現混沌實驗任務的批量下發和調度，該模塊可以快速批量下發各種類型的混沌實驗，支持失敗重發、超時重發、高並發等機制。
故障注入介質負責接收門戶下發的任務，並實施相應的故障注入事件。
高可用專家庫是混沌工程測試人員根據平時混沌測試總結得到的高可用測試模型，基於高可用專家庫用戶可以根據演練場景自動關聯對應的故障注入事件，並為用戶提供一鍵生成演練流程的能力。
圖 2 工行混沌工程故障演練平台架構
2. 故障演練過程詳解
工程師對目標服務器進行故障注入時，涉及環境准備、故障注入任務編排、實施故障注入、終止故障注入任務等一系列操作。
1）環境准備
在實施故障演練之前，需要在混沌工程故障演練平台添加將要實施故障注入的目標服務器。如果實施目標是容器，則無需用戶維護，系統可以自動關聯 PaaS 平台查詢各應用的容器。
2）故障演練任務編排
用戶登陸故障演練平台后，選擇故障演練環境。創建一個故障演練流程，每個故障演練流程至少添加一個故障演練任務，每個故障演練任務可以有一個或多個故障演練事件，每個故障演練任務可以關聯一台或多台服務器。常用的故障演練事件包括對 CPU、內存、磁盤、網絡、數據庫、服務調用、JVM 等注入各類故障。
3）實施故障注入
用戶完成故障注入任務編排后，即可開始實施故障演練。用戶點擊安裝按鈕之后，混沌工程故障演練平台就會將故障注入介質下發至目標服務器，並執行用戶預先編排好的故障演練任務。
此外，故障注入介質還可實時收集服務器在混沌實驗運行期間的性能狀態，如系統層面的 CPU、內存、網絡、磁盤使用情況，並將這些系統指標回傳至混沌工程故障演練管理平台，以圖形化的方式進行展示，以驗證在執行混沌實驗期間系統狀態是否達到預期效果。
4）終止故障注入任務
故障演練任務被用戶手動停止或者正常執行結束后，平台會自動調用虛機管理平台或 PaaS 管理平台的接口，將故障演練銷毀命令下發至各目標服務器，恢復之前注入的故障並銷毀故障注入介質。
實際效果
1. 節點管理模塊
支持用戶根據故障演練具體需求，在工行混沌工程故障演練平台定義不同的故障演練環境，並為各環境添加對應的目標服務器列表。
圖 3 工行混沌工程故障演練平台節點管理模塊
2. 演練管理模塊
演練管理模塊負責維護故障演練任務，支持用戶選擇需要實施故障演練的目標服務器以及需要執行的故障注入事件。
圖 4 工行混沌工程故障演練平台演練管理模塊
3. 演練監控模塊
演練監控模塊主要通過故障注入介質收集故障演練過程中各目標服務器當前系統層面的關鍵指標信息，並在工行混沌工程故障演練平台進行實時展示。
圖 5 工行混沌工程故障演練平台監控管理模塊
4. 高可用專家庫
我們通過對歷史生產問題的排查經驗進行總結，並結合在大量混沌測試實踐中歸納得到的高可用測試模型，建立了工行混沌工程故障演練平台高可用專家庫，共包含六大類一百多種測試案例，涵蓋了應用層、數據庫層、平台層、中間件層、路由層、緩存層等主流的應用高可用測試場景。為降低混沌測試門檻，高可用專家庫支持應用基於自身架構自動匹配測試案例，達到一鍵生成故障演練任務的目的。
圖 6 工行混沌工程故障演練平台高可用專家庫
5. 其他能力
此外，為方便混沌測試人員使用混動工程故障演練平台對測試案例和測試結果的管理，平台也提供了測試案例管理，問題管理等附加模塊。同時對於一些 ChaosBlade 暫時還不具備的故障注入能力如 IO 夯住，我們也自行研發了相關功能並集成至故障注入介質當中。
6. 實踐情況
我們根據分布式技術體系生產運維中的“痛點”：
-
一是全行應用眾多，高可用測試的場景和規模龐大，基於故障注入工具通過手動輸入命令的方式實施故障演練效率十分低下。
-
二是工行分布式系統底層架構非常復雜，涉及容器、虛機、物理機等多類設施，單一故障注入工具無法滿足不同場景的故障演練需求。
因此我們建設了工行混沌工程故障演練平台，將服務器系統故障和 JVM 故障這兩大類作為主要切入點，基於工行混沌工程故障演練平台高可用專家庫，率先在行內快捷支付、聚合支付等一些重點業務線進行落地試點，通過注入上下游調用異常、線程池異常、磁盤 IO 夯等多種類型的故障，在各業務線的平台層、消息中間件層、應用層、數據庫層、路由層均發現了一些傳統測試難以發現的高可用設計等方面的問題。例如：通過對支付類交易實施混沌實驗，模擬雙活應用的單園區網絡斷連然后再恢復，發現該過程中支付鏈路存在一些底層故障場景下交易失敗的架構設計缺陷，並在投入生產之前對支付系統架構進行了重新設計和升級。截止目前全行已對七十多各應用開展常態化故障演練測試，共實施故障演練七千余次，發現並解決了一百多個應用系統層面的高可用問題，有效避免了在生產環境觸發這些問題。
未來展望
后續，工行將持續全面推廣混沌工程文化，在大型活動前期進行專項大規模混沌測試，並根據各應用的測試結果，制定應用高可用水平量化評估體系。此外，隨着混沌工程故障演練在測試環境的不斷推進，平台應用可靠性不斷增強，除了不斷擴大演練半徑外，下一步計划將混沌工程故障演練逐步從測試環境向生產環境推移，對全行重要產品線編排實施各種類型的演練，以確保整個平台能應對業務高峰極端條件下的壓力，全面提升全行開放平台應用服務水平，為工商銀行系統架構的持續優化、產品的快速創新提供堅實支撐。