连通与网络质量
测带宽、时延、抖动与丢包，覆盖业务高峰与专线故障切换两种情形。只测空闲时段的链路，往往在真实高峰暴露容量不足；测试数据要连续采集，单次抽样不足以说明稳定性，也无法说服评审，也避免为省事而只做抽样。
数据一致性
用校验和与抽样比对验证同步结果，测试断点续传与重试。同步延迟要可观测，并定义可接受的最大滞后，而不是笼统说实时；对账机制要能定期运行，否则小偏差会累积成难以解释的差异，对账频率要写进方案。
身份与权限
验证跨侧单点登录、角色映射与权限回收。重点测离职、转岗与临时授权三类场景，这些最容易留下越权入口；权限清单要与实际系统对应，不能只核对文档，抽查若干账号更有说服力，抽查结果要留档。
故障切换
按预案演练单侧故障，记录实际切换耗时与数据损失量，与业务方确认的恢复目标对照。演练后要修订预案，而不是只出一份报告；未通过项要有整改责任人与复测时间，否则问题会一直挂着，否则预案难以落地。
成本与可运维性
检查资源标签是否完整、费用能否按业务线归集，监控是否统一入口、告警是否可达值班人。这些决定上线后能否持续运营；验收阶段不解决，运营期就会变成长期争论，影响后续投入，建议在验收报告里单列。
适用与不适用
适合谁
- 混合云项目进入验收阶段、能协调多部门的团队
- 要组织跨部门验收的甲方项目经理
- 需要向业务方证明连续性的运维负责人
不适合谁
- 尚未完成架构设计的项目，也没有可对照的基线。
- 不设恢复目标、只要求功能可用的验收
典型场景
某银行在混合云验收中安排了三轮演练：先测专线主备切换，再验证同步断点续传，最后模拟本地机房断电。演练发现切换脚本中一处依赖未更新，修复后重测通过。验收报告把恢复耗时与数据损失量如实记录，由业务与科技部门共同签认。
可执行步骤
- 与业务方确认恢复目标与可接受的数据滞后范围，并写明双方的判定责任人
- 测高峰与故障两种情形下的网络质量，连续采集多日数据，形成基线，并留存原始数据
- 验证同步一致性与断点续传，并运行一次全量对账，记录差异并明确处理人
- 测跨侧身份、权限与回收流程，抽查若干真实账号验证，记录结果并形成清单
- 演练切换并据结果修订预案，登记整改项与复测时间，明确责任人并跟踪关闭
常见坑
- 只在空闲时段测网络，高峰期带宽不足，跨侧调用频繁超时，用户感知非常直接，投诉集中在月末，复测也缺少基准。
- 同步只测成功路径，未测断点与重试，异常场景下数据丢失，对账也很难解释，恢复更无从下手，演练时问题更多。
- 权限只测新增，不测离职与转岗回收，越权入口长期存在，检查时难以自证清白，整改成本很高，复核也难以开展。
- 演练结束不修订预案，同样的问题在下次故障中重复出现，问题会一直挂着，团队也会松懈，后续演练更难推动。
- 报告只写通过项，不记录未通过项与整改计划，验收流于形式，争议时缺少依据，责任也无法界定，检查也难过。
自检与验收清单
- 恢复目标是否由业务方书面确认，是否有书面记录
- 网络是否覆盖高峰与故障两种情形，是否连续采集
- 同步一致性与断点续传是否验证，是否运行对账
- 权限回收场景是否实际测试，结果是否留档并复核
- 演练后预案是否更新并关闭问题，责任人是否明确
常见问题
恢复目标该由谁定？
由业务方根据停机影响确定，技术方提供实现方案与验证结果。目标不能由供应商单方面承诺，也不能只写技术指标而不对应业务影响，否则验收时双方理解不一致，标准也容易反复变更。
一致性要测到什么程度？
至少覆盖关键业务表的抽样比对与总量校验，并验证断点续传。对时效要求高的数据，还要测同步延迟的分布，而不只看是否最终一致，分布比均值更有参考价值，便于判断高峰风险。
验收报告要包含什么？
测试范围、环境与版本、用例与结果、原始数据、未通过项与整改计划。报告是后续运维与争议处理的依据，不能只写结论，也不能省略未通过项，签认前不要删减记录，验收时逐项核对。