▸ 標準來源
這些術語全部來自 ISO 22301（業務持續管理系統 BCMS），而非 ISO 27001（資訊安全管理）。
▪ ISO 27001 → 管「資訊安全」（CIA、風險評鑑、控制措施）
▪ ISO 22301 → 管「業務持續」（發生災難時，業務如何存活、多快恢復）
▪ ISO 27001 → 管「資訊安全」（CIA、風險評鑑、控制措施）
▪ ISO 22301 → 管「業務持續」（發生災難時，業務如何存活、多快恢復）
▸ 先用生活例子理解
🏪 情境：便利超商遭遇停電
假設你是一家 7-11 的老闆，今天突然停電了。
停電前最後一次叫貨紀錄是 2 小時前。停電後你最多只能損失那 2 小時的銷售資料——這就是你的 RPO = 2小時 （能接受的最大資料遺失量）。
老闆娘說：「超過 4 小時店還沒開，我們的老客戶就跑光了、損失無法彌補。」 這 4 小時就是你的 MTPD = 4小時 （業務的生死線）。
你的 IT 主管說：「我設定的目標是 2 小時內讓收銀系統恢復」，這叫 RTO = 2小時 （系統恢復的目標時間）。
但系統恢復後，還要花 30 分鐘把備份資料匯入、重新核對庫存，才能真正「開門做生意」——這 30 分鐘就是 WRT = 30分鐘 （資料追回、業務真正恢復的時間）。
你翻了翻過去紀錄，平均每次停電都花 1.5 小時才修好，這是 MTTR = 1.5小時 （歷史修復平均值，要比 RTO 小才算達標）。
而且過去 5 年，這家店平均每 18 個月才停一次電，這段間隔叫做 MTBF = 18個月 （衡量設備/系統的可靠度）。
停電前最後一次叫貨紀錄是 2 小時前。停電後你最多只能損失那 2 小時的銷售資料——這就是你的 RPO = 2小時 （能接受的最大資料遺失量）。
老闆娘說：「超過 4 小時店還沒開，我們的老客戶就跑光了、損失無法彌補。」 這 4 小時就是你的 MTPD = 4小時 （業務的生死線）。
你的 IT 主管說：「我設定的目標是 2 小時內讓收銀系統恢復」，這叫 RTO = 2小時 （系統恢復的目標時間）。
但系統恢復後，還要花 30 分鐘把備份資料匯入、重新核對庫存，才能真正「開門做生意」——這 30 分鐘就是 WRT = 30分鐘 （資料追回、業務真正恢復的時間）。
你翻了翻過去紀錄，平均每次停電都花 1.5 小時才修好，這是 MTTR = 1.5小時 （歷史修復平均值，要比 RTO 小才算達標）。
而且過去 5 年，這家店平均每 18 個月才停一次電，這段間隔叫做 MTBF = 18個月 （衡量設備/系統的可靠度）。
▸ 時間軸全覽
💾
最後備份Last Backup
💥
災難發生Incident
🔧
系統修復System Restored
📋
資料追回Work Done
✅
完全恢復Normal Op.
RPO
資料遺失上限
WRT
資料追回時間
RTO
復原時間目標（含 WRT）
MTPD
最大可容忍中斷 = 業務天花板，RTO 不能超過它
▸ 各術語詳解
MTPD
Maximum Tolerable Period of Disruption
🚨
最大可容忍中斷時間
業務中斷後組織能「撐住」的最長時間。超過此上限，組織將面臨無法接受的嚴重後果（倒閉、違約、法律責任…）。
又稱 MTD（Maximum Tolerable Downtime），在題目中兩者等義。
又稱 MTD（Maximum Tolerable Downtime），在題目中兩者等義。
💡 超商例子：老客戶跑光的那條線 = MTPD
所有 RTO 都必須 ≤ MTPD
所有 RTO 都必須 ≤ MTPD
RPO
Recovery Point Objective
💾
復原點目標
發生災難時，可以接受的最大資料遺失量（以時間衡量）。決定備份頻率：RPO = 1小時 → 至少每小時備份一次。
💡 P = Point，回到哪個時間點
RPO → 決定備份政策（頻率、保留期限）
超商例子：叫貨記錄可以丟掉的最大時段
RPO → 決定備份政策（頻率、保留期限）
超商例子：叫貨記錄可以丟掉的最大時段
RTO
Recovery Time Objective
⏱️
復原時間目標
從業務中斷發生到系統恢復至可接受服務水準的最大允許時間。RTO = 修復時間 + WRT。
RTO 越小，代表需要更高等級的備援架構（成本越高）。
RTO 越小，代表需要更高等級的備援架構（成本越高）。
💡 T = Time，停多久
RTO → 決定復原政策（熱/溫/冷備援）
必須 ≤ MTPD
RTO → 決定復原政策（熱/溫/冷備援）
必須 ≤ MTPD
WRT
Work Recovery Time
📋
工作復原時間
系統/硬體恢復後，還需要多久才能讓業務真正跑起來——包含資料匯入、流程追回、測試確認等工作時間。
💡「系統活了，但人還在整理資料」
這段等待就是 WRT
超商例子：收銀系統修好後，還要匯入備份庫存的那段
這段等待就是 WRT
超商例子：收銀系統修好後，還要匯入備份庫存的那段
MTTR
Mean Time To Repair / Recover
🔧
平均修復時間
歷史上每次故障的平均修復時長，是統計量測值（不是目標值）。用來評估修復能力是否達到 RTO 要求。
💡 RTO 是「目標」，MTTR 是「現實」
MTTR 必須 ≤ RTO 才算達標
超商例子：過去每次停電平均花 1.5 小時修好
MTTR 必須 ≤ RTO 才算達標
超商例子：過去每次停電平均花 1.5 小時修好
MTBF
Mean Time Between Failures
📊
平均故障間隔時間
兩次故障之間的平均正常運作時間，衡量系統可靠性（Reliability）。MTBF 越長 → 越可靠。
可用度 = MTBF ÷（MTBF + MTTR）
可用度 = MTBF ÷（MTBF + MTTR）
💡 衡量「多穩定」，不是「多快恢復」
超商例子：平均每 18 個月才停一次電 → 可靠
超商例子：平均每 18 個月才停一次電 → 可靠
▸ 關係與公式
MTPD
≥
RTO
≥
MTTR
天花板 ≥ 目標 ≥ 現實
RTO
=
修復時間
+
WRT
系統修好 + 資料追回
可用度（Availability）
=
MTBF
÷ (
MTBF
+
MTTR
)
📌 RPO 越小 → 備份越頻繁 → 成本越高
📌 RTO 越小 → 備援等級越高（冷→暖→熱→全備援）→ 成本越高
📌 MTPD 是業務決定的需求，RTO 是 IT 承諾的目標，MTTR 是工程的現實
📌 RTO 越小 → 備援等級越高（冷→暖→熱→全備援）→ 成本越高
📌 MTPD 是業務決定的需求，RTO 是 IT 承諾的目標，MTTR 是工程的現實
▸ RTO 與備援類型對照（常考）
RTO 設定越短，需要越高等級的備援，成本也越高。
| 備援類型 | RTO 範圍 | 說明 | 適合情境 |
|---|---|---|---|
| Cold Site 冷備援 |
數天～數週 | 只有場地與電力，設備需重新安裝設定 | 成本最低，RTO 寬鬆 |
| Warm Site 暖備援 |
數小時～數天 | 設備已就位但未即時同步，需手動切換 | 中等成本，RTO 中等 |
| Hot Site 熱備援 |
分鐘～數小時 | 系統即時同步，可快速自動切換 | RTO ≤ 1～4 小時 |
| Mirrored 全備援 / 鏡射 |
幾乎 0（秒級） | 雙向即時鏡像，無縫自動接手 | RTO 趨近於零，成本最高 |
▸ iPAS 考試陷阱（真實考古題）
⚠️
高頻錯誤觀念整理
以下均來自 iPAS 110～113 年真實考題，請務必記牢
iPAS 112-2 第18題（複選）
❓ 以下哪些是 RTO 的正確描述？
「RTO 決定了備份政策」→ 錯！這是 RPO 的工作
「資料備份從啟動到完成所需最短時間」→ 錯！這是「Backup Window 備份視窗」，跟 RTO 無關
RTO 決定的是「復原政策」（備援架構的等級選擇）
RTO 的定義：業務中斷到恢復至可接受服務水準的最大允許時間
🔑 記憶口訣：RPO → 備份（Backup）；RTO → 復原（Recovery）
iPAS 112-2 第19題
❓ 「RTO 的設定與 MTD（最大可中斷時間）無關」→ 正確還是錯誤？
「無關」→ 錯！這是本題答案，是錯誤敘述
RTO 必須 ≤ MTD（MTPD），兩者密切相關；若 RTO 超過 MTD，系統無法在可接受時間內恢復
🔑 MTD = MTPD（同義），是 RTO 的上限天花板
iPAS 111 第2題
❓ 公司規定系統復原 4 小時內，但實際測試花了 6 小時，違反了什麼？
RPO（復原點目標）→ 錯！RPO 跟資料遺失量有關，跟復原花多久無關
MTTR（平均修復時間）→ 錯！MTTR 是統計歷史平均，不是「規定」
違反 RTO：公司設定目標 4 小時，實際花 6 小時，超過了目標
🔑 有「公司規定 X 小時內恢復」→ 考的幾乎都是 RTO
iPAS 113-2 第13題
❓ 公司規定資料流失不可超過 8 小時（RPO = 8hr），備援資料庫最長可以多久同步一次？
選 9 小時（超過 RPO 目標）→ 錯
選 7 小時：小於 RPO = 8 小時的最大值，且留有緩衝
🔑 備份同步間隔 = 可能的資料遺失時間，必須 < RPO，而且要選「最長可設定」（不是最短）
iPAS 110 第35題
❓ 合約規定中斷不可超過 1 小時，下列哪種備援方案可行？
Cold Site（冷備援）→ 錯！RTO 長達數天，遠超 1 小時
備援設於隔壁棟大樓 → 錯！無法應對區域性災難
Hot Site（熱備援）+ 異地（不同縣市）才是正解
🔑 RTO 越短 → 需要等級越高的備援；異地備援必須真的「異地」（不同縣市）
iPAS 111 第31題
❓ RTO ≤ 4 小時，不考慮成本，最佳備援方案為何？
新廠房建 Hot Site → 錯！同一地區颱風/洪水會同時影響兩處，不是真正異地
租用網路數據中心建置全備援（Mirrored Site）：真正異地 + 即時同步，RTO 最短
🔑 不考慮成本 → 選最高等級（Mirrored）；新廠房若在同一地區不算異地
iPAS 111 第32題
❓ 評估雲端服務商（CSP）作為備援時，哪些安全要素必須考量？
只看價格或 SaaS 功能 → 不夠
必須確認 CSP 提供的 SLO / RTO / RPO 是否符合公司的 DR 計畫
確認實體環境安全控制措施、網路隔離（多租戶安全）
🔑 雲端備援也要談 RTO/RPO，不能只看功能，SLO = Service Level Objective 也是考點
觀念釐清：MTBF vs MTTR
❓ MTBF 和 MTTR 有什麼不同？
MTBF 越大 = 修得越快 → 錯！MTBF 是「故障間隔」，跟修復速度無關
MTBF 大 → 系統可靠（不常壞）
MTTR 小 → 系統可用（壞了修得快）
🔑 可用度 = MTBF ÷ (MTBF + MTTR)，MTBF 和 MTTR 都要好，可用度才高
▸ 一張表總整理
| 術語 | 中文 | 一句話定義 | 決定什麼 | 關係 |
|---|---|---|---|---|
| MTPD | 最大可容忍中斷時間 | 業務的生死線（天花板） | 所有 RTO 的上限 | ≥ RTO |
| RPO | 復原點目標 | 最多可丟失多少資料 | 備份頻率/政策 | 獨立於 RTO |
| RTO | 復原時間目標 | 系統最多停多久 | 備援架構等級 | ≤ MTPD，= 修復+WRT |
| WRT | 工作復原時間 | 系統修好後還要整理多久 | 包含在 RTO 內 | RTO 的子集 |
| MTTR | 平均修復時間 | 歷史上平均修多久（實際） | 驗證是否達到 RTO | ≤ RTO |
| MTBF | 平均故障間隔時間 | 平均多久壞一次（可靠性） | 可用度計算 | 可用度=MTBF/(MTBF+MTTR) |
沒有留言:
張貼留言