文 / 上海銀行金融科技部副總經(jīng)理 朱英華

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

(資料圖片僅供參考)

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

上海銀行金融科技部副總經(jīng)理 朱英華

研究背景與現(xiàn)狀

當(dāng)前，商業(yè)銀行正加快開展新一代架構(gòu)轉(zhuǎn)型的步伐，由傳統(tǒng)的SOA架構(gòu)向分布式架構(gòu)、去中心化發(fā)展，當(dāng)前還進階到注重云化支持和異構(gòu)化微服務(wù)支持的服務(wù)網(wǎng)格模式。

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

在微服務(wù)架構(gòu)轉(zhuǎn)型的驅(qū)動下，“混沌工程”實踐方案受到銀行界越來越多的關(guān)注和探索。它可以通過規(guī)范化、流程化的實踐方案對系統(tǒng)進行一定程度的“隨機破壞”，讓故障在可控范圍內(nèi)頻繁發(fā)生，在此過程中可以深入地認知故障和系統(tǒng)，并達到持續(xù)改進的效果。

混沌工程是通過向系統(tǒng)中引入軟件或硬件的異常狀態(tài)（擾動），制造故障場景并根據(jù)系統(tǒng)在各種壓力下的行為表現(xiàn)確定優(yōu)化策略的一種系統(tǒng)穩(wěn)定性保障手段。其原則是可量化的穩(wěn)定狀態(tài)、可反映真實場景，但風(fēng)險未知的假設(shè)、影響最小化。混沌實驗的具體流程包括實驗設(shè)計、實驗執(zhí)行和實驗結(jié)果分析?？偨Y(jié)來說，混沌工程就是利用實驗提前探知系統(tǒng)風(fēng)險，通過架構(gòu)優(yōu)化和運維模式的改進來解決系統(tǒng)風(fēng)險，真正提升系統(tǒng)架構(gòu)韌性，增強故障免疫力，提高企業(yè)效益。

新一代銀行系統(tǒng)風(fēng)險管理面臨挑戰(zhàn)

1.架構(gòu)層面。當(dāng)前微服務(wù)架構(gòu)已成為互聯(lián)網(wǎng)及銀行業(yè)架構(gòu)發(fā)展的主流模式，它與原先SOA架構(gòu)的區(qū)別是：微服務(wù)更強調(diào)“業(yè)務(wù)需要徹底的組件化和服務(wù)化”。其特性是：客戶端負載均衡、微服務(wù)容錯保護、API服務(wù)網(wǎng)關(guān)、分布式鏈路跟蹤等。而傳統(tǒng)的非功能測試方法只能覆蓋到業(yè)務(wù)邏輯維度，無法覆蓋和測試到上述微服務(wù)特性。

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

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

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

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

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

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

事后可以故障影響分析和修復(fù)設(shè)計，進行復(fù)盤和改進。通過實驗?zāi)M調(diào)用延遲、服務(wù)不可用、機器資源滿載等，查看發(fā)生故障的節(jié)點或?qū)嵗欠癖蛔詣痈綦x、下線，流量調(diào)度是否正確，預(yù)案是否有效?？梢蕴嵘到y(tǒng)容錯容災(zāi)的健壯性。

應(yīng)用案例研究

按照上述混沌工程的實驗原則及流程，分析銀行科技系統(tǒng)風(fēng)險管理的痛點問題，并結(jié)合市場調(diào)研，以提高應(yīng)用系統(tǒng)業(yè)務(wù)邏輯和運行環(huán)境容錯能力、增強高復(fù)雜應(yīng)用架構(gòu)下的系統(tǒng)韌性，最終以提升銀行系統(tǒng)的風(fēng)險防御能力為目標。下文將闡述混沌工程實驗平臺的設(shè)計方案。

1.混沌工程實驗平臺。如圖1所示，混沌實驗平臺功能包括：故障演練、實驗場景庫、任務(wù)調(diào)度、應(yīng)用管理、實驗管理、實驗經(jīng)驗庫、工作臺、監(jiān)控及數(shù)據(jù)分析。

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

測試技術(shù)人員可利用混沌工程實驗平臺對待實驗的系統(tǒng)實施故障演練。根據(jù)混沌實驗流程，利用混沌工程實驗平臺可進行如下操作：先分析待實驗系統(tǒng)的穩(wěn)態(tài)指標；在實驗場景庫模塊中選擇或新增實驗故障場景；在實驗管理模塊中設(shè)計實驗計劃，并在故障演練模塊中進行實驗執(zhí)行；在實驗管理模塊中進行實驗結(jié)果分析，并進行實驗管理。

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

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

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

針對容器K8S，主機/虛擬機上應(yīng)用的場景：涉及CPU資源滿載、內(nèi)存資源負載、磁盤資源負載提升、網(wǎng)絡(luò)資源異常、應(yīng)用進程殺死、容器內(nèi)進程殺死等系統(tǒng)資源類故障場景。涉及延遲、拋異常、數(shù)據(jù)篡改等JAVA應(yīng)用類故障場景。

針對特殊的分布式微服務(wù)應(yīng)用的場景：涉及RPC服務(wù)故障、API網(wǎng)關(guān)故障、配置中心故障、批量任務(wù)故障、中間件故障等場景。

（3）實驗方案。本次混沌工程測試實驗重點圍繞研發(fā)微服務(wù)平臺的容器云和微服務(wù)組件，結(jié)合生產(chǎn)環(huán)境IaaS基礎(chǔ)設(shè)施冗余切換經(jīng)驗，輔助云原生監(jiān)控手段，驗證微服務(wù)平臺服務(wù)間的強弱依賴關(guān)系及魯棒性。

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

圖2 基于研發(fā)微服務(wù)平臺故障場景演練

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

第二步設(shè)定實驗范圍。根據(jù)具體的場景明確對哪些節(jié)點實施故障注入，并且評估出現(xiàn)故障時可能受到的影響范圍，確保不會造成災(zāi)難性的結(jié)果。

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

第四步執(zhí)行實驗及實驗結(jié)果分析。演練結(jié)束后，需要對整個演練進行復(fù)盤。首先要分析總結(jié)演練是否達到預(yù)期，系統(tǒng)是否具備韌性，是否發(fā)生預(yù)期之外的結(jié)果。然后要針對故障演練過程中系統(tǒng)暴露出的問題，進行問題修復(fù)和架構(gòu)優(yōu)化。

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

結(jié)論及建議

銀行在新一代微服務(wù)架構(gòu)發(fā)展背景下，可借鑒混沌工程思想，以模擬生產(chǎn)環(huán)境為對象，對系統(tǒng)進行故障模擬，及時發(fā)現(xiàn)潛在問題，提升管理能效。同時，對于中小銀行，微服務(wù)架構(gòu)還在發(fā)展過程中，混沌工程理念和實驗平臺技術(shù)是一個“從無到有”，到“從有到優(yōu)”的過程。建議先搭建平臺，再豐富平臺功能及與其他應(yīng)用的關(guān)聯(lián)調(diào)度關(guān)系。另外混沌工程當(dāng)前還是一個比較前沿的領(lǐng)域，商業(yè)銀行本身要做到管理與技術(shù)發(fā)展并進，提升和培養(yǎng)技術(shù)人員對混沌工程的意識和能力。

（欄目編輯：張麗霞）

責(zé)任編輯：Rex_31