在資訊領域除了技術以外，業務更是主導技術發展的主要因素，沒有業務需求、市場哪來的技術需求，這篇文算是技術知識的腦補文章，作為作者自己加深記憶關於 BCP、RTO、RPO 的理解用。
BCP (Business continuity planning)
BCP (Business continuity planning) 業務連續性計畫，是一套基於「業務」運行的「管理要求」和「規章流程」，在一個企業中發生「突發事件」時能夠迅速做出反應，並且確保「關鍵業務」功能可以持續不造成業務中斷或業務流程。
在做 BCP 之前要先定義幾個項目：
- BCP 目標、範圍
- 執行人員 (各領域核心人員)
- 關鍵業務項目、風險
- 業務可接受復原時間
- 業務恢復順序
- 定義中斷情境演練
- 實際演練
除了這些當然還有許多細節，概略先列出一些必要項目。
找幾個產業來看範例：
- 直播 (參考 從 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，大略的時間可以參考 (依實際狀況而調整)：
- 商務決策：10 minutes
- 資料同步驗證：30 minutes
- 技術架構切換：10 ~ 60 minutes (依架構複雜度而定)
- 功能測試：~ 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
