业务验证为什么不能省
容灾切换涉及存储、主机、数据库、应用、网络多个层次，任何一层遗漏都会让业务在切换完成后依然不可用。只验证存储侧切换成功，等于只证明了数据能读，没有证明业务能用。业务验证清单要按依赖顺序逐层确认，并且必须包含完整的写入路径与批处理任务，因为只读查询常常会命中缓存或只读副本，不能反映真实可用性。
验证层次
| 基础设施层 | 主机在线、网络可达、多路径状态正常 |
|---|---|
| 数据层 | 数据库挂载正常、无长时间恢复、抽样数据可核对 |
| 应用层 | 服务进程启动、端口监听、健康检查通过 |
| 功能层 | 核心业务主流程可读可写、批量任务可执行 |
| 性能层 | 响应时间与吞吐落在约定区间内 |
| 周边层 | 定时任务、消息队列、对外接口逐一确认 |
典型使用场景
- 容灾演练的收尾环节，用清单证明业务真正可用而不只是存储切换完成
- 真实故障切换时按清单快速推进，避免在压力下遗漏关键检查项
- 切换后业务出现零星报错时，用清单定位是哪一层没有验证到位
- 新增业务系统纳入容灾范围时，为该系统补充对应的验证条目
- 演练复盘时统计各层次不通过频率，决定下一轮加固的重点
- 回切前复用同一清单，确认回切方向上的业务能力同样完整
验证清单
| 层次 | 验证内容 | 通过判据 |
|---|---|---|
| 基础设施 | 主机在线、存储路径与网络状态 | 主机识别到目标卷，链路与多路径无告警 |
| 数据 | 数据库挂载状态与抽样比对 | 无长时间崩溃恢复，抽样数据与预期一致 |
| 应用 | 进程启动、端口监听、健康检查 | 健康检查接口返回正常状态 |
| 功能 | 核心交易主流程与批处理任务 | 登录、查询、写入、批处理全部走通 |
| 周边 | 定时任务、消息队列、对外接口 | 任务按计划触发，消息无异常积压 |
| 性能 | 关键交易响应时间与吞吐 | 响应时间落在约定区间且无明显劣化 |
验证推进顺序
验证推进顺序
# 第一步：基础设施——主机在线、存储路径正常、网络可达
# 第二步：数据——数据库正常挂载，抽样表可读且行数符合预期
# 第三步：应用——服务启动、端口监听、健康检查接口返回正常
# 第四步：主流程——按业务清单走通登录、查询、写入与批量任务
# 第五步：周边联动——定时任务、消息队列、对外接口逐一确认
# 第六步：性能基线——记录关键交易响应时间，与切换前对比
# 全部通过后再通知业务恢复访问，任一步失败即按预案回退只读验证不足以证明切换可用：查询可能走缓存或只读副本，真正的风险集中在写入路径和批处理。清单中至少应包含一次完整写入，并确认写入后的数据能在切换后的站点被读到；对外接口还要核对报文编号与时间序列是否连续，避免出现重复或断档。