Site icon Mr. 沙先生

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

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

BCP (Business continuity planning)

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

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

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

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

找幾個產業來看範例:

從 BCP 延伸的 RTO, RPO

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

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

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

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

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

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

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

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

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

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

Reference

Exit mobile version