文 / 上海銀行金融科技部副總經理 朱英華

上海銀行金融科技部 劉麗 賈弘茹

(資料圖片僅供參考)

當前商業銀行正處于新一代云原生架構轉型期，微服務架構在具備擴展性優、彈性伸縮強等優勢的同時，也使得銀行的系統在架構設計和運維層面等面臨諸多新挑戰。例如新一代銀行應用架構間的依賴度和耦合度愈發復雜、運維難度的極大增加都會導致系統風險可能性的提升。在當前提高銀行系統風險管理的必然趨勢下，混沌工程受到越來越多的關注。本文通過對比傳統架構和微服務架構模式、傳統運維模式和當前業務連續性管理新發展方向，論證混沌工程在銀行系統風險管理的必要性；并根據混沌工程實驗原理，提出混沌工程實驗平臺具體方案；同時以研發微服務平臺為例，進行故障演練實驗案例研究及實驗價值分析。

上海銀行金融科技部副總經理 朱英華

研究背景與現狀

當前，商業銀行正加快開展新一代架構轉型的步伐，由傳統的SOA架構向分布式架構、去中心化發展，當前還進階到注重云化支持和異構化微服務支持的服務網格模式。

一方面由于技術異構性、具備彈性伸縮、可擴展性等優勢，微服務架構得到迅速推廣；另一方面，微服務架構在使用過程中又會面臨諸多挑戰：由于系統級依賴增多而帶來的不確定性風險指數級增長；商業銀行的核心系統規模日益龐大，交易鏈路長，數據流轉復雜；隨著銀行數字化轉型和分布式技術推動，基礎設施多樣化、架構多元化導致運維復雜度極大增加。實踐發現，通過傳統手段進行加強高可用性設計、提高代碼健壯性、加大測試范圍、提高監控敏感度，都無法有效阻止系統故障的發生。所以在新一代銀行微服務架構轉型期，系統的風險管理越來越重要，提高系統韌性成為必然發展趨勢。

在微服務架構轉型的驅動下，“混沌工程”實踐方案受到銀行界越來越多的關注和探索。它可以通過規范化、流程化的實踐方案對系統進行一定程度的“隨機破壞”，讓故障在可控范圍內頻繁發生，在此過程中可以深入地認知故障和系統，并達到持續改進的效果。

混沌工程是通過向系統中引入軟件或硬件的異常狀態（擾動），制造故障場景并根據系統在各種壓力下的行為表現確定優化策略的一種系統穩定性保障手段。其原則是可量化的穩定狀態、可反映真實場景，但風險未知的假設、影響最小化。混沌實驗的具體流程包括實驗設計、實驗執行和實驗結果分析。總結來說，混沌工程就是利用實驗提前探知系統風險，通過架構優化和運維模式的改進來解決系統風險，真正提升系統架構韌性，增強故障免疫力，提高企業效益。

新一代銀行系統風險管理面臨挑戰

1.架構層面。當前微服務架構已成為互聯網及銀行業架構發展的主流模式，它與原先SOA架構的區別是：微服務更強調“業務需要徹底的組件化和服務化”。其特性是：客戶端負載均衡、微服務容錯保護、API服務網關、分布式鏈路跟蹤等。而傳統的非功能測試方法只能覆蓋到業務邏輯維度，無法覆蓋和測試到上述微服務特性。

而混沌工程與傳統測試的不同點為：通常的測試用例會有“期望結果”和“實際結果”，通過將兩個結果比較，或者對用戶行為的預期，來判斷測試通過或失敗。而混沌實驗類似于“探索性測試”。實驗本身沒有明確的輸入和預期結果，是通過對系統和服務的不同組合干預，來觀察系統的“反應”。具體操作時，可以將混沌工程原則融入到測試過程中：在準生產環境小規模模擬系統故障組合并定期自動化執行實驗，通過實驗結果與正常結果進行比對，觀察系統對故障的承受和反應能力。

根據上述對比，我們可以從業務邏輯和系統高可用性兩個維度對微服務系統進行觀察和測試，將傳統測試與混沌工程兩種方案結合，形成了一種更全面的實驗方案。從而無論是在微服務改造期還是云原生轉型期，混沌工程實驗都能夠有效提前發現生產環境問題，提升系統的容錯率和可用性。

2.運維層面。當前銀行業的業務連續性管理已經邁入新的方向。以往的業務連續性管理，重點關注監管合規要求，應急管理時多注重事中檢測；故障的定位和解決多依賴技術人員的能力。而發展中的業務連續性管理更注重工具能力，在符合監管合規的同時，切實提高業務連續性管理能力，并規避實質性風險。

目前，銀行的應急預案與災備切換方案是存在隱患可能性的：從事件故障發生，到監控平臺是否能及時全面的檢測到故障并告警、應急處置流程是否有效、各系統災備切換是否有效、故障修復是否及時有效都存在漏洞可能性。每個步驟的疏漏，都會導致全鏈路的安全隱患大幅升級。而新一代微服務架構又引入了更多更復雜的系統風險問題，導致系統運維層面的壓力大幅增加。憑借原先依賴技術人員個人能力進行事中檢查可靠性大幅下降。

引入混沌工程實驗，能夠更加完善運維的工作體系：事前可以通過混沌工程實驗預測故障、組建紅藍雙方攻防演練，從而主動發現問題和影響范圍，未雨綢繆。例如通過對系統注入故障，驗證監控指標是否準確，監控維度是否完善，告警閾值是否合理，告警接收人是否準確等，有效提升事前監控告警的準確和時效性。

事中可以快速故障定位和解決問題，減少經驗依賴，縮短應急時間。在實驗中，通過故障突襲、隨機對系統注入故障，考察相關人員對問題的應急能力，包括問題上報、處理流程是否合理，達到以戰養戰，鍛煉技術人員定位與解決問題的能力。可有效提升應急響應的及時性。

事后可以故障影響分析和修復設計，進行復盤和改進。通過實驗模擬調用延遲、服務不可用、機器資源滿載等，查看發生故障的節點或實例是否被自動隔離、下線，流量調度是否正確，預案是否有效。可以提升系統容錯容災的健壯性。

應用案例研究

按照上述混沌工程的實驗原則及流程，分析銀行科技系統風險管理的痛點問題，并結合市場調研，以提高應用系統業務邏輯和運行環境容錯能力、增強高復雜應用架構下的系統韌性，最終以提升銀行系統的風險防御能力為目標。下文將闡述混沌工程實驗平臺的設計方案。

1.混沌工程實驗平臺。如圖1所示，混沌實驗平臺功能包括：故障演練、實驗場景庫、任務調度、應用管理、實驗管理、實驗經驗庫、工作臺、監控及數據分析。

圖1 混沌工程實驗平臺功能圖

測試技術人員可利用混沌工程實驗平臺對待實驗的系統實施故障演練。根據混沌實驗流程，利用混沌工程實驗平臺可進行如下操作：先分析待實驗系統的穩態指標；在實驗場景庫模塊中選擇或新增實驗故障場景；在實驗管理模塊中設計實驗計劃，并在故障演練模塊中進行實驗執行；在實驗管理模塊中進行實驗結果分析，并進行實驗管理。

2.基于混沌工程平臺的實驗方案設計。（1）實驗流程。借助DevOps中的配置中心模塊實現混沌工程平臺對被實驗平臺的指令傳遞，通過Agent應用實現對被實驗平臺注入實驗場景，以應用系統和設備為維度實現權限及爆炸半徑管控。實驗平臺通過和綜合診斷分析中心，統一運行監控系統進行關聯，實時查看實驗時的指標情況，進而從實驗準備、實驗編排、故障注入、故障恢復、監控驗證到生成演練報告，形成一套基本的平臺實驗流程。

用戶整體操作層面，首先確定待實驗的應用系統及資源環境，并確認基準“穩定狀態”，然后選擇混沌實驗場景，通過Agent收到實驗信息后，開始通過編排步驟對目標注入故障，觀察系統及資源等情況的綜合反映，識別系統弱點。最后記錄實驗經驗，反饋給應用系統，應用系統修復解決后再次通過混沌實驗進行回歸驗證，驗證完畢關閉本次實驗。

（2）實驗場景。實驗場景含容器K8S，主機/虛擬機上的應用和分布式微服務應用，供選擇不同場景進行不同實驗。

針對容器K8S，主機/虛擬機上應用的場景：涉及CPU資源滿載、內存資源負載、磁盤資源負載提升、網絡資源異常、應用進程殺死、容器內進程殺死等系統資源類故障場景。涉及延遲、拋異常、數據篡改等JAVA應用類故障場景。

針對特殊的分布式微服務應用的場景：涉及RPC服務故障、API網關故障、配置中心故障、批量任務故障、中間件故障等場景。

（3）實驗方案。本次混沌工程測試實驗重點圍繞研發微服務平臺的容器云和微服務組件，結合生產環境IaaS基礎設施冗余切換經驗，輔助云原生監控手段，驗證微服務平臺服務間的強弱依賴關系及魯棒性。

如圖2所示，以研發微服務平臺為例，故障演練實驗如下。

圖2 基于研發微服務平臺故障場景演練

第一步選定假設，明確對研發微服務平臺的哪些場景進行故障注入。系統健壯性實驗：測試如進程掛掉、頻繁GC時，實驗當前應用出現系統級可用性故障時的反應。應用起停順序：在理想情況下，應用啟動應該做到零強依賴啟動，但實際情況有可能無法做到需依賴相關服務提供后才能啟動對外服務，通過實驗服務間起停順序，來檢查系統服務間依賴關系及操作部署。容量評估實驗：正常調用鏈路下的系統容量等是預先設計的，當某個弱依賴掛起時，需注意整體應用的容量變化情況。逃逸實驗：當微服務網關、注冊中心等重要系統出現某個區域的故障時，能對外服務，并評估容量、切換時間、影響范圍等。硬件演練實驗：包括對應用平臺進行CPU滿載、網絡限流、主機資源枯竭等相關實驗，并評估其硬件抗風險能力。

第二步設定實驗范圍。根據具體的場景明確對哪些節點實施故障注入，并且評估出現故障時可能受到的影響范圍，確保不會造成災難性的結果。

第三步明確平臺健康指標。業務、開發、測試多方合作，明確平臺關鍵運行指標。實驗執行故障注入時，重點關注平臺是否可在第一時間內發現異常，可感知到異常后，平臺是否有可承受此故障打擊，最后確認平臺是否具備自修復能力。

第四步執行實驗及實驗結果分析。演練結束后，需要對整個演練進行復盤。首先要分析總結演練是否達到預期，系統是否具備韌性，是否發生預期之外的結果。然后要針對故障演練過程中系統暴露出的問題，進行問題修復和架構優化。

（4）實驗價值。通過故障場景建設，從IaaS層到SaaS層逐層疊加故障測試場景，以原子化方式提取故障因子，按需組合注入故障，可驗證研發微服務平臺的系統健壯性和抗擊打能力。以研發微服務平臺的系統業務連續性提升為目標開展系統故障演練后發現問題的治理工作。同時，通過故障演練，能考驗相關技術人員的應急問題處理能力，豐富研發運維團隊經驗，增強團隊信心。

結論及建議

銀行在新一代微服務架構發展背景下，可借鑒混沌工程思想，以模擬生產環境為對象，對系統進行故障模擬，及時發現潛在問題，提升管理能效。同時，對于中小銀行，微服務架構還在發展過程中，混沌工程理念和實驗平臺技術是一個“從無到有”，到“從有到優”的過程。建議先搭建平臺，再豐富平臺功能及與其他應用的關聯調度關系。另外混沌工程當前還是一個比較前沿的領域，商業銀行本身要做到管理與技術發展并進，提升和培養技術人員對混沌工程的意識和能力。

（欄目編輯：張麗霞）

責任編輯：Rex_31