在銀行業數字化轉型的浪潮中，銀行核心系統的分布式轉型也加快了進行，如何保障分布式核心系統的平穩運作、提升運維服務能力水準，對一線運維人員提出了挑戰。本文結合作者近2年參與分布式核心系統項目建設過程，闡述了對分布式核心系統運維的想法。文章較長，約1.8萬字，較為系統詳細（見文前内容綱要），感興趣建議先收藏以備浏覽。

本文主要内容綱要：

（點選圖檔可放大）

1、分布式銀行核心系統建設

近年來，銀行業數字化轉型深度演進，作為銀行應用系統的大腦“銀行核心系統”在系統的開放性、穩健性和可拓展性上也提出了更高的要求。為順應銀行業數字化轉型的發展趨勢，某商業銀行加強關鍵核心技術攻關，開展以核心系統分布式轉型為代表的自主可控實踐，完成了從大型主機到分布式架構的核心系統轉型。

某商業銀行于2020年12月正式啟動分布式銀行核心系統建設，并于2022年5月全面完成技術投産，啟動生産并行驗證。經過近1年的業務驗證及投産準備，新銀行核心系統在2023年5月3日成功切換上線，正式對外提供服務。

分布式銀行核心系統建設中的一些關鍵技術領域如下：

分布式核心系統服務重構：基于DDD領域模組化方法，将銀行核心業務子產品進行解耦，拆分為業務服務領域和公共服務領域。
分布式技術架構平台建構：基于微服務分布式研發架構，完善分布式排程、分布式事務協調以及實作防重、重試、幂等等關鍵服務接口功能。
分布式資料庫優化改造：分布式資料庫的選型對核心系統至關重要，需要滿足資料可靠性、資料一緻性以及可擴充性等關鍵名額。同時為适應銀行核心業務系統的差異化需求，在特性功能、安全保護、工具運維監控、資料遷移、可用性、性能提升等多個次元進行了改造優化。
分布式核心系統監控運維體系：建立從基礎設施到應用、業務服務的全棧監控，實作對分布式銀行核心系統各個應用生态、各專業領域技術棧的統一管理，實作監控、排障、版本部署和應急流程等全流程關聯。

以下部分内容将圍繞分布式銀行核心系統的運維建設，結合2年來參與分布式核心系統項目建設，闡述自己的想法和思考。

2、分布式銀行核心系統運維

2.1 運維目标和總體架構

2.1.1 分布式核心系統運維的總體目标

銀行核心系統架構由集中式向分布式轉變的過程中，系統架構愈發複雜化、叢集規模指數級增長、各應用系統網元之間互動錯綜複雜，傳統的單點單機的集中式運維模式已經無法滿足分布式架構下的運維需求。在分布式核心系統的運維過程中，主要圍繞兩個目标：保障核心系統生産穩定運作和提升運維服務能力水準。

保障核心系統生産穩定運作，是要實作故障及時發現、業務快速恢複；系統架構上保證高可用，出現問題時能夠自動切換、實作故障自愈；故障可複盤、日志可回溯，及時的排查問題根源；變更自動可控，減少變更引起的系統可用性風險；架構和性能上易擴充伸縮，以應對性能和容量突增的業務增長需求。
提升運維服務能力水準，是要提升基礎資源快速傳遞能力，滿足伺服器、存儲和網絡等基礎資源的申請需求；提高運維需求的服務保障，如資料提取、運維監控建設需求等提升分布式核心系統服務水準的基本需求；規範化的流程和規範，制定标準化的流程進行管理，限制開發和運維操作的規範性，提升運維能力。

分布式核心系統運維圍繞兩個目标，對基礎的運維場景進行拆解，梳理出基本的運維能力和技術訴求，形成如下圖所示的總體運維目标：

圖2-1 分布式核心系統運維的總體目标

2.1.2 分布式核心系統運維的總體架構

為實作分布式核心系統的運維目标，從運維的具體業務場景出發，形成基礎設施IaaS層、基礎平台服務PaaS層、實際的運維場景管理層以及服務展現層。

管理對象層是對運維的基礎對象進行管理，包括基礎設施、伺服器、作業系統、資料庫、中間件、容器和應用系統等；
基礎服務層分為基礎平台和基礎資料，其中基礎平台提供資源傳遞以及運維對象的運維管理，基礎資料是對運維資料的采集、存儲和加工分析等處理；
基礎流程層是對基礎的運維流程進行管理，包括包括監控、應急、變更、高可用以及性能容量管理等；
服務展現層是運維的統一門戶管理，包括監控大屏、移動端和Web端入口等。

以上運維場景結合相應的運維指導規範，形成如下圖所示的分布式核心系統運維的總體架構：

圖2-2 分布式核心系統運維總體架構

2.2 運維規範和标準化

運維标準和規範是分布式核心系統日常運維工作中的指導性規範和參考依據，在運維工作中遇到有争議或者出現偏差的地方可以參考規範進行評估。總的标準規範包括監控和業務連續性規範要求、運維及開發規範、配置基線、CMDB配置模型、安全合規管理規範等。

圖2-3 運維規範和标準化

2.2.1 監管和業務連續性規範

為防範金融IT系統風險，提升業務連續性，原銀保監會制定《商業銀行業務連續性監管指引》，提出“商業銀行應當将業務連續性管理納入全面風險管理體系”，并提到核心業務系統容災建設的RPO/RTO要求：

原則上，重要業務系統RTO不得大于4小時，重要業務RPO不得大于半小時。

商業銀行應當至少每三年對全部重要業務開展一次業務連續性計劃演練。

同樣在人行2020年的《分布式資料庫技術金融應用規範災難恢複要求》也提到，“應用于金融領域的分布式事務資料庫災難恢複能力應至少達到4級及以上能力要求，滿足RPO、RTO和災備部署等關鍵名額”。

圖2-4 分布式資料庫容災等級要求

這些标準和規範為分布式核心系統的架構部署提供了規範和參考。

2.2.2 運維開發規範

在日常的運維和開發過程中，由于開發人員和運維人員個體存在差異，亟需标準規範來形成規範的開發流程和标準化操作流程，提升分布式核心系統的性能和穩定性。運維及開發規範主要包括安裝部署、資料庫開發、備份恢複、監控應急和變更管理等不同内容：

安裝部署規範包括作業系統和資料庫等基礎軟體部署安裝中的規範原則和配置
資料庫開發規範主要是面向開發人員制定了資料庫對象設計規範、DDL規範、DML規範和SQL開發規範等
備份恢複是為滿足業務連續性和系統恢複制定的備份恢複政策，是系統和業務應急恢複的最後保障
監控應急是面向實際生産系統在運作維護過程中指定的監控名額和應急處理流程
變更管理涵蓋應用版本部署和系統變更維護，規定了應用和系統變更中的基本流程和基本原則

在分布式核心系統運維工作中，建立一套完善的運維開發規範，對于保障系統穩定、安全、高效地運作至關重要。

2.2.3 CMDB資料模型

CMDB配置管理是資料中心基礎設施的神經網，關聯着各個基礎服務對象，包括實體執行個體、依賴關系。傳統的CMDB資料模型通常包括以下部分：

CI配置項：表示IT架構中的實體，比如伺服器、網絡裝置、資料庫軟體等，每個配置項都有一個唯一的辨別符和屬性，如ID、版本号等
關系：表示配置項之間的依賴關系，比如伺服器和IP、伺服器和資料庫等。關系也有唯一的辨別符和屬性，表示前置和後置的CI對象。
狀态：表示配置項的狀态資訊，如未投産、已上線、已下線等，狀态也是某個CI對象的生命周期管理。

但是在分布式核心系統中，随着單元化、容器和分布式資料庫等新技術和架構的引入，CMDB的資料模型也需要進行疊代優化。

在單元化模型中，引入業務單元和應用子產品模型，應用系統中包括多個應用子產品、應用系統中又包含多個業務單元
在容器模型中，引入應用叢集模型，并将應用叢集與容器叢集關聯起來，包括命名空間、工作負載、Pod、Container等CI對象
在分布式資料庫模型中，包括資料庫叢集、管理節點、資料節點、計算節點、租戶等，并将租戶和業務單元或者應用系統建立關聯關系

圖2-5 CMDB資料模型

CMDB資料模型是運維的最基礎和關鍵環節，各CI配置關系的準确性和保鮮度至關重要，關聯到告警資訊的精準度、應用群集視圖的展示以及裝置上下線流程的更新等。

2.2.4 配置基線管理

在日常系統維護工作中，通過配置基線标準化和規範化管理，可以有效地避免因配置項不完整或不一緻導緻的系統故障或安全風險，同時也可以提高IT服務的品質和效率。配置基線包括以下部分：

作業系統基線：包括大型機zOS、小型機AIX、Redhat、Windows、信創Kylin或UOS等
資料庫系統：包括DB2、Oracle、MySQL、國産資料庫等
中間件基線：包括WAS、MQ、Redis以及國産中間件産品等
容器雲平台基線：包括Docker、K8S等

配置基線包括性能參數配置、容量參數配置、安全審計相關配置等，并且随着軟體版本的更新進行更新維護。

2.2.5 資源部署模闆

分布式核心系統基礎設施資源部署過程中，涉及到上千台伺服器資源的申請，有實體機、虛拟機和容器資源，不同的應用對存儲、檔案系統和使用者也有不同的需求。這些資源申請的需求可以固化為不同的模闆，哪些是應用伺服器的、哪些是資料庫伺服器的，并将分類後的标準模闆定制到多雲資源申請平台中，由IaaS雲平台自動完成不同需求的資源建立部署，極大的提高了資源部署的效率，達到資源快速傳遞的目标。

2.2.6 安全合規管理

安全生産、合規操作是系統運維的底線，也是運維人員牢記心中的基本原則。安全合規管理分為幾個方面：

安全漏洞政策：系統和軟體産品是否滿足最新的安全漏洞政策，需要定期進行漏洞掃描以及更新更新檔，比如Apache Log4j漏洞
合規審計：一般由内部安全員對運維操作是否滿足規範、規章制度的執行情況、敏感資訊和系統的通路控制等
監管審計：由監管機構或第三方機構定期對系統進行審計，以評估其安全合規性和風險控制措施的有效性。審計結果需要向監管機構報告，并采取相應的糾正措施。
安全攻防演練：攻防演練是模拟真實攻擊和防禦的網絡安全演練，旨在評估和檢驗目标系統的安全性和防禦能力

是以，在日常的系統運維工作中，需要建立完善的安全管理和合規制度，確定系統的安全性、資料的保護和業務的合規性。同時，還需要定期進行安全檢查和審計，及時發現和處理潛在的安全風險和漏洞，確定業務穩定運作和客戶資訊安全。

2.3 高可用建設

2.3.1 兩地三中心高可用架構

分布式核心系統采用兩地三中心的高可用架構，生産中心、同城中心和災備中心分别承載不同的業務流量。應用側采用豎井式架構，跨中心之間互相不通路，由流量分發層實作跨中心的流量轉發；資料庫則由分布式資料庫實作跨中心的高可用。總體架構如下所示：

圖2-6 兩地三中心高可用架構

1)三中心業務經過終端管道通過域名的方式通路核心系統，各中心承載一定的流量業務，其中災備中心主要是一些白名單類業務

2)業務流量經過流量分發層會按照一定的流量比例進行配置轉發，比如生産和同城配置比例9:1，則業務流量有90%運作在生産站點、10%運作在同城站點。這個流量配比是可以動态調整的。

3)業務流量經過網關層，會根據單元資訊和注冊的應用服務，将流量路由到對應的應用伺服器，在這裡實作單元化和路由分發功能。

4)最後應用服務通過負載均衡通路資料庫節點，分布式資料庫架構中主節點一般在生産中心，對于單元化的應用部署架構，會将部分單元的資料庫主節點部署在同城中心，實作應用和資料庫雙活。

5)對于跨應用間的分布式事務，由分布式事務協調元件實作分布式事務的一緻性和復原機制，而在單個應用内則由分布式資料庫實作分布式事務。

6)對于批量業務，由批量排程架構統一排程，後面會重點展開。

2.3.2 應用高可用

2.3.2.1 聯機應用

各中心聯機業務采用豎井式架構，跨中心之間不互訪，由流量分發層實作不同中心的流量負載，實作同城應用雙活。當生産站點故障時，由同城站點接管全部流量，保證業務連續性。

各中心本地通過服務注冊發現的方式，将本地應用服務注冊到服務網關，由服務網關實作應用服務的統一排程、路由分發、監控和生命周期管理。
跨中心的流量通路由流量分發層統一配置，實作跨中心的業務通路
災備站點主要承載應用版本投産時候的一些白名單業務，以及在災備切換演練場景下的業務流量

圖2-7 聯機應用高可用架構

注意：在跨中心的流量通路中，由于應用和資料庫主節點的互動是跨中心的，整個應用鍊路的響應時間會相應增加，一般會比本地通路增加20%左右。

2.3.2.2 批量同城雙活

批量應用由分布式批量排程架構進行排程管理，生産站點和同城站點的批量應用由排程架構統一排程管理，分發作業任務執行，實作生産和同城批量雙活。

批量排程架構主節點運作在生産中心，配置和監控等資訊儲存在分布式資料庫節點中。如果主節點發生故障，自動切換到同城接管運作。
如果生産站點發生故障，則進行整體切換，保證批量業務的連續性。

圖2-8 批量同城雙活高可用架構

注意：同城批量任務需要關注生産和同城站點的帶寬使用，以及跨中心通路資料庫主節點響應時間的增加。

2.3.2.3 下遊資料服務

由于核心系統存儲保留的資料周期限制，需要将一部分資料同步到近線庫或者曆史庫中長期儲存，為下遊應用系統提供資料服務。資料同步采用日志同步工具如Canal實時采集分布式資料庫主節點的binlog日志，并通過流式資料加工處理後存儲在近線庫中儲存。

日志同步工具和資料傳輸子產品三中心部署，但是隻有生産中心是工作狀态，其它為備用；資料抽取路徑采用豎井式設計，不做跨中心互聯互訪。
近線資料庫由分布式資料庫實作高可用架構
生産中心故障時，整體切換到同城，保證業務可用性

圖2-9 下遊資料服務高可用架構

2.3.3 網絡高可用

在分布式核心系統的網絡架構設計中，劃分獨立的核心網絡區域與其它應用區域進行隔離，以最小化通路授權原則，分區内網絡互訪、分區外防火牆隔離。同時為了滿足生産和同城及災備之間跨中心的大流量複制需求，部署專用的資料同步傳輸線路。

另外，為了保證實體部署站點的高可用，在生産和同城站點采用雙AZ域部署機房子產品，每個機房子產品采用标準化的部署方案，包括彙聚交換機、leaf交換機、負載均衡器等。

AZ域内每個機房子產品的交換機、負載均衡器采用主備部署架構，保證高可用；AZ域間機房子產品間實體隔離，當AZ1域故障時AZ2域可正常提供服務，保證高可用。
為配合雙AZ部署架構，單個應用的分布式資料庫的主節點保持在一個機房，一是減少應用内跨機房的網絡通路消耗；二是當AZ域故障時，該應用的資料庫節點能夠一起快速切換到另外機房。

圖2-10 網絡高可用架構

2.3.4 資料庫高可用

分布式資料庫高可用由資料庫本身機制實作，DB節點的主備複制保證資料的一緻性，而計算節點是無狀态的，通過負載均衡保證各節點的業務通路均衡。

在應用單元化設計架構中，将部分業務單元對應的資料節點主節點部署在同城，實作生産和同城站點的應用級資料庫雙活
當出現故障發生切換時，有分布式資料庫産品層實作業務單元級别和整體的切換，迅速的恢複業務，保證RTO以及業務可用性。

圖2-11 資料庫單元化高可用架構

2.3.5 存儲NAS高可用

在分布式核心系統中，NAS通常用于檔案服務請求，比如存放上送檔案或者下發檔案，跨應用之間的檔案共享等。由于NAS性能和穩定性上的限制，在實際使用的時候會有很多限定場景和規範，比如聯機業務和應用程式限制使用、跨中心跑批場景下不能保證資料同步的實時性等。

在應用同城雙活架構中，生産中心和同城中心的應用伺服器可以同時通路生産站點的NAS存儲。資料由生産站點異步複制到同城站點，同城的NAS預授權給生産和同城兩中心的伺服器。
當生産站點的NAS故障時，同城NAS更換為主存儲角色，生産和同城的應用同時通路同城站點的NAS。

圖2-12 存儲NAS高可用架構

2.4 監控告警

監控告警是分布式核心系統運維的“眼”和“耳”，耳聰目明是保證核心系統穩定運作的關鍵，出現問題時能夠及時監控、快速響應。由于分布式架構下關聯的伺服器很多、組網關系複雜，在監控管理的時候采用标準化政策、名額分散采集、集中存儲、統一展示和全局監控的政策。

對于伺服器和資料庫軟體的性能資料和日志資料制定标準化采集模闆下發到采集代理政策中；同時監控平台支援定制化的政策用于應用和分布式資料庫的個性化政策
各伺服器群組件上采集的性能和日志資料推送到監控平台和日志平台集中存儲，用于後續的名額資料分析和名額監控政策配置
監控平台和日志平台對采集的名額資料和日志資料進行統計分析，形成标準的展示圖表，并具備自定義的名額視圖和監控面闆
監控平台定制應用系統群集的監控，滿足整個應用群的全局監控視圖

圖2-13 監控平台功能子產品

2.4.1 監控名額

1）監控名額分類

應用和系統的監控名額根據用途和功能分為不同的類型，包括狀态類、性能類和容量類

狀态類主要是服務的運作狀态、程序的狀态或者任務的執行情況。狀态類的名額除了監控平台标準化的采集模闆外，一般需要應用和系統自定義采集對象和規則，或者由第三方産品采集推送到監控平台彙總。
性能類主要涉及系統和軟體的性能名額，比如交易耗時、TPS、CPU和記憶體使用等。性能類名額多采用标準化的采集模闆，屬于多數應用和系統通用的子產品。
容量類關聯到伺服器或系統軟體的性能上限，比如伺服器CPU和記憶體增長趨勢、檔案系統的使用、資料庫連接配接數等

2）監控名額采集項

不同的應用和系統的監控名額資料會有所不同，總結下來有以下幾類：

業務和應用監控名額

業務性能名額如業務TPS、QPS、響應時間、交易成功率和響應率，以及批次的運作時間等
應用服務的運作狀态類名額，比如服務程序和端口狀态、批次任務執行情況、檔案推送和接收情況等

系統和網絡監控名額

硬體層面的伺服器性能和網絡流量使用
作業系統層面的CPU、記憶體、磁盤IO、網絡流量、檔案系統使用等。如果是實體機做RAID，還可以進行檢測磁盤性能情況，提前發現磁盤問題

資料庫監控名額

資料庫對象監控包括表分區建立情況、表結構一緻性檢查、表資料量和空間增長情況、binlog統計、備份完成情況等
資料庫層面的TPS、QPS、連接配接數、線程池、主備時延、鎖逾時和死鎖等名額監控

随着新的應用軟體和資料庫産品的使用，通用的監控采集名額已經無法滿足個性化的監控需求，尤其是分布式資料庫需要定制化的采集名額，這些通常也是由産品本身實作，以接口的方式由監控平台直接調用采集。

2.4.2 監控平台

監控平台實作标準化監控名額資料的采集，監控名額資料的彙總以及告警政策的配置，并實作自定義的監控視圖以及定制化的應用群集視圖。

監控大盤和看闆是名額資料的彙總展示，能直覺的看到各個應用群組件相關名額的趨勢和運作情況
應用群集視圖将應用系統群集作為一個整體進行觀測，每個元件或者服務背後是各個名額資料的彙聚展示，能夠直覺的定位到異常點和影響範圍

以業務監控名額為例，通過TPS、交易成功率、響應時間和P99響應時間“四象限”監控交易的性能情況，通過多個名額次元來精準的監控到系統的運作情況。

圖2-14 監控四象限示例

另外，監控平台通過接入第三方平台的性能及監控資料，形成全棧監控，比如批量運作資料、資料庫管理平台的監控資料等。

2.4.3 事件告警

事件告警的來源主要有幾種：應急、系統和應用的錯誤資訊推送到監控平台，根據配置的告警政策觸發告警；監控平台采集的名額資料，根據配置的政策觸發告警門檻值産生告警。告警資訊具備及時性、準确性、可讀性，當發生故障時第一時間通過告警資訊定位哪個應用哪個元件出現問題，判斷出影響範圍。同時，事件告警管理時還需要注意以下幾點：

告警資訊的級别：告警資訊通常分為緻命、重要、一般和通知類，通過告警分級将最為關鍵的資訊及時的告知管理者
告警資訊豐富：告警資訊中如果隻有IP和伺服器資訊，在伺服器混合部署的情況下是無法準确判斷屬于哪個應用哪個元件的。是以，在告警資訊中包含必要的應用資訊、節點資訊甚至業務單元資訊，以便準确的定位影響範圍。
告警風暴的影響：在分布式架構下，某個環節出現故障時候可能會出現成百上千條告警出來，形成告警風暴，極大的影響故障定位。如何從這些告警資訊中聚焦到關鍵的告警和名額，需要借助于全局的監控視圖、事件關聯分析等監控工具進行快速排障
事件關聯分析：告警事件之間往往是有關聯的，子系統元件之間、系統和應用之間，基于應用架構和拓撲，對相關的告警進行關聯分析

總之，告警資訊的時效性和準确性影響後續的業務影響判斷和應急響應。

2.4.4 日志平台

現有的ELK或EFK日志處理架構已經相當成熟，将分散在各個伺服器的不同節點的相關日志統計采集到日志平台，進行統計分析、彙聚展示以及告警提示。

日志平台采集的不同日志類别用于不同的場景，比如運作日志中提取錯誤資訊用于告警、性能日志用于性能資料分析、審計日志用于運維審計等
利用平台的統計功能對錯誤碼資訊和性能日志進行彙總統計，形成趨勢對比，能觀察到不同次元的系統運作情況
自定義的看闆和視圖對應用運作日志進行統計生成監控視圖，實時監控TPS、響應時間以及成功率等交易量變化

不過，需要注意的是日志平台采集這麼多日志資料，對平台本身的性能也是有一定的要求，如何快速的生成統計分析結果，也會影響運維服務體驗的。

2.4.5 基于全鍊路日志監控

在分布式架構下，基于全鍊路日志能夠實作應用間端到端的監控，将應用各個服務元件調用、應用和資料庫之間的調用關系以及元件之間的耗時情況統計出來，清晰的觀測到交易鍊路中哪個環節出現問題。

圖2-15 全鍊路日志跟蹤示例

全鍊路監控在實作上簡單來說是由分布式跟蹤系統如Zipkin、Skywalking等每個請求生成一個唯一的traceID，并将其包含在請求和響應的header中，以便在整個應用程式中追蹤請求和事務。同時，分布式資料庫支援将全鍊路traceID記錄到資料庫性能日志中，這樣形成應用間、應用到資料庫之間的端到端監控。基于全鍊路日志能夠統計到各個鍊路調用的耗時、SQL通路的耗時，便于排障和問題分析。

2.4.6 eBPF監控

eBPF監控基于eBPF程式在核心中運作，可以采集核心中的各種參數、狀态和事件資訊，例如系統調用、網絡包、網絡連接配接、磁盤I/O等。采集到的資料可以通過Map資料結構在核心中進行存儲和處理，然後通過使用者空間程式擷取這些資料進行展示和分析。

圖2-16 eBPF監控

在Linux系統中可以使用bcc-tool安裝，然後直接調用進行監控。實際生産運維過程中eBPF可以作為通用監控的補充，能夠更為精确的定位磁盤或者網絡的性能問題。比如：

磁盤IO性能監控：xfsdist監控磁盤IO時延情況，通過對比正常讀寫IO性能，比伺服器和系統本身更早的發現性能問題；
網絡rtt時延監控：tcprtt監控網絡rtt時延，提早發現網絡性能問題

需要注意的是，eBPF還處于研究試用階段，對系統和應用的侵入性，尚未經過廣泛的使用驗證。但是相信，eBPF在雲原生尤其是容器的可觀測性上會有幫助。

2.5 應急管理

2.5.1 應急預案及應急演練

生産運維過程中出現故障應急時，以第一時間恢複業務為首要目标，保證業務的連續性和系統的可用性。在應急流程管理過程中，現場運維管理人員根據告警資訊和業務影響快速排查定位問題，邊恢複邊上報将故障及時的通知到上一級别管理人員。對于無法判斷原因的優先考慮增加資源、隔離、重新開機應用等處置措施，判斷與變更相關的，考慮進行變更應急或回退。

圖2-17 應急處理流程

對于分布式核心系統，以告警為統一入口實作監控、排障、應急全流程關聯，實作1分鐘響應、10分鐘排障定位、30分鐘應急恢複。另外，除了現場應急處置外，在日常的運維過程中準備應急預案并做好應急演練工作。

2.5.2 故障自愈

故障自愈是指系統在運作過程中能夠自動檢測和修複故障，進而實作自我修複和持續運作的能力。在分布式核心系統運維過程中，故障自愈其實是一種理想狀态，更多的運維場景下依賴于系統的容錯和高可用機制，以及人工幹預處理。

故障檢測和診斷：系統需要具備能夠實時檢測和診斷故障的能力。通過監控系統的各個元件和關鍵名額，可以及時發現潛在的故障和問題，并進行相應的處理。
自動化修複：系統需要具備自動化修複故障的能力，以避免人工幹預的時間和成本。通過編寫自動化腳本和程式，可以實作故障的自動檢測、定位和修複。比如應用程序異常挂起，通過心跳檢測等檢查機制，将應用重新開機以恢複。
高可用容錯能力：在高可用部署架構下，當單個元件出現故障時觸發自動切換，進而實作系統快速恢複。

故障自愈在簡單的運維場景下能夠實作應用和系統快速恢複，幫助系統實作自我修複和快速運作。結合實時監控和告警等機制，實作對系統故障的及時發現和處理，提高系統的穩定性和可靠性。

2.5.3 故障域隔離

故障域隔離指的是将系統劃分為不同的故障域，将故障隔離在一個特定的故障域内，避免故障對整個系統的影響。在單元化的部署架構中，當其中一個單元的元件出現故障時，通過網絡隔離、防火牆或者虛拟化等技術，将故障隔離在單個故障域内，以避免對整個系統的影響。故障域管理有利于避免全局性的系統風險，但是如果故障域劃分過細，也會增加運維管理成本。同時故障域的應急處理能夠實作自動化，以便于快速的應急處理。

2.5.4 應急自動化

監控平台将一些标準化的應急操作步驟固化成自動化應急場景，實作菜單式應急。比如檔案系統告警的應急擴容、日志目錄的應急清理、長SQL和長事務的應急處理、應急限流和應急殺交易等操作。應急自動化适用于标準化的應急流程，當觸發告警時由一線管理者根據告警資訊和應急知識庫直接在監控平台完成應急操作，優化運維操作流程。

2.5.5 應急知識庫

運維知識庫中儲存有标準化的運維操作手冊、應急處理手冊，監控平台将告警資訊與運維知識庫關聯，将标準的應急手冊帶入監控告警中，提升告警應急處理能力。對于知識庫中沒有的應急處理措施，需人工補錄進去，将專家經驗轉化為标準化、數字化的知識經驗。

2.6 變更管理

分布式核心系統運維中的變更管理分為應用版本部署和系統變更維護，其中應用版本部署涉及到應用程式投産、資料庫版本部署和參數維護等操作；系統變更維護涉及到基礎設施維護更新、資料庫等軟體版本更新、參數配置調整等維護操作。變更管理流程涵蓋需求評審、應用和系統測試、變更評審、投産演練和投産上線環節。

圖2-18 變更管理流程

需求評審：一般開發和運維需求包括業務開發類、系統運維類和軟體産品功能更新等需求，需求經專家組評審後進入開發和測試階段。
應用和系統測試：測試環節至關重要，是産品和功能能夠在生産穩定運作的前提。測試包括應用功能測試、性能測試、影響評估報告、SQL稽核報告等，測試完成後送出測試報告作為變更評審材料。
變更評審：變更評審是變更的準入稽核，包括變更準備材料、變更視窗、變更期間的業務影響評估，涉及到停業的還有停業公告等。
投産演練：投産演練是上線前的步驟和時序驗證，演練期間發現的問題及時回報解決。作為核心系統需要準備一套投産演練環境，作為投産時序、操作手冊和變更視窗時長的提前驗證，以提前發現問題。
投産上線：在既定視窗變更投産，出現問題應急解決，必要時需回退版本。

2.6.1 應用版本部署

分布式核心系統具備兩地三中心的部署架構，在應用版本部署時會考慮三中心的部署流程進行跨站點部署、灰階驗證，以減少投産期間的業務影響，保障業務的可用性。

圖2-19 應用跨中心部署流程圖

應用變更自動化平台實作跨中心的應用版本部署，同城和災備站點批前投産、生産站點批後投産
同城中心投産時将流量全部切換到生産站點，應用投産完成後将部分流量（1%）切換到同城進行灰階驗證
資料庫DDL和生産的應用版本在批後投産，将流量全部切換到同城後再部署生産應用
應用部署完成後恢複投産前的流量配比和排程配置

基于兩地三中心的架構，整個應用版本部署流程上盡量減少應用影響，保證業務連續性。需要注意的是，如果涉及到熱點表或者非線上DDL的變更操作，需要安排在停業視窗執行，并充分評估好視窗的執行時間。

2.6.2 系統變更維護

系統變更維護通常包括硬體故障更換或更新換代、系統軟體版本更新、參數配置調整、備份恢複等維護操作。在分布式核心系統中，涉及到硬體伺服器、網絡、作業系統和資料庫等基礎設施及軟體變更維護，依托于高可用部署架構，做到提前切換、線上變更、滾動操作、應用無感，盡可能減少對業務的影響。

在伺服器或者網絡等基礎設施等變更操作時，提前将故障裝置切換到備機以提供服務，比如資料庫伺服器主節點切換到備節點伺服器、網絡交換機切換到備援裝置
作業系統和資料庫等軟體更新維護采用站點級别的滾動更新政策，比如将流量全部切換到生産站點後再更新同城站點。分批次滾動變更操作，以減少業務的影響時間。
對于參數配置變更等需要重新開機生效的操作，如果滿足應用雙活架構采用跨站點的變更方式，如果是主備架構的需要采用滾動的變更方式。

2.6.3 應用變更自動化

應用版本部署由應用變更自動化平台實作自動化部署，将版本部署流程編排到自動化平台調用背景的部署腳本自動執行，實作變更流程的自動化、變更日志的可分析、變更記錄的可追溯，同時和變更流程關聯起來，實作應用版本的快速傳遞和部署。

圖2-20 應用變更自動化流程

2.7 性能容量管理

2.7.1 性能壓測

性能壓測是通過壓測工具如Jmeter等模拟高負載的業務場景，檢測系統的性能瓶頸以及評估系統穩定性的測試方法。通過性能測試以及測試結果分析，找到系統和應用在性能容量上的短闆，對系統進行針對性的優化，以應對突發的高并發業務請求，提高系統的性能和穩定性。在分布式核心系統中常用的性能壓測場景包括以下：

1)單交易壓測：針對單個交易場景進行壓力測試，旨在測試單個交易場景下的性能和穩定性。比如基于主鍵的單點查詢、一對一綜合轉賬交易等，測試系統和應用程式的響應速度以及負載處理能力等名額。

2)混合交易壓測：針對多交易場景下的混合壓測，模拟真實生産環境的讀寫交易比例，測試系統和應用的運作情況。

3)熱點賬戶壓測：在核心系統中存在熱點賬戶更新等特殊業務場景，這類熱點賬戶的并發通路資料庫操作對分布式資料庫的單節點的性能是個考驗。通過熱點賬戶的壓力測試，驗證應用針對熱點賬戶的設計方案以及資料庫的熱點記錄處理能力，提高核心系統的可用性和穩定性。

4)性能極限測試：極限測試目的是測試系統和應用在極端情況下的性能極限，旨在測試目前系統和應用架構下能夠支撐的最大業務。極限測試也是為性能容量評估和擴容提供了資料支撐。

5)疲勞測試：應用和系統長期運作在高負載下的壓力測試，一般由混沌工程觸發演練場景，模拟高負載的壓力情況，測試系統和應用性能。

6)網聯組織的壓測：每年配合網聯等支付機構進行針對性的壓力測試，評估整個交易鍊路的性能和穩定性。

性能壓測是驗證系統和應用在不同測試場景下的性能情況，并檢驗交易鍊路中網絡和系統架構的穩定性。結合性能測試的結果有針對性的進行應用或系統擴容、參數配置調優以及交易鍊路的優化，提升系統的可用性。

2.7.2 性能分析及調優

性能分析和調優是例行的工作，基本在分布式核心并網運作期到後面的生産運作維護期間持續進行着。從聯機和批量應用、資料庫和應用多個元件和次元，基于全鍊路統計日志、資料庫性能日志、系統性能日志等性能資料全面深入分析排查潛在的性能問題。

通過全鍊路日志統計交易鍊路層各個接口的耗時情況、SQL執行的次數以及耗時
通過分析資料庫性能日志統計慢查詢，找到執行計劃異常的SQL
ü通過分析應用伺服器和資料庫伺服器的CPU、磁盤IO和網絡時延情況，定位出資源上是否存在瓶頸
ü針對批量業務尤其是高并發的資料庫通路，達到資料庫處理能力上限。這種秒級别的CPU毛刺由應用側控制并發來優化。

應用的性能調優是全局考慮層層剖析的，從應用并發控制、連接配接池的配置、再到資料庫線程池和記憶體參數設定，将系統性能調優到最佳狀态。性能調優過程中的基本經驗是應用并發不是越大越快，大部分時候并發降下來，CPU毛刺消失了，而業務的執行并沒有變慢。

2.7.3 基礎設施容量評估

容量評估基于現有的業務增長資料、伺服器性能資源使用情況以及應用資料量的增長變化，評估出現有的資源配置能否支撐未來的業務TPS增長、資料存儲以及批次運作視窗的要求。性能容量評估需要注意以下幾點：

性能資料的采集和儲存：包括業務名額資料、伺服器性能名額資料以及應用表存儲相關資料，定期儲存用于後續的容量模型評估
容量預估模型：基于曆史的名額資料建立合适的容量評估模型，覆寫業務TPS、批量運作視窗、應用資料量增長等關鍵名額
資源擴充和架構調整：模型評估完成後，是否需要擴充伺服器資源、資料庫分片能否滿足業務壓力、存儲資源有沒有瓶頸以及相應的備份資源擴容等。其中資料庫分片調整還涉及到部署架構的調整，需要提前做好規劃。

圖2-21 性能容量評估

總之，容量評估是保障業務連續性和穩定性的重要環境，評估資料的完整性和評估模型的準确性影響系統的性能、資源的使用和運維支出成本。

2.8 容災切換驗證

2.8.1 高可用切換驗證

高可用切換是驗證系統架構穩定性的基礎，通過實戰切換檢驗高可用架構是否有瑕疵，業務的RTO能否保證。同時根據監管規範和業務連續性要求，分布式核心應用系統每年需要進行一次同城切換演練，每3年需要進行一次災備演練。

圖2-22 高可用切換驗證場景

高可用切換驗證如上圖所示從切換場景上分為：本地域的切換演練、同城整體切換演練、同城單元切換演練以及災備演練，其中同城整體切換需要保證RTO<15分鐘、災備演練需要保證RTO<4小時。

本地域的切換演練：包括AZ域機房級别故障、資料庫主節點故障切換、應用服務故障、負載均衡故障，驗證本地機房級别的高可用
同城整體切換演練：同城實戰和故障切換，将核心應用系統、關聯的下遊系統、資料庫整體切換到同城運作，滿足15分鐘的RTO要求，保證業務連續性。
同城單元切換演練：某個業務單元子產品出現故障時候，将該業務單元切換到同城運作，不影響其它業務單元在生産站點的正常運作。
災備演練：分為災備切換和孤島演練，災備實戰切換是将生産的業務切換到災備站點運作；孤島演練是将災備和生産同城網絡斷開，在災備站點形成孤島進行測試演練，交易資料不需要回寫到生産站點，不影響生産站點業務的正常運作。在實際生産部署架構中，由于生産和災備網絡時延限制，為滿足監管要求采用孤島演練的方案進行災備演練作為首選。

高可用切換驗證至關重要，無論是本地域服務或者元件級别的故障切換，還是同城站點級别的切換，完整的切換流程和切換時序驗證，這些都需要借助于自動化切換平台實作。

2.8.2 自動化災切平台

自動化災切平台是将同城切換演練和災備演練完整的時序和标準的切換流程固化到切換平台中，通過平台調用切換腳本或者接口完成各個子產品的切換工作，減少人工執行的動作，提高切換的效率，做到切換流程的可編排、自動化、可視化。

圖2-23 自動化災切平台流程

2.8.3 混沌工程

混沌工程是在分布式系統中通過故障注入來主動發現和修複系統中的故障和錯誤的技術，目的是提高系統的彈性和可靠性。

混沌工程是在分布式系統上進行的實驗科學，旨在提高系統容錯性，建立系統抵禦生産環境中發生不可預知問題的信心。

混沌工程通常使用混沌工程工具比如Chaos Mesh來模拟各種故障和錯誤，例如網絡故障、節點故障、應用程式崩潰等。通過模拟這些故障和錯誤，發現系統中的弱點，并采取相應的措施來修複它們。在開發混沌工程實驗時，牢記以下原則，将有助于實驗的設計。

建立穩定狀态的假設
用多樣的現實世界事件做驗證
在生産環境中進行實驗
自動化實驗以持續運作
最小化爆炸半徑

圖2-24 混沌工程流程

混沌工程其實是高可用演練場景的補充，基于混沌工程，通過在并網環境對應用系統和伺服器中随機注入故障，用以檢測系統在部分對象或功能異常時候能否正常的對外提供服務。通過模拟真實生産環境下的故障場景，建立包括應用層、系統層以及容器層的故障注入能力，提供應急協同、故障定位和故障恢複的運維能力。

2.8.4 系統備份恢複驗證

系統備份恢複是運維的最後保障線，守住這條線在出現系統故障或者誤删庫删表時，能夠及時的恢複出資料，保證資料不丢業務才能繼續下去。系統備份恢複主要是在備份恢複管理規範下制定備份政策和資料恢複方案，在既定的備份資料中能夠做到指定時點的資料恢複、跨叢集的資料恢複以及跨版本的資料恢複。

指定時點的資料恢複：根據資料庫的全量備份和增量日志備份實作資料的指定時點恢複，滿足業務的資料恢複需求
跨叢集資料恢複：将生産環境資料恢複到異機環境，以滿足資料提取等恢複需求
跨版本資料恢複：舊有版本的備份資料能夠在新的資料庫版本中恢複，實作跨不同版本的資料恢複

總之，系統備份恢複是生産系統運維的最後一道屏障，是保證分布式核心系統穩定運作和業務連續性的根本。

2.9 運作情況報告

2.9.1 系統和應用運作情況

應用系統投産後需要生成運作情況報告，報告形式不必過于複雜，主要包括應用總體運作情況、系統和資料庫總體運作情況等幾個要素。運作報告确定好報告模闆，資料源來源于監控平台或者自動化腳本采集，通過巡檢平台每天自動生成報告，包括以下内容子產品：

應用群集展示：包含金融和非金融交易TPS、批量運作狀态和視窗、應用服務狀态以及關鍵管道交易的變化情況。
聯機交易的運作情況：包含金融和非金融交易整體的交易總量、TPS峰值、平均響應時間和系統成功率；各主要管道的交易統計資訊。
批次運作情況：各應用主批次的開始時間、結束時間、批次執行視窗耗時情況等
資料庫運作情況：包括資料庫層TPS和QPS峰值、聯機時段和批量時段CPU使用峰值、檔案系統使用率、應用表資料增長情況、日增日志量等名額。
系統運作情況：包括虛拟機主控端CPU、記憶體、網絡和存儲IO使用情況
網絡運作情況：包括網絡負載均衡、複制帶寬流量的使用情況
運作報告期間的發生的故障和事件統計

運作報告能夠直覺的反應當天應用和系統的運作情況，提高了對應用系統的可了解性，提升了運維服務水準。

2.9.2 日常巡檢報告

日常巡檢報告是每天定時對系統和應用執行巡檢腳本并生成巡檢報告，以監控系統的日常運作狀況和性能，及時發現并解決系統中的問題和故障。通過梳理巡檢名額确認采集的名額資料，然後根據采集政策執行巡檢腳本儲存巡檢結果，在巡檢中心定制化巡檢報告模闆生成巡檢報告。日常巡檢報告涵蓋應用通用名額、分布式批量、分布式資料庫名額以及基礎設施層面的運作情況等内容：

應用通用名額：覆寫應用伺服器資源、聯機交易、應用服務狀态、分布式事務以及資料狀态校驗等

應用伺服器和容器Pod的CPU、記憶體等資源使用情況
聯機交易的TPS和耗時統計、SQL執行統計、服務接口耗時以及連接配接池等情況
事務的吞吐和積壓情況、分布式事務的耗時、分布式事務的成功和失敗情況統計
應用服務的運作狀态、Full GC的統計、應用服務的耗時統計等
業務層面資料狀态校驗結果，檔案是否下發完成、下遊資料同步情況等

分布式批量運作名額：批量運作視窗時長、關鍵路徑執行情況、作業執行情況統計、異常資訊統計等
資料庫名額：覆寫資料庫相關的業務運作名額、系統運作名額以及資料庫運作名額

業務運作名額包括資料庫統計的TPS和QPS情況、應用表資料增長情況
系統運作名額包括資料庫伺服器CPU、記憶體和磁盤網絡IO情況
資料庫運作名額包括連接配接數統計、分布式事務統計、主備同步時延、死鎖逾時檢測、應用表狀态及一緻性檢查、備份完成情況等

基礎設施名額：覆寫虛拟化主機、容器平台、網絡裝置以及存儲資源等

虛拟化主機的資源使用和IO、網絡性能情況
容器平台的資源使用和性能情況
網絡負載均衡使用率、同城和災備的網絡複制帶寬使用情況等
存儲資源的使用及性能情況

日常巡檢報告不僅限于以上名額，這些标準化的名額資料由巡檢腳本定時采集儲存，最後由巡檢中心調取巡檢結果，生成定制化的巡檢報告，包括例行的日報、月報以及版本前後性能分析對比報告。通過将運維人員日常的巡檢工作标準化和流程化，并固化到巡檢平台中，減輕運維工作的壓力。

2.9.3 深度巡檢報告

深度巡檢是在應用和系統運作一段時間後定期進行的巡檢工作，通過對系統深層次的名額資料采集和分析，發現潛在的問題和風險，并做好相應的應對措施。深度巡檢通常比日常巡檢的名額更為豐富，涉及到系統軟體内部運作狀态的檢查，一般由相關領域的專家完成，并形成深度巡檢報告。

2.10 運維平台賦能

分布式核心系統利用資料中心現有的運維平台能力，實作“實作1分鐘響應、10分鐘排障定位、30分鐘應急恢複”的全流程的運維監控管理。以下是具備的運維平台能力：

圖2-25 運維技術平台

監控中心

監控平台：實作監控采集、監控名額存儲、監控告警推送、監控視圖展示等全流程的監控管理
日志平台：負責日志資料的采集、存儲、統計分析以及視圖展示，尤其是全鍊路日志能夠實作端到端服務元件之間的監控，提升了問題分析能力
服務營運平台：用于應用服務的注冊、發現和生命周期管理，內建到監控平台實作應用群集的服務狀态監控
智能運維分析平台：通過智能學習算法提高名額資料監控運維的準确性，減少誤報
應急演練平台：內建混沌工程以故障注入的方式主動在應用系統模拟真實的生産故障，驗證系統的穩定性和可用性
故障排障樹：基于監控名額資料和應用系統拓撲以及鍊路關系實作快速故障定位

自動化運維平台

多雲資源管理平台：定制化資源申請模闆，提升基礎設施資源快速傳遞
應用自動化變更平台：應用版本部署流程化和自動化，實作版本快速部署
系統自動化運維平台：分布式架構下運維腳本的批量下發執行、批量彙總執行結果，提升自動化運維能力
資料庫運維管理平台：實作分布式資料庫的部署、監控和變更維護
網絡自動化運維平台：網絡資源的自動化處理并開放自助式頁面增加運維的自由度，比如負載均衡的上下線、負載均衡鏡像流量采集等
容災切換平台：實作災備切換流程的可編排、自動化和可視化，減少人工操作步驟，提升RTO業務恢複時間

性能分析管理平台

巡檢平台：通過标準化的巡檢名額和定制化的巡檢模闆，實作自動化的系統應用運作報告和例行的運作報告
性能容量管理平台：基于性能資料的增長趨勢預估容量增長模型，評估應用和系統容量使用趨勢，提升系統的可用性

雲原生平台建設：将基礎設施資源、平台能力雲化管理，實作資源快速傳遞部署、自動擴縮容的管理能力

基礎運維平台是分布式核心系統平穩運作的基本能力，建立數字化的基礎運維平台實作全棧的監控、應急和運維服務能力，保證應用系統的穩定性并提升運維服務水準，實作分布式核心系統運維的總體目标。

2.11 潛在問題和風險

分布式核心系統由于業務系統的重要性、分布式應用架構和分布式資料庫的複雜性、基礎設施和網元節點管理的規模化增長，在實際的生産維護、變更管理以及監控應急過程中仍然需要保持一顆敬畏之心。雖然分布式核心系統投産上線穩定運作兩個多月，在運維過程中還是需要關注一些潛在的問題和風險：

1）基礎架構的穩定性和容錯能力

分布式架構下X86平台相比集中式的大型主機平台，在伺服器的穩定性和單機處理能力上明顯不足。當出現硬體伺服器故障，應用或者資料庫節點能否及時的感覺異常并切換到可用節點，還需要經過生産環境實際運作的長時間考驗。高可用切換演練及故障場景演練并不能完全覆寫實際的生産運作場景，面對一些未知的故障場景下系統架構的穩定性和高可用機制、故障影響的爆炸半徑以及影響範圍收縮等，能否滿足業務連續性要求有待驗證。

2）分布式群集下的故障快速定位及處理

在分布式核心系統複雜的交易鍊路群組網架構下，監控資訊的及時性和準确性、故障能否快速恢複或者隔離以減少業務影響、應急響應的時效要求等，也是對監控平台全棧監控能力的展現。

3）分布式架構下熱點賬戶的處理瓶頸

在集中式架構中由于單機處理能力強大，面對熱點賬戶等業務場景能夠滿足性能要求。但是在分布式架構下，由于單節點處理能力的限制，已經無法滿足熱點賬戶等高并發的業務請求，此時需要在應用設計上具備熱點賬戶的處理機制，在應用側進行流量控制以減少對資料庫層的影響。尤其是在分布式資料庫架構下，單個節點的資料庫異常時，可能會引發全局的影響，造成雪崩式的反應。

4）高負載情況下網絡複制帶寬的壓力

在高并發高負載的業務場景下，尤其是批量業務高峰時段，生産和同城及災備的複制帶寬承受明顯的壓力。當複制帶寬使用率過高時會影響資料庫事務的送出性能，進而影響業務的處理效率。為了滿足業務性能及批量視窗要求，需要時刻關注流量複制帶寬的使用情況，必要時候擴容資源，以保障系統的穩定性和業務連續性要求。

5）應用版本部署後的性能變化

應用程式和SQL在測試環境性能測試通過後，部署到生産環境由于真實的生産環境和測試環境在資料量、環境配置以及架構上的差異，導緻資料庫通路的執行計劃發生變化，引發性能問題。大部分的SQL經過SQL稽核工具掃描已經排查分析并經過投産演練環境測試驗證，不排除存在漏網之魚，出現這種場景時要采取快速的應急措施，前端限流後端添加索引等優化措施以恢複業務正常通路。

3、總結和展望

在分布式核心系統成功切換投産的時候，研發的上司提到，大緻意思是技術的發展周期為10年，在這周期的前3年完成分布式核心系統下移的偉大跨越，後續繼續沿着技術創新的步伐前進。這是開發的視角去思考，從運維的視角，資料中心的上司有個很形象的比喻，“分布式核心系統就像一個孩子，現在這個孩子呱呱墜地了，撫養的重任交到資料中心來了，後面需要悉心照料，以健康茁壯的成長”。

天下之勢分久必合合久必分，回顧主機核心發展的這二十多年，當年的大集中建設如火如荼，也抗下了近十年的業務迅猛發展。但是面對資訊安全、信創改造和自主可控的必然趨勢，銀行核心系統必須要進行更新改造，加速數字化轉型、突破發展瓶頸。不僅僅是中小型商業銀行，業務體量更大的四大行的核心改造工程也早已提上日程勢不可擋，并且有些核心業務功能子產品已經投産上線。

總之，新的分布式核心系統平穩投産上線并穩定運作一段時間了，但後續的生産穩定運作保障，還是需要運維和研發團隊一起負重前行。

作者：大唐小少

來源：twt社群

運維新挑戰：銀行業分布式核心系統運維的思考及實踐