制定演练计划：范围、目标与成功标准
演练计划是整个恢复演练的「施工图纸」。图纸画歪了，后面再努力也是白搭。我见过太多团队，一上来就喊「我们要做全量灾备切换」，结果连业务系统的主备关系都没理清，演练当天乱成一锅粥。
说白了，制定计划就是回答三个问题：练什么？练到啥程度？怎么算练成了？ 咱们一个一个拆开讲。
定义演练边界：别想一口吃成胖子
很多同学问我：「老师，演练范围是不是越大越好？」我的回答永远是：不是。范围越大，风险越高，失败概率也越大。我早年在一家电商公司，第一次做全站切换演练，把支付、订单、库存、物流全拉进来，结果支付网关超时，整个演练被迫中止，排查了三个小时才发现是测试环境的路由策略配错了。
从那以后，我养成了一个习惯：用「最小可行范围」原则来切分演练边界。
核心原则：每次演练只覆盖一个「业务能力单元」。比如「用户登录」是一个单元，「商品搜索」是另一个单元。不要跨单元混在一起练。
具体怎么切？我一般按三个维度来定义边界：
- 业务维度：按业务功能划分。例如「订单创建流程」涉及前端、API网关、订单服务、数据库、消息队列。这次演练就只覆盖这个链条。
- 技术维度：按技术栈或组件划分。例如「MySQL主从切换演练」只涉及数据库层，不碰应用层。
- 地理维度：按数据中心或可用区划分。例如「北京机房到上海机房的跨地域切换」。
你想想看，这三个维度可以组合使用。比如「北京机房的订单服务切换到上海机房」，这就是业务+地理的双重边界。
我的经验：第一次做演练的团队，建议从「技术维度」的单组件开始。比如先练一个Redis哨兵切换，成功了再逐步扩大范围。别一上来就搞全链路。
设定可量化的RTO/RPO目标
RTO（恢复时间目标）和RPO（恢复点目标）是演练的「度量衡」。没有这两个数字，你根本没法判断演练是快还是慢、是好还是坏。
但问题来了——很多团队定的RTO/RPO是拍脑袋拍出来的。我记得有一次帮一家金融科技公司做咨询，他们的RTO写的是「30分钟」，我问为什么是30分钟？回答是：「感觉差不多。」结果演练一测，实际恢复用了2小时17分钟。
所以，设定RTO/RPO必须遵循一个原则：从业务需求倒推，而不是从技术能力硬凑。
RTO：业务能等多久？
RTO指的是从故障发生到业务恢复的最大可接受时间。怎么定？我建议你直接去找业务方聊，问他们一个问题：
「如果系统挂了，你们能忍受多久不能干活？」
业务方的回答通常很模糊，比如「最好别超过一顿饭的功夫」。这时候你要帮他们量化。我一般会用这张表来引导：
| 业务场景 | 可接受中断时间 | 对应RTO |
|---|---|---|
| 在线支付 | 1-5分钟 | 5分钟 |
| 用户登录 | 5-15分钟 | 15分钟 |
| 后台报表生成 | 2-4小时 | 4小时 |
| 历史数据归档 | 24小时以上 | 24小时 |
你看，不同业务对中断的容忍度天差地别。把RTO定成统一的「30分钟」本身就是不合理的。
RPO：能丢多少数据？
RPO指的是故障发生时，最多能容忍丢失多少时间的数据。这个数字直接决定了你的备份频率和复制策略。
举个例子：如果RPO是1分钟，那你的数据复制延迟就不能超过1分钟。如果RPO是1小时，那每小时做一次全量备份就够了。
注意：RPO和RTO是相互制约的。RPO越短，技术成本越高（比如需要同步复制、实时备份）。RTO越短，运维复杂度越高（比如需要预启动备用环境）。定目标时一定要考虑成本。
我个人习惯在演练计划里用一张「目标矩阵」来明确每个系统的RTO/RPO：
| 系统名称 | 业务等级 | RTO目标 | RPO目标 | 当前能力 |
|---|---|---|---|---|
| 核心交易库 | P0 | 5分钟 | 0（零丢失） | RTO 8分钟，RPO 30秒 |
| 用户画像服务 | P1 | 15分钟 | 1分钟 | RTO 12分钟，RPO 2分钟 |
| 日志分析平台 | P2 | 2小时 | 15分钟 | RTO 45分钟，RPO 10分钟 |
有了这张表，演练的时候就能对照着看：目标是否达成？差距有多大？
明确「成功」的标准
演练结束，怎么算「成功」？很多人说「系统切过去了就算成功」。嗯，这太粗糙了。我曾经遇到过一个案例：演练时数据库切换成功了，但应用层没连上新库，业务照样不可用。你说这算成功吗？
所以，成功标准必须包含三个层面：
1. 功能完整性
恢复后的系统，核心功能必须可用。我一般会准备一份「功能检查清单」，演练结束后逐条验证：
- 用户能否正常登录？
- 订单能否正常创建和查询？
- 支付回调是否正常？
- 数据一致性是否校验通过？
2. 性能达标
恢复后的系统不能「能用了但慢得要死」。我建议在演练中加入性能基准测试：
- 接口响应时间是否在SLA范围内？
- 并发处理能力是否达到正常水平的80%以上？
- 数据库连接池是否正常？
3. 时间达标
这是最硬性的指标——实际恢复时间是否在RTO范围内？数据丢失量是否在RPO范围内？
成功标准公式：演练成功 = 功能完整 + 性能达标 + 时间达标。三者缺一不可。
我习惯把成功标准做成一个「打分卡」，演练结束后直接打分：
| 检查项 | 权重 | 通过条件 | 实际结果 |
|---|---|---|---|
| 核心功能可用 | 50% | 所有P0功能通过 | 通过/未通过 |
| RTO达标 | 25% | 实际恢复时间 ≤ RTO | 通过/未通过 |
| RPO达标 | 15% | 数据丢失量 ≤ RPO | 通过/未通过 |
| 性能达标 | 10% | 响应时间 ≤ 正常值×1.5 | 通过/未通过 |
只有四项全部「通过」，这次演练才算真正的成功。任何一项不通过，都要记录为「演练未达标」，并制定改进计划。
核心逻辑：从目标到验证的闭环
说了这么多，其实整个演练计划的制定就是一个闭环。我画了一张图，帮你理清思路：
你看，整个流程是从业务需求出发，先定义边界，再设定目标，然后明确成功标准，最后通过演练执行来验证。验证结果反过来又反馈到目标设定和边界定义中，形成持续改进的闭环。
一个小建议：每次演练结束后，花30分钟做一次「复盘会」。对照成功标准逐项分析，把「未达标」项记下来，作为下一次演练的改进重点。这样循环3-5次，你的演练计划就会越来越精准。
好了，关于演练计划的制定，核心就是这三件事：边界要清晰、目标要量化、成功标准要可验证。下次做演练之前，先把这三件事写下来，贴在墙上。演练过程中随时对照，你就不会跑偏。