概述：容災，也是災難恢復，是一個綜合很多技術使用的一個系統性工程，對于容災測試除了具備扎實的測試技能，同時也要有系統性的分析思維來拆解，將難度降低到一個個小小的場景和用例中去，以下做一些簡單的介紹，只做拋磚引玉，最終還是要看具體的實踐。

一、容災概念理解：

1、災難恢復概念（Disaster recovery，也稱災備），是指在相隔較遠的異地，建立兩套或多套功能相同的IT系統，互相之間可以進行健康狀態監視和功能切換，當一處系統因意外(如火災、地震等)停止工作時，整個應用系統可以切換到另一處，使得該系統功能可以繼續正常工作。容災技術是系統的高可用性技術的一個組成部分，容災系統更加強調處理外界環境對系統的影響，特別是災難性事件對整個IT節點的影響，提供節點級別的系統恢復功能。

2、容災系統的類型：從對系統的保護程度來分，可以將容災系統分為：數據容災和應用容災。

數據容災就是指建立一個異地的數據系統，該系統是本地關鍵應用數據的一個實時復制。采用的主要技術是數據備份和數據復制技術，可以分為同步傳輸方式、半同步傳輸和異步傳輸方式。

應用容災是在數據容災的基礎上，在異地建立一套完整的與本地生產系統相當的備份應用系統(可以是互為備份)，在災難情況下，遠程系統迅速接管業務運行。數據容災是抗御災難的保障，而應用容災則是容災系統建設的目標。主要的技術包括負載均衡、集群技術及對應的故障切換機制。

3、容災系統的等級：參照國際災難備份行業的通行災難備份等級劃分原則，根據異地數據的多寡，異地數據與生產數據的差異程度，以及災難恢復環境的完備程度，將災難備份系統從低到高劃分為如下四個等級：

第0級：沒有備援中心：這一級容災備份，實際上沒有災難恢復能力，它只在本地進行數據備份，并且被備份的數據只在本地保存，沒有送往異地。

第1級：本地磁帶備份，異地保存：在本地將關鍵數據備份，然后送到異地保存。災難發生后，按預定數據恢復程序恢復系統和數據。這種方案成本低、易于配置。但當數據量增大時，存在存儲介質難管理的問題，并且當災難發生時存在大量數據難以及時恢復的問題。為了解決此問題，災難發生時，先恢復關鍵數據，后恢復非關鍵數據。

第2級：熱備份站點備份：異地建立一個熱備份點，通過網絡進行數據備份。也就是通過網絡以同步或異步方式，把主站點的數據備份到備份站點，備份站點一般只備份數據，不承擔業務。當出現災難時，備份站點接替主站點的業務，從而維護業務運行的連續性。

第3級：活動備援中心，在相隔較遠的地方分別建立兩個數據中心，它們都處于工作狀態，并進行相互數據備份。當某個數據中心發生災難時，另一個數據中心接替其工作任務。這種級別的備份根據實際要求和投入資金的多少，又可分為兩種：①兩個數據中心之間只限于關鍵數據的相互備份；②兩個數據中心之間互為鏡像，即零數據丟失等。零數據丟失是目前要求最高的一種容災備份方式，它要求不管什么災難發生，系統都能保證數據的安全。所以，它需要配置復雜的管理軟件和專用的硬件設備，需要投資相對而言是最大的，但恢復速度也是最快的。

容災系統的衡量指標

RPO（Recovery Point Objective）：即數據恢復點目標，主要指的是業務系統所能容忍的數據丟失量。

RTO（Recovery Time Objective）：即恢復時間目標，主要指的是所能容忍的業務停止服務的最長時間，也就是從災難發生到業務系統恢復服務功能所需要的最短時間周期。

RPO針對的是數據丟失，而RTO針對的是服務丟失，二者沒有必然的關聯性。RTO和RPO的確定必須在進行風險分析和業務影響分析后根據不同的業務需求確定。對于不同企業的同一種業務，RTO和RPO的需求也會有所不同。

二、如何做容災測試：

1、確認整體跨城架構，逐層分析交易數據流；

2、了解和分析跨城容災觸發的條件和步驟，分析跨城容災步驟的合理性，從流程上分析是否存在哪些不足。

3、掌握跨城容災的實現原理，逐層逐系統分析，哪些是做了容災，哪些是沒有做的（系統不同階段，滿足容災的等級要求是不一樣的，有些系統可能還是屬于單點，但是一般要設計合理的應急措施），梳理測試風險點和關注點。

4、編寫測試方案，方案包括：系統架構圖、跨城切換步驟、測試計劃（什么人、什么時間、負責什么內容，達到什么效果）、測試環境準備部署圖、測試準備（對應工具及腳本開發、數據準備、數據依賴等）、測試策略（哪些要驗證、哪些不驗證、驗證到什么程度）、測試關注點、風險點列表及應對措施等。

5、編寫測試用例，重點對測試關注點、測試風險逐個擴展編寫用例，主要關注點有如下一些要素：

模擬觸發容災切換的條件，一般觸發容災切換的要素：交易成功率下降到某個閾值、網絡中斷、服務異常（服務請求沒反應，服務請求拒絕、進程假死等）、機器異常（硬件故障、CPU打滿、內存耗盡、網絡擁堵請求不可達等）。這些條件，系統要能監控到，并根據一定策略來觸發容災處理（成功率、請求數是否小于定義最小、對等set是否正常、仲裁計算是否滿足切換條件）；

容災切換一般做法：

單機異常：從負載均衡策略中，摘除該機器（自動or人工or策略觸發）、系統自動擴容、機器重啟，如果是DB機器異常，做主備切換或者切換到其他備機，數據同步策略變化；

機房級別異常：整個機房做切換或者觸發同城切換，切換要看設計方案中涉及到具體網絡部署和服務、數據庫部署切換，需要結合實際部署來看。

城市級異常：觸發跨城切換，跨城切換會導致整個系統耗時增加、服務整體切換、跨城數據同步和后續數據回補，由于切換后節點減少，系統壓力驟增，這個要逐個節點來考慮系統切換完備性及系統系統承受能力。

切換層次：目前大部分系統是分層架構，比如分布式緩存、接入層、控制層、集成層、服務層、數據層、相關第三方依賴和關聯系統。在分層架構下，為了減少跨城耗時，會做到條帶化，即城市內的煙囪式條帶化訪問，同時增加跨城備份訪問。為避免切換帶來的業務連續性問題，切換不一定會觸發整體切換，會實現層級切換，通過跨城訪問來降低切換風險。比如A城數據庫異常，如果A城做了數據跨城備（B城），那么上層服務層直接連到B城數據庫即可。

其他的容災做法有：系統限流、業務降級、功能依賴切換等

容災效果驗證：容災后，需要對容災后的效果做驗證，需要結合業務場景來驗證，比如：

切換前：切換前發起的訂單未到終態，切換后，這些業務處理方式，是直接失敗，還是會有補償機制？這里又區分聯機實時業務、批量業務、事務相關處理；

切換中：切換過程會有個延時，多個系統切換不是瞬間完成的，這個瞬間的切換，測試時把過程拉長時間，以便驗證每個切換步驟和系統的兼容性；

切換后：需要驗證切換后的業務連續性是否能保證，實時交易、批量交易、事務是否能正常處理；

回切：系統恢復后，需要做回切處理，這個回切后業務連續性驗證，回切前業務是否能正常處理，回切后業務數據流是否正常。

數據回補驗證：數據回補和校驗邏輯驗證，切換前業務交易，數據回補后是否能繼續處理等，數據回補是有損還是無損，對應補償機制及應對措施驗證。

容災演練配合：容災系統建設之后，容災演習就要變成常態化動作，需要在生產環境模擬觸發容災切換的場景，來模擬真實容災切換，需要做的內容主要有以下幾種：

災難場景模擬：需要對場景做細分，比如交易成功率下降，這個可以通過對某臺機器的網絡端口進行網絡限制或者協議層阻塞來模擬；網絡丟包，也可以通過iptable來模擬。

觸發場景后的業務驗證：觸發切換后，發起對應自動化業務用例，用例中需要對數據進行核對和檢查，確保業務驗證是否符合需求。

三、容災測試的異常模擬方法：

使用iptbables直接模擬系統和某系統之間的網絡不通：

sudo iptables -A OUTPUT -o eth0 -d <依賴系統的IP> -j DROP

使用iptables直接模擬系統的某個端口不通

sudo iptables -A OUTPUT -o eth0 -p tcp --dport <端口號> -j DROP

清除所有設置的iptables規則：iptables –F

查看當前設置的所有iptables規則：iptables –L

模擬應用變慢和超時：添加對某個依賴系統的流量控制，下面的命令需要按照順序執行。

使用ifconfig查看默認的網卡信息，一般默認為eth0

使用tc流量控制命令對eth0網口過來的數據包添加一個排列規則，延遲1000ms

sudo tc qdisc add dev eth0 root handle 1: prio

sudo tc qdisc add dev eth0 parent 1:3 handle 30: tbf rate 20kbit buffer 1600 limit 3000

sudo tc qdisc add dev eth0 parent 30:1 handle 31: netem delay 1000ms 10ms distribution normal

添加從某ip過來的流控規則(替換**.**.**.**為需要流控的ip)

sudo tc filter add dev eth0 protocol ip parent 1:0 prio 3 u32 match ip dst **.**.**.**/32 flowid 1:3

查看已經設置的限流規則: sudo tc filter list dev eth0 parent 1:0

刪除已經設置的所有的限流規則: sudo tc filter del dev eth0 parent 1:0 prio 3 u32

刪除已經設置的從某ip過來的流控規則（直接替換添加流控規則命令中的add為del即可）：

sudo tc filter del dev eth0 protocol ip parent 1:0 prio 3 u32 match ip dst **.**.**.**/32 flowid 1:3

版權聲明：本文為CSDN博主「jackey_sdc」的原創文章，遵循CC 4.0 BY-SA版權協議，轉載請附上原文出處鏈接及本聲明。

原文鏈接：https://blog.csdn.net/jackey_sdc/article/details/109410005