一、背景介紹
相比于其他行業(yè)，銀行業(yè)對于信息系統(tǒng)可用性與連續(xù)性有著很高的要求，基于這樣的客觀需求，同時也是滿足銀保監(jiān)會《商業(yè)銀行數(shù)據(jù)中心監(jiān)管指引》的要求，絕大部分大中型銀行都已經(jīng)建立兩地三中心架構(gòu)，甚至多地多中心架構(gòu)。為了驗證同城中心或者異地中心的IT服務連續(xù)性保障能力，需要持續(xù)開展災備切換演練，一般情況下分為同城災備切換演練與異地災備切換演練。
在進行經(jīng)驗分享之前，需要統(tǒng)一對于IT服務連續(xù)性的理解，明確一下IT服務連續(xù)性的目標和原則，以便更好在各類管理措施與技術(shù)方案的選擇上面進行抉擇。
首先，IT服務連續(xù)性的目標是為了保障業(yè)務連續(xù)性，他的目標最終是為了保障銀行的業(yè)務的可用性與連續(xù)性，這是我們開展各項工作的基本原則，針對災備切換，換句話說，不一定只有通過將所有應用系統(tǒng)從A中心切換到B中心才能保障業(yè)務連續(xù)性。
第二，業(yè)務分級與重要業(yè)務優(yōu)先原則，在我們開展業(yè)務連續(xù)性工作、進行切換演練或者實施真實切換等階段，如果在人力資源、系統(tǒng)資源、時效性、工具系統(tǒng)建設(shè)或者存在限制或者相互沖突的情況下，我們應該優(yōu)先考慮重要信息系統(tǒng)，著重以最短的時間恢復重要系統(tǒng)的連續(xù)運行，對一般性業(yè)務進行降級或者將恢復一般性業(yè)務作為第二階段工作。
第三，要以應對真實場景，有效保障業(yè)務系統(tǒng)連續(xù)性為原則，此原則看似簡單，但是在實際處理過程中，具體的工作要求或者方案設(shè)計會與此原則存在一定差距。
二、存在的問題及解決方案
銀行IT服務連續(xù)性體系是一個涉及組織結(jié)構(gòu)、數(shù)據(jù)中心架構(gòu)與高可用設(shè)計、應用架構(gòu)規(guī)范與治理、應急管理的系統(tǒng)性工程，也是一項長期性工作，需要統(tǒng)籌設(shè)計、整體建設(shè)、持續(xù)改進，不是單純依靠加強一個方面就能達成目標的，例如依靠災備切換工具的能力。其主要包含以下方面的工作：
（一）數(shù)據(jù)中心的布局設(shè)計
為保障IT服務連續(xù)性，數(shù)據(jù)中心應如何布局，現(xiàn)有的數(shù)據(jù)中心布局應如何優(yōu)化？首先建立異地災備中心比同城災備中心的成本更高，一方面是需要申請至少兩條以上高帶寬長途專用線路，費用較高，第二是異地中心的基礎(chǔ)設(shè)施資源相對于同城中心來說，更難以復用，第三是建立異地模式災備中心，在人員日常組織協(xié)調(diào)與管理方面的成本更高，因此如果按照監(jiān)管要求，無需建立異地災備的小型銀行，可建立同城災備中心。
對于按照監(jiān)管要求，需要設(shè)立異地災備中心的大中型銀行，在設(shè)立異地中心的情況下，是否有必要設(shè)立同城中心。大中型銀行普遍對于可用性與連續(xù)性有著更高的要求，雖然設(shè)立異地災備中心是為了應對地理區(qū)域級別的災難，但是由于距離的因素，因此異地災備中心數(shù)據(jù)同步的時效性遠低于同城災備中心，對于聯(lián)機交易同城數(shù)據(jù)中心數(shù)據(jù)同步時效性接近0，但是異地數(shù)據(jù)同步一般為分鐘級。因此大中型銀行在具備異地災備中心后，仍然有必要設(shè)立同城災備中心，同時設(shè)立同城數(shù)據(jù)中心為了實現(xiàn)應用系統(tǒng)同城雙活創(chuàng)造了條件，甚至直接建設(shè)或者后續(xù)演進至一個區(qū)域內(nèi)的多活數(shù)據(jù)中心，類似AWS的一個region的多個AZ，眾多分布式多活技術(shù)組件有三個以上副本的要求。
對于有能力將大量應用、甚至核心應用做到異地多活的銀行，也有足夠人力物力資源的情況下，可以考慮在異地也設(shè)立雙活中心或者多活中心，實現(xiàn)異地雙活或者異地多活，設(shè)置多個地域，但是達成上述要求，對于應用架構(gòu)、應用治理與分布式基礎(chǔ)設(shè)施組件的方面，提出了很高的技術(shù)能力與治理能力要求，在這方面互聯(lián)網(wǎng)行業(yè)的一些技術(shù)創(chuàng)新可以作為重要的參考。對于大中型銀行，是否需要在異地建設(shè)多數(shù)據(jù)中心是一個需要全面論證和權(quán)衡的問題，需要分析投入產(chǎn)出比，或者在可用性因素之外，有其他行內(nèi)的特殊情況需要在異地設(shè)立多中心。
銀行在規(guī)劃異地多活數(shù)據(jù)中心時候，可能會陷入一個技術(shù)誤區(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ù)據(jù)的不一致性，事后通過技術(shù)或者業(yè)務層面的補帳機制去保障業(yè)務最終一致。
在目前IT技術(shù)、互聯(lián)網(wǎng)、電子化渠道已經(jīng)代替原始線下紙質(zhì)憑證的情況下，純業(yè)務層面的補帳機制會存在很多局限性，并且通常需要更長的時間。在遠距離情況下，通過在應用技術(shù)層面設(shè)計補帳機制，能夠最大程度上減少數(shù)據(jù)一致性差異，降低RTO時間。
（二）應用架構(gòu)應該符合哪些規(guī)范，應如何對應用進行持續(xù)治理
建立同城雙活或者異地雙活數(shù)據(jù)中心，實現(xiàn)高可用的信息系統(tǒng)架構(gòu)，不只是能夠單純依靠建設(shè)數(shù)據(jù)中心或者依靠雙活/多活基礎(chǔ)設(shè)施就可以獲得的，需要在符合要求的基礎(chǔ)設(shè)施之前，制定應用系統(tǒng)部署與運行規(guī)范，對應用系統(tǒng)進行治理和改造，才能夠達成信息系統(tǒng)高可用與連續(xù)性目標，有效支撐業(yè)務系統(tǒng)的連續(xù)運行。
這里面需要目前IT業(yè)界比較火熱的云原生應用、應用微服務化、DEVOPS等理念與技術(shù)，對于實現(xiàn)應用同城或者多活，互聯(lián)網(wǎng)行業(yè)也有很多的先進經(jīng)驗。但是銀行業(yè)是否能直接拿來使用，是否應該直接生搬硬套就能滿足我們的需求，需要值得考量。銀行信息系統(tǒng)與其他行業(yè)信息系統(tǒng)相比，存在一些特殊情況：
第一是存量系統(tǒng)的轉(zhuǎn)型問題，銀行以及產(chǎn)品供應商經(jīng)過多年的研發(fā)，銀行信息系統(tǒng)已經(jīng)形成了一套應用系統(tǒng)體系和大量存量應用，這些系統(tǒng)早期設(shè)計研發(fā)時，更多地考慮功能性和性能需求，對于本地多活或者異地多活的需求沒有現(xiàn)在要求這么高，基于成本或者其他方面的考慮在這方面有沒有做過多的研發(fā)和支持，在產(chǎn)品和體系都較為成型的情況下，進行重構(gòu)和設(shè)計需要投入大量的研發(fā)資源，在供應商方面即滿足需求又經(jīng)過市場檢驗的產(chǎn)品較少，比如目前市場上的分布式核心銀行系統(tǒng)，這就決定各個銀行必須制定適合自己的應用治理路線和技術(shù)規(guī)范標準，并且這個標準一般情況下是分步驟分階段，每個階段都需要權(quán)衡投入產(chǎn)出比。
第二是互聯(lián)網(wǎng)行業(yè)自主研發(fā)的情況較多，對比銀行業(yè)，除了大型商業(yè)銀行能夠做到自主研發(fā)外，小型銀行與部分銀行只能依靠采購供應商產(chǎn)品和定制化開發(fā)，進行應用的改造或者重構(gòu)涉及成本問題、廠商的產(chǎn)品市場方向以及廠商自身研發(fā)實力的問題。
第三是銀行業(yè)對于強一致性的要求很高，行業(yè)對于一致性方面的偏好直接決定了實現(xiàn)多活以及實現(xiàn)異地多活的架構(gòu)設(shè)計難度、投入成本、可能造成的風險，并且銀行業(yè)業(yè)務交易對于響應時間等非功能性需求要求也很高，因此在遠距離情況下，如果實現(xiàn)強一致性交易很大程度上會帶來性能與整體可用性的下降。
第四是監(jiān)管層要求的不同，銀行業(yè)受到的監(jiān)管較為嚴格，一方面是對于生產(chǎn)故障事件的監(jiān)管和考核，導致銀行實施系統(tǒng)改造或者實施演練的過程中，需要提前控制可能造成的生產(chǎn)故障風險，因此這些會影響系統(tǒng)重構(gòu)或者改造的步伐，其次對于開源軟件的自主可控問題，導致引入一些多活類支撐類基礎(chǔ)軟件還是需要依托廠商或者自身投入更多的開源自主可控力量，另外監(jiān)管對于業(yè)務高峰業(yè)務時段控制的要求以及研發(fā)與運維人員分離的要求，也對銀行引入新的應用架構(gòu)和研發(fā)過程體系提出更多的要求。
也是基于這樣的角度考慮，銀行選擇建設(shè)同城雙活、異地災備的數(shù)據(jù)中心架構(gòu)，相對實現(xiàn)異地多活來說，實現(xiàn)同城雙活能夠很好地應對單個數(shù)據(jù)中心故障，但是又能夠很好降低技術(shù)難度，降低應用改造與遷移成本，雖然未實現(xiàn)異地雙活，但是整個地區(qū)遭遇毀滅性故障本身屬于極低概率事件，并且在此情況下，也能夠容忍一定的RTO時間。同時，制定了適應同城雙活、異地災備的應用部署架構(gòu)規(guī)范與治理規(guī)范，實現(xiàn)能夠在較短的時間內(nèi)，對應用改造成本的情況下，最大地發(fā)揮現(xiàn)有數(shù)據(jù)中心基礎(chǔ)設(shè)施的能力，并提高整體信息系統(tǒng)可用性與連續(xù)性。
具體的應用部署架構(gòu)規(guī)范主要包含如下幾個方面：
1、應用系統(tǒng)的應用節(jié)點部分需要支持多活部署和運行，這是實現(xiàn)同城雙活的基礎(chǔ)條件。一般應用節(jié)點不包含持久化數(shù)據(jù)的情況下，一般較為容易滿足此項條件，并且每個應用至少在本地中心和同城中心各部署2個以上節(jié)點，并且在一個數(shù)據(jù)中心也需要使用非親和性調(diào)度策略使得兩個階段不處于同一個機房模塊或者機架。但是對于數(shù)據(jù)庫實現(xiàn)跨數(shù)據(jù)中心多活，存在一定技術(shù)難度，同時某些特殊或者極端情況下，反而會帶來整體可用性的下降，或者在人工介入進行恢復操作場景下反正增加恢復難度，因此對于應用系統(tǒng)的數(shù)據(jù)庫節(jié)點，仍然采用較為可靠的主備方案，同時在存儲層面以最大可用模式進行數(shù)據(jù)復制，一般情況下RPO=0，同時在同城雙中心連接出現(xiàn)中斷，或者備中心出現(xiàn)故障時，不會影響主中心數(shù)據(jù)庫的正常運行。
2、應用系統(tǒng)雙中心流量基本均衡。應用系統(tǒng)在進行了雙活改造和雙活部署的情況下，在運行時候仍然會發(fā)現(xiàn)雙中心的交易流量不均衡，或者一個中心出現(xiàn)流量為0的情況。造成這種情況的原因有很多可能性，例如應用實現(xiàn)了雙活，但是線路未實現(xiàn)雙活，或者對接的應用系統(tǒng)、對接的合作方、第三方未均衡地分配交易流量，只有雙中心真實承載均衡的交易流量，才能保證雙中心都是處于可用狀態(tài)，同時也能夠提高兩個中心基礎(chǔ)設(shè)施資源利用率。同時，在各類渠道的流量調(diào)度策略也需要結(jié)合業(yè)務場景進行調(diào)整，比如實現(xiàn)一個網(wǎng)點的柜員和ATM分配到不同的數(shù)據(jù)中心，這樣在故障發(fā)生后切換恢復前，至少有一半左右的柜員或ATM可用，保證在業(yè)務層面能夠繼續(xù)為客戶提供服務。
3、基礎(chǔ)設(shè)施、應用系統(tǒng)的同城雙中心解耦。為了實現(xiàn)高可用性與連續(xù)性，需要在基礎(chǔ)設(shè)施以及應用系統(tǒng)的架構(gòu)設(shè)計與實施上，要減少單一故障原因?qū)е碌碾p中心同時故障，首先例如在基礎(chǔ)網(wǎng)絡層面如果實現(xiàn)大二層可能會帶來網(wǎng)絡層面的單一故障點，其次是應用系統(tǒng)聯(lián)機交易應避免使用雙中心共享存儲節(jié)點，因為此類共享存儲節(jié)點故障就會造成雙中心同時故障，第三在應用層面，要求一個應用不應跨中心訪問其他應用系統(tǒng)，保障流量進入一個數(shù)據(jù)中心后續(xù)交易不會分派到另外一個中心，避免在切換操作過程無法快速有效地隔離某個數(shù)據(jù)中心，降低災備切換操作的難度，第四，要求應用系統(tǒng)在發(fā)布過程需要采取藍綠發(fā)布等模式，避免同時在雙中心更新應用版本，導致全局故障。當然，能夠?qū)е码p中心同時故障的單一故障點無法絕對消除，例如非同城多活的數(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地址就可以容易完成應用切換。在數(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)生更多對于基礎(chǔ)設(shè)施和切換工具的依賴，簡而言之，為了實現(xiàn)高效災備切換，更要把工作做到前期設(shè)計和研發(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、故障的診斷流程可操行性差，難以細化。數(shù)據(jù)中心包含多個模塊機房，每個機房有各類設(shè)施，每類設(shè)備都有各類組件，在出現(xiàn)故障的情況下，在這么多預案中，我們應該首先選擇執(zhí)行哪個預案呢，所以各類現(xiàn)象和告警信息可以提供一些參考信息，但是預案梳理仍然較多。同時，問題的診斷流程實質(zhì)上會出現(xiàn)很多分支，類似于決策樹，從一個現(xiàn)象出現(xiàn)，會診斷出來大量可能的故障，每個故障都有不同的流程，難以在一個預案中明確。
3、以應用/設(shè)備內(nèi)部技術(shù)告警信息作為啟動條件，應用/設(shè)備內(nèi)部的各類技術(shù)部件和告警信息繁多，例如每天網(wǎng)絡設(shè)備產(chǎn)生的告警數(shù)多達百萬級別，此類告警可能對業(yè)務有影響但是有時候又不影響業(yè)務，應急人員頻繁進行應急處置，會消耗大量的無效成本。同時，在服務出現(xiàn)異常時，此時設(shè)備也不一定出現(xiàn)告警信息，或者即使出現(xiàn)，該類告警信息也會淹沒在日常大量的告警信息中。
經(jīng)過長期的摸索和實踐，總結(jié)出來一條行之有效的應急預案編寫實踐經(jīng)驗：
1、應急以快速恢復業(yè)務原則，降低業(yè)務影響為原則，不以定位問題原因為原則。這個原則雖然很容易理解，但是技術(shù)人員在編寫預案或者實際操作過程容易陷入尋找問題原因。應急診斷過程中，需要進行分析將故障區(qū)域明確至一個可執(zhí)行預案的級別，但是一旦明確后，在應急現(xiàn)場不需要再進一步分析故障原因。同時，監(jiān)控等工具系統(tǒng)也要配合進行監(jiān)控覆蓋，以最快的速度給應急處置人員提示故障域信息。
2、合并故故障域原則，因為數(shù)據(jù)中心從數(shù)據(jù)中心級別、機房模塊級別、應用集群級別、設(shè)備級別都進行冗余設(shè)計，我們可以在數(shù)據(jù)中心級別、機房模塊級別、應用集群級別、設(shè)備級別進行隔離切換。如果可以判斷是設(shè)備級別故障，我們就隔離整臺設(shè)備，而無需關(guān)注設(shè)備內(nèi)部什么部件因為什么原因出現(xiàn)故障，應用集群、機房模塊、數(shù)據(jù)中心也以此類推。同時，無法短時間明確故障域，可直接將故障域上提一個層次，但是需要控制上一級別故障域應急操作帶來的風險。同時，如果高層次應急操作操作簡單，經(jīng)過多次檢驗，風險較低，可以刪除低層級應急操作預案，以降低應急預案數(shù)量，以較少的預案應對更多的故障，降低應急預案編織、管理與演練的成本。
3、盡可能從業(yè)務角度判斷服務正常作為啟動條件，例如從業(yè)務交易影響占比角度判斷是否出現(xiàn)數(shù)據(jù)中心整體故障，例如一個數(shù)據(jù)中心的業(yè)務交易出現(xiàn)30%以上失敗時即認為數(shù)據(jù)中心出現(xiàn)整體性故障，作為數(shù)據(jù)中心級別切換的啟動條件，對于網(wǎng)絡設(shè)備以觀察網(wǎng)絡異常流量的占比（網(wǎng)絡數(shù)據(jù)包重傳）作為判斷網(wǎng)絡設(shè)備是否故障的判斷條件（網(wǎng)絡提供的服務即網(wǎng)絡通訊），對于應用集群也是同理。這樣做一方面，應急啟動條件和現(xiàn)象很明確，監(jiān)控工具也很容易落地，應急處置人員也很容易掌握。另一方面，包含的故障場景很全面，可能影響業(yè)務的技術(shù)故障一般情況下都會涵蓋，同時對于不會影響業(yè)務的技術(shù)故障，不會啟動應急，節(jié)約寶貴的人力與IT資源。
（四）切換工具建設(shè)實踐
應急切換工具平臺的建設(shè)屬于運維自動化的范疇之一，技術(shù)上存在通用型，只是應對業(yè)務場景不同而已。IT服務連續(xù)性體系和應急管理體系的建設(shè)不能過于依賴切換工具平臺的建設(shè)。首先，如果我們的基礎(chǔ)設(shè)施和應用如果標準化程度不高，就會導致自動化平臺切換步驟多樣且復雜，在應急情況下能夠成功完成切換的可能性就會降低，這一點跟實現(xiàn)IT運維自動化的前提是標準化類似。其次，很多情況下，應急切換工具自身也會受到故障的影響，因此需要在設(shè)計預先設(shè)計并驗證，保證應急工具自身的可用性。最后，技術(shù)存在局限性，因此需要保持自動化切換失敗場景下，通過手工進行切換的能力，保證大家都是技術(shù)知識和操作步驟的熟悉程度。
切換工具的建設(shè)投入也與上述故障場景與應急預案的設(shè)計明確密切相關(guān)，如果能對于故障域進行整合，從業(yè)務監(jiān)控層面設(shè)計應急場景，應急場景與應急預案，以至于應急切換步驟都可以得到大幅度的減少和簡化。
自動化切換平臺建設(shè)在技術(shù)上與自動化運維平臺差別不大，相關(guān)方式和方法、技術(shù)手段、技術(shù)框架都可以復用，自動化運維平臺開源工具、廠商提供的工具較多，因此本文不做過多介紹，主要針對切換平臺需要在建設(shè)過程中需要特殊關(guān)注的點進行經(jīng)驗分享：
1、切換工具自身如何實現(xiàn)高可用
如何避免切換工具自身受到故障的影響，主要需要遵循的原則就是就是切換工具需要保障在被切換對象外部，同時在基礎(chǔ)設(shè)施層面，要保證在所設(shè)計的故障場景下被切換對象的可達，包括故障場景下網(wǎng)絡可達等。例如兩地三中心情況下，異地切換工具可以部署在異地中心。對于同城AB中心，可以將工具雙活部署在AB中心，A中心故障情況下登陸B(tài)中心切換工具進行切換，B中心故障情況下，登陸A中心切換進行切換，同時兩個中心切換工具的配置數(shù)據(jù)層面進行定期同步，由于切換工具對于數(shù)據(jù)一致性與實時性的要求較低，因此一般實現(xiàn)起來具備可行性?？梢詫B中心的工具地址提供給用戶，并在操作手冊中注明，在什么場景下應該登陸對應的地址進行操作。
另外，數(shù)據(jù)中心基礎(chǔ)設(shè)施一般都建設(shè)有帶外網(wǎng)絡，異常情況下可以手工通過帶外網(wǎng)進行操作，因此切換工具也應利用帶外網(wǎng)絡代替人工進行應急切換操作，切換工具需要在帶外網(wǎng)絡部署相應節(jié)點，并且這些節(jié)點能夠保證在與帶內(nèi)網(wǎng)絡端口的情況下，具備可用性。
2、切換工具的容錯
切換工具在編排操作時，一般情況下不應考慮進行故障域的內(nèi)部進行操作，比如數(shù)據(jù)中心整體故障場景下，一般不編排進入故障數(shù)據(jù)中心對于某個應用進行關(guān)閉或者重啟操作。如果只是進行嘗試性操作，也應保證程序的容錯，也即如果對象可達且可操作，則按照步驟進行操作，如果不可達或者不可操作，也應自動跳過繼續(xù)后續(xù)流程的處理，并注意超時時間的控制。
3、切換流程的執(zhí)行控制
切換流程一般都是多種多樣，一般需要引入工作流引擎，引入activity編制并驅(qū)動工作量。工作流的設(shè)計遵循BPMN2.0UI規(guī)范，一方面BPMN2.0規(guī)范能力強大，能夠表達的場景較為豐富，并且作為一個通用標準，便于與其他工具的開發(fā)以及與其他外部系統(tǒng)的對接。工作量需要支持豐富的人工介入手段，以支持應急切換中碰到的特殊情況，一般情況下需要支持人工暫停、重試、跳過等操作，以及對于執(zhí)行中流程實例的調(diào)整能力，比如增加或者刪除操作步驟、子流程。
實現(xiàn)流程編排可視化，可以降低編排工作的難度，簡化流程編排人員的工作量，同時，在切換過程中進行可視化展現(xiàn)，也能方便在應急協(xié)同過程中，現(xiàn)場各專業(yè)人員對于進度的掌握。
三、整體總結(jié)
在上述體系化思想指導下，可建設(shè)完成同城雙活、異地災備的金融云數(shù)據(jù)中心基礎(chǔ)設(shè)施架構(gòu)體系，在基礎(chǔ)設(shè)施層面實現(xiàn)了同城雙中心解耦，應用系統(tǒng)層面實現(xiàn)同城雙活部署，對應用系統(tǒng)全面治理與云化改造，并部署面向業(yè)務的監(jiān)控工具體系，建設(shè)同城切換自動化平臺，并成功實施同城數(shù)據(jù)中心切換演練，RTO控制在5分鐘以內(nèi)，對銀行業(yè)乃至金融業(yè)的建設(shè)高可用性架構(gòu)體系，完善業(yè)務連續(xù)性能力提供參考，具有很好的借鑒意義。
【作者】程康，擅長數(shù)據(jù)中心高可用架構(gòu)設(shè)計與IT服務連續(xù)性建設(shè)領(lǐng)域相關(guān)技術(shù)，有豐富的ITIL服務管理實踐，擁有2項發(fā)明專利。
