一、背景與方案

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

二、預(yù)案一鍵切換

1、雙活架構(gòu)模型

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

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

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

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

2、原子預(yù)案編排

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

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

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

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

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

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

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

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

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

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

3）預(yù)案版本管理

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

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

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

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

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

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

5、工具可用性

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

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

1）多活

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

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

2）降級

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

3）性能

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

三、運行可觀測性

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

1、運行監(jiān)控

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

2、架構(gòu)可觀測性

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

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

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

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

四、演練線上化

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

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

1、方案風(fēng)險控制

1）影響范圍評估

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

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

2）實施風(fēng)險評估

我們也通過工具對實施風(fēng)險進(jìn)行評估，主要包括以下幾方面：

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

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

2、演練流程管控

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

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

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

3、演練效能提升

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

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

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

2）流程信息集成

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

3）輔助技術(shù)驗證

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

4）運營決策分析

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

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

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

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

5、演練過程指揮

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

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

五、上線后的收益

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

1）容災(zāi)能力提升

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

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

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

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

3）應(yīng)急方式豐富

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

2、變更安全能力提升

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

1）常規(guī)變更

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

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

2）藍(lán)綠發(fā)版

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

Q&A

Q1：是否有必要進(jìn)行以存儲為中心的容災(zāi)演練，相比應(yīng)用為中心的容災(zāi)演練有什么區(qū)別？

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

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

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

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

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

Q4：一年進(jìn)行幾次容災(zāi)切換的應(yīng)急演練？

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

Q5：切換是僅限同城嗎？

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

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

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