大家好,我是伐伐伐伐木工
今天要與大家分享災難復原計畫 DRP,本篇內容的重點如下
災難復原計畫 DRP (Disaster Recovery Plan)是確保業務連續性的關鍵,這計畫將有助於當災難發生時,核心業務可以迅速且可靠的恢復正常運作。有效的 DRP 可能會包含下列要素
迷之聲 : 我是誰、我在哪、我要去哪裡
以下是可能會遇到的問題
Q1 : 萬事起頭難,如何開始 ?
A : 先了解你的業務與IT資源使用,包含業務運作、IT 基礎建設、應用程式、雲端服務商或是數據庫等等,列出您目前擁有的所有資源跟系統。
範例
盤點後可能如下,將服務拆成不同類別,並依據既有服務可以拆分為
Service | Name | Description |
---|---|---|
Network | 網路設定 | AWS Elastic Ips、S3、Subnet、NAT Gateway、Route 53、Load balance |
Application Server | 網站應用程式 | ECS、EC2、Service、Launch Template、Auto Scaling Group |
Database | 數據資料 | 產品目錄、客戶訂單和用戶資訊 |
就資料 (Data) 與非資料 (Network & Application) 層面拆開來看分析
災難復原是恢復數據的能力,同步與備援機制如下
資料庫數據和日誌的容量整理如下,包括完整備份、數據傳輸時間估計、還原預估等
另外還需考慮
透過現有狀況盤點後,可以得到系統恢復的真實時間,例如,上述盤點完光資料庫部分還原需要 6 小時,而產品服務的期待時間是 2 小時,因此我們要思考如何數據步驟是否有其他更快的方式進行還原,ex : 數據庫進行拆分。
Q2 : 如何進行 BIA (業務影響分析)
A : 進行業務影響分析(Business Impact Analysis),確定哪些業務功能對您的業務至關重要,以及它們的優先順序。這有助於確定災難發生時應首先恢復的部分。
順序 | 業務目標 | 功能 | 服務 |
---|---|---|---|
1 | 登入 | 功能A、功能B | 主站、登入 API |
2 | 目錄 | 功能C、功能D | 目錄 API |
3 | 訂單 | 功能E、功能F | API |
4 | 其他 |
除了找到商業上重要的功能外,還要了解對應的服務資訊,以計算每個服務和數據恢復的關鍵時間。
Q3 : 如何計算 Application 恢復時間
A : 盤點每個功能,在按下部署按鈕後到完成所需的步驟和時間。應用程式上線的總時間可以表示為:
AP上線總時間 = Script + 機器請求 + 移交機器 + Provisioned + Health Check
計算整個應用程式恢復所需的時間,包括腳本執行、機器請求、機器建立、Provisioned 腳本執行和健康檢查等步驟。這有助於確定可以控制的和無法控制的恢復時間因素。
Q4 : RTO 與 RPO 時間如何定義 ?
A : 可以參考前一篇文章對於其定義與介紹 Day5 DR
Business Continuity Plan (BCP) vs. Disaster Recovery Plan (DRP): What Are the Key Differences?