災備-故障演練

為了確保應用系統具備足夠的健壯性，通常需要設計容災方案進行部署，在容災方案落地實行之前通常需要進行故障的模擬，以達到：

1. 確保系統能夠按照預想的方式進行故障恢復；
2. 尋找系統意想之外的弱點，提高系統的健壯性。

一、故障演練類型

1. 桌面演練：桌面演練是通過對災難恢復預案的一個理論驗證，并不會進行真正的故障注入和恢復，其主要目的是驗證方案的有效性，同時方便相關人員了解業務流程和相關人員的綜合能力等。
2. 模擬演練：模擬演練是以桌面演練為基礎，由多個部門參加模擬演練，采用模擬數據和模擬業務系統運行演練。盡可能接近真實環境發生災難的處理過程，驗證方案的有效性和可行性，以及相關人員的配合程度。
3. 實際演練：實際演練需要在真實的線上業務場景下進行演練，通過手動注入故障，讓災備中心接替線上業務真正運行一段時間，這種方式更容易發現潛在的問題。

二、故障類型

三、故障演練順序

3.1 故障演練前

1. 檢查必備能力 需要用用具備業務鏈路流量標記能力；具備下游依賴服務故障注入的能力；具備流量回放/隔離的能力。
2. 確定故障演練的范圍 故障演練的范圍：哪些流量、哪些下游服務、哪個應用環境
3. 回放流量隔離
4. 制定故障應對預案
5. 配置故障
6. 確定演練目標

3.2 故障演練中

1. 將錄制的線上流量逐步加壓回放到故障演練的發起應用中的無真實流量機器
2. 開啟應用的故障模擬開關，觀察故障影響
3. 啟動應用的故障應對預案

3.3 故障演練后

1. 現場清理
2. 輸出演練報告和總結

四、技術難點

1. 如何在災備的故障演練過程中，不影響線上業務，不造成生產環境的數據和日志污染
2. 故障演練的流量如何獲取
3. 故障的影響如何捕捉Asert出來
4. 提升故障的覆蓋率

個人思考：目前存在的災備故障模擬工具，例如阿里的ChaosBlade，k8s開源社區的ChaosMesh等都具備了比較強大的混沌實驗能力，能夠模擬多個場景下常見的系統故障，但是故障的粒度一般來說比較大，比如基礎資源宕機、應用服務崩潰等導致服務直接不可用。這些工具沒有適配用戶的應用系統，同時代碼級的故障也無能為力。 個人感覺故障演練和測試團隊或者安全領域模糊測試有異曲同工之妙，有可能這個不在故障演練的范疇內，屬于用戶安全滲透團隊的業務范圍，但如果故障演練可以包含更細粒度的故障測試，就可以提高災備能力，應對更多更復雜的故障場景，進一步提高系統的健壯性。