系統高可用之容災應急切換演練探討活動總結

隨著企業容災備份的建設，定期進行容災系統的切換演練，已成為驗證系統高可用和練兵的重要視窗，然而容災演練的現狀卻不盡人意。要麼存在走過場形式化的演練，要麼過度消耗資源。前一種，無法面對真實的災難環境，後一種，給企業造成人力與物力上的浪費。透過本次關於容災切換演練的活動探討，讓我們運維人對如何使容災真正做到有備無患、切換演練做到行之有效，有了新的思路。

在活動中的精彩問題和觀點交流時，我們把容災切換演練的過程與專案管理理論緊密相連，下面就從專案的整體、質量、成本、時間、人力、風險等幾個管理領域，對此次活動觀點進行整理。

1、容災切換演練中的整體規劃

典型問題：

如何進行容災應急切換演練的規劃?

系統的高可用容災應該建設到什麼程度?

容災策略制定過程和那些因素有關?

觀點總結：

演練的整體規劃是要從頂層設計一步步落實到底層實施，越是系統架構不夠完善的企業，越要形成容災的機制。演練，未必一定要選擇停機的方式進行，如果之前沒有演練過，可以設計好演練的計劃和方案，先進行桌面和模擬演練，待系統建設完善和可用性提升後，在進行實操演練。演練，也不是最終目的，目的是進一步完善企業的應急機制。

在選擇我們的容災方案時候，要根據目前我們系統架構的可用性進行分析。按照國際標準SHARE78，從本地磁碟的備份，到將備份的磁帶儲存在異地，再到建立應用系統實時的切換的異地備份系統。並結合sla要求、建設預算情況、企業資訊發展等進行同步規劃。

容災演練的整體標準如下：

企業在加強容災處理能力、增強應急處置能力時。的確應該形成一整套容災備份的標準和措施。

標準或者措施的落地，可以透過形成一整套容災管理體系的文件，其標準應該包括有：

資訊系統容災備份的建設規範：是企業進行容災建設的詳細方案。從機房選址、網路容災模式到主機系統、資料庫選用方案等各個方面。

容災備份策略和計劃：梳理企業資訊系統可能會遇到的各種災難，以及在發生災難後的應急措施。

系統切換演練的操作手冊：規範應急恢復的操作步驟、內容詳盡應包含演練切換說明、恢復指令碼等等。

在制定演練整體計劃時應該遵循如下原則：

目的明確，切記不切實際。如果一個目的不明確的容災，技術人員很難設計，要數不確定，最好都是耗時耗力領導還不滿意。

分步實施，循序漸進。容災是以備不時之需，最重要還是搞好生產系統。容災的需求專案最終是生產的複製和最佳化，不可能畢一功為一役。

合適最好，易於實現。容災的模型適合自己的才是最好的，而且也要有利於運維，有利於實現，切莫最求新、大、豪。

忠於實際，日積月累。容災系統建設要契合自己的實際，規章制度都要以實際為首要，不要想天衣無縫，都是過坑跨坎一天一天完善的。

在整體管理方面對如下幾個關鍵點進行掌控：

做到災備系統知根知底。談到災備系統，首先我們不管是管理者還是執行者，都要對自己的災備系統有個清晰的瞭解。首先，我們的災備系統是基於什麼目的來建設的，能達到什麼程度的容災。災備系統很多，投資力度不同，側重點也不同。對於自己的災備系統架構、效能、缺點、優點。瞭解的越深入越能知根知底，才能做到胸有成竹。

做好核心團隊建設。再好的災備系統都需要人來執行，如果說運維人員都沒準備好，一切都是扯淡。一個穩定的核心團隊建設，也是生產力的體現。團建建設不僅要平時就有的放矢，而且更要注重團隊建設。技術運維更是如此，只有做好平時技術積累和訓練，才能做到用時能頂的上，下的來。

組織上要有分工。真到災備切換的時候，那就是最後的希望了。到那時，沒有人是不緊張的，只要分工明確，職責清晰，才能到時正常運轉。技術運維人員要這樣，管理領導層更要明確分工，不要真到關鍵時刻，沒有人下命令或者不知如何下命令。

協調能力要加強。一個系統可能是多個部門或單位在使用，切換需要各個部門相互配合，技術上切換成功，不代表切換成功。只有所以部門都步調一致，才能把切換成果最大化。

風險控制不容忽視。沒有百分之百安全的方案，只有萬分小心才能換得一次心安。平時要加強監控能力，及時對風險做出準確的判斷和及時的預警，才能把風險降到最低。風險來自人力、技術、裝置、管理、環境等等方方面面，再怎麼重視也不為過。

做好各種預案。沒有預案，就是耍流氓。做好預案，不僅是管理能力的提高，也是標準化建設能力體現，也是各部門各個人做好工作的前提。沒有預案，真到意外時，沒章可循豈不是笑話。

做好容災應急演練測試工作。功夫再好，不拉出練練，誰知道行不行。只有經得住檢驗的容災切換測試才是真正可靠的。要定期組織相關部門都參與容災應急演測試，做到認證對待，溝通通暢，測試正常，結果達到預期才算正常。

最後一步，容災切換。前面做的再多也是為最後一步準備，只有容災切換成功的才是修成正果，得道昇天。

2、容災切換演練中的質量控制

典型問題：

如何透過對災備中心的有效日常運維，來保障容災系統的順利切換?

容災無大小，你都有哪些手段和措施?

觀點總結：

因人力、成本等各種客觀因素，容災中心的日常運維標準往往不能達到生產中心的水平，下面內容討論該從哪些方面保障容災中心日常的運維工作的質量：

資料完整性、有效性審查機制：在容災系統中建立起與生產系統的資料同步審查機制，並透過資料核對幫助生產系統發現可能出現的問題，尤其對於選用資料庫DR功能的容災模式，要時刻關注資料庫同步狀態，並根據預定指標進一步檢查資料的一致性、完整性，進一步完善和最佳化生產系統和容災系統。

系統資源監控：為了保證容災系統接管生產系統時，不會因為IT因素、基礎設施問題而發生接管失敗，對IT基礎設施所進行的日常例行檢查、維護工作。目的是幫助系統組、業務組成員對生產系統及其容災系統的執行情況進行監控，對故障進行快速準確定位。

軟體版本管理：在軟體版本進行變更、升級過程中，要及時對生產系統及其容災系統的軟體版本進行管理，保證容災系統能按既定目標順利接管業務，避免由於版本不一致造成的資料錯誤、業務接管失敗。

容災變更管理：嚴格控制、管理容災系統中的變更行為，確保容災變更平穩實施。嚴格審查發起，影響及資源評估、接受、執行、變更總結等。

以資料庫複製架構為例:

日常檢查(主備庫狀態、主備庫切換狀態、主備庫日誌同步情況、主備庫是否有GAP、主備庫警告日誌、主備庫負載情況等等)。

容災技術準備檢查(容災切換手冊或者工具有效性檢查、環境變化檢查、容災技術體系完善性檢查)

監控檢查(容災決策依據的監控點是否可用、是否有異常等等)

應急機制(流程、工具、人員有效性)

其他對容災演練質量控制的細節：

建立完整的組織體系(可以是虛擬的)，分工要求明確。

災備日常管理員必須得到上層領導授權。

嚴格的變更評審機制(每一個關係到災備系統的變更必須經過災備管理審批，一旦確認於災備有關，必須同步啟動災備中心變更)。

嚴格執行演練手冊的變更和版本控制;(在涉及到災備相關係統的變更時，災備日常維護人員必須注意演練手冊的更新升級)。

定期的組織學習，以及推演(這個很重要，能在過程中發現很多問題)。

定期組織真正的演練。

演練完成後一定要總結，並更新演練手冊。

3、容災切換演練中的風險規避

典型問題：

容災演練隱患剖析

在做容災應急切換的時候應該有哪些需要注意的風險點

應急演練的矛盾

影響容災演練不成功的因素有哪些?

觀點總結：

隱患之一容災組織建設不健全：

容災團隊需要有一個包括決策組、執行組、行政組的完整組織機構。需要有團隊組織和完成日常管理、預警、演練、測試、培訓等工作。

但很多企業建成容災中心後，維護的工作量增加很多。但卻忽視了要增加相應的維護人力資源，致使系統切換的執行人員保障不到位;再者，當發生災難時，由於決策成員對於容災中心的關注度不夠，無法做出決策;行政組更是形同虛設，諸如人員調配、資訊釋出和公共關係等工作，都只能由技術部門完善。

隱患之二缺乏預警流程：

企業當面對災難時，很難嚴格按照預警流程執行，往往各個部門亂作一團，缺乏響應的預警流程機制，使容災系統無法起到應有的作用。

結合演練工作將預警流程可以分為以下幾個主要步驟：風險上報--風險評估--風險決策--風險告知--發起系統切換。

1、風險上報主要包括風險資訊獲知、收集、上報。風險獲知後，應驗證風險的真實性，完整性。

2、風險評估需要容災團隊根據上報資料做出全面評估，必要時形成評估報告，應包括造成災難的機率、影響程度、發展趨勢等。

3、風險決策需要領導組根據風險評估報告決定後續的處理，包括是否提前啟動切換，進入風險警備狀態。

4、風險告知需要行政管理組將有關風險的資訊及時對內對外發布，保持訊息溝通順暢。

5、系統切換過程是在領導組在做出切換系統的決策後，按照應急預案和相關操作手冊直接進入災難恢復啟動步驟。

隱患之三容災演練流於形式：

企業沒有建立起完善的容災演練機制，容災演練利於形式，沒有形成針對各災難場景行之有效的演練模式。

容災演練不僅要檢驗災難恢復流程的有效性，而且也要驗證容災系統是否能夠實現正常的切換和回切。容災演練的主要步驟應至少包括：制定演練計劃、審批、演練啟動、訊息釋出、演練切換、業務驗證、演練回切、總結等。

在容災演練切換過程中，應詳細記錄各個重要環節的時間點，並分析切換演練是否能夠達到容災系統和生產系統的各項指標。在演練後應及時總結經驗，對發現的問題應及時解決，修改或最佳化演練的應急流程，完善演練應急預案。

隱患之四容災測試不及時：

如果對容災系統的資料、功能、效能等方面沒有充分的測試驗證，就難以保證容災系統實現資料保護和業務接管的功能。

進行測試時，儘可能採用測試指令碼，避免人為誤操作。測試環境儘可能與生產系統隔離。在不發生系統變更時，最好每月測試一次，否則須即時測試。

隱患之五沒有做好容災培訓：

透過容災培訓，可確保相關人員及時準確地瞭解容災系統結構，熟悉測試、演練、災難恢復流程，明確自身職責，使溝通、協作順暢，提高工作技能和災難應對能力。

培訓計劃由執行組與人力資源部門共同制訂和執行。培訓內容主要包括：容災基礎培訓、容災流程培訓、容災技術培訓等。

以上所述的五個方面的隱患，任何一個環節的缺失都可能致使容災中心形同虛設。養兵千日，用兵一時。所以任何一個環節都不能忽視。

其實對於容災本身來講，這是不僅僅是一個技術問題，更是一個考驗組織、管理、流程的重要場合：

容災架構。這是個技術問題，也是個成本問題。我們可以從技術角度將容災架構打的堅實一點，先進一點，避免問題出在技術架構本身上。比如說選擇什麼樣的資料複製架構，什麼樣的網路雙活架構，什麼樣的應用負載架構等等。

容災切換。首先這個容災切換從技術上是否可行?RTO&RPO分別能保障到什麼程度。然後對於切換本身來講是否執行過或者驗證過，驗證的場合和真實的場合有哪些差異，做過哪些差異分析。

切換決策。這是個管理科學和決策科學。容災切換的判定標準，容災切換的流程設定，容災切換的管理體系等直接決定災難判定的準確率及時率，直接決定容災決策和實施之間的時間效率。

很多企業在執行穩定後逐漸縮減運維部門人員，縮減運維資金投入，一種飛鳥盡，良弓藏的感覺，在這種情況下，在勉強開始把容災演練推給IT運維部門，主觀的認為這是IT運維部門的事，缺少整體團隊配合。缺少領導的執行力，最終導致多種問題出現在容災演練中。

4、容災切換演練中的成本分析

典型問題：

關於容災，IT在技術和人員的投入都有哪些?

容災和災備的建立是否都是不可或缺的?資料中心的初期建設重點應放在哪方面?

觀點總結：

建設初期，無論從使用者觀念還是專案團隊來說都是先要把資料中心穩定執行起來。只有吃過虧的運維人員才會這麼重視資料容災和災備，從資金投入上初期也肯定會把重點都放在平穩執行上，但在初期有兩個事情是要重視的：

可以沒有容災，可以沒有災備，但一定不能沒有資料備份。哪怕最基礎的資料備份，系統備份。這個在初期一定要有。

在初期的時候，一定給使用者灌輸資料容災的重要性，讓他知道在資料中心平穩執行後隨著資料中心的重要級別建立相應的容災或者災備。在專案初期的方案設計中，也要提及資料容災的內容。使用者可以不做。但我們不能不說。

對於IDC前期成本的投入：

IDC成長期，穩定遠比容災重要：IDC初期，系統建設、維穩遠比想象中的複雜，很多系統都是經過一段時間的沉澱才能逐漸定型，運維人員也要經過一番折騰才能吃下系統。對於IDC最初起步的五年，時間精力基本全投入在系統成長、服務穩定這個點上。在有限的時間和資源上，很難再考慮容災，即使允許規劃，也僅僅是規劃。

專案資金、資源的侷限：專案規劃得再好，沒錢使之落地也是白搭。IDC初期建設，專案資金和資源基本耗盡，接下來的幾年肯定側重保護業務系統的發展。加之容災備份這塊，很多企業並不視為第一要務，所以在專案資金、資源上也會比較困難。

傳統備份容災已經能滿足IDC當前需求：IDC初建之後，最適合IDC當前保護需求的肯定是傳統的容災備份技術，成本低、方便管理、維護成本低，換句話說最低的成本滿足了預期需求。因此往往很多中小企業在IDC初期都會選擇傳統備份作為容災保障。

企業對於容災中心的態度就並不是過於重視，把容災中心完全的推給運維，而並沒有把有效的資金，人力，執行力持續的投入到容災中心中。導致容災中心雖然建立。建立的初期也一切執行正常。但慢慢的開始投入不足。人員不足。容災中心開始無法與資料中心保持高度的一致和同步。沒有足夠的人員進行運維，巡檢。在突發事件的時候，沒有有效的執行力排程所有部門配合，而更多的是應用部門的抱怨和只能部門的不斷催促，導致容災中心執行多年到真正發揮時間無法正常執行。

容災也好，資料備份也好，我覺得都和買保險一樣。很多企業覺得這個保險的費用太高了。所以更多的時候選擇不買，靠運氣，靠運維。真正讓企業的資訊管理部門重視資料的重要性，才會讓他們下定決心去支援容災中心的建立和制度的完善。

5、容災切換演練中的時間管理

典型問題：

容災切換應急演練一年舉行幾次為宜?

7*24執行的生產系統，選擇什麼時間段切換演練最好?怎樣決策?

觀點總結

總體來說每個系統1-2次為宜，建議在年初統籌制定演練工作計劃，根據維護視窗、重要業務變更日等時間節點，確定好演練次數。

同時，整理好要進行演練的重要系統，根據各系統的高可用建設模式，確定演練的方式，可以先進行桌面和模擬演練，在實戰演練前，務必把每一個時間點的操作爛熟於心。

特別是要進行演練的系統較多時，更要做好統籌安排。比如，網路和系統的演練儘量不要安排在一起，如果因停機視窗等原因實在需要一起演練，一定要演練一套，驗證一套，避免出現問題後，排查困難。

演練的時間段應儘量選擇業務最低谷進行，在做決策時，建議考慮以下幾點：

首先，確定要參加演練的業務系統，制定演練技術方案，若演練會造成停機，要確定其影響範圍，和影響時間。

之後，制定完整的演練進度計劃，對演練要做的每項具體技術工作，作出合理的時間估計，並細化完整的演練時間計劃，並對演練進度進行監控。

最後，要嚴格控制好演練的時間進度，詳細瞭解每個業務系統及其與其他業務系統之間的關聯關係，建議您利用關鍵路徑合理調整每個業務系統的切換順序，保障演練在預定時間內完成，避免造成時間過長的停機。

演練時間管理的細節如下：

選擇業務量少的時期，比如休息日，凌晨1-5點，生產線大型檢修期。

無論什麼時間。在進行演練之前一定要協調好所有部門。保證各個關鍵系統有主要人員駐留，保證一旦某個環節出現問題的時候可以找到人，找到備件，找到技術手冊，找到密碼。甚至找到一個房間的鑰匙。

在演練之前做好應急預案，一切做最好的準備，最壞的打算。應急方案通知給相關所有的部門人員。

要有絕對的領導者對應急預案進行指揮，協調。做到遇到突發事件忙而不亂，各司其職，有序進行。不受外界因素擺佈而打亂整個計劃。

6、容災切換演練中的人力管理

典型問題：

容災應急切換由誰來組織

關於容災，IT在技術和人員的投入都有哪些?

觀點總結：

每個單位的資訊化部門結構都不太相同，有的資訊化部門屬於管理部門。有的資訊化部門屬於服務部門，對於需要協調公司多數業務部門來進行的容災應急切換演練。各個單位都是有那些部門來牽頭組織實施呢。在實施過程中，資訊運維部門又擔當一個什麼角色呢?

麻雀雖小，五臟俱全。容災演練的組織架構應該不斷完善健全。雖然每個單位的組織架構、規模各不相同，但在容災實施過程中，應至少下設如下組織機構，才能在演練切換工作在組織架構和職責分工上得以明確。

領導組來負責決策，下達演練指令給指揮組。人員構成應包括公司領導(CIO)、技術部及風險部門的領導等

指揮組來負責具體的演練工作及整個演練的進度和過程控制。人員構成包括技術部門領導、參演業務部門等。

演練實施組來負責容災環境搭建、應用系統的切換、容災場景制定等。人員構成有技術部門的網路、系統、應用恢復人員。

演練保障組負責各項後勤工作，如資訊釋出、人員調配等。人員可以有行政部門、技術部門、維保廠商等。

演練驗證組來負責對演練切換、回切後的業務驗證。人員由參演業務驗證部門人員構成。

總得來說，組織部門可以是專門的風險合規部門，由他們牽頭;但實施和上報是科技部門的責任;業務部門負責驗證;後勤部門負責後勤;領導把控大局。

容災切換演練中人力管理存在的痛點：

資訊化運維部門，屬於服務部門。缺少管理許可權，上層有資訊化管理部門。但對業務完全不同。一個空頭部門，基本不起作用。在網上的公司管理層對資訊化重視程度不夠。所以我們的業務變更，切換，都是由我們提出報告，實施，但由於缺少管理權，所以以前就有過業務遷移過程中各個應用部門還在不斷催促，詢問什麼時候恢復業務，其實這個在之前就已經下達過通知，但真正執行的時候還是會受到各個部門的影響，有時候甚至為了遷就重要部門或者領導而不得不臨時變更計劃。

各個行業不一樣，即使同一個行業也不盡相同，有的是科技部牽頭，有的是風險管理部，有的是總行組織的，所以切換要看級別，有的就是一個基於科技內部的，有的是演給監管部門看到，有的是演給自己看的。

容災切換演練流程

最後，結合本次活動中會員們提出的精彩觀點，對演練流程做一個全面的梳理：

容災切換演練主要由以下4個階段構成:

階段一演練：演練前期準備

前期準備主要有如下具體工作：

1、演練方案的提交與釋出：首先演練專案組要根據本次容災演練系統 的自身特性，結合硬體資源和容災中心現狀，制定容災演練方式和技術實現手段，透過與容災演練應用系統的應用開發商進行訪談溝通，確認容災演練應用系統對應的容災場景和技術實現手段，做出詳細的演練方案。包括儲存系統的切換，應用系統的切換，網路系統及防火牆的切換。

2、演練專案組組織召開方案評審會：請容災演練領導和專家、容災中心領導和專家就容災演練方案進行綜合評審，最終確定容災演練方案。

3、業務驗證案例準備：演練專案組要督促本次進行演練的業務部門進行業務驗證案例的準備，並和業務專家一起綜合評審，最終確定業務驗證案例方案。

4、演練專案組要組織相關人員進行人員聯絡表、分時計劃、人員簽到表、演練記錄表等表的編寫和更新，上報本次參演部門及參演人員給演練領導組並得到批准。

階段二演練前的準備工作

這個階段主要進行當日正式演練開始前的準備工作。當時在較早時間要發“演練通知提醒”，提醒當時參加演練的相關人員進行演練前的準備及準時到崗。演練專案組通知本次演練的系統小組進行應用系統的檢查，網路小組進行網路的檢查，保證演練正式幵始能進行切換。並將檢查結果上報演練指揮組。如果出現檢查不透過情況，由演練指揮組請求演練領導組決定是否進行這次演練。

階段三演練執行

1、系統切換操作

這一階段為正式演練的開始。當進入正式演練的幵始時間，演練指揮組將發出“演練開始”命令。整個演練將按照“演練計劃方案”進行。進行系統的 切換和網路的切換。

2、測試驗證

首先由系統組進行各系統的測試驗證，業務部門依據容災演練方案中由應用開發商提供的容災演練應用系統的業務測試場景和詳細測試步驟進行容災演練應用驗證，認真仔細核對業務測試場景得出的結果與測試指令碼在生產系統中測試查詢結果是否一致，如果結果一致，容災演練業務場景成功結束，如果不一致需要找出問題的原因，重新進行容災演練。此階段的結果決定此 次演練的成功與失敗。

3、系統回切恢復

此階段進行演練恢復階段。進入此階段，不管之前演練的成功與失敗，為保證不影響第二業務的正常運轉。都必須進行業務系統的恢復。系統組和網路組進行系統恢復。

4、回切後業務驗證

系統組和網路組進行系統恢復後，業務部門還要進行業務驗證。保證生產系統的正常運轉。

階段四演練總結

容災演練結束後，召開容災演練總結會，容災專案組和容災演練參與人員要就整個演練過程中出現的問題進行總結，針對每個問題都要找到是什麼原因引起來的，應該如何解決和避免同樣的問題再次出現，彙總問題列表並 提出改進建議和方法。至此整個容災演練圓滿結束。