概念地圖・復原時間目標與復原點目標
作者 山姆（謝冠生）・喵喵書評創辦人
發布
分類：系統
這一頁不只是把一個概念解釋一遍——一張自己畫的結構圖，加上拿台灣情境從頭走一次的實例演練、這個框架什麼時候會騙你，以及它接回 P.A.I.N. 之後長什麼樣。一頁必須交付的三層 →
RTO 與 RPO：把「不能出事」翻譯成兩個數字
週五下班前十分鐘，冷鏈倉的出貨系統當掉。值班主管腦中同時跳出兩個問題：什麼時候能重新開單？剛剛掃進去的那一百八十箱，紀錄留住了沒有？上一次備份停在昨晚二十三點，所以要重來的遠不只那二十分鐘。這兩個問題各自有名字：往前看的那個叫 RTO 復原時間目標，往回看的那個叫 RPO 復原點目標。它們是災難復原計畫裡最常被寫進合約、也最常被填成願望的兩個數字——因為填的時候不痛，兌現的時候才痛。
兩段各自在問什麼，各自要開什麼支票
同一場事故，左右兩段的問法、單位、帳單全部分開。把它攤成一張表就看得出來，這不是同一筆預算能一次解決的事。
| 問的角度 | RPO（事故點左段） | RTO（事故點右段） |
|---|---|---|
| 在問什麼 | 可以接受掉多少資料 | 可以接受停多久 |
| 往哪邊看 | 往回看，從上次備份到事故那一刻 | 往前看，從事故那一刻到重新開單 |
| 現況 | 每晚 23:00 全量備份一次，最壞掉將近一天 | 主機壞掉重建約 2 天，等於 48 小時不能出貨 |
| 目標 | 15 分鐘 | 4 小時 |
| 錢花在哪 | 交易日誌持續傳送、異地複寫，買的是資料的密度 | 備援環境、切換演練、有人半夜接得起電話，買的是切換的速度 |
| 設成零要什麼 | 同步複寫，每一筆都要寫進兩地才算成功，日常效能就要付代價 | 雙活，兩套環境同時在跑、隨時互接，日常成本一起翻上去 |
表格最後一行是整張圖最貴的一行。兩個目標同時歸零，報價會從一年幾萬的量級跳到一年幾百萬的量級，而且日常就要開始付：同步複寫讓每一次寫入都要等兩地都點頭，雙活讓兩套環境天天燒錢。多數公司要的其實沒有那麼極端，缺的只是一個講得出口、也簽得下去的數字。
填這兩個數字之前，四個自問
一、上次備份到現在，那段時間裡累積了多少筆。RPO 的單位寫的是時間，實際要付的帳單是那段時間裡累積了多少筆。週五傍晚的十分鐘跟週日凌晨的十分鐘，重打的工不是同一個量級。先去看那段時間的筆數與經手人數，再回頭決定備份頻率要調到多密。自問：一天當中最忙的那一小時整段掉了，要幾個人加班幾小時才補得回來？
二、系統回來了跟能開單，中間還隔著好幾件事。RTO 很常被寫成「主機恢復」，但業務要的是能重新掃碼出貨。中間還躺著資料校驗、庫存對帳、把停機期間的手寫單一張一張補進系統。這幾段沒算進去，四小時的承諾會在第六小時才兌現。自問：從「系統可以登入」到「第一張出貨單成立」，你們實際量過幾分鐘？
三、有沒有第二條路，決定這一段能放多寬。有人工替代路徑的環節，RTO 可以放寬；沒有替代路徑的環節，RTO 就得往下壓。倉庫可以先用紙本記下批號與溫層，出貨勉強走得動；但退貨入庫如果沒有掃碼就判不出效期——那一段連紙筆都接不住。分級之後，錢才會落在真的擋不住的地方。自問：哪一個環節一停，就沒有任何人工做法可以頂過去？
四、這兩個數字後面，要寫得出名字與科目。沒有人負責的數字只是願望。RPO 15 分鐘意味著要編列日誌傳送與異地儲存的年度費用，RTO 4 小時意味著有人得在凌晨從床上爬起來——而且知道第一步要按什麼。這兩件事都要有人點頭、有人排班、有人在預算表上找到科目。自問：這兩個數字下面，寫得出負責人的名字跟預算科目嗎？
一座第三方冷鏈物流倉，把事故點左右兩段各填一個數字
- 先量左段：出貨資料庫每晚二十三點做一次全量備份，白天不再動。週五傍晚當機，要重打的是昨晚二十三點之後的所有進出倉紀錄，將近二十小時。是目標的八十倍
- 再量右段：主機硬碟壞掉，重灌加還原，上一次真的發生時花了兩天。冷鏈客戶合約寫的是隔日配，停兩天等於整批貨要重新排車、重新約溫層車班。是目標的十二倍
- 左段怎麼壓：把交易日誌改成持續傳送到異地機房，備份不再是一天一張快照，而是一條連續的流水。買到的是資料的密度。RPO 15 分鐘
- 右段怎麼壓：異地備妥一套隨時可接手的環境，每季演練切換一次，並排出半夜接得起電話的值班表。買到的是切換的速度。RTO 4 小時
- 差點填反的那一格：資訊主管原本打算把整年預算都投進異地複寫。左段確實變密了，可是主機壞掉那天，還原流程照樣要跑兩天。右段一步沒動
- 沒被涵蓋的那一段：溫層紀錄器的資料另存在倉內本機，備份範圍從來沒有涵蓋它。壓到 15 分鐘的只有出貨資料庫。效期追溯仍是斷的
這座倉庫最後填出來的兩個數字，表面上只是把「不能出事」換算成十五分鐘與四小時，真正被改寫的是預算怎麼分配。左段的錢買資料寫下來的頻率，右段的錢買人與環境的待命，兩張報價單來自不同供應商、落在不同科目，也由不同的人簽名。更值得記住的是那一格差點填反的預算：把錢全押在左段，事故當天照樣要等兩天才開得出單，客戶感受不到任何差別。最後那條溫層紀錄則提醒了另一件事——兩個數字只保護它們涵蓋得到的系統，涵蓋之外的東西不會因為合約寫得漂亮就自動被保護。以上為說明結構用的示意情境，僅供理解框架之用。
這兩個數字什麼時候會騙你
- 填得出數字，不代表還原得回來。RPO 15 分鐘的前提，是那份日誌真的能被還原成一個可用的資料庫。備份任務天天顯示成功、還原卻從來沒有被完整跑過一次，是這一行最常見的空頭支票。數字要靠演練兌現；設定畫面上的綠色勾勾只證明任務跑完了，證明不了資料回得來。演練時記得連「還原到哪個時間點」也一起量，那個實測值才是你真正的 RPO。
- 兩個數字通常只覆蓋主系統。簽在合約裡的 RTO 與 RPO 幾乎都是照核心資料庫寫的，週邊的檔案伺服器、報表、簽核流程、跟貨運商的介接常常沒有人認領。事故當天卡住的往往正是這些沒被寫進範圍的東西，它們平常不起眼，一停掉卻讓主系統就算起來了也開不出單。範圍寫得愈窄，數字愈漂亮，兌現時的落差也愈大。
- 零這個數字會先吃掉日常。RPO 壓到零要靠同步複寫，每一筆交易都得寫進兩地才算成功，兩地之間的距離會直接變成每一次寫入的延遲；RTO 壓到零要靠雙活，兩套環境同時在跑，成本與複雜度一起翻上去。追求零的公司，常常在事故還沒發生之前，就先被日常的慢與貴拖住了腳步。
兩個數字談得完停多久，談不完誰會先動不了
資訊部門講的是風險，老闆聽到的是花錢。
這兩個數字最有價值的地方，是把「不能出事」這種情緒換成兩個可以簽名的時間，會議室裡才有東西能討論、能編預算、能追進度。但它翻譯得出時間，翻譯不出這段停擺會先卡住誰的哪一件事：同樣停四小時，對出貨組是重排一次班表，對等著收貨的客戶可能是整批退運，對稽核來說則是一段沒有溫層紀錄的空白。這張圖畫得出時間軸上該補多少錢，畫不出那段時間裡誰的損失最先發生、誰會第一個打電話進來。P.A.I.N. 的第一格問的正是誰在痛——把兩個數字填進合約很容易，難的是先問出誰會先痛。今晚就能做的小動作：翻出最近一次系統異常的通報紀錄，看第一通抱怨電話是誰打來的、他當時卡在哪一件事上，把那個人的名字寫在 RTO 這個數字旁邊。
關於這兩個數字，常被問到的幾件事
RTO 和 RPO 到底差在哪？
兩個都以時間為單位，量的東西完全不同。RPO 往回看，量的是事故發生時最多可以接受掉多少資料，決定於備份或複寫的頻率；RTO 往前看，量的是從事故到服務恢復最多可以停多久，決定於備援環境與切換速度。畫成一條時間軸，事故點在正中間，RPO 在左邊、RTO 在右邊。兩段的錢花在完全不同的地方，把預算全砸在其中一段，另一段一步都不會動。
這兩個數字要怎麼訂才合理？
從業務端反推，不要從機房設備反推。問三件事：停多久客戶會開始改單或退單、掉多少筆人工補得回來、公司願意為這兩件事付多少年費。訂出來的數字要能對應到一張具體的報價單，否則它只是會議紀錄上的一行字。常見做法是分級：核心交易系統壓到小時級與分鐘級，報表與歷史查詢放寬到一天，這樣錢才會落在真的擋不住的環節。
RPO 想做到 15 分鐘，是不是每 15 分鐘備份一次就好？
定期快照只是其中一種做法，而且要考慮備份本身跑多久、跑的時候對線上系統的負擔有多大。多數資料庫的做法是「全量備份加上交易日誌持續傳送」，日誌每隔幾分鐘就送到異地，真正還原時是最近一次全量再疊上之後的日誌。真正要驗證的是還原演練實際能回到哪個時間點，那個實測時間點才是你手上真正的 RPO。
RTO 跟 SLA 上的可用率（例如 99.9%）是同一件事嗎？
兩者管的東西不一樣。可用率講的是一整年允許壞掉的總量，99.9% 大約等於一年 8.76 小時；RTO 講的是單一次事故從發生到恢復的長度。把兩個數字擺在一起才有意思：一個年度可用率 99.9% 的系統，如果每次事故都要修四小時，出兩次就用掉八小時多，第三次直接超標。想守住可用率，通常得先把 RTO 壓下來，或者先讓事故少發生一次。
兩個數字談完之後，還有一張圖在畫事故之後的那塊面積。韌性三角形把恢復過程畫成一塊掉下去又補回來的面積，看的是整段過程累積的總損失；錯誤預算管的則是平時允許壞掉多少，讓團隊在穩定與改版之間有一個可以花的額度。RTO 與 RPO 站在最前面：事故點左右兩段，兩個今天就寫得進合約的數字。
喜歡這篇文章嗎？
每週幫你拆二本好書，把判斷力、好書金句、好問題，直送你的信箱。
不適合你可隨時退訂 · 每週兩封，陪你把書讀進生活。
送出即表示同意我們依隱私權政策使用你的 email。