4. 演练计划制定：年度计划、季度计划、月度计划、周计划的时间安排

说实话，很多金融客户第一次找我做灾备咨询时，上来就问：「我们能不能一个月搞一次全量演练？」

我的回答通常是——你先把年度计划排出来，咱们再聊频率。

灾备演练不是拍脑袋定的。它跟你的业务连续性等级、监管要求、系统复杂度、甚至预算都挂钩。我这些年踩过的坑告诉我：没有分层级的计划，演练就是一场灾难。

4.1 年度计划：定调子、划红线

年度计划是纲领性文件。我个人习惯在每年11月启动下一年度的演练规划，因为这时候监管的年度检查刚结束，该暴露的问题都暴露了。

年度计划要回答三个问题：

1. 演练目标——今年要验证哪些关键系统？要达到什么RTO/RPO？
2. 监管合规——银保监会、央行、证监会要求的演练频次是否覆盖？
3. 资源预算——机房、网络、存储、人力，这些够不够？

举个例子，我曾经帮一家城商行做年度计划，他们原本只打算做2次全量演练。我翻了翻监管要求，发现他们核心系统的RTO要求是15分钟，但过去一年从未验证过。最后我们硬是排了4次全量演练，覆盖了所有核心链路。

时间节点	工作内容	产出物
11月-12月	复盘本年度演练，收集问题	年度演练总结报告
1月	制定年度演练计划，审批	年度演练计划书
2月-11月	按计划执行，季度复盘	季度演练报告
12月	年度总结，下一年规划启动	年度演练评估报告

4.2 季度计划：定场景、分优先级

季度计划是把年度目标拆解成可执行的场景。我一般按「系统重要性」和「风险等级」两个维度来排。

为什么是季度？因为金融系统的变更周期通常是季度。每个季度末，系统版本冻结，这时候做演练最安全。

我记得有一次，某客户在季度计划里排了「核心交易系统全量切换」，但没考虑到那个季度正好赶上他们做数据库版本升级。结果演练当天，新版本的复制链路出了问题，差点酿成生产事故。从那以后，我要求季度计划必须跟变更计划对齐。

季度计划模板：

Q1：核心交易系统全量切换 + 数据库容灾验证
Q2：支付网关 + 风控系统 半量切换
Q3：全链路压测 + 存储容灾切换
Q4：年度综合演练（含监管验收）

4.3 月度计划：定人员、定步骤

月度计划是执行层面的东西。说白了，就是「谁、在什么时间、做什么事」。

我建议月度计划包含以下内容：

• 演练窗口——具体到哪一天、几点到几点
• 参与人员——操作组、观察组、应急组，名单要落实到人
• 操作步骤——不是详细脚本，而是关键步骤清单
• 回退方案——演练失败怎么办？谁决策回退？

嗯，这里要注意。月度计划不要写得太细，否则没人看得完。我一般控制在2页以内，核心是「时间、人、关键动作」。

4.4 周计划：定细节、定脚本

周计划是演练前一周的「冲刺计划」。我个人习惯在演练前一周的周一发出周计划，周三做一次预演，周五正式演练。

周计划包含：

1. 详细操作脚本——每一步的命令、预期结果、异常处理
2. 环境确认——演练环境是否就绪？数据是否已同步？
3. 通知清单——哪些人需要收到演练通知？哪些人需要旁站？
4. 应急联系人——网络、存储、数据库、安全，各领域的接口人

你想想看，如果周计划里没有写清楚「演练期间禁止执行生产变更」，那很可能演练到一半，有人跑上去改了个配置，整个演练就废了。我遇到过，真的遇到过。

4.5 时间安排的核心逻辑

说了这么多，其实核心逻辑就一句话：年度定方向，季度定重点，月度定任务，周度定执行。

我画了一张图，帮你理解这个分层关系：

这张图我用了很多年，每次给客户讲演练计划，我就拿这张图出来。你看，从上到下，粒度越来越细，但每一层都跟上一层对齐。年度计划里定的目标，在季度计划里变成场景，在月度计划里变成任务，在周计划里变成脚本。

最后说一句：计划不是用来锁死的，是用来指导的。我见过太多团队，计划写得漂漂亮亮，但执行的时候完全走样。真正好的计划，是让每个人都知道「我该做什么、什么时候做、做错了怎么办」。