一、背景與方案

1、業(yè)務連續(xù)性挑戰(zhàn)

在銀行業(yè)，業(yè)務連續(xù)性是一個非常重要的領域。

• 業(yè)務系統(tǒng)發(fā)生大規(guī)模中斷會產(chǎn)生資金損失甚至影響公司形象。
• 金融業(yè)務關系國計民生，影響大眾生活。
• 監(jiān)管對銀行業(yè)務連續(xù)性能力的檢視非常重視，會定期開展巡檢。

因此，很多銀行都建立了兩地三中心的容災能力。當基礎架構層面具有容災能力后，出現(xiàn)單機房故障時，通過同城機房的切換實現(xiàn)故障恢復是一種非常理想的故障處理方式。

但通過與同行交流發(fā)現(xiàn)，在出現(xiàn)單機房故障時，大家還是傾向于在本地進行故障恢復，通過同城切換來實現(xiàn)故障恢復的案例少之又少。主要原因如下：

• 架構治理： 架構層面對雙活的技術方案和實現(xiàn)未制定統(tǒng)一的標準，生產(chǎn)環(huán)境部署和配置存在不一致的情況。
• 預案維護： 預案維護于文檔系統(tǒng)中管理，隨著業(yè)務的快速發(fā)展預案的新鮮度和準確性存在問題。
• 演練驗證： 演練本身的生產(chǎn)風險和實施成本巨大，演練覆蓋率較低。預案有效性、應急流程和應急人員操作缺乏有效的驗證。

所以當有了容災的基礎能力后，距離隨時能切，想切就切的實戰(zhàn)能力還有一定距離。

2、業(yè)務場景切換能力

當業(yè)務系統(tǒng)或業(yè)務場景出現(xiàn)故障后，快速通過切換實現(xiàn)我們的恢復目標，是我們?nèi)轂那袚Q非常重要的能力。

我們往往將業(yè)務場景切換過程分為以下三個階段：

• 機房、網(wǎng)絡、存儲等基礎架構恢復；
• 操作系統(tǒng)、容器平臺、信息系統(tǒng)恢復；
• 業(yè)務場景對應的應用與數(shù)據(jù)庫恢復。

應用場景恢復過程往往在整個階段中耗時最久，因為它的切換對象數(shù)量極多。另外，業(yè)務場景與應用數(shù)據(jù)庫之間的關系非常復雜，維護預案的成本很高，所以當出現(xiàn)預案不準確的情況時，往往會導致故障恢復不能達到預期效果，增加故障恢復時長。

為了解決以上問題，我們會定期對全行業(yè)務進行梳理，找出產(chǎn)生故障后會導致巨大資金損失的關鍵業(yè)務，之后根據(jù)這些關鍵業(yè)務梳理出業(yè)務相關的業(yè)務場景，最后定位到這些業(yè)務場景所依賴的子系統(tǒng)。

3、面向子系統(tǒng)的容災能力

當每一個子系統(tǒng)都建成同城容災的能力后，我們就可以認為我們的業(yè)務具備了同城級別的容災能力。換言之，當我們的業(yè)務場景出現(xiàn)故障時，我們可以通過切換對應的系統(tǒng)快速恢復故障。

IT架構往往分成系統(tǒng)、子系統(tǒng)以及應用三個層次，系統(tǒng)由多個實現(xiàn)特定業(yè)務功能的子系統(tǒng)組成，每一個子系統(tǒng)又由多個實現(xiàn)特定業(yè)務邏輯的應用組成。

我們在建設容災能力時，目前選擇子系統(tǒng)作為容災建設的最小單位，原因有以下幾點：

• 業(yè)務邊界明確： 子系統(tǒng)有明確的業(yè)務功能邊界，變動性小，易于建立與業(yè)務場景的關聯(lián)關系；
• 職能管理維度： 在業(yè)務開發(fā)、版本控制、運維管理有配套的人員和職能支持；
• 維護成本可控 ： 相比數(shù)千級別的應用數(shù)量，數(shù)百個子系統(tǒng)在預案維護上成本相對可控；
• 架構管理單元： 子系統(tǒng)作為架構的管理單元，會對架構設計、高可用等進行評估；
• 服務流量入口： 子系統(tǒng)間有提供服務相對獨立，內(nèi)部訪問關系高內(nèi)聚，彼此訪問松耦合等特點；
• 數(shù)據(jù)庫獨立使用： 子系統(tǒng)在數(shù)據(jù)庫使用上相對獨立，架構治理成本相對較低。

二、預案一鍵切換

1、雙活架構模型

上文中我們講到通過子系統(tǒng)建設容災能力，子系統(tǒng)在切換時，其實是將故障機房的一些服務全部拉出，然后把流量和服務切換到服務正常的同城機房。

那么對于一個完成改造的子系統(tǒng)而言，它的服務分成三層，切換時需要對這三層的一些組件做解綁動作。最上面的一層是互聯(lián)網(wǎng)的流量，例如我們公網(wǎng)的GLSB和 HTTP DNS等流量，也有一些廣域網(wǎng)的專線，還有一些負載均衡的服務。 當流量進入內(nèi)網(wǎng)后，我們通過內(nèi)網(wǎng)的GSLB與負載均衡的切換實現(xiàn)HTTP層的流量調(diào)度。 對于一些微服務的流量，我們通過注冊中心的 一些流量 拉入拉出實現(xiàn)流量的切換。

除了以上三種，銀行中還有一個比較特殊的服務模式——跑批，即晚上對當天的交易進行復核，跑批的結果會直接影響第二天銀行能否順利開門，也會間接影響我們服務的可能性。 在這個過程中，我們會對作業(yè)在哪個地方去跑等做一些切換控制。

理論上，當子系統(tǒng)完成了一些架構改造后，通過這些流量的調(diào)度切換，就可以完成我們的工程切換。但實際上，也有一些長尾問題，比如有些子系統(tǒng)做一些雙活的改造成本很高，或它是一些比較老的外購系統(tǒng)，這樣的系統(tǒng)比例不高，但很重要。所以我們支持這些子系統(tǒng)切換的時候，提供了一些更加靈活的切換能力，比如我們支持做一些應用配置的修改，或者執(zhí)行自定義的腳本，甚至會提供一些數(shù)據(jù)庫層面的數(shù)據(jù)修改能力，讓那些非標的子系統(tǒng)具備自動化、快速切換的能力，提高應急切換效率。 在數(shù)據(jù)庫層面，更多的是像 Oracle、Mysql或MongoDB等數(shù)據(jù)庫組件的切換。

2、原子預案編排

在切換過程中，每一個類型的切換，我們內(nèi)部都稱之為一個原子的預案，切換工具會對這些原子預案進行預案編排。在執(zhí)行前，我們有一個檢查階段，來確保目前處于適合切換的狀態(tài)，才能執(zhí)行。

當完成執(zhí)行動作后，我們還需要通過驗證來確保執(zhí)行目標的達成，但具體步驟不是由我們的工具提供，這些能力是由數(shù)據(jù)庫團隊或平臺架構團隊的變更能力提供。而我們的平臺是通過HTTP的方式，讓他們對執(zhí)行、檢查的步驟進行快速編排。這種檢查、執(zhí)行、驗證的編排模式，讓大家的切換能力變得更加標準化，也更加安全。

當我們完成切換后，往往還需要對服務進行恢復，切換是從雙活變到單活的過渡，當故障恢復后或演練要回切時，我們也會把單活的能力回退到雙活的模式，這時候會有一個回退的編排。在回退編排中要做一些檢查、執(zhí)行和驗證動作的編排。

由于每一個原子預案都是很基礎的預案，風險非常大。所以當我們的預案要發(fā)布時，會請每個領域的專家對預案的內(nèi)容進行評估，甚至做一些測試來保證預案能達到相應效果，保證預案本身的安全性。

3、子系統(tǒng)應急預案

1）故障場景關聯(lián)

當我們有了原子預案能力以及明確的系統(tǒng)切換清單后，我們就可以在子系統(tǒng)層面編排子系統(tǒng)的預案，這個預案內(nèi)容可能會包含一些應用、網(wǎng)絡以及數(shù)據(jù)庫的操作。當做子系統(tǒng)切換時，這些動作需要同步切換。但是我們可以將對應的故障場景進行區(qū)分，盡可能降低切換范圍。

2）串并執(zhí)行編排

我們完成雙活改造后，切換對象之間的切換都是獨立的，所以我們默認通過一些并行切換的方式提升整體切換效率。

但是因為有一些長尾問題，例如有些子系統(tǒng)在切換之前需要先關閉一些流量才能執(zhí)行后面的切換動作，所以我們最終提供的是串并行結合的編排能力。

3）預案版本管理

因為架構一直在發(fā)生變化，當架構發(fā)生變化之后，工具能夠捕獲到這種變化，我們會將這些變化信息同步給對應的預案維護人，他們可以通過這些提示信息對預案進行實時更新，以免發(fā)生價格變化后預案更新不及時的情況。

4）演練狀態(tài)標識

預案維護后是未驗證的狀態(tài)，只有當子系統(tǒng)完成一次演練后，我們才會認為這個預案處于安全有效的狀態(tài)，所以我們會在預案沒有演練前，提示其切換過程中可能存在的風險。

以上4個能力是子系統(tǒng)預案編排過程中比較關鍵的能力。當我們的子系統(tǒng)具備了預案管理能力后，我們再去做業(yè)務場景的編排會更容易。我們只需要明確業(yè)務場景中包含了哪些子系統(tǒng)，并按照故障恢復的優(yōu)先順序設定切換執(zhí)行的批次即可。

4、執(zhí)行過程可視化

在執(zhí)行過程中我們會提供預案執(zhí)行過程的看板，展示目前切換的耗時與執(zhí)行成功與否，以及每一類組件切換的進度和狀態(tài)。在執(zhí)行過程中，如果說有一些步驟或一些預案執(zhí)行失敗，我們也可以通過一些下鉆查看具體的報錯原因。

5、工具可用性

每年的演練非常多，我們希望通過自助的方式，讓運維、DBA以及一些演練執(zhí)行人能夠自助解決一些問題。

上文講的是如何通過工具體系提高業(yè)務系統(tǒng)的可能性，其實工具的可用性相比業(yè)務系統(tǒng)的可能性要求更高，因為發(fā)生故障時，你期望通過工具對業(yè)務系統(tǒng)進行恢復。我們在工具建設過程中，提出了更高的可能性要求。

1）多活

切換工具及其關鍵依賴，我們會在三個數(shù)據(jù)中心進行部署。這三個數(shù)據(jù)中心包含我們的同城機房，生產(chǎn)機房，還有第三地機房。我們會默認把主服務部署在第三地機房。這樣當同城和生產(chǎn)機房出現(xiàn)問題時，工具可以快速接管服務，實施切換動作。

切換工具，其關鍵依賴，以及變更能力是工具的核心能力，發(fā)生故障時這些能力不能出現(xiàn)任何問題，所以我們會定期對這些強依賴或關鍵依賴做一些容災切換演練。

2）降級

登錄等能力是切換工具的弱依賴，切換工具的核心能力是切換。當這些能力出現(xiàn)故障時，我們要盡量避免它對我們核心切換能力產(chǎn)生影響，所以我們會定期通過故障注入或者主動降級來做一些弱依賴的降級演練，確保弱依賴發(fā)生故障時，核心功能不受影響。

3）性能

我們也會對切換原子預案的執(zhí)行性能做一些測試。我們在每一個原子預案上線前，會要求預案提供方提供性能測試的基準，明確指出每一個原子預案執(zhí)行的并行度是多少，以及在對應并行度下切換的SLA是多少。這種情況下，工具可以對原子預案的執(zhí)行做流控，保證切換過程的穩(wěn)定性。

三、運行可觀測性

在執(zhí)行切換過程中，切換的實施人要實時關注切換服務的運行狀態(tài)是否出現(xiàn)異常，以及是否達到相應效果。

1、運行監(jiān)控

在應急或演練時，我們會有一個切換成功的標準：切換完成后，業(yè)務的關鍵指標沒有明顯波動，目標機房要承載100%的生產(chǎn)流量，應用層和基礎層對應服務的一些能力滿足對應的SLA要求。這需要我們給演練的實施人提供信息匯聚的能力，包括業(yè)務層、應用層以及基礎架構層面的監(jiān)控能力。

2、架構可觀測性

除監(jiān)控能力外，我們也會以清單形式展示對應組件的情況。異常展示是分層的，只有出現(xiàn)異常時，我們才會下鉆查看實際部署的異常展示。另外，我們也會將告警、變更等體現(xiàn)生產(chǎn)系統(tǒng)異?；虼嬖陉P聯(lián)影響的動作在服務節(jié)點進行標識，及時提示生產(chǎn)變更的潛在風險。

3、運維數(shù)據(jù)中臺

以上提到的展示能力都依賴于運維數(shù)據(jù)中臺實現(xiàn)。

在運維數(shù)據(jù)中臺中，我們會將服務之間的調(diào)用關系以及CMDB的一些部署信息組合成一張拓撲關系網(wǎng)，并在每一個拓撲節(jié)點上附加一些配置屬性、監(jiān)控的 url 地址以及變更等信息，豐富每一個拓撲節(jié)點的數(shù)據(jù)。當有了拓補和信息之后，我們就可以快速提供可觀測性能力，包括預案維護過程中識別架構變化的能力，以及一些自動化驗證的能力。

四、演練線上化

當我們有了一鍵切換能力以及可觀測性能力后，我們還需要通過演練驗證人員的有效性、預案本身的有效性以及流程的有效性。中間過程中還要解決一些問題。

我們的同城子系統(tǒng)切換演練，其實是一個子系統(tǒng)層面的中高風險生產(chǎn)變更。在變更方案制定過程中，我們要盡可能避免因為方案層面問題產(chǎn)生的影響。

1、方案風險控制

1）影響范圍評估

我們的演練是為了提高生產(chǎn)的穩(wěn)定性，所以我們在演練過程中，會對演練的影響范圍做評估，主要包括以下幾方面：

• 識別與演練子系統(tǒng)關聯(lián)的子系統(tǒng)，如是否存在數(shù)據(jù)庫共用的情況；
• 識別關聯(lián)系統(tǒng)的相關人員，如開發(fā)、運維、DBA等；
• 有相關人員協(xié)同識別方案風險，并參與演練的驗證。

2）實施風險評估

我們也通過工具對實施風險進行評估，主要包括以下幾方面：

• 數(shù)據(jù)庫防火墻未開識別；
• 集群部署當前可用容量不對稱問題；
• 軟件、框架使用版本不符合基線問題；
• 異常識別自動化檢查與二次驗證。

有了上述能力后，我們就可以大幅度規(guī)避方案層面的一些風險。

2、演練流程管控

第二個風險是流程控制層面的風險。一個完整的流程，對降低演練過程的風險非常有幫助。流程的存在，也能夠提升演練的有效程度。對于演練過程中發(fā)現(xiàn)的一些問題，我們可以通過問題管理的一些流程跟進，關注它的持續(xù)解決。

但是流程的存在也會產(chǎn)生一些成本。因為流程本身非常復雜，有較高的學習和培訓成本，并且在有制度無管控的情況下，達不到期望的管理效果，同時，完整的流程實施還會產(chǎn)生巨大的人力成本。

所以我們將線下流程變到線上時，對這些信息做了一些梳理，通過一些強流程的控制，對那些存在變更風險或流程風險的地方做了設置的關卡，來規(guī)避一些流程中的風險。對于一些本身很復雜的流程，我們通過提示及引導的方式大大降低用戶演練門檻。

3、演練效能提升

我們在工具層面做了一些信息優(yōu)化，來提升流程的效率。沒有工具之前，單次演練的累計時長加起來可能長達三天時間，如果考慮它的起始時間，甚至可能長達一個月。當我們將演練線上化后，我們工具從四個方面提升了演練效能，縮短了演練時長。

1）演練人員協(xié)同

線上化演練可以通過識別，實現(xiàn)風險評估、方案制定和演練驗證等環(huán)節(jié)的信息協(xié)作錄入，這樣的話我們演練的負責人只需要對結果做review和確認就可以完成演練的制定，大大降低了溝通協(xié)同成本。

2）流程信息集成

線上化演練可以集成變更管控、問題管理、審批管理等流程系統(tǒng)，并且在演練過程中自動完成流程信息的關聯(lián)與狀態(tài)翻轉(zhuǎn)。

3）輔助技術驗證

線上化演練可以通過面向不同演練對象建立標準化的技術驗證格式和指標減少驗證成本，還能夠自動生成驗證信息，大幅降低演練中驗證信息的填寫成本，顯著縮短演練時間。

4）運營決策分析

線上化演練可以通過對演練過程信息的埋點，建立數(shù)字化的過程度量能力，并且通過多緯度的統(tǒng)計分析建立演練質(zhì)量的運營分析能力，提高演練流程的質(zhì)量和效率。

有了上述能力后，單次演練的平均投入時間從原來的3天減少到2小時，效率提升了10倍以上，同時形成了常態(tài)化演練的條件，可以大幅提高我們演練的覆蓋率。

4、演練模擬執(zhí)行

上文講述的內(nèi)容是通過演練的方式驗證切換預案內(nèi)容本身的有效性，除此之外還應該驗證人員的有效性以及流程的有效性。這些有效性往往通過培訓或桌面沙盤模擬，以及應急響應演練來實現(xiàn)，因此我們開發(fā)了一套模擬執(zhí)行的機制。通過模擬執(zhí)行的方式，可以提升我們一線團隊、一線同事對于切換流程的熟悉程度，也可以驗證我們流程的有效性。

5、演練過程指揮

我們在做大規(guī)模演練的時候，會產(chǎn)生一些指揮層面的需求。

比如我們的演練負責人需要關注參加當次演練的人員信息以及所設計業(yè)務監(jiān)控的正常程度，并且需要關注切換過程中數(shù)據(jù)中心的流量變化。那么通過我們的指揮大屏，指揮官可以清晰看到數(shù)據(jù)中心運行信息。在演練過程中，我們也會將每個子系統(tǒng)的切換進度在大屏上進行展示。

五、上線后的收益

1、業(yè)務連續(xù)性能力提升

1）容災能力提升

我們實現(xiàn)了容災切換平臺后，整個切換時長得到了大幅提升。目前我們一個子系統(tǒng)端到端的切換RTO小于10分鐘，縮短至了原來的三分之一。

對于應用類的切換，RTO的值更小，因為應用類切換的成本主要是不同系統(tǒng)之間的操作成本，當我們?nèi)グ凑找粋€預案批量執(zhí)行時，基本上幾秒鐘就可以完成。

2）業(yè)務切換能力

那么因為我們建立了業(yè)務場景與子系統(tǒng)之間的關系，子系統(tǒng)又完成了預案管理的閉環(huán)，所以我們具備了業(yè)務場景切換的預案維護的閉環(huán)能力。當業(yè)務場景出現(xiàn)故障時，我們可以快速通過子系統(tǒng)的切換實現(xiàn)業(yè)務場景的一鍵恢復。

3）應急方式豐富

原來我們發(fā)現(xiàn)一些故障的時候，往往是通過重啟、擴容、回穩(wěn)這傳統(tǒng)的三把斧方式恢復故障。有了切換能力后，我們有了更快速的方式，可以通過切換來快速恢復服務，同時切換的方式也是經(jīng)過驗證的，所以它也是一種較為安全的故障恢復手段。

2、變更安全能力提升

除了業(yè)務連續(xù)性能力提升之外，我們還發(fā)現(xiàn)了額外的驚喜。

1）常規(guī)變更

我們原來去做一些技術架構層面的變更，無論是應用運維還是技術架構的同事都非常擔心，變更可能產(chǎn)生一些較大規(guī)模的故障。

當我們具備切換能力后，再進行機房維護時，我們就會提前將這些應用的流量及相關一些子系統(tǒng)的流量切換到我們的通訊機房，保障變更過程中的安全性。當我們完成技術架構變更時，再分批將流量切回來，大大提升了安全系數(shù)。

2）藍綠發(fā)版

原來我們行業(yè)的發(fā)版主要集中在周二和周四，對于一些關鍵系統(tǒng)，這個時間點往往在周二周四的凌晨兩三點鐘，對于運維人員很不友好。當我們有了切換能力后，發(fā)布過程的安全性提升了，可用于發(fā)版的時間段延長，同時發(fā)版后業(yè)務異常支持快速回退。

Q&A

Q1：是否有必要進行以存儲為中心的容災演練，相比應用為中心的容災演練有什么區(qū)別？

A1： 我們在做容災切換時，不僅做應用層的，也會做數(shù)據(jù)層的。所以我理解這個切換應該是應用與數(shù)據(jù)庫整體的切換，至于存儲部分是由技術架構團隊單獨實施。

Q2：在演練之前如何確保兩邊的數(shù)據(jù)是一致的？

A2： 我們目前在應用層有一些巡檢機制，所以我們會定期做一些檢查，在切換之前也會做檢查工作，我們切換前后不能說一致，但至少生產(chǎn)的機房跟同城機房之間，處于可切換狀態(tài)，數(shù)據(jù)庫層面通過數(shù)據(jù)來實現(xiàn)切換。

Q3：切換后增量的數(shù)據(jù)可以恢復到原生產(chǎn)數(shù)據(jù)中心嗎？

A3： 這個問題在演練跟應急過程中有一些區(qū)別，演練過程中我們會盡可能避免數(shù)據(jù)丟失的行為，因為演練過程中有一個Switch over的切換方式，但是真正發(fā)生生產(chǎn)應急的時候，Switch over的方式時間會比較久。真正發(fā)生生產(chǎn)應急的時候，我們會用vivo的 方式做切換，這個時候其實會有一些數(shù)據(jù)丟失，丟失的數(shù)據(jù)由DBA同學修復。

Q4：一年進行幾次容災切換的應急演練？

A4： 我們有一個要求，兩年之內(nèi)要對我們的核心系統(tǒng)做到演練覆蓋，所以每年的演練數(shù)量基本多達幾百次。

Q5：切換是僅限同城嗎？

A5： 我們在建設容災能力時，有同城能力也有災備能力，但因為大數(shù)據(jù)是實時復制的，同城機房與生產(chǎn)機房都有流量，所以切換的安全性更高一些。兩個同城機房都不可用的情況之下，我們才會做一些災備切換，二者的使用頻率跟場景是不一樣的，所以我們的演練災備機房也會有，但同城演練的頻率可能更高一些。

Q6：平時業(yè)務在兩個中心同時跑，是按照1:1的比例分配流量，如果是應用層面的問題，一般兩中心同時都有問題，那么切換是否就沒有意義了？

A6： 我們平時的流量是在生產(chǎn)跟同城機房以1:1的形式部署的，如果一個節(jié)點出現(xiàn)一個問題，物理設備出現(xiàn)一些問題，或單機房的PaaS服務出現(xiàn)一些問題，故障往往是單機房的。如果應用層面出現(xiàn)問題，例如容量問題，這種情況通過切換是解決不了的。所以容災切換只適用于部分場景，并不能解決所有問題。