銀行 IT 服務連續(xù)性體系與災備自動化切換建設經(jīng)驗

1、 銀行 IT 服務連續(xù)性體系與災備自動化切換建設經(jīng)驗 【摘要】銀行IT服務連續(xù)性體系是一個涉及組織結構、數(shù)據(jù)中心架構與高可用設計、應用架構規(guī)范與治理、應急管理的系統(tǒng)性工程。本文介紹了某股份制銀行IT服務連續(xù)性體系的規(guī)劃思想和具體實踐，并著重介紹了災備自動化切換建設經(jīng)驗。在體系化思想指導下，該銀行建設完成同城雙活、異地災備的金融云數(shù)據(jù)中心基礎設施架構體系，其經(jīng)驗可以對銀行業(yè)乃至金融業(yè)建設高可用性架構體系、完善業(yè)務連續(xù)性能力提供參考，具有很好的借鑒意義?！咀髡摺砍炭担彻煞葜沏y行運維總監(jiān)，長期從事數(shù)據(jù)中心運維管理體系建設與智能運維平臺研發(fā)工作，熟悉數(shù)據(jù)中心高可用架構設計與IT服務連續(xù)性建設，熟悉I

2、TIL服務管理最佳實踐，曾主導某銀行金融云管理平臺研發(fā)工作，擁有2項發(fā)明專利。一、背景介紹相比于其他行業(yè)，銀行業(yè)對于信息系統(tǒng)可用性與連續(xù)性有著很高的要求，基于這樣的客觀需求，同時也是滿足銀保監(jiān)會商業(yè)銀行數(shù)據(jù)中心監(jiān)管指引的要求，絕大部分大中型銀行都已經(jīng)建立兩地三中心架構，甚至多地多中心架構。為了驗證同城中心或者異地中心的 IT 服務連續(xù)性保障能力，需要持續(xù)開展災備切換演練，一般情況下分為同城災備切換演練與異地災備切換演練。在進行經(jīng)驗分享之前，需要統(tǒng)一對于 IT 服務連續(xù)性的理解，明確一下 IT 服務連續(xù)性的目標和原則，以便更好在各類管理措施與技術方案的選擇上面進行抉擇。首先， IT 服務連續(xù)性的

3、目標是為了保障業(yè)務連續(xù)性，他的目標最終是為了保障銀行的業(yè)務的可用性與連續(xù)性，這是我們開展各項工作的基本原則，針對災備切換，換句話說，不一定只有通過將所有應用系統(tǒng)從 A 中心切換到 B 中心才能保障業(yè)務連續(xù)性。第二，業(yè)務分級與重要業(yè)務優(yōu)先原則，在我們開展業(yè)務連續(xù)性工作、進行切換演練或者實施真實切換等階段，如果在人力資源、系統(tǒng)資源、時效性、工具系統(tǒng)建設或者存在限制或者相互沖突的情況下，我們應該優(yōu)先考慮重要信息系統(tǒng)，著重以最短的時間恢復重要系統(tǒng)的連續(xù)運行，對一般性業(yè)務進行降級或者將恢復一般性業(yè)務作為第二階段工作。第三，要以應對真實場景，有效保障業(yè)務系統(tǒng)連續(xù)性為原則，此原則看似簡單，但是在實際處理過程

4、中，具體的工作要求或者方案設計會與此原則存在一定差距。二、存在的問題及解決方案銀行 IT 服務連續(xù)性體系是一個涉及組織結構、數(shù)據(jù)中心架構與高可用設計、應用架構規(guī)范與治理、應急管理的系統(tǒng)性工程，也是一項長期性工作，需要統(tǒng)籌設計、整體建設、持續(xù)改進，不是單純依靠加強一個方面就能達成目標的，例如依靠災備切換工具的能力。其主要包含以下方面的工作：（一）數(shù)據(jù)中心的布局設計為保障 IT 服務連續(xù)性，數(shù)據(jù)中心應如何布局，現(xiàn)有的數(shù)據(jù)中心布局應如何優(yōu)化？首先建立異地災備中心比同城災備中心的成本更高，一方面是需要申請至少兩條以上高帶寬長途專用線路，費用較高，第二是異地中心的基礎設施資源相對于同城中心來說，更難以復

5、用，第三是建立異地模式災備中心，在人員日常組織協(xié)調(diào)與管理方面的成本更高，因此如果按照監(jiān)管要求，無需建立異地災備的小型銀行，可建立同城災備中心。對于按照監(jiān)管要求，需要設立異地災備中心的大中型銀行，在設立異地中心的情況下，是否有必要設立同城中心。大中型銀行普遍對于可用性與連續(xù)性有著更高的要求，雖然設立異地災備中心是為了應對地理區(qū)域級別的災難，但是由于距離的因素，因此異地災備中心數(shù)據(jù)同步的時效性遠低于同城災備中心，對于聯(lián)機交易同城數(shù)據(jù)中心數(shù)據(jù)同步時效性接近 0 ，但是異地數(shù)據(jù)同步一般為分鐘級。因此大中型銀行在具備異地災備中心后，仍然有必要設立同城災備中心，同時設立同城數(shù)據(jù)中心為了實現(xiàn)應用系統(tǒng)同城雙活

6、創(chuàng)造了條件，甚至直接建設或者后續(xù)演進至一個區(qū)域內(nèi)的多活數(shù)據(jù)中心，類似 AWS 的一個 region 的多個 AZ ，眾多分布式多活技術組件有三個以上副本的要求。對于有能力將大量應用、甚至核心應用做到異地多活的銀行，也有足夠人力物力資源的情況下，可以考慮在異地也設立雙活中心或者多活中心，實現(xiàn)異地雙活或者異地多活，設置多個地域，但是達成上述要求，對于應用架構、應用治理與分布式基礎設施組件的方面，提出了很高的技術能力與治理能力要求，在這方面互聯(lián)網(wǎng)行業(yè)的一些技術創(chuàng)新可以作為重要的參考。對于大中型銀行，是否需要在異地建設多數(shù)據(jù)中心是一個需要全面論證和權衡的問題，需要分析投入產(chǎn)出比，或者在可用性因素之外，

7、有其他行內(nèi)的特殊情況需要在異地設立多中心。銀行在規(guī)劃異地多活數(shù)據(jù)中心時候，可能會陷入一個技術誤區(qū)，就是要實現(xiàn)異地多活，任意中心故障情況下都能做到對業(yè)務無影響 RTO 等于 0 ，數(shù)據(jù)強一致性，同時還要保證日常數(shù)據(jù)處理系統(tǒng)具備足夠的性能，在多活數(shù)據(jù)中心超過一定距離的情況下，類似 CAP 原理，可用性、一致性、高性能是存在矛盾的，無法做到兼顧。因此對于異地多活中心，在發(fā)生區(qū)域性故障時，一般情況下會降低部分用戶的可用性，保留一定的 RTO 時間，保證受影響部分用戶的數(shù)據(jù)強一致性，在預估 RTO 過長或者對于數(shù)據(jù)一致性要求不那么高的業(yè)務，也可以選擇快速恢復可用性，降低 RTO 時間，但是容忍短期部分數(shù)

8、據(jù)的不一致性，事后通過技術或者業(yè)務層面的補帳機制去保障業(yè)務最終一致。在目前 IT 技術、互聯(lián)網(wǎng)、電子化渠道已經(jīng)代替原始線下紙質憑證的情況下，純業(yè)務層面的補帳機制會存在很多局限性，并且通常需要更長的時間。在遠距離情況下，通過在應用技術層面設計補帳機制，能夠最大程度上減少數(shù)據(jù)一致性差異，降低 RTO 時間。（二）應用架構應該符合哪些規(guī)范，應如何對應用進行持續(xù)治理建立同城雙活或者異地雙活數(shù)據(jù)中心，實現(xiàn)高可用的信息系統(tǒng)架構，不只是能夠單純依靠建設數(shù)據(jù)中心或者依靠雙活 / 多活基礎設施就可以獲得的，需要在符合要求的基礎設施之前，制定應用系統(tǒng)部署與運行規(guī)范，對應用系統(tǒng)進行治理和改造，才能夠達成信息系統(tǒng)高可

9、用與連續(xù)性目標，有效支撐業(yè)務系統(tǒng)的連續(xù)運行。這里面需要目前 IT 業(yè)界比較火熱的云原生應用、應用微服務化、 DEVOPS 等理念與技術，對于實現(xiàn)應用同城或者多活，互聯(lián)網(wǎng)行業(yè)也有很多的先進經(jīng)驗。但是銀行業(yè)是否能直接拿來使用，是否應該直接生搬硬套就能滿足我們的需求，需要值得考量。銀行信息系統(tǒng)與其他行業(yè)信息系統(tǒng)相比，存在一些特殊情況：第一是存量系統(tǒng)的轉型問題，銀行以及產(chǎn)品供應商經(jīng)過多年的研發(fā)，銀行信息系統(tǒng)已經(jīng)形成了一套應用系統(tǒng)體系和大量存量應用，這些系統(tǒng)早期設計研發(fā)時，更多地考慮功能性和性能需求，對于本地多活或者異地多活的需求沒有現(xiàn)在要求這么高，基于成本或者其他方面的考慮在這方面有沒有做過多的研發(fā)和

10、支持，在產(chǎn)品和體系都較為成型的情況下，進行重構和設計需要投入大量的研發(fā)資源，在供應商方面即滿足需求又經(jīng)過市場檢驗的產(chǎn)品較少，比如目前市場上的分布式核心銀行系統(tǒng)，這就決定各個銀行必須制定適合自己的應用治理路線和技術規(guī)范標準，并且這個標準一般情況下是分步驟分階段，每個階段都需要權衡投入產(chǎn)出比。第二是互聯(lián)網(wǎng)行業(yè)自主研發(fā)的情況較多，對比銀行業(yè)，除了大型商業(yè)銀行能夠做到自主研發(fā)外，小型銀行與部分銀行只能依靠采購供應商產(chǎn)品和定制化開發(fā)，進行應用的改造或者重構涉及成本問題、廠商的產(chǎn)品市場方向以及廠商自身研發(fā)實力的問題。第三是銀行業(yè)對于強一致性的要求很高，行業(yè)對于一致性方面的偏好直接決定了實現(xiàn)多活以及實現(xiàn)異地

11、多活的架構設計難度、投入成本、可能造成的風險，并且銀行業(yè)業(yè)務交易對于響應時間等非功能性需求要求也很高，因此在遠距離情況下，如果實現(xiàn)強一致性交易很大程度上會帶來性能與整體可用性的下降。第四是監(jiān)管層要求的不同，銀行業(yè)受到的監(jiān)管較為嚴格，一方面是對于生產(chǎn)故障事件的監(jiān)管和考核，導致銀行實施系統(tǒng)改造或者實施演練的過程中，需要提前控制可能造成的生產(chǎn)故障風險，因此這些會影響系統(tǒng)重構或者改造的步伐，其次對于開源軟件的自主可控問題，導致引入一些多活類支撐類基礎軟件還是需要依托廠商或者自身投入更多的開源自主可控力量，另外監(jiān)管對于業(yè)務高峰業(yè)務時段控制的要求以及研發(fā)與運維人員分離的要求，也對銀行引入新的應用架構和研發(fā)

12、過程體系提出更多的要求。也是基于這樣的角度考慮，某股份制銀行選擇建設同城雙活、異地災備的數(shù)據(jù)中心架構，相對實現(xiàn)異地多活來說，實現(xiàn)同城雙活能夠很好地應對單個數(shù)據(jù)中心故障，但是又能夠很好降低技術難度，降低應用改造與遷移成本，雖然未實現(xiàn)異地雙活，但是整個地區(qū)遭遇毀滅性故障本身屬于極低概率事件，并且在此情況下，也能夠容忍一定的 RTO 時間。同時，制定了適應同城雙活、異地災備的應用部署架構規(guī)范與治理規(guī)范，實現(xiàn)能夠在較短的時間內(nèi)，對應用改造成本的情況下，最大地發(fā)揮現(xiàn)有數(shù)據(jù)中心基礎設施的能力，并提高整體信息系統(tǒng)可用性與連續(xù)性。具體的應用部署架構規(guī)范主要包含如下幾個方面：1、 應用系統(tǒng)的應用節(jié)點部分需要支持

13、多活部署和運行，這是實現(xiàn)同城雙活的基礎條件。一般應用節(jié)點不包含持久化數(shù)據(jù)的情況下，一般較為容易滿足此項條件，并且每個應用至少在本地中心和同城中心各部署 2 個以上節(jié)點，并且在一個數(shù)據(jù)中心也需要使用非親和性調(diào)度策略使得兩個階段不處于同一個機房模塊或者機架。但是對于數(shù)據(jù)庫實現(xiàn)跨數(shù)據(jù)中心多活，存在一定技術難度，同時某些特殊或者極端情況下，反而會帶來整體可用性的下降，或者在人工介入進行恢復操作場景下反正增加恢復難度，因此對于應用系統(tǒng)的數(shù)據(jù)庫節(jié)點，仍然采用較為可靠的主備方案，同時在存儲層面以最大可用模式進行數(shù)據(jù)復制，一般情況下 RPO=0 ，同時在同城雙中心連接出現(xiàn)中斷，或者備中心出現(xiàn)故障時，不會影響主

14、中心數(shù)據(jù)庫的正常運行。2、 應用系統(tǒng)雙中心流量基本均衡。應用系統(tǒng)在進行了雙活改造和雙活部署的情況下，在運行時候仍然會發(fā)現(xiàn)雙中心的交易流量不均衡，或者一個中心出現(xiàn)流量為 0 的情況。造成這種情況的原因有很多可能性，例如應用實現(xiàn)了雙活，但是線路未實現(xiàn)雙活，或者對接的應用系統(tǒng)、對接的合作方、第三方未均衡地分配交易流量，只有雙中心真實承載均衡的交易流量，才能保證雙中心都是處于可用狀態(tài)，同時也能夠提高兩個中心基礎設施資源利用率。同時，在各類渠道的流量調(diào)度策略也需要結合業(yè)務場景進行調(diào)整，比如實現(xiàn)一個網(wǎng)點的柜員和 ATM 分配到不同的數(shù)據(jù)中心，這樣在故障發(fā)生后切換恢復前，至少有一半左右的柜員或 ATM 可用

15、，保證在業(yè)務層面能夠繼續(xù)為客戶提供服務。3、 基礎設施、應用系統(tǒng)的同城雙中心解耦。為了實現(xiàn)高可用性與連續(xù)性，需要在基礎設施以及應用系統(tǒng)的架構設計與實施上，要減少單一故障原因導致的雙中心同時故障，首先例如在基礎網(wǎng)絡層面如果實現(xiàn)大二層可能會帶來網(wǎng)絡層面的單一故障點，其次是應用系統(tǒng)聯(lián)機交易應避免使用雙中心共享存儲節(jié)點，因為此類共享存儲節(jié)點故障就會造成雙中心同時故障，第三在應用層面，要求一個應用不應跨中心訪問其他應用系統(tǒng)，保障流量進入一個數(shù)據(jù)中心后續(xù)交易不會分派到另外一個中心，避免在切換操作過程無法快速有效地隔離某個數(shù)據(jù)中心，降低災備切換操作的難度，第四，要求應用系統(tǒng)在發(fā)布過程需要采取藍綠發(fā)布等模式，

16、避免同時在雙中心更新應用版本，導致全局故障。當然，能夠導致雙中心同時故障的單一故障點無法絕對消除，例如非同城多活的數(shù)據(jù)庫節(jié)點，只能減少存在的點或者降低發(fā)生的概率。4、 各類應用節(jié)點、數(shù)據(jù)庫節(jié)點需要進行 DNS 改造、自動重連改造。應用的 DNS 改造，包括數(shù)據(jù)中心對外服務的 DNS 改造，以及數(shù)據(jù)中心內(nèi)部應用之間訪問的 DNS 改造、應用內(nèi)部應用節(jié)點間訪問的 DNS 改造（如應用節(jié)點訪問數(shù)據(jù)庫節(jié)點），對數(shù)據(jù)中心以外來說，實現(xiàn) DNS 改造后，能夠很好地做到應用切換對于用戶的透明，加強災備切換操作的難度，例如柜員在配置域名訪問的情況下，數(shù)據(jù)中心可以通過切換域名對應的 IP 地址就可以容易完成應用

17、切換。在數(shù)據(jù)中心內(nèi)部，實現(xiàn) DNS 改造能夠很好實現(xiàn)組件之間的解耦，減少組件動態(tài)遷移對于其他組件的影響，例如應用對于數(shù)據(jù)庫的訪問，在數(shù)據(jù)庫切換完成后，應用無需進行復雜的重新配置與重啟操作，降低切換操作難度，提高切換操作成功率，降低切換操作時間繼而降低業(yè)務中斷時間。同時，在組件可能出現(xiàn)動態(tài)遷移或者切換的情況下，應用節(jié)點需要進行自動重連改造，一般情況下在切換過程不需要也不應該對應用進行類似重啟操作，在演練過程中也不需要出于保證演練對于業(yè)務無影響的角度出發(fā)對應用進行重啟，進而更好地通過演練發(fā)現(xiàn)問題，落實責任，保障在正式場景下快速切換恢復業(yè)務，以免應用產(chǎn)生更多對于基礎設施和切換工具的依賴，簡而言之，為

18、了實現(xiàn)高效災備切換，更要把工作做到前期設計和研發(fā)階段，降低演練中的復雜度，降低真實故障下的復雜度。（三）應急預案的編寫根據(jù)監(jiān)管部門業(yè)務連續(xù)性與應急管理要求，應急預案需要明確各類故障的診斷方法和流程，需要明確系統(tǒng)恢復流程和處置操作手冊，目前在業(yè)界編織應急預案的時候主要存在以下難點：1、 明確應急預案的啟動條件較為困難，比如某個應急預案的啟動條件是單個數(shù)據(jù)中心出現(xiàn)整體性故障，但是在實際單個數(shù)據(jù)中心故障場景下，例如 20 個以上的服務器 ping 不同屬于單個數(shù)據(jù)中心出現(xiàn)整體故障了嗎？同時，各個層面各個專業(yè)都會出現(xiàn)大量告警信息，告警的信息也在變化，給啟動條件的明確增加了更多的困難。2、 故障的診斷流

19、程可操行性差，難以細化。數(shù)據(jù)中心包含多個模塊機房，每個機房有各類設施，每類設備都有各類組件，在出現(xiàn)故障的情況下，在這么多預案中，我們應該首先選擇執(zhí)行那個預案呢，所以各類現(xiàn)象和告警信息可以提供一些參考信息，但是預案梳理仍然較多。同時，問題的診斷流程實質上會出現(xiàn)很多分支，類似于決策樹，從一個現(xiàn)象出現(xiàn)，會診斷出來大量可能的故障，每個故障都有不同的流程，難以在一個預案中明確。3、 以應用 / 設備內(nèi)部技術告警信息作為啟動條件，應用 / 設備內(nèi)部的各類技術部件和告警信息繁多，例如每天網(wǎng)絡設備產(chǎn)生的告警數(shù)多達百萬級別，此類告警可能對業(yè)務有影響但是有時候又不影響業(yè)務，應急人員頻繁進行應急處置，會消耗大量的無

20、效成本。同時，在服務出現(xiàn)異常時，此時設備也不一定出現(xiàn)告警信息，或者即使出現(xiàn)，該類告警信息也會淹沒在日常大量的告警信息中。經(jīng)過長期的摸索和實踐，某股份制銀行總結出來一條行之有效的應急預案編寫實踐經(jīng)驗：1 、應急以快速恢復業(yè)務原則，降低業(yè)務影響為原則，不以定位問題原因為原則。這個原則雖然很容易理解，但是技術人員在編寫預案或者實際操作過程容易陷入尋找問題原因。應急診斷過程中，需要進行分析將故障區(qū)域明確至一個可執(zhí)行預案的級別，但是一旦明確后，在應急現(xiàn)場不需要再進一步分析故障原因。同時，監(jiān)控等工具系統(tǒng)也要配合進行監(jiān)控覆蓋，以最快的速度給應急處置人員提示故障域信息。2 、合并故故障域原則，因為數(shù)據(jù)中心從數(shù)

21、據(jù)中心級別、機房模塊級別、應用集群級別、設備級別都進行冗余設計，我們可以在數(shù)據(jù)中心級別、機房模塊級別、應用集群級別、設備級別進行隔離切換。如果可以判斷是設備級別故障，我們就隔離整臺設備，而無需關注設備內(nèi)部什么部件因為什么原因出現(xiàn)故障，應用集群、機房模塊、數(shù)據(jù)中心也以此類推。同時，無法短時間明確故障域，可直接將故障域上提一個層次，但是需要控制上一級別故障域應急操作帶來的風險。同時，如果高層次應急操作操作簡單，經(jīng)過多次檢驗，風險較低，可以刪除低層級應急操作預案，以降低應急預案數(shù)量，以較少的預案應對更多的故障，降低應急預案編織、管理與演練的成本。3 、盡可能從業(yè)務角度判斷服務正常作為啟動條件， 例如

22、從業(yè)務交易影響占比角度判斷是否出現(xiàn)數(shù)據(jù)中心整體故障，例如一個數(shù)據(jù)中心的業(yè)務交易出現(xiàn) 30% 以上失敗時即認為數(shù)據(jù)中心出現(xiàn)整體性故障，作為數(shù)據(jù)中心級別切換的啟動條件，對于網(wǎng)絡設備以觀察網(wǎng)絡異常流量的占比（網(wǎng)絡數(shù)據(jù)包重傳）作為判斷網(wǎng)絡設備是否故障的判斷條件（網(wǎng)絡提供的服務即網(wǎng)絡通訊），對于應用集群也是同理。這樣做一方面，應急啟動條件和現(xiàn)象很明確，監(jiān)控工具也很容易落地，應急處置人員也很容易掌握。另一方面，包含的故障場景很全面，可能影響業(yè)務的技術故障一般情況下都會涵蓋，同時對于不會影響業(yè)務的技術故障，不會啟動應急，節(jié)約寶貴的人力與 IT 資源。（四）切換工具建設實踐應急切換工具平臺的建設屬于運維自動化

23、的范疇之一，技術上存在通用型，只是應對業(yè)務場景不同而已。IT 服務連續(xù)性體系和應急管理體系的建設不能過于依賴切換工具平臺的建設。首先，如果我們的基礎設施和應用如果標準化程度不高，就會導致自動化平臺切換步驟多樣且復雜，在應急情況下能夠成功完成切換的可能性就會降低，這一點跟實現(xiàn) IT 運維自動化的前提是標準化類似。其次，很多情況下，應急切換工具自身也會受到故障的影響，因此需要在設計預先設計并驗證，保證應急工具自身的可用性。最后，技術存在局限性，因此需要保持自動化切換失敗場景下，通過手工進行切換的能力，保證大家都是技術知識和操作步驟的熟悉程度。切換工具的建設投入也與上述故障場景與應急預案的設計明確密

24、切相關，如果能對于故障域進行整合，從業(yè)務監(jiān)控層面設計應急場景，應急場景與應急預案，以至于應急切換步驟都可以得到大幅度的減少和簡化。自動化切換平臺建設在技術上與自動化運維平臺差別不大，相關方式和方法、技術手段、技術框架都可以復用，自動化運維平臺開源工具、廠商提供的工具較多，因此本文不做過多介紹，主要針對切換平臺需要在建設過程中需要特殊關注的點進行經(jīng)驗分享：1、 切換工具自身如何實現(xiàn)高可用如何避免切換工具自身受到故障的影響，主要需要遵循的原則就是就是切換工具需要保障在被切換對象外部，同時在基礎設施層面，要保證在所設計的故障場景下被切換對象的可達，包括故障場景下網(wǎng)絡可達等。例如兩地三中心情況下，異地

25、切換工具可以部署在異地中心。對于同城 AB 中心，可以將工具雙活部署在 AB 中心， A 中心故障情況下登陸 B 中心切換工具進行切換， B 中心故障情況下，登陸 A 中心切換進行切換，同時兩個中心切換工具的配置數(shù)據(jù)層面進行定期同步，由于切換工具對于數(shù)據(jù)一致性與實時性的要求較低，因此一般實現(xiàn)起來具備可行性?？梢詫?AB 中心的工具地址提供給用戶，并在操作手冊中注明，在什么場景下應該登陸對應的地址進行操作。另外，數(shù)據(jù)中心基礎設施一般都建設有帶外網(wǎng)絡，異常情況下可以手工通過帶外網(wǎng)進行操作，因此切換工具也應利用帶外網(wǎng)絡代替人工進行應急切換操作，切換工具需要在帶外網(wǎng)絡部署相應節(jié)點，并且這些節(jié)點能夠保證在與帶內(nèi)網(wǎng)絡端口的情況下，具備可用性。2、 切換工具的容錯切