切换演练怎么执行与计时
切换演练按真实流程做一次计划内切换，并给每个阶段单独计时。它的产出有两份：一份实测 RTO 数据，一份待整改的问题清单。只记录总耗时不足以定位瓶颈，只有把隔离、提升、引流、验证各段拆开，才知道该优化哪里。
基本信息
| 计时边界 | 从『决定切换』到『业务验证通过』，与 RTO 定义保持一致 |
|---|---|
| 阶段划分 | 停写或隔离 → 提升备侧 → 应用启动与健康检查 → 入口引流 → 业务冒烟 |
| 记录方式 | 每阶段单独记录开始与结束时间，并标注操作人 |
| 产出物 | 实测 RTO、失败步骤、改进项与责任人、需要修订的预案条款 |
典型使用场景
- 计划内维护切换：机房搬迁、硬件更换时按流程走一遍
- 预案有效性验证：检验文档是否与真实环境一致、步骤是否可执行
- 自动化切换回归：上线自动切换能力后用同口径复测耗时
- 新成员培训：让值班人员亲手执行一次，熟悉操作与判断点
- 双活站点轮换：定期切换主备角色，避免长期只用一侧导致另一侧腐化
执行与计时骨架
执行与计时骨架
T0=$(date +%s)
# 阶段一：停止主侧写入/隔离
date '+%T 隔离开始'
# 阶段二：提升备侧（数据库提升、应用启动、健康检查）
# 阶段三：应用启动与健康检查
# 阶段四：VIP/DNS/负载均衡引流切换
# 阶段五：业务冒烟验证（核心链路，不停留在能打开页面）
date '+%T 验证通过'
T1=$(date +%s)
echo "总耗时: $((T1-T0)) 秒" # 与 RTO 目标对比阶段耗时与常见短板
| 阶段 | 典型耗时来源 | 观察要点 |
|---|---|---|
| 停写隔离 | 等待业务排空、长事务结束 | 长事务会让切换起点推迟，需提前确认 |
| 提升备侧 | 数据一致性校验、日志补齐 | 若需等待延迟归零，说明复制策略有改进空间 |
| 应用启动 | 依赖服务连接、配置指向 | 应用侧写死旧地址是常见阻塞点 |
| 入口引流 | DNS 生效时间、负载均衡健康检查窗口 | TTL 设置过长会显著拉长这段耗时 |
| 业务验证 | 缺少冒烟用例、验证靠人工点页面 | 应固化脚本与判定标准 |
第一次演练超时很常见：把它当作基线，优化瓶颈后复测，而不是掩盖结果或直接调整目标值。
切换演练必须有回退路径与回退时限：若验证不通过，要能在约定时间内回到原侧，并保证回切时两侧数据对齐。