銀行業(yè)IT服務(wù)連續(xù)性體系規(guī)劃與災(zāi)備自動化切換建設(shè)

一、背景介紹相比于其他行業(yè)，銀行業(yè)對于信息系統(tǒng)可用性與連續(xù)性有著很高的要求，基于這樣的客觀需求，同時也是滿足銀保監(jiān)會《商業(yè)銀行數(shù)據(jù)中心監(jiān)管指引》的要求，絕大部分大中型銀行都已經(jīng)建立兩地三中心架構(gòu)，甚至多地多中心架構(gòu)。為了驗證同城中心或者異地中心的IT服務(wù)連續(xù)性保障能力，需要持續(xù)開展災(zāi)備切換演練，一般情況下分為同城災(zāi)備切換演練與異地災(zāi)備切換演練。在進(jìn)行經(jīng)驗分享之前，需要統(tǒng)一對于IT服務(wù)連續(xù)性的理解，明確一下

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

例如從業(yè)務(wù)交易影響占比角度判斷是否出現(xiàn)數(shù)據(jù)中心整體故障，例如一個數(shù)據(jù)中心的業(yè)務(wù)交易出現(xiàn)30%以上失敗時即認(rèn)為數(shù)據(jù)中心出現(xiàn)整體性故障，作為數(shù)據(jù)中心級別切換的啟動條件，對于網(wǎng)絡(luò)設(shè)備以觀察網(wǎng)絡(luò)異常流量的占比（網(wǎng)絡(luò)數(shù)據(jù)包重傳）作為判斷網(wǎng)絡(luò)設(shè)備是否故障的判斷條件（網(wǎng)絡(luò)提供的服務(wù)即網(wǎng)絡(luò)通訊），對于應(yīng)用集群也是同理。這樣做一方面，應(yīng)急啟動條件和現(xiàn)象很明確，監(jiān)控工具也很容易落地，應(yīng)急處置人員也很容易掌握。另一方面，包含的故障場景很全面，可能影響業(yè)務(wù)的技術(shù)故障一般情況下都會涵蓋，同時對于不會影響業(yè)務(wù)的技術(shù)故障，不會啟動應(yīng)急，節(jié)約寶貴的人力與IT資源。（四）切換工具建設(shè)實踐應(yīng)急切換工具平臺的建設(shè)屬于運維自動化的范疇之一，技術(shù)上存在通用型，只是應(yīng)對業(yè)務(wù)場景不同而已。IT服務(wù)連續(xù)性體系和應(yīng)急管理體系的建設(shè)不能過于依賴切換工具平臺的建設(shè)。首先，如果我們的基礎(chǔ)設(shè)施和應(yīng)用如果標(biāo)準(zhǔn)化程度不高，就會導(dǎo)致自動化平臺切換步驟多樣且復(fù)雜，在應(yīng)急情況下能夠成功完成切換的可能性就會降低，這一點跟實現(xiàn)IT運維自動化的前提是標(biāo)準(zhǔn)化類似。其次，很多情況下，應(yīng)急切換工具自身也會受到故障的影響，因此需要在設(shè)計預(yù)先設(shè)計并驗證，保證應(yīng)急工具自身的可用性。最后，技術(shù)存在局限性，因此需要保持自動化切換失敗場景下，通過手工進(jìn)行切換的能力，保證大家都是技術(shù)知識和操作步驟的熟悉程度。切換工具的建設(shè)投入也與上述故障場景與應(yīng)急預(yù)案的設(shè)計明確密切相關(guān)，如果能對于故障域進(jìn)行整合，從業(yè)務(wù)監(jiān)控層面設(shè)計應(yīng)急場景，應(yīng)急場景與應(yīng)急預(yù)案，以至于應(yīng)急切換步驟都可以得到大幅度的減少和簡化。自動化切換平臺建設(shè)在技術(shù)上與自動化運維平臺差別不大，相關(guān)方式和方法、技術(shù)手段、技術(shù)框架都可以復(fù)用，自動化運維平臺開源工具、廠商提供的工具較多，因此本文不做過多介紹，主要針對切換平臺需要在建設(shè)過程中需要特殊關(guān)注的點進(jìn)行經(jīng)驗分享：1、切換工具自身如何實現(xiàn)高可用如何避免切換工具自身受到故障的影響，主要需要遵循的原則就是就是切換工具需要保障在被切換對象外部，同時在基礎(chǔ)設(shè)施層面，要保證在所設(shè)計的故障場景下被切換對象的可達(dá)，包括故障場景下網(wǎng)絡(luò)可達(dá)等。例如兩地三中心情況下，異地切換工具可以部署在異地中心。對于同城AB中心，可以將工具雙活部署在AB中心，A中心故障情況下登陸B(tài)中心切換工具進(jìn)行切換，B中心故障情況下，登陸A中心切換進(jìn)行切換，同時兩個中心切換工具的配置數(shù)據(jù)層面進(jìn)行定期同步，由于切換工具對于數(shù)據(jù)一致性與實時性的要求較低，因此一般實現(xiàn)起來具備可行性?？梢詫B中心的工具地址提供給用戶，并在操作手冊中注明，在什么場景下應(yīng)該登陸對應(yīng)的地址進(jìn)行操作。另外，數(shù)據(jù)中心基礎(chǔ)設(shè)施一般都建設(shè)有