4. 容灾演练工程生命周期

容灾演练不是一次性的“切库表演”，而是一项有生命周期的工程活动。它从业务对灾难恢复的真实诉求出发，经过方案设计、资源与脚本准备、现场执行、结果评估，最终沉淀为优化项并转入常态化运营。理解这条生命周期，才能避免“演练时成功、真故障时失效”的常见困境。本节按阶段展开每个环节的关键输入、实际做法与判断依据。

需求分析：把业务语言翻译成 RTO/RPO 指标

需求分析的核心是确定“能容忍丢多少数据、能容忍停多久”。这一步必须与业务方共同完成，而不是由 DBA 单方面拍板。典型做法是梳理核心业务系统清单，对每个系统标注业务等级、交易峰值、数据变更频率和监管要求，再据此推导 RTO（恢复时间目标）与 RPO（恢复点目标）。

例如某订单系统，业务方要求“故障后 30 分钟内可下单，最多丢失 5 分钟数据”，则 RTO=30min、RPO=5min。这两个数字直接决定后续技术选型：RPO=5min 意味着归档日志传输间隔必须小于 5 分钟，RTO=30min 意味着切换脚本加验证必须在 30 分钟内跑完。需求分析阶段还应识别依赖关系，如订单系统依赖用户中心、支付网关，演练范围必须覆盖这些上下游，否则单库切换成功也无法恢复业务。

方案设计：从指标反推技术架构与切换策略

方案设计要回答三个问题：用什么容灾架构、切换由谁触发、失败如何回退。以 Data Guard 为例，若 RPO 要求接近 0，应选择最大保护或最高可用模式；若可容忍少量丢失，最高性能模式配合异步传输更合适。方案中需明确主备角色、保护模式、日志传输方式、切换类型（Switchover 计划切换 / Failover 故障切换）以及回退路径。

设计阶段还应产出切换决策表，把“什么条件下执行什么动作”写清楚。例如：主库实例宕机但主机可登录，优先尝试重启；主机整体不可用且备库同步延迟小于阈值，执行 Failover；若备库延迟过大，则先评估数据丢失影响再决定是否强制切换。决策表把临场判断变成事前约定，是演练能否有序执行的关键。

演练准备：把方案变成可执行的检查单

准备阶段决定演练能否“可控”。需要落实的内容包括：切换脚本与验证脚本、专用账号与权限、备库快照或备份回退点、监控项与告警阈值、通知机制、人员分工与时间窗。以一次计划内 Switchover 演练为例，准备清单可包含：确认备库延迟为 0、确认归档日志已全部应用、记录主备当前 SCN、创建备库快照、准备业务验证 SQL、通知相关方进入演练窗口。

准备阶段还应做一次“桌面推演”，即不真正切换，只按脚本逐条走查命令与判断分支，确认脚本路径、环境变量、密码文件、监听配置均可用。很多演练失败并非技术不可行，而是脚本里写死了旧 IP、密码过期或目录不存在。桌面推演能以极低成本提前暴露这些问题。

执行：按决策表操作并全程计时

执行阶段要严格按方案与决策表推进，同时记录每个关键动作的时间戳。以 Switchover 为例，典型动作序列为：停止应用写入 → 确认备库无延迟 → 主库执行角色转换 → 备库转为 PRIMARY → 启动监听与应用连接 → 执行业务验证 SQL → 记录切换完成时间。整个过程需有人专门计时，因为 RTO 是“从业务中断到业务恢复”的墙钟时间，而不是某条命令的执行时间。

执行中若出现异常，应按预案判断是继续、回退还是升级。例如切换后备库无法打开，应立即检查告警日志与数据文件状态；若短时间无法恢复，则启用回退点恢复原主库，避免演练演变成真实故障。

评估与优化：用数据说话，把问题闭环

评估阶段要把实际结果与需求指标对比。例如需求 RTO=30min、RPO=5min，实际切换耗时 22min、数据丢失 0，则达标；若实际耗时 45min，则需分析时间花在哪里——是应用连接切换慢，还是验证脚本执行久。评估还应包含数据一致性校验，如对比关键表行数、检查序列当前值、验证业务流水号连续性。

优化阶段把评估发现的问题转化为可跟踪的整改项，明确责任人与完成时间。常见优化包括：把手工命令固化为脚本、调整 Data Guard 参数降低延迟、补充应用连接串自动切换配置、增加监控告警项。优化完成后应更新方案书与检查单，形成版本化文档。

常态化运营：让容灾能力持续可用

演练结束不等于工作结束。常态化运营要求把演练纳入年度计划，例如每季度一次桌面推演、每半年一次计划内切换、每年一次模拟故障切换。同时把容灾监控接入日常告警体系，对备库延迟、归档传输中断、保护模式降级等关键状态设置阈值告警。人员方面应建立轮训机制，确保关键岗位至少两人能独立执行切换，避免“只有一个人会”的单点风险。