用Gemini起草業務連續性計劃初稿

一句話結論：多數中小企業備份是能用的，但沒有一份寫下來的業務連續性計劃（BCP），而這個缺口往往要等到客戶、保險公司或審計方來要這份文檔時才暴露。Gemini 能把一段對你 IT 環境的平實描述，變成一份像樣的初稿——範圍、RTO 與 RPO 目標、恢復順序、角色分工和溝通安排——用一個下午而不是一個季度。它做不到的是核實這些目標是否真的達得到，而一份沒有演練過的計劃只是文檔，不是能力。

新加坡一家 90 人的建築設計事務所，備份是真的在跑。Veeam 每晚對本地文件服務器和項目數據庫做備份，Microsoft 365 另有第三方備份，IT 經理自己恢復過足夠多次單個文件，對這套流程是信得過的。

然後一家有政府背景的客戶發來了更新版的供應商材料包，裡面多了一條以前沒有的要求：提交你們的業務連續性計劃，包含承載客戶數據的系統的恢復時間目標。投標回覆還有三週。

文檔是沒有的。有的是一張備份計劃表、一個監控看板，以及裝在一個人腦子裡的大量知識。那個誠實的說法——"我們備份很紮實，從來沒丟過東西"——是真的，但它回答不了這個問題，因為問題問的是文件服務器掛掉之後那四個小時會發生什麼、誰來做哪些決定、東西按什麼順序恢復回來。

這篇文章要講的就是這個缺口：不是備份能力（這家公司有），而是那份能證明這種能力、可供他人審閱的書面計劃。它是中小企業 IT 裡最常見的文檔缺口之一，而且正好對得上 AI 助手真正擅長的事。

為什麼多數中小企業有備份卻沒有成文的 BCP

備份之所以被建起來，是因為出過事。計劃之所以被寫出來，是因為有人來要。對多數中小企業來說，第二件事就是會比第一件晚得多，通常晚好幾年，而且觸發它的通常是外部原因而不是內部原因。

這類觸發越來越常見。企業客戶和公共部門客戶會把連續性問題寫進供應商材料包。網絡安全保險的投保材料會問 RTO 和 RPO 數字，以及你們做哪些測試。認證體系要求有成文的連續性安排。母公司的集團審計會向子公司要這份計劃。這些都不是一張健康備份任務的截圖能應付過去的。

它一直沒被做掉的原因是：BCP 是一張實打實很難下筆的白紙。它不是技術文檔，而是運營文檔，需要做出這些判斷：哪些系統按什麼順序才要緊、業務能容忍沒有各個系統多久、誰有權宣佈進入事件狀態、誰去通知客戶。一個被要求從零寫出這份東西的 IT 經理，理所當然會把它排在真正壞掉的事情後面，每一次都是，直到截止日期來臨。

面對一段環境描述，Gemini 實際能起草出什麼

Gemini 既有獨立的助手形態，也整合進了 Google Workspace，可以直接在 Docs 裡起草。它對長輸入的處理能力，讓"把一整段環境描述粘進去"變得可行——系統、依賴關係、站點、人數、哪些在雲上哪些在本地——從這份描述出發，而不是從一個通用模板出發。具體有哪些功能取決於你的套餐和版本，所以請查閱當前文檔，不要憑印象假設。

誠實的定位是：它把一張白紙變成一份可審閱的草稿。你得到的是結構、術語和完整度：評估方期望看到的那些章節、你本來就該問的那些問題、把你已經知道的東西排列好。裡面的每一個數字都只是一個待你確認或替換的提議，而這份計劃只有在有人真的測過之後才成立。一份寫完從未演練過的 BCP，是一份會在最需要它的那一刻失效的文檔。

一份結構化提綱——範圍、RTO 與 RPO 目標、恢復順序、角色

有效的提示詞不是"給我們寫一份 BCP"。而是一段你的環境描述，加上對計劃結構的要求，並且凡是需要業務側（而不是 IT 側）拍板的地方，都要明確留出佔位。

一套可用的結構：範圍，以及哪些內容被有意排除在外；覆蓋哪些中斷場景——場地不可用、系統故障、勒索軟件、關鍵供應商中斷；按重要性分層的系統清單；每一層的 RTO 與 RPO；恢復順序及其依賴關係；角色，並指定替補；啓動標準以及誰有權宣佈；對內與對客戶的溝通；以及測試和複審的時間表。

其中有兩項值得特別注意，因為 AI 起草的計劃通常就栽在這裡。RTO 和 RPO 是業務決策，不是 IT 偏好——公司在沒有某個系統的情況下能撐多久，以及能承受丟掉多少工作量。請把它們作為留給業務側回答的明確問題來要求輸出，並把模型提出的任何數字都當作啓動這場對話的引子。

把一份系統清單變成有優先級的恢復順序

真正有用的第二項產出是排序。多數中小企業的系統清單要麼按字母排，要麼按歷史排；幾乎沒有一份是按"什麼必須先回來"排的，而計劃的成敗恰恰就在這個排序上。

把依賴關係講清楚——項目數據庫需要文件服務器上的共享目錄、報價工具要靠本地目錄服務做身份驗證、VPN 必須先通遠程員工才能幹活——然後要求據此推導出一個恢復順序，每一步都寫明所依賴的前提。回來的結果通常八成是對的，而錯的那一處很有啓發性：它往往是團隊早已習以為常、不再注意的某個依賴。光是把它找出來，這一趟就不虧。

一套可複用的流程——從"我們跑的是這些"到一份可審閱的初稿

1. 先把環境描述寫成一份文檔。系統、版本、各自跑在哪裡、由什麼備份、多久一次、備份落到哪裡、誰在管。不管你最後寫不寫計劃，這份東西本身就有價值，而後面每一步都取決於它準不準。

2. 先要結構，再要內容。先拿到章節清單，和客戶或保險公司實際提出的要求對一遍，在寫出任何一段正文之前把它調整好。改提綱很便宜；重構一份寫完的稿子不便宜。

3. 要問題，而不只要答案。明確要求它列出：這份草稿需要業務側提供、而 IT 無法自行決定的是哪些——各系統可容忍的停機時長、可接受的數據丟失量、誰能批准啓動。把這份清單拿去找一位董事。這場對話才是真正的工作，草稿存在的意義是把它挑起來。

4. 一節一節地起草，每次提示詞裡都帶上你自己的環境。通用的連續性套話毫無價值；一段點名了你的文件服務器、你的備份工具和你真實依賴順序的文字則不然。全程把環境描述保留在上下文裡。

5. 用工程師而不是審閱者的眼光去讀那個恢復順序。逐步對照現實走一遍：域控掛了那台服務器還連得上嗎、這次恢復需不需要一把沒人手上有的許可證密鑰、在規定的時間窗裡帶寬夠不夠把那麼多數據拉回來。凡是你不確定的每一步，都標出來。

6. 用證據來定 RTO 和 RPO，然後演練。真的去計一次有代表性系統的恢復耗時，用那個數字，而不是用一個願望。然後拉上計劃裡點名的那些人做一次桌面推演，並記下日期——"你們上一次測試是什麼時候"現在已經是常規問題了。

AI 起草的 BCP vs 顧問撰寫的 BCP vs 乾脆沒有書面計劃

AI 起草的初稿。消除了白紙，快速產出一份完整、結構常規的文檔，而被低估的那一半是：它會生成一份"需要業務側回答的問題"清單。它無法核實任何一個目標，對你環境的瞭解不超過你粘進去的內容，而且會為一次從未嘗試過的恢復寫出自信而像模像樣的文字。正確用法：快速拿到一份可審閱的草稿和一份決策清單，同時把每個數字都當作臨時值。
顧問撰寫的計劃。帶來方法論、與同行業其他組織如何處理同類風險的橫向比較，以及一個外部方敢於挑戰樂觀假設的意願。它要花真金白銀，週期以周計；而常見的失敗是：交付、歸檔、從未演練——和一份糟糕計劃的下場一樣，只是價格更高。正確用法：受監管或合同要求嚴格的場景，以及複雜到排序真的需要專業判斷的組織。
乾脆沒有書面計劃。在一家很小的公司裡，如果一個人就能把整套恢復裝在腦子裡、又沒人來要這份文檔，這不必然算失職。但只要客戶、保險公司或審計方一開口，它就站不住了——或者只要那一個人休假時文件服務器剛好掛掉，它也站不住。正確用法：一旦有任何外部方在問，基本就沒有正確用法了，而且現在問的人只會越來越多。

一份未經測試的草案計劃危險在哪

沒人量過的 RTO 只是一個數字，不是目標。寫進計劃裡的"四小時"如果從未測過，它就是一整套假設：恢復吞吐量、許可證可用性、手邊有硬件、以及那個懂流程的人聯繫得上。真實的恢復在第一次嘗試時，往往要花掉估計值的好幾倍時間，而第一次嘗試不應該發生在事件當中。

一份點了名卻沒人演練過的角色分工，會卡在第一個決定上。真正失敗的那一步很少是技術性的。它是這樣一個時刻：計劃寫著由事件負責人宣佈啓動，而沒人確定眼下這個情況算不算、或者自己有沒有權限批准這筆支出。一次桌面推演一小時就能把它暴露出來；一次真實中斷則是用昂貴的方式暴露它。

一份寫得很自信的文檔可能讓你更不安全。這正是一份建立在未經測試假設之上的精良計劃的特有風險：它把一個誠實的不確定，轉換成了一句明確的承諾。向保險公司或客戶提交一個數字是一種陳述，而計劃書不是一個適合樂觀的地方。凡是某個目標尚未核實過，就在文檔裡寫明，並給出你打算測試它的日期。

把這件事做對——提示詞裡的基礎設施細節、計劃測試，以及何時該讓 IT 介入

你要描述多少環境細節，請有意識地決定。一份有用的草稿需要的是系統角色、依賴關係和大致規模。它不需要主機名、IP 地址規劃、對外端點、管理員帳號名，或者你備份廠商的門戶信息——一份詳盡描述你基礎設施及其恢復薄弱點的文檔，恰恰是攻擊者最想要的那份。描述功能而不是標識符，並在粘貼任何內容之前，先確認你自己關於企業版與個人版 AI 帳號的政策。

把計劃壓到在壓力下真的能用的長度。連續性計劃因為太長而失效的次數，和因為內容不對而失效的次數差不多。事件當中真正用得上的就那麼幾頁：啓動標準、誰做什麼、恢復順序、聯繫人名單。其餘都是附錄。請明確要求做這個拆分，因為放任不管的助手會產出一份長度均勻的大文檔。

在排序和測試這兩件事上讓 IT 介入，因為計劃真正成形就在這裡。哪個系統是真的必須最先恢復、你現在跑的備份計劃能不能支撐你寫下的 RPO、面對勒索軟件場景有沒有不可變或離線副本、一次完整恢復到底要多久——這些問題靠測試回答，不靠起草。而這也正是一份計劃不再只是紙面的地方。

弄清楚助手在連續性工作裡到底能幫上什麼忙——以及它的輸出在任何人依賴它之前必須先被測試過——這屬於 AI+ 支援的範疇。文檔背後的那份能力，包括圍繞 RTO 與 RPO 的 BCP 策略與方法、本地與跨雲備份、備份介質異地存放，以及定期恢復演練，屬於雲託管備份，由同一支真到執行計劃時會上場的 IT 支援團隊負責。關於"演練而不是歸檔"這套紀律，可參見我們關於生成事件響應桌面推演場景的文章；關於同一套結構化手冊手法用在系統上線上，可參見起草 UAT 腳本與割接手冊。

常見問題

一份草案計劃能滿足審計師或保險公司真正要的東西嗎？

一份結構良好的文檔能讓你過第一問，過不了第二問。評估方會問你的 RTO 是多少、這個數字是怎麼來的、上一次測試是什麼時候、測出了什麼——而一份目標沒人量過、也沒有測試記錄的計劃，只回答得了第一問。把草稿當作讓這場對話得以開始的東西，然後真的去量、去演練，因為被評估的其實是後面這些。

我們的環境描述需要具體到什麼程度？

在功能和依賴關係上要具體，在標識符上要模糊。草稿需要知道的是：你的項目數據庫依賴本地文件服務器上的共享目錄、遠程員工通過 VPN 訪問它、每晚備份落到一台 NAS 上並每週做一次異地副本。它不需要主機名、地址或帳號名。這樣拆分，你既能得到一份紮根於真實環境的草稿，又不會把這個環境的地圖寫下來。

這能取代一次真實的恢復演練嗎？

不能，而這是最需要守住的一條界限。起草產出的是一份計劃；演練產出的是"這份計劃管用"的證據，以及——幾乎每次都有——一份"這些地方不管用"的清單。常見的發現都很平淡卻很關鍵：一次恢復比預想的久太多、一把誰都找不到的許可證密鑰、一個從來沒人寫下來的依賴。如果先寫計劃有助於你組織這次演練，那就先寫；但讓計劃變成真的那一步，是演練。

BCP 該多久更新一次？

既要按週期，也要按變更來，而且變更這一項更要緊。一年一次複審加一次測試是常見基線，也是多數評估方期望看到有記錄的做法。但真正會讓計劃失效的，是系統遷上雲、開了新辦公室、換了備份平台，或者點名的事件負責人離職這類變化——任何一件都可能在年度複審之後一週內就讓文檔失準。請把計劃更新明確掛在這些事件上，而不是隻掛在日曆上。