用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 该多久更新一次？

既要按周期，也要按变更来，而且变更这一项更要紧。一年一次复审加一次测试是常见基线，也是多数评估方期望看到有记录的做法。但真正会让计划失效的，是系统迁上云、开了新办公室、换了备份平台，或者点名的事件负责人离职这类变化——任何一件都可能在年度复审之后一周内就让文档失准。请把计划更新明确挂在这些事件上，而不是只挂在日历上。