銀行業IT服務連續性體系規劃與災備自動化切換經驗

【摘要】銀行IT服務連續性體系是一個涉及組織結構、資料中心架構與高可用設計、應用架構規範與治理、應急管理的系統性工程。本文介紹了銀行IT服務連續性體系的規劃思想和具體實踐，並著重介紹了災備自動化切換建設經驗。可供銀行業乃至金融業建設高可用性架構體系、完善業務連續效能力參考借鑑。

【作者】程康，擅長資料中心高可用架構設計與IT服務連續性建設領域相關技術，有豐富的ITIL服務管理實踐，擁有2項發明專利。

一、背景介紹

相比於其他行業，銀行業對於資訊系統可用性與連續性有著很高的要求，基於這樣的客觀需求，同時也是滿足銀保監會《商業銀行資料中心監管指引》的要求，絕大部分大中型銀行都已經建立兩地三中心架構，甚至多地多中心架構。為了驗證同城中心或者異地中心的 IT 服務連續性保障能力，需要持續開展災備切換演練，一般情況下分為同城災備切換演練與異地災備切換演練。

在進行經驗分享之前，需要統一對於 IT 服務連續性的理解，明確一下 IT 服務連續性的目標和原則，以便更好在各類管理措施與技術方案的選擇上面進行抉擇。

首先， IT 服務連續性的目標是為了保障業務連續性，他的目標最終是為了保障銀行的業務的可用性與連續性，這是我們開展各項工作的基本原則，針對災備切換，換句話說，不一定只有透過將所有應用系統從 A 中心切換到 B 中心才能保障業務連續性。

第二，業務分級與重要業務優先原則，在我們開展業務連續性工作、進行切換演練或者實施真實切換等階段，如果在人力資源、系統資源、時效性、工具系統建設或者存在限制或者相互衝突的情況下，我們應該優先考慮重要資訊系統，著重以最短的時間恢復重要系統的連續執行，對一般性業務進行降級或者將恢復一般性業務作為第二階段工作。

第三，要以應對真實場景，有效保障業務系統連續性為原則，此原則看似簡單，但是在實際處理過程中，具體的工作要求或者方案設計會與此原則存在一定差距。

二、存在的問題及解決方案

銀行 IT 服務連續性體系是一個涉及組織結構、資料中心架構與高可用設計、應用架構規範與治理、應急管理的系統性工程，也是一項長期性工作，需要統籌設計、整體建設、持續改進，不是單純依靠加強一個方面就能達成目標的，例如依靠災備切換工具的能力。其主要包含以下方面的工作：

(一)資料中心的佈局設計

為保障 IT 服務連續性，資料中心應如何佈局，現有的資料中心佈局應如何最佳化?首先建立異地災備中心比同城災備中心的成本更高，一方面是需要申請至少兩條以上高頻寬長途專用線路，費用較高，第二是異地中心的基礎設施資源相對於同城中心來說，更難以複用，第三是建立異地模式災備中心，在人員日常組織協調與管理方面的成本更高，因此如果按照監管要求，無需建立異地災備的小型銀行，可建立同城災備中心。

對於按照監管要求，需要設立異地災備中心的大中型銀行，在設立異地中心的情況下，是否有必要設立同城中心。大中型銀行普遍對於可用性與連續性有著更高的要求，雖然設立異地災備中心是為了應對地理區域級別的災難，但是由於距離的因素，因此異地災備中心資料同步的時效性遠低於同城災備中心，對於聯機交易同城資料中心資料同步時效性接近 0 ，但是異地資料同步一般為分鐘級。因此大中型銀行在具備異地災備中心後，仍然有必要設立同城災備中心，同時設立同城資料中心為了實現應用系統同城雙活創造了條件，甚至直接建設或者後續演進至一個區域內的多活資料中心，類似 AWS 的一個 region 的多個 AZ ，眾多分散式多活技術元件有三個以上副本的要求。

對於有能力將大量應用、甚至核心應用做到異地多活的銀行，也有足夠人力物力資源的情況下，可以考慮在異地也設立雙活中心或者多活中心，實現異地雙活或者異地多活，設定多個地域，但是達成上述要求，對於應用架構、應用治理與分散式基礎設施元件的方面，提出了很高的技術能力與治理能力要求，在這方面網際網路行業的一些技術創新可以作為重要的參考。對於大中型銀行，是否需要在異地建設多資料中心是一個需要全面論證和權衡的問題，需要分析投入產出比，或者在可用性因素之外，有其他行內的特殊情況需要在異地設立多中心。

銀行在規劃異地多活資料中心時候，可能會陷入一個技術誤區，就是要實現異地多活，任意中心故障情況下都能做到對業務無影響 RTO 等於 0 ，資料強一致性，同時還要保證日常資料處理系統具備足夠的效能，在多活資料中心超過一定距離的情況下，類似 CAP 原理，可用性、一致性、高效能是存在矛盾的，無法做到兼顧。因此對於異地多活中心，在發生區域性故障時，一般情況下會降低部分使用者的可用性，保留一定的 RTO 時間，保證受影響部分使用者的資料強一致性，在預估 RTO 過長或者對於資料一致性要求不那麼高的業務，也可以選擇快速恢復可用性，降低 RTO 時間，但是容忍短期部分資料的不一致性，事後透過技術或者業務層面的補帳機制去保障業務最終一致。

在目前 IT 技術、網際網路、電子化渠道已經代替原始線下紙質憑證的情況下，純業務層面的補帳機制會存在很多侷限性，並且通常需要更長的時間。在遠距離情況下，透過在應用技術層面設計補帳機制，能夠最大程度上減少資料一致性差異，降低 RTO 時間。

(二)應用架構應該符合哪些規範，應如何對應用進行持續治理

建立同城雙活或者異地雙活資料中心，實現高可用的資訊系統架構，不只是能夠單純依靠建設資料中心或者依靠雙活 / 多活基礎設施就可以獲得的，需要在符合要求的基礎設施之前，制定應用系統部署與執行規範，對應用系統進行治理和改造，才能夠達成資訊系統高可用與連續性目標，有效支撐業務系統的連續執行。

這裡面需要目前 IT 業界比較火熱的雲原生應用、應用微服務化、 DEVOPS 等理念與技術，對於實現應用同城或者多活，網際網路行業也有很多的先進經驗。但是銀行業是否能直接拿來使用，是否應該直接生搬硬套就能滿足我們的需求，需要值得考量。銀行資訊系統與其他行業資訊系統相比，存在一些特殊情況：

第一是存量系統的轉型問題，銀行以及產品供應商經過多年的研發，銀行資訊系統已經形成了一套應用系統體系和大量存量應用，這些系統早期設計研發時，更多地考慮功能性和效能需求，對於本地多活或者異地多活的需求沒有現在要求這麼高，基於成本或者其他方面的考慮在這方面有沒有做過多的研發和支援，在產品和體系都較為成型的情況下，進行重構和設計需要投入大量的研發資源，在供應商方面即滿足需求又經過市場檢驗的產品較少，比如目前市場上的分散式核心銀行系統，這就決定各個銀行必須制定適合自己的應用治理路線和技術規範標準，並且這個標準一般情況下是分步驟分階段，每個階段都需要權衡投入產出比。

第二是網際網路行業自主研發的情況較多，對比銀行業，除了大型商業銀行能夠做到自主研發外，小型銀行與部分銀行只能依靠採購供應商產品和定製化開發，進行應用的改造或者重構涉及成本問題、廠商的產品市場方向以及廠商自身研發實力的問題。

第三是銀行業對於強一致性的要求很高，行業對於一致性方面的偏好直接決定了實現多活以及實現異地多活的架構設計難度、投入成本、可能造成的風險，並且銀行業業務交易對於響應時間等非功能性需求要求也很高，因此在遠距離情況下，如果實現強一致性交易很大程度上會帶來效能與整體可用性的下降。

第四是監管層要求的不同，銀行業受到的監管較為嚴格，一方面是對於生產故障事件的監管和考核，導致銀行實施系統改造或者實施演練的過程中，需要提前控制可能造成的生產故障風險，因此這些會影響系統重構或者改造的步伐，其次對於開源軟體的自主可控問題，導致引入一些多活類支撐類基礎軟體還是需要依託廠商或者自身投入更多的開源自主可控力量，另外監管對於業務高峰業務時段控制的要求以及研發與運維人員分離的要求，也對銀行引入新的應用架構和研發過程體系提出更多的要求。

也是基於這樣的角度考慮，銀行選擇建設同城雙活、異地災備的資料中心架構，相對實現異地多活來說，實現同城雙活能夠很好地應對單個資料中心故障，但是又能夠很好降低技術難度，降低應用改造與遷移成本，雖然未實現異地雙活，但是整個地區遭遇毀滅性故障本身屬於極低機率事件，並且在此情況下，也能夠容忍一定的 RTO 時間。同時，制定了適應同城雙活、異地災備的應用部署架構規範與治理規範，實現能夠在較短的時間內，對應用改造成本的情況下，最大地發揮現有資料中心基礎設施的能力，並提高整體資訊系統可用性與連續性。

具體的應用部署架構規範主要包含如下幾個方面：

1、 應用系統的應用節點部分需要支援多活部署和執行，這是實現同城雙活的基礎條件。一般應用節點不包含持久化資料的情況下，一般較為容易滿足此項條件，並且每個應用至少在本地中心和同城中心各部署 2 個以上節點，並且在一個資料中心也需要使用非親和性排程策略使得兩個階段不處於同一個機房模組或者機架。但是對於資料庫實現跨資料中心多活，存在一定技術難度，同時某些特殊或者極端情況下，反而會帶來整體可用性的下降，或者在人工介入進行恢復操作場景下反正增加恢復難度，因此對於應用系統的資料庫節點，仍然採用較為可靠的主備方案，同時在儲存層面以最大可用模式進行資料複製，一般情況下 RPO=0 ，同時在同城雙中心連線出現中斷，或者備中心出現故障時，不會影響主中心資料庫的正常執行。

2、 應用系統雙中心流量基本均衡。應用系統在進行了雙活改造和雙活部署的情況下，在執行時候仍然會發現雙中心的交易流量不均衡，或者一箇中心出現流量為 0 的情況。造成這種情況的原因有很多可能性，例如應用實現了雙活，但是線路未實現雙活，或者對接的應用系統、對接的合作方、第三方未均衡地分配交易流量，只有雙中心真實承載均衡的交易流量，才能保證雙中心都是處於可用狀態，同時也能夠提高兩個中心基礎設施資源利用率。同時，在各類渠道的流量排程策略也需要結合業務場景進行調整，比如實現一個網點的櫃員和 ATM 分配到不同的資料中心，這樣在故障發生後切換恢復前，至少有一半左右的櫃員或 ATM 可用，保證在業務層面能夠繼續為客戶提供服務。

3、 基礎設施、應用系統的同城雙中心解耦。為了實現高可用性與連續性，需要在基礎設施以及應用系統的架構設計與實施上，要減少單一故障原因導致的雙中心同時故障，首先例如在基礎網路層面如果實現大二層可能會帶來網路層面的單一故障點，其次是應用系統聯機交易應避免使用雙中心共享儲存節點，因為此類共享儲存節點故障就會造成雙中心同時故障，第三在應用層面，要求一個應用不應跨中心訪問其他應用系統，保障流量進入一個資料中心後續交易不會分派到另外一箇中心，避免在切換操作過程無法快速有效地隔離某個資料中心，降低災備切換操作的難度，第四，要求應用系統在釋出過程需要採取藍綠髮布等模式，避免同時在雙中心更新應用版本，導致全域性故障。當然，能夠導致雙中心同時故障的單一故障點無法絕對消除，例如非同城多活的資料庫節點，只能減少存在的點或者降低發生的機率。

4、 各類應用節點、資料庫節點需要進行 DNS 改造、自動重連改造。應用的 DNS 改造，包括資料中心對外服務的 DNS 改造，以及資料中心內部應用之間訪問的 DNS 改造、應用內部應用節點間訪問的 DNS 改造(如應用節點訪問資料庫節點)，對資料中心以外來說，實現 DNS 改造後，能夠很好地做到應用切換對於使用者的透明，加強災備切換操作的難度，例如櫃員在配置域名訪問的情況下，資料中心可以透過切換域名對應的 IP 地址就可以容易完成應用切換。在資料中心內部，實現 DNS 改造能夠很好實現元件之間的解耦，減少元件動態遷移對於其他元件的影響，例如應用對於資料庫的訪問，在資料庫切換完成後，應用無需進行復雜的重新配置與重啟操作，降低切換操作難度，提高切換操作成功率，降低切換操作時間繼而降低業務中斷時間。同時，在元件可能出現動態遷移或者切換的情況下，應用節點需要進行自動重連改造，一般情況下在切換過程不需要也不應該對應用進行類似重啟操作，在演練過程中也不需要出於保證演練對於業務無影響的角度出發對應用進行重啟，進而更好地透過演練發現問題，落實責任，保障在正式場景下快速切換恢復業務，以免應用產生更多對於基礎設施和切換工具的依賴，簡而言之，為了實現高效災備切換，更要把工作做到前期設計和研發階段，降低演練中的複雜度，降低真實故障下的複雜度。

(三)應急預案的編寫

根據監管部門業務連續性與應急管理要求，應急預案需要明確各類故障的診斷方法和流程，需要明確系統恢復流程和處置操作手冊，目前在業界編織應急預案的時候主要存在以下難點：

1、 明確應急預案的啟動條件較為困難，比如某個應急預案的啟動條件是單個資料中心出現整體性故障，但是在實際單個資料中心故障場景下，例如 20 個以上的伺服器 ping 不同屬於單個資料中心出現整體故障了嗎?同時，各個層面各個專業都會出現大量告警資訊，告警的資訊也在變化，給啟動條件的明確增加了更多的困難。

2、 故障的診斷流程可操行性差，難以細化。資料中心包含多個模組機房，每個機房有各類設施，每類裝置都有各類元件，在出現故障的情況下，在這麼多預案中，我們應該首先選擇執行哪個預案呢，所以各類現象和告警資訊可以提供一些參考資訊，但是預案梳理仍然較多。同時，問題的診斷流程實質上會出現很多分支，類似於決策樹，從一個現象出現，會診斷出來大量可能的故障，每個故障都有不同的流程，難以在一個預案中明確。

3、 以應用 / 裝置內部技術告警資訊作為啟動條件，應用 / 裝置內部的各類技術部件和告警資訊繁多，例如每天網路裝置產生的告警數多達百萬級別，此類告警可能對業務有影響但是有時候又不影響業務，應急人員頻繁進行應急處置，會消耗大量的無效成本。同時，在服務出現異常時，此時裝置也不一定出現告警資訊，或者即使出現，該類告警資訊也會淹沒在日常大量的告警資訊中。

經過長期的摸索和實踐，總結出來一條行之有效的應急預案編寫實踐經驗：

1 、應急以快速恢復業務原則，降低業務影響為原則，不以定位問題原因為原則。這個原則雖然很容易理解，但是技術人員在編寫預案或者實際操作過程容易陷入尋找問題原因。應急診斷過程中，需要進行分析將故障區域明確至一個可執行預案的級別，但是一旦明確後，在應急現場不需要再進一步分析故障原因。同時，監控等工具系統也要配合進行監控覆蓋，以最快的速度給應急處置人員提示故障域資訊。

2 、合併故故障域原則，因為資料中心從資料中心級別、機房模組級別、應用叢集級別、裝置級別都進行冗餘設計，我們可以在資料中心級別、機房模組級別、應用叢集級別、裝置級別進行隔離切換。如果可以判斷是裝置級別故障，我們就隔離整臺裝置，而無需關注裝置內部什麼部件因為什麼原因出現故障，應用叢集、機房模組、資料中心也以此類推。同時，無法短時間明確故障域，可直接將故障域上提一個層次，但是需要控制上一級別故障域應急操作帶來的風險。同時，如果高層次應急操作操作簡單，經過多次檢驗，風險較低，可以刪除低層級應急操作預案，以降低應急預案數量，以較少的預案應對更多的故障，降低應急預案編織、管理與演練的成本。

3 、儘可能從業務角度判斷服務正常作為啟動條件， 例如從業務交易影響佔比角度判斷是否出現資料中心整體故障，例如一個資料中心的業務交易出現 30% 以上失敗時即認為資料中心出現整體性故障，作為資料中心級別切換的啟動條件，對於網路裝置以觀察網路異常流量的佔比(網路資料包重傳)作為判斷網路裝置是否故障的判斷條件(網路提供的服務即網路通訊)，對於應用叢集也是同理。這樣做一方面，應急啟動條件和現象很明確，監控工具也很容易落地，應急處置人員也很容易掌握。另一方面，包含的故障場景很全面，可能影響業務的技術故障一般情況下都會涵蓋，同時對於不會影響業務的技術故障，不會啟動應急，節約寶貴的人力與 IT 資源。

(四)切換工具建設實踐

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

切換工具的建設投入也與上述故障場景與應急預案的設計明確密切相關，如果能對於故障域進行整合，從業務監控層面設計應急場景，應急場景與應急預案，以至於應急切換步驟都可以得到大幅度的減少和簡化。

自動化切換平臺建設在技術上與自動化運維平臺差別不大，相關方式和方法、技術手段、技術框架都可以複用，自動化運維平臺開源工具、廠商提供的工具較多，因此本文不做過多介紹，主要針對切換平臺需要在建設過程中需要特殊關注的點進行經驗分享：

1、 切換工具自身如何實現高可用

如何避免切換工具自身受到故障的影響，主要需要遵循的原則就是就是切換工具需要保障在被切換物件外部，同時在基礎設施層面，要保證在所設計的故障場景下被切換物件的可達，包括故障場景下網路可達等。例如兩地三中心情況下，異地切換工具可以部署在異地中心。對於同城 AB 中心，可以將工具雙活部署在 AB 中心， A 中心故障情況下登陸 B 中心切換工具進行切換， B 中心故障情況下，登陸 A 中心切換進行切換，同時兩個中心切換工具的配置資料層面進行定期同步，由於切換工具對於資料一致性與實時性的要求較低，因此一般實現起來具備可行性。可以將 AB 中心的工具地址提供給使用者，並在操作手冊中註明，在什麼場景下應該登陸對應的地址進行操作。

另外，資料中心基礎設施一般都建設有帶外網路，異常情況下可以手工透過帶外網進行操作，因此切換工具也應利用帶外網路代替人工進行應急切換操作，切換工具需要在帶外網路部署相應節點，並且這些節點能夠保證在與帶內網路埠的情況下，具備可用性。

2、 切換工具的容錯

切換工具在編排操作時，一般情況下不應考慮進行故障域的內部進行操作，比如資料中心整體故障場景下，一般不編排進入故障資料中心對於某個應用進行關閉或者重啟操作。如果只是進行嘗試性操作，也應保證程式的容錯，也即如果物件可達且可操作，則按照步驟進行操作，如果不可達或者不可操作，也應自動跳過繼續後續流程的處理，並注意超時時間的控制。

3、 切換流程的執行控制

切換流程一般都是多種多樣，一般需要引入工作流引擎，引入 activity 編制並驅動工作量。工作流的設計遵循 BPMN2.0UI 規範，一方面 BPMN2.0 規範能力強大，能夠表達的場景較為豐富，並且作為一個通用標準，便於與其他工具的開發以及與其他外部系統的對接。工作量需要支援豐富的人工介入手段，以支援應急切換中碰到的特殊情況，一般情況下需要支援人工暫停、重試、跳過等操作，以及對於執行中流程例項的調整能力，比如增加或者刪除操作步驟、子流程。

實現流程編排視覺化，可以降低編排工作的難度，簡化流程編排人員的工作量，同時，在切換過程中進行視覺化展現，也能方便在應急協同過程中，現場各專業人員對於進度的掌握。

三、整體總結

在上述體系化思想指導下，可建設完成同城雙活、異地災備的金融雲資料中心基礎設施架構體系，在基礎設施層面實現了同城雙中心解耦，應用系統層面實現同城雙活部署，對應用系統全面治理與雲化改造，並部署面向業務的監控工具體系，建設同城切換自動化平臺，併成功實施同城資料中心切換演練， RTO 控制在 5 分鐘以內，對銀行業乃至金融業的建設高可用性架構體系，完善業務連續效能力提供參考，具有很好的借鑑意義。