無人值守率達55%,億級金融系統智慧運維的深度實踐

語言: CN / TW / HK

本文根據陳澤昊 老師在 2022 Gdevops全球敏捷運維峰會-廣州站 〗現場演講內容整理而成。 (點選上方【dbaplus社群】公眾號,回覆“220617”可獲取完整PPT)

講師介紹

陳澤昊, 微眾銀行存款核心系統運維負責人。2016年入職騰訊,主要負責騰訊地圖相關業務運維工作;2018年加入微眾銀行,擔任資深業務運維工程師,作為銀行存款核心系統運維負責人,主要負責核心系統的運營規劃,以及智慧化運維在核心繫統中的實踐和推進工作。

分享概要

一、微眾銀行分散式架構

二、自動化之路

三、智慧化實踐

四、挑戰及未來

一、微眾銀行分散式架構

微眾銀行的分散式架構融合了分散式的松耦合架構和一主兩從節點的強同步架構,為什麼我們會選擇這兩個架構?

1、分散式松耦合架構

我們先來看一下分散式的松耦合架構。在分散式架構興起之前,中國銀行業主流的技術架構是集中式的松耦合架構,它的優點是一定程度上分散了風險,提高了資源利用率。但是銀行業務的複雜性使得銀行業務的系統呈現出一種高度的相互依賴性,很多客戶的服務請求是一個從端到端的完整的鏈路請求,它往往需要多個銀行業務系統之間進行配合。

舉一個例子,我從銀行的APP發起轉賬轉出去,可能會經過一個APP的子系統,到一個存款的系統,需要扣減餘額,再到一個匯款的系統,然後可能要通過超網等銀行之間的渠道出去,那麼在這當中只要有一個子系統出現了故障,可能就會對其上下游的系統產生影響,從而對銀行整體可用性和穩定性產生較大的影響。

因此我們在中間做了一個橫向的切分,就形成了一個分散式松耦合的部署架構,使一個節點成為一個客戶的服務節點,該客戶的全生命週期資料都集中在一個節點上,涉及單一客戶的交易處理也在同一個節點上完成。也就是說,一個客戶只會存在於一個節點之中,從開戶到做金融交易再到銷戶,所有請求都會在單節點中產生,所以節點與節點之間是相互隔離的,沒有依賴性,如客群一故障並不會影響到客群二和客群三。分散式松耦合架構既保證了我們整體架構的穩定性,同時通過節點數量提升了我們架構的效能。

2、一主兩從節點強同步架構

金融機構對於資料的質量是有要求的,我們主要是通過一主兩從節點強同步架構來保證資料一致性。

最開始我們考慮到網際網路的架構是分散式的多主節點架構,這套架構的好處是高彈性、高可用和低成本,但是分散式多主節點架構無法同時滿足CAP,也就是說我們的服務在某些場景下可能會是有損的,但是金融行業其實有一定的要求,金融機構在金融服務場景下無法接受有損的服務,從而引出我們的一主兩從節點強同步架構。我們通過資料副本保證可用性,同時資料和主節點是強同步的,那麼就實現了整體資料的高可用。

融合分散式松耦合架構和一主兩從節點強同步架構,最終就成為了微眾銀行的IT架構模式。在應用層面採用松耦合的部署模式,即不同應用域之間的系統不共享物理資源,則能保證其高可用性,同時通過強同步的模式保證資料的一致性,最終該IT架構降低了對於系統單例項的效能要求,也就是降低了研發的門檻,但是因為架構比較複雜,所以對於運維管理而言要求相對較高,需要有一套高度自動化的運維體系支撐整個IT系統的穩定執行。

這裡補充一點就是我們的客群,在行內稱作DCN,即資料中心節點,是我們用來管理架構的一個最小單元,後面可能會提及DCN的概念。

二、自動化之路

接下來介紹一下我們的自動化運維過程,以及我們遇到的一些問題和我們的解決思路。自動化運維即DevOps其實是我們做AIOps和智慧化的必經之路,裡面很多沉澱出來的東西對於智慧化有很多借鑑意義。

1、最大的挑戰

先看一下我們在自動化運維裡遇到的最大的挑戰是什麼。

1)銀行業務增長量超過了人力的增長

意味著運維在保證日常工作正常開展的同時,還要去做自動化運維的一些建設,相當於一個人要當成兩個人用。

2)多業務場景,業務架構差異

微眾銀行雖然只有7年多的歷史,但是隨著銀行規模的擴大,它的業務發展非常快速,銀行業務有對私和對公、也有存款業務和貸款業務,不同的業務場景會導致我們的業務架構產生不同的差異,需要自動化做不同的適配。

3)需求迭代非常頻繁和快速

我們基本上是兩個星期一個版本,所以需要運維快速地響應。

4)金融機構一般都會有來自審計的要求

所有的操作不管是自動化還是人工,都需要能夠被審計溯源。

2、應對挑戰的策略

針對以上挑戰,我們的策略如下:

1)流程化+標準化的建立

通過運維流程和標準建立運維文件,打通運維工具,對運維工具進行標準化的管理,將運維流程和事件關聯起來。

2)工具全鏈路打通

例如打通CMDB與監控平臺等資料平臺,保證資料的閉環和管理。

3)運維資料視覺化

運維資料視覺化之後可以做一些資料化的運營,例如一些服務、規劃,成本的核算,以及支援業務場景的分析等。

3、自動化之後的挑戰

我們在做到自動化之後也會有一些比較大的挑戰,可能通過自動化是無法實現的。

1)及時性

金融系統對於穩定性是有要求的,關鍵交易必須達到無損,所以快速發現異常並解決異常非常重要。

2)準確率

銀行的業務場景相對比較複雜,除了我們自身的一些自研業務之外,傳統銀行可能會有很多外購的機器,包括銀行間對接、銀行與民間各種伺服器對接,可能是必須要外購的,這種多業務場景帶來的不確定因素,會給自動化運維的覆蓋帶來一定的困難。

3)規模帶來的挑戰

規模發展非常快,積累了海量資料,自動化運維在這個過程中相對會比較吃力。

三、智慧化實踐

針對以上幾點挑戰,以及近幾年AI技術發展得非常快,微眾銀行的智慧化運維應運而生。

為什麼要做智慧化?其實智慧化特別適合這種大規模且複雜的場景。我們總結出來智慧化有兩個前提,分別是資料和自動化,而資料和自動化也是我們在自動化建設過程中就已經有所準備的。

我們在智慧化運維中劃分了4個領域,不同的領域制定了不同的運營策略。

1、資源管理領域

通過建立資料生命週期管理,自動化流程驅動資料更新,以及打通多個運維工具,促進資料的消費以提供資料的流動性,同時以應用為中心,建立智慧化的運維體系,從應用的角度規劃各種運維場景,例如可以收集CM DB的一些語言定義資料,相當於識別資訊,與我們的監控平臺IMS的一些動態資料整合起來,再疊加一些AI演算法,生成我們的智慧應用畫像,智慧應用畫像可以提供給我們的容器排程平臺等資源排程平臺使用,從而達到動態的擴縮容或智慧編排的效果。

另外,我們目前支援應用屬性、監控資料、運維屬性、依賴關係的一些資料的聚合,從而達到資料閉環的管理以實現智慧化。

2、監控領域

1)異常檢測

監控領域的最初目標是通過異常事件,我們能夠自動地發檢測、預測和告警,以此擺脫根據人工經驗定義故障閾值的場景,因為通過人工經驗定義閾值往往容易漏告和誤告,而且當閾值需要調優時,可能會有反覆的操作,非常影響運維的效率,所以我們希望通過智慧化實現異常檢測,並且在有些情況下,我們可能沒有配置故障閾值和告警閾值,那麼就需要做到無閾值曲線的異常檢測。

在這個過程中,我們有一個原則是少見即異常,將檢測異常轉化為另一個問題,就是衡量當前情況是否少見,如果這個情況少見則可能它已經發生了異常,或者至少它應該是我們運維需要關注的一個地方。

在方法上我們規劃了智慧監控系統識圖模組,我們內部稱為“慧識圖”,慧識圖演算法是針對業務四大黃金指標而制定的檢測策略,業務四大黃金指標指的是交易量、業務成功率、系統成功率和平均時延,這些資料都是分鐘級的。往往我們的業務出現故障時,最終都會在這些業務指標上有所體現,因此我們只要能夠準確捕捉到這些指標的異常,就能夠快速發現影響業務的異常。這四個指標的統計維度、波動規律是有所差別的,所以我們需要用不同的演算法進行檢測,主要是採用三種演算法:

  • 一是基於LSTM與高斯分佈的檢測: 主要用於交易量和平均時延的檢測,對於曲線有異常凸起的情況能夠準確地檢測到,但演算法的死角在於小幅度長時間的緩慢變化容易被漏掉。

  • 二是基於k-means演算法的特徵檢測: 主要用於填補第一種演算法的空區,在交易量緩慢變化的場景效果較好。

  • 三是基於概率密度的檢測: 主要用於業務成功率和系統成功率的曲線,因為成功率曲線的背後隱藏著無數的可能,比如轉賬的成功率背後可能有餘額不足、賬戶被管制等影響因素,需要用一個更接近本質的量衡量異常的程度。

我們做到前面這些異常檢測之後,包括曲線也能預測出來,那麼我們其實具備了主動預測異常的能力。還有一點就是低頻交易,因為銀行有一些交易其實是來自於人工發起,比如一些櫃面的操作,或者司法機關有一些凍結的請求,這種交易往往是比較低頻的。針對低頻交易,我們用的是滑動視窗的方式,因為我們的監控資料本來是分鐘級的,如果低頻度的交易比較多,可能在監控曲線上會有掉點、斷續的情況出現,給我們的檢測帶來比較大的偏差,可能會導致檢測結果不準確。通過滑動視窗的方式聚合某段時間內的監控資料,將其形成一條連貫的曲線,最終就能提升檢測的準確率。

2)根因分析

在監控異常之後,如何快速地恢復異常也非常重要。因為對於運維而言,保證系統百分百的可用是不太可能的,我們只有儘可能減少故障影響時間,讓可用率無限接近百分百。

除了在我們日常運維過程中慣用的手段,比如快速隔離異常、做一些擴容操作、回退變更操作等,在異常發生的時候如果我們能夠快速知道異常的根因,其實可以為我們異常恢復爭取更多寶貴的時間。

最開始微眾銀行做根因分析採用的是專家系統的方式,專家系統的資料並不透明,意味著每一次做根因分析之後,我們還需要檢視分析結果是否正確,每天大量異常事件如果都需要運維做檢視會非常影響效率,而且專家系統規則維護非常困難和複雜。

後來我們引用了圖資料庫,將異常事件以知識圖譜的方式儲存到圖資料庫裡,因為我們儲存到資料庫所以意味著我們要做資料多維度的採集,比如異常事件的相關資訊,異常事件的開始時間、結束時間和影響時間,以及業務的一些關鍵指標,包括前面提及的業務四大黃金指標,交易量、業務成功率、系統成功率、平均時延等,還有一些流水資訊和流水日誌等。

那麼我們將根因定位劃分為兩個維度,分別是橫向維度和縱向維度。橫向維度是指對從入口子系統開始到後端所有交易鏈路上各個子系統進行橫向的排程分析,縱向維度是指對應用層支撐子系統的所有邏輯層、物理層,包括DB、網路、主機等做縱向的分析。微眾銀行大部分子系統是通過統一的訊息匯流排進行互動的,通過訊息日誌能夠自動地進行橫向的分析,即使有些子系統可能無法做到像訊息日誌一樣自動分析,其實它在CMDB裡也是有資料的,通過CMDB裡記錄的一些CI的關係資訊,我們也能夠進行相關的呼叫分析。

前面的資料其實就是一棵交易樹的葉子節點,縱向與橫向分析出來的一些鏈路就是交易樹的枝幹,那麼基於交易樹,我們能夠快速定位異常事件的根因。

另外,我們通過在事件指紋庫裡比對歷史的異常事件,也能提高我們根因分析的準確率。事件指紋庫是一個異常事件的博物館,記錄了我們歷史中所有的異常事件。一個完整的比對過程包括異常事件的指紋選取,指紋選取其實就是多維度資料的採集,以及異常事件在知識圖譜裡的更新和儲存,最後我們會根據指紋權重做一些匹配的演算法。我們還有人工標記的方式,也就是說我們會定期進行復盤,解釋根因分析是否正確,同時也會在上面加一些優化處理的事項的標記,那麼整個監控從異常檢測到根因分析再到異常優化,就形成了一個閉環處理。

3、變更領域

1)質量

在變更領域,我們是通過建立SOP和準生產環境驗證來保證變更質量。

建立SOP標準作業流程,其實是我們在前面自動化運維過程中已經沉澱出來的一些運維的標準作業流程整理歸類為文件。

金融機構對於資料治理有一定的要求和規範,資料天然存在一種物理隔離,就是生產環境的資料是不能出到測試環境,所以通過測試環境做驗證很難達到案例的百分百覆蓋。而且在生產環境做一些主動撥測相對較為困難,因為金融系統有審計、監管上報等功能,作假比例操作也是會被審計的,所以無法做到主動的撥測和驗證。那麼我們通過準生產環境模擬生產環境的全量資料,以此達到上線前變更的驗證檢查。

2)效率

我們前面已經在資源管理領域和監控領域實現了一定的智慧化,因此我們可以通過標準作業的編排實現自動化的釋出操作,以及在自動化釋出之後,可以實現自動化的驗證,最終實現無人值守變更。我們的無人值守率目前達到了55%,對於整體運維的效率能夠提升30%。

4、規模領域

1)效率

在規模領域,我們實現了一鍵擴容DCN,也就是一鍵擴容我們的資料中心節點。銀行系統如果停服,對使用者企業的影響是比較大的,尤其是微眾銀行的服務基本都是在線上,所以在不停服的情況下,我們目前擴容一組DCN只需要一個工作日,整體架構能夠支撐的單日金融交易峰值是7.98億筆。

2)質量

在質量方面,我們更關注的也是一些資料的質量,因為隨著規模的發展,我們會對接很多海量資料,而金融機構對資料是有審計要求的,所以我們通過上下游系統的對賬以及AI演算法的識別來保證應用資料的一致性。

最終微眾銀行的智慧化運維體系就分為了資源管理、監控、變更和規模4個模組,資源管理領域和監控領域服務於上層的變更領域和規模領域。

四、挑戰及未來

1)通過智慧化 提升異常檢測的準確性和有效性 ,包括在異常檢測方面、根因定位方面,以及我們剛剛提到的資料一致性的資料質量的準確識別。

2)通過 提升無人值守的覆蓋度 ,保證無人作業的有效性情況下,進一步提升運維的效率,以此降低IT成本。

以上就是我們對未來的展望。