BCP 企業營運持續管理 RTO, RPO 理解與筆記

2020-06-04 Policy

在資訊領域除了技術以外,業務更是主導技術發展的主要因素,沒有業務需求、市場哪來的技術需求,這篇文算是技術知識的腦補文章,作為作者自己加深記憶關於 BCP、RTO、RPO 的理解用。

BCP (Business continuity planning)

BCP (Business continuity planning) 業務連續性計畫,是一套基於「業務」運行的「管理要求」和「規章流程」,在一個企業中發生「突發事件」時能夠迅速做出反應,並且確保「關鍵業務」功能可以持續不造成業務中斷或業務流程。

在做 BCP 之前要先定義幾個項目:

  1. BCP 目標、範圍
  2. 執行人員 (各領域核心人員)
  3. 關鍵業務項目、風險
  4. 業務可接受復原時間
  5. 業務恢復順序
  6. 定義中斷情境演練
  7. 實際演練

除了這些當然還有許多細節,概略先列出一些必要項目。

找幾個產業來看範例:

  • 直播 (參考 從 GCP 故障看 17 Media 工程團隊的災難應變)
    • 目標:基礎設施發生災難性異常時,確保關鍵業務可正常執行
    • 範圍:直播主、觀看會員
    • 關鍵業務:直播串流
    • 非關鍵業務:斗內、表情、計數器等
  • 人力銀行
    • 目標:基礎設施發生災難性異常時,確保關鍵業務可正常執行
    • 範圍:Business、Customs
    • 關鍵業務:找工作、找人才
    • 非關鍵業務:家教、外包、顧問等

從 BCP 延伸的 RTO, RPO

從 BCP 定義好災難發生的流程和要求後,再來就是要探討當災難發生後可接受的恢復時間、資料點,這關乎於一家企業備於這個災難發生前、後要準備的成本有多少。

RTO (Recovery Time Objective) 最大可允許中斷時間

在業務上會定義「最大中斷時間」,而在實作上會定義整個流程的「恢復時間」有多久,RTO 大家都希望越短越好,但是這絕對跟成本、架構、技術甚至是整個企業文化流程都有極大的關係,怎麼說呢?舉例以下

  • 我希望 RTO 小於 2 個月

RTO 2 個月在「不大的企業」幾乎可以重建一套系統了,平常只要做好資料備份就行,如果是夠大的企業基本上也是要有 Disaster Recovery Site 才能支撐,因為光是一整個機房消失 (火災、地震等) 要搶租機房、搶購買設備的業務報價請款流程就不知道等到哪去了。

  • 我希望 RTO 小於 6 小時

RTO 6 小時基本上已經不能把時間浪費在業務流程(採購設備、機房、線路等)上面,當發生時災難時要隨時能從任何地方進行恢復,亦即 Remote 作業是基本需求,基於 Remote 能處理的基本上是軟體架構,盡量避免硬體操作 (即使可以也盡量避免),如果技術上來說最低要求是 Layer 4 以上的操作是最適當的。

實際案例通常是採用 Active-Standby 架構像是 Disaster Recovery Site,大略的時間可以參考 (依實際狀況而調整):

  1. 商務決策:10 minutes
  2. 資料同步驗證:30 minutes
  3. 技術架構切換:10 ~ 60 minutes (依架構複雜度而定)
  4. 功能測試:~ 6 hours
  • 我希望 RTO 小於 1 小時

RTO 1 小時,能做的事情基本上已經不多了,實務上當發生災難後的「商務決策」時間就已經所剩無幾了,所以架構上的選擇基本上已經至少要到 Disaster Recovery Site,甚至優先選擇是 Active-Actve 架構,做到這種架構考量的情境可以分為幾種:

  • 應用層 Active-Standby、資料層 Active-Standby
    • 通常是架構單純切換簡單,才有可能在 1 小時內搞定,否則 1 小時根本是逼死自己。
  • 應用層 Active-Active、資料層 Active-Standby
    • 通常是考量資料庫的效能瓶頸或是成本問題,Standby 那段僅在離峰時段同步資料,避免減少 Main Site 效能、資源。
  • 應用層 Active-Active、資料層 Active Read – Standby Write
    • 通常是考量資料庫的資料強一致性而設計,所以常態仍然選擇單一主要機房作為寫入端點,但讀取仍可以兩邊各自讀取,即使寫入端的機房異常,仍可以正常讀取資料。
  • 應用層 Active-Active、資料層 Active ReadWrite – Active ReadWrite
    • 終極架構,資料層已經沒問題了,通常到這樣的架構要考量資料的「強一致性」、「最終一致性」、「順序性」問題,甚至應用層也要做好資料的防呆,確保資料不誤寫,在這樣的狀況下非同步的架構實作會很常在應用層實作。

通常最複雜的會是「技術架構」這一塊,每一家企業的「技術債」或「技術戰」都不同,越大的架構要考量的東西越多,「資料同步驗證」這塊的解決方案算很完成不太容易構成問題,而「功能測試」關乎於自動化的涵蓋率與完整度

RPO (Recovery Point Objective) 數據損失可允許的最遠回溯時點

RPO 就蠻好理解的,實務上就是資料備份的週期加上傳輸的時間,假設 RPO 24 小時就包含「資料備份完成 -> 同步資料到異地」

假設每日凌晨 00:00 進行備份,將備份檔案傳輸到異地需要 1 小時,則 RPO 需要 24 + 1 = 25 小時。

能從異地還原的資料點才算是 RPO 關注的重點

Reference

給 Mr. 沙先生一點建議

彙整

分類

展開全部 | 收合全部

License

訂閱 Mr. 沙先生 的文章

輸入你的 email 用於訂閱