營運持續計畫（Business Continuity Plan，簡稱 BCP）是預先寫好的程序，說明公司遇到重大中斷時，關鍵業務在中斷期間與之後要怎麼繼續運作。訂定的順序是：先做營運衝擊分析，找出中斷後影響大的業務流程與它能承受的中斷時間，再替支撐這些流程的官網與系統訂出復原時間目標（RTO）與復原點目標（RPO），依目標選擇備份與備援做法，寫成啟動、復原、重建的程序，接著定期演練與更新。以下名詞依美國國家標準與技術研究院（NIST）的應變規劃指南整理。
營運持續計畫與災難復原計畫的分工
NIST 對營運持續計畫的定義是：一組預先訂好的指示或程序，說明在重大中斷期間與之後，組織的業務流程要如何維持。它關心的是訂單能不能接、客服能不能回、貨能不能出，而不只是主機能不能開機。同一份指南把幾種計畫分開：
| 計畫 | 關注對象 | 典型內容 |
|---|---|---|
| 營運持續計畫 | 業務流程 | 中斷期間與之後，關鍵業務如何維持，含替代作業與對外溝通 |
| 災難復原計畫（DRP） | 資訊基礎設施 | 針對重大、通常是實體的中斷，把系統移到替代設施復原 |
| 資訊系統應變計畫 | 單一系統 | 不論在原地或替代地點，把某個系統復原的步驟 |
中小企業不必一次寫出三份文件，但要知道營運持續計畫是上層，官網、訂單系統、信箱各自的復原步驟是它的附件。若客戶或合約要求驗證，國際標準是 ISO 22301（營運持續管理系統），驗證流程以驗證機構的說明為準。
從營運衝擊分析找出關鍵業務與依賴系統
營運衝擊分析（BIA）是分析各項營運功能，以及中斷可能對它們造成的影響。NIST 把它拆成三步：確認業務流程與復原的重要程度、確認每個流程需要的資源、排出系統資源的復原優先順序。實務上可以這樣填：
- 列出業務流程：接單、出貨、收款、客服、官網詢價、內部簽核，每項寫明負責主管。
- 描述中斷影響：會不會停止營收、違反合約交期或讓客戶無法聯繫，影響是否隨時間擴大。
- 對應依賴資源：官網、訂單資料庫、公司信箱、金流與物流串接，以及操作它們的人員與委外廠商。
- 排出復原順序：被多個流程共用的系統排在前面，例如網域與 DNS、登入帳號、資料庫。
這份分析要由業務主管與資訊負責人一起填，避免只依技術難度、而不是業務影響來排序。
RTO、RPO 與可容忍中斷時間怎麼訂
替每個關鍵流程與系統訂三個目標，定義依 NIST 原文：
- 可容忍中斷時間上限（MTD）：業務流程可以中斷、而不對組織造成重大傷害的時間，屬於業務端的判斷。
- 復原時間目標（RTO）：系統元件可以停留在復原階段、而不對業務流程造成負面影響的整體時間。NIST 指出 RTO 必須確保不超過 MTD，所以通常要比 MTD 短。
- 復原點目標（RPO）：中斷後資料必須復原到的時間點。它不屬於 MTD 的一部分，取決於業務流程在復原期間能容忍多少資料遺失。
訂目標時用業務語言提問：「詢價表單停擺時，業務還有沒有其他管道接到詢問？」「中斷前一段時間的訂單若遺失，能不能從金流紀錄重建？」能重建的資料，RPO 可以放寬；無法重建的，RPO 要接近中斷當下。RPO 會牽動備份或同步的間隔，間隔比 RPO 長，就可能損失超出可接受範圍的資料。目標越嚴，備援架構與費用越高，所以每個系統各自訂。
網站與系統的備援層級：冷站、溫站到熱站
NIST 依替代設施的準備程度分成三種，可以對應到網站與系統的備援做法：
- 冷站：有電力與實體設施，但沒有電腦設備。對應到網站，是只有備份檔，出事才租主機、建環境、還原資料。
- 溫站：部分配備資訊系統的空間。對應到網站，是預先備好相同環境的備用主機，出事時還原備份並切換網域指向。
- 熱站：配備硬體與軟體、可以完全運作的異地設施。對應到系統，是持續同步資料、可以快速切換的備用環境。
RTO 短又無法用人工替代的系統，才需要考慮溫站或熱站；能接受較長恢復時間的形象官網，可以先用備份加還原程序對應。備份怎麼配置，參考備份三二一原則的做法。另外要把這些依賴列進範圍：網域註冊與 DNS 管理帳號、SSL 憑證、寄信服務與郵件驗證紀錄、金流與物流的 API 金鑰、管理員的多重要素驗證裝置。任何一項只有一個人能操作，就是計畫裡的單點。
把復原程序寫成啟動、復原與重建三段
NIST 的系統應變計畫分成三個階段，附件可以照這個結構寫：
- 啟動與通知：誰有權宣告啟動、依什麼條件判斷（例如預估中斷會超過 RTO）、通知哪些人。名單包含主機商、網域商、開發廠商與各流程負責人，另存一份在中斷時仍拿得到的地方。
- 復原：依排定順序恢復，例如先確認網域與 DNS，再恢復主機與資料庫，接著是應用程式與對外串接。每步寫明操作者與需要的帳號，期間的替代作業（改用電話接單、官網放暫停公告）也寫進去。
- 重建：NIST 說明這個階段包含測試與驗證系統功能。實務上要核對資料是否完整、表單與金流能否正常送出，再通知內部恢復作業。
中斷原因若是入侵或資料外洩，還有證據保存與通知義務，可參考個資外洩的處理步驟；依法需要通報的，依規定時限同步辦理。
演練與更新：桌上推演到實際切換
NIST 指出，測試是驗證復原能力，訓練是讓人員準備好啟動計畫。演練可分兩種：
- 桌上推演：以討論為主，主持人提出情境與問題，參與者說明自己的角色與回應，用來驗證計畫內容。情境可選「主機商機房中斷」「管理員帳號被盜用」「網域忘了續約」。
- 功能演練：讓負責營運的人員在模擬的營運環境中驗證計畫與應變準備。例如把資料庫備份還原到測試主機，記錄到網站能正常下單花了多久，和 RTO 比較；再看資料停在哪個時間點，和 RPO 比較。
演練後把落差寫成改善項目：還原時間超過 RTO，就調整備援層級或簡化步驟；資料時間點落後 RPO，就縮短備份間隔。NIST 提醒計畫要持續更新，系統改版、換主機商或開發廠商、負責人離職時，都要同步修改計畫與名單。
營運持續計畫常見的缺口
- 有備份但沒量過還原時間：沒人實際還原過，不知道能不能在 RTO 內完成。
- 計畫放在會一起中斷的地方：文件與名單只存在公司主機或單一雲端帳號，中斷時打不開。
- 關鍵帳號集中在一個人：網域、DNS、主機後台與多重要素驗證裝置只在一位同仁或前任廠商手上。
- 委外合約對不上目標：維護合約沒寫支援時段與還原責任，和公司訂的 RTO 不一致。
- 只寫系統、沒寫替代作業：客服與業務不知道系統恢復前要怎麼接單、怎麼回覆客戶。
常見問題
營運持續計畫和備份計畫有什麼不同？
備份計畫處理資料怎麼保存與還原，是營運持續計畫的一部分。營運持續計畫還包含業務恢復的優先順序、各系統的復原目標、中斷期間的替代作業、通知名單與演練。
小公司也需要營運持續計畫嗎？
官網、信箱或訂單系統停擺同樣影響營收。小公司可以從簡化版開始：列出幾個關鍵流程與依賴的系統，訂出復原目標，寫好聯絡名單與還原步驟，再做一次桌上推演。
RTO 和 RPO 是不是訂得越短越好？
不是。目標越嚴格，需要的備援環境、資料同步與維運人力越多。業務影響大、又無法用人工替代的系統才訂嚴格目標，其他系統可以接受較長的恢復時間。
營運持續計畫一定要取得國際標準驗證嗎？
沒有一定。是否取得驗證，視客戶、產業或合約是否要求而定。沒有驗證需求的公司，也可以參考 NIST 的應變規劃指南，建立適合自己規模的計畫。
營運持續計畫多久要檢視一次？
除了固定週期檢視，系統改版、更換主機或開發廠商、關鍵人員異動、演練發現問題時，都應更新計畫。NIST 的範例政策以每年檢視、視需要更新為例，可作為參考。
本文由京采數位科技整理。我們自 2005 年起提供官網設計、系統開發與 Google SEO 服務，實際案例可見成果與案例。
想直接討論你自己的網站狀況，或需要一份初步的搜尋機會評估？
相關主題
下一步
建議先完成營運衝擊分析，替官網、訂單或會員系統各訂出 RTO 與 RPO，再檢查現有備份間隔、主機架構與帳號歸屬是否對得上。京采可以協助盤點網站與系統的主機、資料庫、網域與 DNS 設定，規劃備份排程與備援環境，並在測試主機上做還原演練，確認目標做得到。需要規劃或改版時，可參考網頁設計服務，或直接與我們聯繫。
