歡迎關注原創公衆号：
容災（Disaster Tolerance）：就是在上述的災難發生時，在保證生産系統的資料盡量少丢失的情況下，保持生存系統的業務不間斷地運作。
容錯（Fault Tolerance）：指在計算機系統的軟體、硬體發生故障時，保證計算機系統中仍能工作的能力。
差別：容錯可以通過硬體備援、錯誤檢查和熱交換再加上特殊的軟體來實作，而容災必須通過系統備援、災難檢測和系統遷移等技術來實作。當裝置故障不能通過容錯機制解決而導緻系統當機時，這種故障的解決就屬于容災的範疇。
什麼是災難恢複（Disaster Recovery）：指的是在災難發生後，将系統恢複到正常運作的能力。
差別：容災強調的是在災難發生時，保證系統業務持續不間斷地運作的能力，而災難恢複強調的災難之後，系統的恢複能力。現在的容災系統都包含着災難恢複的功能，是以本文的讨論除了包括容災方面的内容，還包括了災難恢複的部分内容。
x.1 BCM、RPO、RTO與災備等級
災備及應急管理體系的建設首先需要明确一個概念兩個名額，即業務連續性管理BCM以及恢複點目标（RPO）和恢複時間目标（RTO）。
● BCM
業務連續性管理（Business Continuity Management，簡稱BCM），是一項綜合管理流程，它使企業認識到潛在的危機和相關影響，制訂響應、業務和連續性的恢複計劃，其總體目标是為了提高企業的風險防範能力，以有效地響應非計劃的業務破壞并降低不良影響。業務連續性管理(BCM)是每一個希望基業長青企業都需要考慮的戰略問題。企業的核心系統已成為生産工具和核心資産，特别是核心系統中斷以及資料問題對企業的影響愈發嚴重，故其應該納入BCM管理範疇。BCM聚焦三個關鍵點：業務、連續性以及管理，即通過一些列度的管理方式、技術工具、流程制度等保障業務連續不中斷。從實際上來說，包括應用系統及資料層面的不中斷和業務層面的不中斷，其二者的差別在于系統及資料層面的不中斷是為業務不中斷進行服務的，側重于技術側，如應用級别的災備、資料級别的災備等，業務層面的不中斷還包括業務側的備份應急措施。同時業務關鍵點傾向于價值較高的業務活動，而非所有，這也是降低成本，提高TCO的必要措施。
BCM涉及的整體工作範圍應包括：
圖：業務連續性管理
（1）基于CMDB分類分級中高價值的業務系統及資料（實際上“價值”也是CMDB分類分級的重要依據）；
（2）BCM聚焦于重大性、緊急突發性以影響全局性的事件，同時基于是事件的不同等級和屬性，确定啟動時間及方案；
（3）BCM包括事前、事中、事後三個階段涵蓋事件（災難性時間）管理的全生命周期的PDCA閉環管理。事前側重于風險識别、風險控制、災備方案制定及實施、災備流程機制制定、組織架構、教育訓練以及應急演練等；事中包括災備處理流程機制、業務恢複方案實時以及請示彙報等；事後包括的UI災備應急處理的流程制度、處理方案以及組織機制等進行複盤分析，優化現有機制，提高同類問題的處理效率和成功率。
| 可能性中高 | 可能性中低 | 基本不可能 |
| 恐怖事件（炸彈威脅，爆炸，挾持人員等） | 氣候災難（暴風雪，嚴寒等） | 核戰/戰争 |
| 建築物倒塌 | 城市事件（罷工，動亂等） | |
| 人為過失/故意破壞（對公司不滿的員工，外部黑客，計算機病毒等） | 工作場所的環境緊急事件（化學污染等） | |
| 氣候災難（台風，洪水等） | 地震 | |
| 裝置/硬體/系統故障 | 流行疾病 | |
| 業務應用軟體故障 | 社會性恐慌 | |
| 火災 | ||
| 基礎設施故障（網絡，通信，電力，空調，通風等） |
| 災難種類 | 影響損失 | 影響範圍 | 可能的業務中斷或業務損失 | 抵禦的方法 |
| 地震 | 高 | 高 | 資料中心全部業務中斷，資料大量丢失 | 異地災備站點 |
| 火災 | 高 | 中 | 資料中心業務中斷 | 遠端災備站點備份應用系統和備援網絡接入 |
| 停電 | 中 | 中 | 資料中心業務中斷 | 備援電源供應（UPS或者多電源接入） |
| 資料庫崩潰 | 低 | 低 | 資料中心業務中斷 | 資料庫鏡像技術，或者資料庫備份中取回資料 |
| 部分硬體故障 | 中 | 低 | 資料中心部分業務中斷 | 增加硬體備援度，使用叢集技術和資料複制技術等等 |
| …… | …… | …… | …… | …… |
圖：BCMS核心架構
ISO22301 BCMS的核心架構（圖1）是一個雙循環結構，外循環用于建立、實施和運作、監視和評審、保持和改進一個特定的管理體系，内循環則用于建立、實施、運作、監視、評審、保持和改進業務連續性。這兩個循環結構，外循環是面向管理體系的；内循環是為了得到業務連續性能力，之是以把業務連續性管理（BCM，即内循環涉及的管理過程）外面套上一個管理體系，是為了讓管理業務連續性的工作可控、可評估和可持續改進。
綜上所述，業務連續性是一種組織能力，業務連續性管理（BCM）是實施和保持業務連續性的一整套管理過程，業務連續性管理體系（BCMS）是用于管理(即建立、實施和運作、監視和評審、保持和改進)業務連續性的一個特定的管理體系；換言之，業務連續性管理（BCM）和業務連續性管理體系（BCMS）都是用于管理業務連續性的方法。
（4）BCM平台統合災備及應急體系的全流程、全周期的管理，包括組織機制及權限管控、災備項目管理及實施跟進、災備響應機制、應急處理方案等，同時監控平台也屬于BCM平台的一部分，已達到提前發現、主動識别災備事件的目的，進而提高問題處理的效率和準确率。
● RPO與RTO
衡量一個災備系統建設優秀與否，或是否符合等級保護要求的兩大關鍵名額是恢複時間目标（RTO）、恢複點目标（RPO）。恢複時間目标（RTO）∶Recovery Time Objective，即恢複時間目标，指的是使用者業務系統所能容忍的業務停止服務的最長時間；恢複點目标（RPO）∶Recovery Point Objective，即資料恢複點目标，指的是業務系統所能容忍的資料丢失量。
圖：RPO與RTO時間
恢複時間目标（RTO）指當業務發生中斷後，從業務發生中斷時開始，到将業務恢複到正常所需要的時間，此兩點之間的時間段稱為RTO。如業務在下午15點的時候發生故障，啟動災備處理措施，業務在18點恢複至可接受的級别，那麼這之間的3小時則為RTO實際發生事件，實際上如果規定RTO的時間為2小時，則應在17點的時候恢複業務。RTO是反映業務恢複的及時性名額，表示業務從中斷到恢複正常所需的時間，RTO數值越小，代表容災系統的恢複能力越強。可以部署多站點容災方案等等來擷取最小的RTO，越小的RTO可能意味着容災方案可能需要投入越多的資金。
RPO恢複點目标是指可接受的資料丢失的最大資料量，也就是容忍丢失的最大資料量。RPO表示為從丢失事件到最近一次備份的時間度量。以備份為例，一般備份都是一天做一次，通常是在淩晨業務空閑期，例如淩晨2點做了備份，如果白天出現系統故障或資料錯誤且無法修複，那從備份完成後到錯誤出現時所寫入的資料都無法挽回了，這期間沒有備份，資料就丢失了，一天備份這種情況下RPO就是24小時，實際上上述淩晨2點備份，如果10點出現故障，則實際RPO時間為8小時。如每天20點備份資料，在第二天20點前發現資料異常且無法修複，隻能恢複前一天20點的備份資料，RPO就是24小時。如果定義了RPO為5小時，我們原則上則需要每5小時要進行一次備份。同時為了減少RPO，一味的增加備份的頻率是不現實的，同時也是不可靠的（影響系統及資料本身的性能），需要根據業務實際的情況，結合相應的同步/異步/備份等技術，制定适合業務實際的方案。
RTO和RPO名額并不是孤立的，而是從不同角度來反映的容災能力。RPO名額來自于故障發生前，而RTO名額來自故障發生後，兩者的數值越小，就能有效縮短業務正常到業務過渡期的時間間隔，單一地提升RTO或RPO名額也可以縮減業務故障到過渡期的時間，具體從哪個名額上來改善，就要結合的實際情況分析，提升那個名額代價最小，效果更明顯。當然完美的方案當然是RTO和RPO都為零，這表示當故障發生後，系統立即恢複，而且完全沒有資料丢失，要達到這樣的目标系統設計是及其複雜的，而且造價也是非常昂貴的，也不一定有這個必要。企業通常根據當業務不可用時對業務的實際影響（即前文所述的“價值”）來定義可接受的RTO和RPO,然後資訊部門（一般需要聯合業務部門一起）根據RTO、RPO的要求設計災難恢複方案，在規劃時同時要考慮方案的實作成本。可用性越高，RTO、RPO的值越低，可能實作成本就越高。
● 災備等級
關于災備等級的劃分，可以參考兩個标準，一個是國際标準Share 78,另一個是國家标準《資訊系統災難恢複規範》
Share78 容災國際标準（也稱SHARE 78 定義的七級業務恢複級别）分級原則：
（1）備份/恢複的範圍
（2）災難恢複計劃的狀态
（3）應用地點與備份地點之間的距離
（4）應用地點與備份地點如何互相連接配接
（5）資料是怎樣在兩個地點之間傳送的
（6）允許有多少資料丢失
（7）怎樣保證備份地點資料的更新
（8）備份地點可以開始備份工作的能力
根據上述8條原則，國際标準Share 78對容災系統的定義有七個層次：從最簡單的僅在本地進行錄音帶備份，到将備份的錄音帶存儲在異地，再到建立應用系統實時切換的異地備份系統，恢複時間也可以從幾天到小時級到分鐘級、秒級或零資料丢失等。目前針對這七個層次，都有相應的容災方案，是以，使用者在選擇容災方案時應重點區分它們各自的特點和适用範圍，結合自己對容災系統的要求判斷選擇哪個層次的方案。
| Share78 | |
| 災備等級 | 具體内容 |
| Tier 0 無異地備份 (No off-site Data) | 0等級容災方案資料僅在本地進行備份，無異地備份資料，無災難恢複計劃。該方式是成本最低，但不具備真正災難恢複能力。 |
| Tier 1 實作異地備份 -PTAM 卡車運送通路方式 (Pickup Truck Access Method) | 第1級容災方案是将關鍵資料備份到本地錄音帶媒體上，然後送往異地儲存，但異地沒有可用的備份中心、備份資料處理系統和備份網絡通信系統，未制定災難恢複計劃。災難發生後，使用新的主機，利用異地資料備份媒體（錄音帶）将資料恢複起來。 |
| Tier 2 熱備份站點備份-PTAM 卡車運送通路方式+熱備份中心 (PTAM + Hot中心) | 第2級容災方案是将關鍵資料進行備份并存放到異地，制定有相應災難恢複計劃，具有熱備份能力的站點災難恢複。一旦發生災難，利用熱備份主機系統将資料恢複。它與第1級容災方案的差別在于異地有一個熱備份站點，該站點有主機系統，平時利用異地的備份管理軟體将運送到異地的資料備份媒體上的資料備份到主機系統。當災難發生時可以快速接管應用，恢複生産。 由于有了熱備中心，投資會增加，相應的管理人員要增加。技術實作簡單，利用異地的熱備份系統，可以在本地發生毀滅性災難後，快速進行業務恢複。但這種容災方案由于備份媒體是采用交通運輸方式送往異地，異地熱備中心儲存的資料是上一次備份的資料，可能會有幾天甚至幾周的資料丢失。這對于關鍵資料的容災是不能容忍的。 |
| Tier 3 線上資料恢複 -電子連結 (Electronic Vaulting) | 第3級容災方案是通過網絡将關鍵資料進行備份并存放至異地，制定有相應災難恢複計劃，有備份中心，并配備部分資料處理系統及網絡通信系統。該等級方案特點是用電子資料傳輸取代交通工具傳輸備份資料，進而提高了災難恢複的速度。利用異地的備份管理軟體将通過網絡傳送到異地的資料備份到主機系統。一旦災難發生，需要的關鍵資料通過網絡可迅速恢複，通過網絡切換，關鍵應用恢複時間可降低到一天或小時級。這一等級方案由于備份站點要保持持續運作，對網絡的要求較高，是以成本相應有所增加。 |
| Tier 4 定時資料備份-活動狀态的備份中心 (Active Secondary中心) | 第4級容災方案是在第3級容災方案的基礎上，利用備份管理軟體自動通過通信網絡将部分關鍵資料定時備份至異地，并制定相應的災難恢複計劃。一旦災難發生，利用備份中心已有資源及異地備份資料恢複關鍵業務系統運作。這一等級方案特點是備份資料是采用自動化的備份管理軟體備份到異地，異地熱備中心儲存的資料是定時備份的資料，根據備份政策的不同，資料的丢失與恢複時間達到天或小時級。由于對備份管理軟體裝置和網絡裝置的要求較高，是以投入成本也會增加。但由于該級别備份的特點，業務恢複時間和資料的丢失量還不能滿足關鍵行業對關鍵資料容災的要求。 |
| Tier 5 實時資料備份-Two-Site Two-Phase Commit | 第5級容災方案在前面幾個級别的基礎上使用了硬體的鏡像技術和軟體的資料複制技術，也就是說，可以實作在應用站點與備份站點的資料都被更新。資料在兩個站點之間互相鏡像，由遠端異步送出來同步，因為關鍵應用使用了雙重線上存儲，是以在災難發生時，僅僅很小部分的資料被丢失，恢複的時間被降低到了分鐘級或秒級。由于對存儲系統和資料複制軟體的要求較高，所需成本也大大增加。 這一等級的方案由于既能保證不影響目前交易的進行，又能實時複制交易産生的資料到異地，是以這一層次的方案是目前應用最廣泛的一類，正因為如此，許多廠商都有基于自己産品的容災解決方案。如存儲廠商EMC等推出的基于智能存儲伺服器的資料遠端拷貝；系統複制軟體提供商VERITAS等提供的基于系統軟體的資料遠端複制；資料庫廠商Oracle和Sybase提供的資料庫複制方案等。但這些方案有一個不足之處就是異地的備份資料是處于備用（Standby）備份狀态而不是實時可用的資料，這樣災難發生後需要一定時間來進行業務恢複。更為理想的應該是備份站點不僅僅是一個分離的備份系統，而且還處于活動狀态，能夠提供生産應用服務，是以可以提供快速的業務接管，而備份資料則可以雙向傳輸，資料的丢失與恢複時間達到分鐘甚至秒級。據了解，目前DSG公司的RealSync全局複制軟體能夠提供這一功能。 |
| Tier 6 零資料丢失 (Zero Data Loss) | 第6級容災方案是災難恢複中最昂貴的方式，也是速度最快的恢複方式，它是災難恢複的最進階别，利用專用的存儲網絡将關鍵資料同步鏡像至備份中心，資料不僅在本地進行确認，而且需要在異地（備份）進行确認。因為，資料是鏡像地寫到兩個站點，是以災難發生時異地容災系統保留了全部的資料，實作零資料丢失。這一方案在本地和遠端的所有資料被更新的同時，利用了雙重線上存儲和完全的網絡切換能力，不僅保證資料的完全一緻性，而且存儲和網絡等環境具備了應用的自動切換能力。一旦發生災難，備份站點不僅有全部的資料，而且應用可以自動接管，實作零資料丢失的備份。通常在這兩個系統中的光纖裝置連接配接中還提供備援通道，以備工作通道出現故障時及時接替工作，當然由于對存儲系統和存儲系統專用網絡的要求很高，使用者的投資巨大。采取這種容災方式的使用者主要是資金實力較為雄厚的大型企業和電信級企業。但在實際應用過程中，由于完全同步的方式對生産系統的運作效率會産生很大影響，是以适用于生産交易較少或非實時交易的關鍵資料系統，目前采用該級别容災方案的使用者還很少。 |
表：Share78災備等級
實際上對于國内大部分國企事業機關以及大中型國企，多參考國家标準《資訊系統災難恢複規範》
| 《資訊系統災難恢複規範》 (GBT20988-2007) | ||||||
| 等級 | 第1級 | 第2級 | 第3級 | 第4級 | 第5級 | 第6級 |
| 基本支援 | 備用場地支援 | 電子傳輸和部分裝置支援 | 電子傳輸及完整裝置支援 | 實時資料傳輸及完整裝置支援 | 資料零丢失和遠端叢集支援 | |
| 資料備份系統 | a) 完全資料備份至少每周一次； b) 備份媒體場外存放。 | a) 完全資料備份至少每周一次； b) 備份媒體場外存放。 | a) 完全資料備份至少每天一次； b) 備份媒體場外存放； c) 每天多次利用通信網絡将關鍵資料定時批量傳送至備 用場地。 | a) 完全資料備份至少每天一次； b) 備份媒體場外存放； c) 每天多次利用通信網絡将關鍵資料定時批量傳送至備用 場地。 | a) 完全資料備份至少每天一次； b) 備份媒體場外存放； c) 采用遠端資料複制技術，并利用通信網絡将關鍵資料實 時複制到備用場地。 | a) 完全資料備份至少每天一次； b) 備份媒體場外存放； c) 遠端實時備份，實作資料零丢失。 |
| 備用資料處理系統 | — | 配備災難恢複所需的部分資料處理裝置，或災難發生後能在 預定時間内調配所需的資料處理裝置到備用場地。 | 配備災難恢複所需的部分資料處理裝置。 | 配備災難恢複所需的全部資料處理裝置，并處于就緒狀态或 運作狀态。 | 配備災難恢複所需的全部資料處理裝置，并處于就緒或運作 狀态。 | a) 備用資料處理系統具備與生産資料處理系統一緻的處理 能力并完全相容； b) 應用軟體是“叢集的”，可實時無縫切換； c) 具備遠端叢集系統的實時監控和自動切換能力。 |
| 備用網絡系統 | — | 配備部分通信線路和相應的網絡裝置，或災難發生後能在預 定時間内調配所需的通信線路和網絡裝置到備用場地。 | 配備部分通信線路和相應的網絡裝置。 | a) 配備災難恢複所需的通信線路； b) 配備災難恢複所需的網絡裝置，并處于就緒狀态。 | a) 配備災難恢複所需的通信線路； b) 配備災難恢複所需的網絡裝置，并處于就緒狀态； c) 具備通信網絡自動或集中切換能力。 | a) 配備與主系統相同等級的通信線路和網絡裝置； b) 備用網絡處于運作狀态； c) 最終使用者可通過網絡同時接入主、備中心。 |
| 備用基礎設施 | 有符合媒體存放條件的場地 | a) 有符合媒體存放條件的場地； b) 有滿足資訊系統和關鍵業務功能恢複運作要求的場地 | a) 有符合媒體存放條件的場地； b) 有滿足資訊系統和關鍵業務功能恢複運作要求的場地。 | a) 有符合媒體存放條件的場地； b) 有符合備用資料處理系統和備用網絡裝置運作要求的場 地； c) 有滿足關鍵業務功能恢複運作要求的場地； d) 以上場地應保持 7x24 小時運作。 | a) 有符合媒體存放條件的場地； b) 有符合備用資料處理系統和備用網絡裝置運作要求的場 地； c) 有滿足關鍵業務功能恢複運作要求的場地； a) 以上場地應保持 7x24 小時運作。 | a) 有符合媒體存放條件的場地； b) 有符合備用資料處理系統和備用網絡裝置運作要求的場 地； c) 有滿足關鍵業務功能恢複運作要求的場地； d) 以上場地應保持 7x24 小時運作。 |
| 專業技術支援能力 | — | — | 在災難備份中心有專職的計算機機房運作管理人員。 | 在災難備份中心有： a) 7x24 小時專職計算機機房管理人員； b) 專職資料備份技術支援人員； c) 專職硬體、網絡技術支援人員。 | 在災難備份中心7x24小時有專職的： a) 計算機機房管理人員； b) 資料備份技術支援人員； c) 硬體、網絡技術支援人員。 | 在災難備份中心7x24小時有專職的： a) 計算機機房管理人員； b) 專職資料備份技術支援人員； c) 專職硬體、網絡技術支援人員； d) 專職作業系統、資料庫和應用軟體技術支援人員。 |
| 運作維護管理能力 | a) 有媒體存取、驗證和轉儲管理制度； b) 按媒體特性對備份資料進行定期的有效性驗證。 | a) 有媒體存取、驗證和轉儲管理制度； b) 按媒體特性對備份資料進行定期的有效性驗證； c) 有備用站點管理制度； d) 與相關廠商有符合災難恢複時間要求的緊急供貨協定； e) 與相關營運商有符合災難恢複時間要求的備用通信線 路協定。 | a) 按媒體特性對備份資料進行定期的有效性驗證； b) 有媒體存取、驗證和轉儲管理制度； c) 有備用計算機機房管理制度； d) 有備用資料處理裝置硬體維護管理制度； e) 有電子傳輸資料備份系統運作管理制度。 | a) 有媒體存取、驗證和轉儲管理制度； b) 按媒體特性對備份資料進行定期的有效性驗證； c) 有備用計算機機房運作管理制度； d) 有硬體和網絡運作管理制度； e) 有電子傳輸資料備份系統運作管理制度。 | a) 有媒體存取、驗證和轉儲管理制度； b) 按媒體特性對備份資料進行定期的有效性驗證； c) 有備用計算機機房運作管理制度； d) 有硬體和網絡運作管理制度； e) 有實時資料備份系統運作管理制度。 | a) 有媒體存取、驗證和轉儲管理制度； b) 按媒體特性對備份資料進行定期的有效性驗證； c) 有備用計算機機房運作管理制度； d) 有硬體和網絡運作管理制度； e) 有實時資料備份系統運作管理制度； f) 有作業系統、資料庫和應用軟體運作管理制度。 |
| 災難恢複預案 | 有相應的經過完整測試和演練的災難恢複預案 | 有相應的經過完整測試和演練的災難恢複預案。 | 有相應的經過完整測試和演練的災難恢複預案。 | 有相應的經過完整測試和演練的災難恢複預案。 | 有相應的經過完整測試和演練的災難恢複預案。 | 有相應的經過完整測試和演練的災難恢複預案。 |
| RTO(某企業) | 2天以上 | 24小時以上 | 12小時以上 | 數小時至2天 | 數分鐘至2天 | 數分鐘 |
| RPO(某企業) | 1天至7天 | 1天至7天 | 數小時至1天 | 數小時至1天 | 0至30分鐘 | 0 |
表：GBT20988-2007災備等級
容災分類分級通用的劃分方式還有如下：資料級、應用級和業務級。不同級别的容災，實作的方案和達成的效果各不相同。資料級，是最底級，要保證資料副本可用，應用級主要是在應用程式層實作高可用，業務級需要通過通路接入控制等實作多活。
（1）資料級說明
資料級容災在容災的級别中，屬于最基礎層，一般通過建立一個異地容災資料中心，使用各類備份技術，将主資料中心的資料進行遠端備份，備份至災備資料中心中。在資料級的備份有多種方式，如通過儲存設備本身的遠端存儲複制功能，以及最基本的正常網絡備份功能。在資料級容災的級别下，單資料中心在災難發生之後，其他資料中心的資料不會丢失或者遭到破壞，能夠繼續使用。資料級容災實作的備份内容僅是檔案，由于隻考慮到了資料，是以這種方式費用比較低，建構實施相對簡單。但是資料級容災，有一定的缺陷，就是災難發生時，應用還是會中斷，業務通路使用會受影響，實際上資料級的容災就是簡單的遠端的資料備份中心，不具備應用熱備份和應用高可用的功能，這個時候出現災難性問題就需要重新建構應用，是以資料級容災的恢複時間比較長。
（2）應用級說明
應用級容災是在資料級容災的基礎之上的，想要實作應用級容災，必須依靠資料級容災。所謂應用級容災，就是要實作應用系統的高可用，既然是高可用，就需要有多套一樣業務系統，互相協同進行對外提供服務，達成這樣的效果話，就需要在災備資料中心建立一套與主資料中心完全相同的應用系統。在存在多套相同系統的前提下，依靠資料級容災實作資料的同步，同步方式有同步和異步兩種方式，需要根據系統的實際情況進行設定。通常通過檔案系統層面的資料同步程式實作遠端複制，還有就是通過跨資料中心建立存儲叢集的副本卷，通過政策，保障不同副本卷資料落盤在不同的資料中心中，來配合應用實作容災效果。這樣可以保證關鍵應用在允許的時間範圍内恢複運作，盡可能減少災難帶來的損失，省去了應用重建的時間，讓使用者基本感受不到災難的發生。應用級容災簡單來說就是建立一個應用的備份系統，相比資料級容災，它提供的服務是完整、可靠、安全的，確定了業務的連續性。但是在投入上需要的費用較高，需要更多的軟體來實作，并且需要時時刻刻在災備資料中心做好業務切換的準備。
（3）業務級說明
業務級容災是全業務的災備，它的前提是資料容災和應用容災，需要在這兩者的基礎上投入更多的硬體基礎設施來實作。相比應用容災，業務容災需要保障在出現某機房故障的時候，使用者可以無感覺。是以需要保障業務的連續性，即應用實作雙活或者多活，并且實作使用者接入的高可用，接入高可用一般情況下通過智能DNS和負載均衡裝置等實作，以實作智能檢測和通路排程功能。業務級容災完全保障了業務通路的連續性，但是費用很高，包括了軟體、硬體、網際網路線路等，還需要場所費用的投入，實施難度大。
圖：災備等級RTO與TCO關系
x.2 災備管理體系
災備管理體系的建設以運維基礎資料CMDB為基礎、按照分類分級思想建設不同等級應用系統及資料的災備，主要内容包括：災備技術方案、災備分級建設以及恢複評價等内容。
災備管理體系的建設要基于企業應用系統及資料的規模、重要性和架構，同時兼顧投入的經濟成本和人力成本，確定所建設的企業災備方案和體系在保障應用系統及資料穩定、安全的前提下，實作最佳投入産出比，實作經濟效益的最大化。整個災備體系方案設計圍繞運維CMDB為基礎，結合業務需求和系統屬性，明确災備對象、界定災備建設的範圍，同時依助技術架構、管理機制群組織保障完善災備體系化建設，在確定安全、穩定的前提下實作災備建設的最佳投入産出比。
圖：災備建設體系
x.2.1 災備技術方案
（1）基礎設施災備
從基礎設施層面，災備建設方式有經典的兩地三中心、多活資料中心和雲災備等幾種形式：兩地三中心的架構為公司所在地同城自建或是租賃兩個資料中心機房，這兩個機房之間以光纖打通，應用系統、檔案及資料以實時同步的方式實作兩個機房的實時熱備、同城雙活中心，同時在另一個300公裡外的城市租賃或是自建機房，作為雙活中心的異地災備中心。異地機房跟同城的兩個機房多采用延遲同步或是手動同步的方式存儲IT系統、檔案和資料等。一般異地機房是用作同城機房的系統冷備和備份集存儲，原則上不與同城資料中心的資料實時同步，甚至每次同步采用主動模式，先建立連接配接、進行同步、完成後斷開連接配接的方式，其目的在于避免同城機房資料、檔案被删除、篡改、惡意加密或中勒索病毒等情況的發生導緻異地機房實時同步資料也不可用的情況。異地災備中心比較經濟的方案是在異地租賃IDC機房及伺服器，存儲同城機房的備份集和核心系統的冷備。另外根據公司資料的保密程度有選擇的采用雲端伺服器進行備份集存儲或是系統冷熱備。
多活資料中心為在雙活中心基礎上的擴充，通過網絡專線的方式根據公司業務分布情況選擇主幹城市作為中心節點建設或租賃資料中心，并且與主機房進行二層網絡打通實作應用系統及資料的實時多向同步，借助GSLB全局負載均衡技術，為公司系統使用者提供就近區域方案、最佳營運商鍊路接入的方式，提高使用者體驗的同時，最大化規避單點故障的産生。多活資料中心作用于大型集團企業的核心業務系統，建設成本較高，特别是存儲級别的實時同步，對網絡帶寬延遲要求高、網絡投入大，另外設計3中心及以上應用、系統層面高可用實作較為複雜，有的情況需要業務系統進行改造以支援分布式事務的處理。多活資料中心解決了單點故障，但是不能解決勒索、資料删除、篡改等問題，故延遲狀态下災備中心仍需要進行設定。
雲災備借助于雲平台資源池和雲下、雲上網絡互通，實作應用系統及資料的高可用部署和備份存儲，是目前經濟價值較高的一種災備方式，借助于雲平台的快速便捷性可以快速建構起企業災備中心，同時即需即供的雲模式省去線下資料中心的建設、上架調試環節，實施難度和複雜度也大大降低。但是雲災備多基于應用和資料層面，存儲級别的災備造價較高（專線及1:1的存儲），需要采用雲平台獨占模式，其難以充分發揮雲平台的優勢。
綜合考慮，針對大中型的集團公司，基于兩地三中心+雲災備的模式相對比較适合，雲災備中心與災備中心同為異地災備，但基于雲的高效便利性，建議雲災備中心與雙活資料中心建立單向或雙向實時同步的方式，最大化提高雲災備中心的使用率。災備中心的建設則原則上以延遲備份為主，同時建議災備中心在儲存備份集合的時候拉起最近一次的備份以節省備份恢複時間和恢複效率。
營運商介入方面遵循三網接入、負載均衡的機制，規避單一營運商的問題，同時提高不同營運商的最佳網絡線路，提高通路性能。
（2）硬體高可用及備件
雙活資料中心或主資料中心在硬體設計及實施上采用高可用或主備設計，具體表現在網絡層面的雙核心雙鍊路架構、存儲層面的存儲雙活或主備同步以及網絡安全裝置在整個網絡鍊路上的旁路設計。
基于硬體設施裝置的備件管理是在災備管理的另一個重點，包括備份核心交換機、實體服務、邊界防火牆等整體備機以及光子產品、硬碟、主機闆、CPU、交換機背闆等元器件内容。備件管理既不能出現大量的硬體過剩導緻資源使用率低又不能過于緊張導緻難以應對突發情況，是以基于備件資産管理要從備件類型、備件梳理、生産使用時長等多個次元綜合考慮，一般可建議如下：
1-3年的硬體裝置相關備件保留1-3件即可，如1-3年的核心交換機，可保留1塊闆卡備用，1-3年的實體機可保留2個CPU、3塊硬碟等。數量上略微備援，在滿足一次故障處理的同時，仍有少了可在使用即可；3-5年的硬體裝置相關備件保留5件左右；5年以上的硬體裝置應該建立退出生産機制，如果仍持續使用，應有可随時替換的備機，備機包括同等或高于目前配置，并且相關政策預配置好。
由于備份集在生成、傳輸和存儲過程中具有占用較大的帶寬及存儲、且使用頻率低等特點，為不影響生産系統的正常使用，強烈建議設定專用的備份網絡及備份存儲。規劃專有網絡鍊路用于備份傳輸，在作業系統層面指定專用網卡用作備份或資料同步用。備份存儲方面采用不同性能規格的存儲按照備份集時間遠近、資料冷熱進行存儲，近期、重要的備份集存儲在高性能的存儲媒體中，歸檔備份集存儲在NAS或錄音帶庫中，基于生産系統及資料量進行壓縮後計算備份存儲容量，提前做好備份容量規劃，整體上以求達到投産最佳比。
（3）應用及資料高可用與備份
基于兩地三中心和雲災備中心的基礎設施設計，應用系統及資料采用分布式高可用架構部署，實作應用級資料層面的多中心同步。高可用的架構分為叢集和主備兩種方式：叢集中的各個節點均對外提供服務，提高了系統整體的吞吐量可實作更高的并發；主備模式為主節點對外提供服務、備節點作為主節點的備用，處于備用狀态，主備模式未能實作吞吐和并發的翻倍擴容，但是可實作讀寫分離的功能，也是常用的高可用方案之一。叢集或主備節點在部署時，應選擇同一資料中心不同機櫃、不同資料中心的方式部署。
相比存儲級别的資料同步，應用系統及資料的高可用架構可以更加靈活、更細粒度的實作災備需求，且應用系統和資料層面的高可用可以為性能帶來提升，便于彈性伸縮。但存儲級别的資料同步架構相對簡單，控制粒度粗，隻需要關注存儲層面資料塊同步即可，上層應用則依賴虛拟化層面的HA對網絡專線依賴很高，而應用系統及資料的高可用則涉及内容較多，技術管理上存在一定的複雜度。
以應用、資料庫和檔案的高可用介紹，具體如下：
應用、資料庫和檔案總體來說采用叢集或是主備方式部署，避免單點故障。另外負載均衡和反向代理的使用也可以減輕單節點的通路壓力和提高内網伺服器的安全。
● 應用高可用
很多企業可能直接把應用伺服器如tomcat，weblogic等直接映射到外網ip,這樣如果需要部署多台的話，需要做多個公網ip的映射，并且難以實作通路的負載均衡，由于出現故障需要手動切換，故不能算是實作了高可用。
采用反向代理伺服器的方式如nginx,haproxy既可以實作反向代理，也可以實作負載均衡，并且可以節省公司的公網IP資源。每一組應用至少部署兩台不同的虛拟機上，避免應用的單點故障。資源比較緊張的情況下，可以實作交叉部署，例如應用A1和應用A2部署在虛拟機VM1和VM2上，應用B2和應用B1也部署在與A1，A2相同的虛拟機上，統一虛拟機多應用，每個應用又在其他虛拟機有部署，避免單點故障還節省資源。但是要注意，一般業務量比較均衡的不同應用可以交叉部署，業務量比較大且核心系統還是要分開部署的。
● 資料庫高可用
不管是Oracle還是Mysql或是Sqlserver都有較多且已在不同公司的生産正常運作的高可用和叢集方案，這裡簡單介紹一下Oracle、Mysql和Redis。
Oracle高可用
Oracle比較常見的高可用方案主要是RAC+DG。其中RAC可以實作負載均衡和單點故障。一般部署方式RAC的兩個節點挂載同一存儲，存儲方面存在單點故障的可能。由于RAC主要是做負載均衡，不太好實作讀寫分離。可以采用搭建RAC的DataGuard實作RAC的資料實時同步到standby資料庫中。另外standby可以對外提供隻讀操作，實作讀寫分離，減少主庫RAC的壓力。另外OGG即Oracle GoldenGate是Oracle做資料同步的另一主要解決方案。OGG也可以實作異構跨平台的資料同步。
Mysql高可用
Mysql的高可用方案也比較多，比較常見的有主從複制，MHA，MMM等。另外不同的Mysql廠商也提供了不同的基于Mysql的叢集Cluster方案且都有生産實施案例，如GaleraCluster、Percona的PXC和MySQL官方的Cluster等都可以實作mysql的高可用叢集和讀寫分離。另外mysql也有衆多的中間件如mycat,oneproxy等可以很容易的實作讀寫分離和分庫分表、分布式等方案。
Redis高可用
一般IT系統架構使用Redis主要兩大用途：共享session存儲和緩存資料。Redis的高可用架構一般主要兩種：哨兵模式的主從和cluster叢集。
上圖為redis的哨兵模式，通過哨兵監控，實作故障後自動推舉master。Redis Cluster是Redis3.0以後推出的，截止目前生産應用的也已經比較多。
● 檔案高可用
在系統架構中，一般檔案伺服器作為單獨的服務進行部署，主要存放檔案、圖檔、app應用上傳的附件等。有的時候也把靜态資源放到檔案伺服器中。有的公司會選擇自建檔案伺服器，也有的會選擇雲服務，如阿裡雲的OSS等。我所在的公司主要考慮到資料和檔案的保密性，采取了自建檔案伺服器的方式，主要采用了FastDFS這一開源架構進行搭建。
采用三台伺服器交叉部署三組Tracker+Storage，為公司所有IT系統提供靜态資源（主要包括檔案、圖檔）讀寫服務。
● 其他中間件高可用
| 序号 | 類型 | 産品 | 目前部署方式 |
| 1 | 反向代理 負載均衡 | Nginx | Nginx+Keepalived叢集部署 配置雙向同步 |
| 2 | LVS | Nginx+Keepalived叢集部署 配置雙向同步 | |
| 4 | MQ | RocketMQ | 叢集 |
| 5 | Kafka | 叢集 | |
| 6 | 緩存 | Redis | 主備，哨兵模式 |
| 7 | 搜尋 | ES | 主備/叢集 |
| 8 | DB | MyCAT | 叢集 |
| 9 | ShardingSphere | 叢集 | |
| 11 | 檔案 | FastDFS | 3節點叢集 |
| 12 | MongoDB | 叢集 | |
| 13 | 配置中心 | Zookeeper | 3節點叢集 |
| 15 | 定時任務 | XXL-job | 叢集 |
| 16 | LTS | 叢集 |
x.2.2 備份管理政策
備份集管理在整個災備體系建設上至關重要，備份也是災備建設的底線，從災備品質效果來看，要求備份集準确、完整且安全，及備份出來的備份集應該存儲在安全的位置并且其應該是準确、完整、可用，并且應該有詳細的恢複評估，以備随時可用。備份集管理主要在政策方面，備份政策總的大概分為：備份周期、存儲位置、恢複政策、驗證政策四大部分。
備份對象
備份政策首選要确定備份對象，并且按照備份對象的定級為優先級逐漸開展實施。備份對象涵蓋應用系統及資料的方方面面，從前端應用到後端資料庫，從系統層面的虛拟機備份到伺服器上的具體某一個檔案，都是待備份的對象。一般來說備份虛拟機和備份應用是有重複的地方，但是多管齊下，做到最可靠，這樣的代價就是在結果集存儲上會出現重複備存儲的情況，一定程度上提高了IT的存儲成本。
備份周期
備份周期一般以周為機關，周三和周天全備，其他時間增量備份。全備+增量備份可以節省一部分資源，也提高了恢複的速度。虛拟機層面一般采用虛拟機全備的方式。另外将備份删除政策定在備份周期裡。根據系統的重要性和要求，定期删除一些過期的備份集，釋放存儲資源。
存儲位置
備份集的存放本着多處存放的原則。一般在本地伺服器存放一份，機房内備份伺服器或是NAS存放一份，異地機房存放一份，根據備份集對象資料的保密性，有選擇的在雲端存放一份。多地存放，降低了備份集丢失的可能性。同時本地伺服器存儲最近一次備份集，以便出現問題的時候可以快速恢複，省去備份集傳輸時間，異地災備機房或雲災備中心在存儲最近備份的同時，拉起最近一次備份集做恢複，既可測試備份結果的準确性又節省備份恢複時間。
恢複政策
恢複政策包括恢複方案、恢複腳本以及恢複評估三個主要内容。恢複方案和恢複腳本相結合，確定備份集能夠按照預定方案進行準确性、高效性的恢複，恢複評估為對恢複方式的綜合評價，包括備份恢複的方法、恢複時間、恢複後資料丢失或影響、備份存儲位置及大小、傳輸速度等多方面内容，基于備份集的恢複評估可供運維人員在進行恢複決策的時候提供依據和預期，是備份管理工作的重要内容之一。
驗證政策
有備份，就一定要驗證，而且要制定計劃、定期驗證備份集中的每一個備份的可用性、準确性和完整性，并且通過驗證收集恢複評估資訊并逐漸完善。制定并實施持續完整的備份驗證政策，是保證備份集可用的最佳途徑，在驗證備份集的時候，要根據恢複政策的腳本和方案進行恢複驗證，并且記錄驗證時間。為後續的真實恢複做好前置準備和恢複預期。
x.2.3 組織架構與流程管理
災備規劃、設計、建設、管理以及切換恢複與業務部門和資訊部門都有密切關系，企業層面廣義上的災備除了技術層面的建設還包括業務層面的備用方案手段，災備設計及建設在實際過程中完全實作與生産環境1:1的映射很難，多有取舍，故在規劃、設計和建設時就應該與應用系統及資料關聯的業務人員、開發人員、項目經理等充分溝通達成共識，以便對應用系統及資料的災備效果有共同的認識和預期。是以組織架構設計上可采用“虛拟小組”的方式聯系各方幹系人和關聯部門，災備的管理工作主要在運維部門，災備效果以及備份集評估需要運維主動與業務級開發、測試等工程師一同推進，完成效果評估評價工作，同時在這一過程中也加深了對災備建設的共同認識。災備恢複的切換啟用是災備管理工作的核心關鍵點，需要基于災備及備份的評估評價效果和目前災難發生情況、影響範圍及影響程度以及生産修複難度進行綜合評定，既要結合既定預案又要充分考慮目前情況，災備的啟用、備份集的恢複需要虛拟小組共同決定并彙報責任上司，一緻決定後，才可進行進一步的操作。從流程管理上，大緻可參考如下：
圖：災備處理流程
災難發生或是故障發生時首先進行彙報和緊急處理，彙報包括彙報至相關上司、業務部門等主要幹系人，緊急處理指對目前災備問題或故障情況進行初步的排查處理，并且結合應急預案進行應急臨時處理或是業務層面的備用手段，對于較大、較複雜的問題，還需要及時對災備中心系統、備份集進行綜合評估，确認災備啟用或備份恢複的影響；根據故障處理情況及影響範圍、影響情況進行進一步的彙報和聯合排故等，并且根據影響範圍、時間及影響度和故障處理情況等進行資訊彙總以此決定是否啟用災備或是備份進行恢複；災備環境啟用或是備份進行恢複後要立即進行測試并投入使用，同時生産故障繼續處理進行恢複，直至生産恢複後切換回至生産環境，災備進入收尾工作。
災備的收尾工作是災備閉環工作的最後一環，其主要展現三個方面：一是切回至生産環境後，災備環境産生的資料是自動還是手動同步回生産環境；二是災備環境恢複為初試環境與生産環境進行同步、備份；三是對此次災備或備份使用情況進行分析、總結，包括災備啟用條件、災備啟用手冊及順序、災備測試及使用、備份恢複腳本及方案等全流程、全内容，對其中有缺陷地方進行整改、修複。
x.3 災備建設案例
某公司隸屬民航運輸業，設有本地資料中心機房，其資訊系統較多且與機場、空管站、航信等專線相連，架構相對錯綜複雜，但核心系統比較重要，原則上不允許中斷以免出現公衆事件和影響公司經營考核，故災備建設至關重要，是運維工作的重要一環。
圖：災備建設案例
項目立項後，首先對公司資訊系統及資料進行了全面的梳理，結合實際情況大緻劃分為四類系統：公共基礎服務類、運作類系統、商務營銷類系統和辦公類系統，其中公共基礎服務和運作類系統為核心關鍵系統，為公司航班正常運作提供系統支援和保障，災備等級建設原則上不得低于國标5級；商務營銷類系統主要面向票務銷售和旅客服務，相比核心關鍵系統重要性略低，災備等級原則上不得低于4級，OTA主要銷售管道系統不得低于5級；辦公類系統圍繞公司正常運作提供系統保障，災備等級可進一步降低。不同類别、不同等級的系統，經過摸排梳理和溝通确認後，災備需求大緻如下：
| 系統類别 | 系統名稱 | 系統等級 | 持續可用性名額 | 災備等級 | RPO | RTO | 建設計劃 |
| 公共基礎服務 | 檔案服務系統 | 5 | 99.99% | 5 | 30min | 30min | 災備系統+備份 |
| 公共基礎服務 | 資料緩存系統 | 5 | 99.99% | 5 | 30min | 30min | 災備系統+備份 |
| 運作類系統 | 運作控制系統 | 5 | 99.99% | 5 | 15min | 15min | 災備系統+備份 |
| 運作類系統 | 機務維修系統 | 5 | 99.99% | 5 | 30min | 30min | 災備系統+備份 |
| 運作類系統 | 資質管理系統 | 4 | 99.99% | 4 | 2h | 1h | 災備系統+備份 |
| 商務類系統 | 官網銷售系統 | 4 | 99.99% | 4 | 2h | 1h | 災備系統+備份 |
| 商務類系統 | 旅客管理系統 | 4 | 99.99% | 4 | 2h | 1h | 災備系統+備份 |
| 商務類系統 | OTA銷售系統 | 5 | 99.99% | 4 | 15min | 15min | 災備系統+備份 |
| 商務類系統 | 線上客服系統 | 3 | 99.90% | 4 | 6h | 6h | 備份 |
| 辦公類系統 | OA系統 | 3 | 99% | N/A | 1d | N/A | 備份 |
| 辦公類系統 | 财務系統 | 3 | 99% | N/A | 1d | N/A | 備份 |
| 辦公類系統 | 人事系統 | 3 | 99% | N/A | 1d | N/A | 備份 |
依據此計劃開展災備系統及備份建設工作，要點如下：
（1）災備中心的建立以先雲災備中心為主，後建裝置用機房，確定災備中心可以快速傳遞，節省項目實施周期；
（2）應用系統、中間件以及資料庫通過高可用叢集部署的方式，在雲災備中心建立節點并且與本地主機房通過網絡專線實時同步；
（3）應用系統的配置檔案改為域名/hosts的方式進行連結，規避IP:端口的方式，以求做到本地主機房和雲中心應用配置的便捷管理，雲災備中心應用連接配接雲中心的配置，確定本地主機房故障可以獨立運作；
（4）在雲災備中心資源池設定雲桌面，以供本地主機房災難性故障時，可以通過網絡連接配接雲桌面進行雲上内網系統的操作；
（5）通過專業備份軟體、備份腳本對應用、資料庫、檔案以及虛拟機等進行備份，備份存儲在本地備份伺服器的同時通過另一條專線與雲中心備份資源池連接配接，存儲備份結果集，實作第三方備份存儲的監管要求；
（6）在資源池每日恢複最新一次備份集，確定備份集準确、可用，同時節省備份恢複時間；
（7）備用機房建設放在雲災備中心之後，整體計劃優先建設核心關鍵系統的雲災備系統和備份工作，同時為備用機房的推進打下技術基礎。備用機房與本地主機房計劃通過裸光纖的方式實作存儲級同步，降低技術難度和管理複雜度；