先定基准负载
用真实业务的一段流量做基准，包含正常请求、批量任务与峰值突发。为什么不用跑分工具：跑分与实际业务的读写比例、并发形态差别很大。边界是涉及敏感数据时，用脱敏样本与影子流量，别把生产库直接搬过去。
测网络与链路
私有化的专线延迟、抖动与丢包，公有云的跨区与出网时延，都要实测。怎么做：在业务时段连续测一周，记录分位值而不是平均值。边界是平均值好看但长尾差，用户体验依然会投诉，验收时也会被质疑。
做故障演练
断网、节点故障、存储降级与证书过期，都要在验证期演练一次。为什么必要：部署形态的差异往往在故障时才显现。怎么做：记录发现时间、恢复步骤与耗时，形成演练报告并留档，以此判断稳定性，并留存记录。
按实际用量记账
验证期把两套环境的资源用量、流量与人力工时逐日记账，而不是按报价推算。怎么用：用实际用量乘以单价，得到可比成本。边界是短期用量不代表长期，需标注季节性因素与增长假设，否则结论会失真。
适用与不适用
适合谁
- 正在两套部署方案之间犹豫的企业
- 需要向上级提交可比数据的项目组
不适合谁
- 还没有真实负载、只能靠估算的团队
典型场景
某集团在专属云与自建机房之间做验证：同一套检索服务在两套环境跑两周，记录时延分位值、错误率与专线抖动，并做了一次断网演练。结果显示自建机房长尾时延更差，最终选择专属云，把自建机房留作灾备，验证报告一并归档。
可执行步骤
- 选一段真实流量做基准，覆盖正常请求、批量任务与峰值突发，并冻结样本，逐项确认后归档
- 在业务时段连续测一周链路，记录延迟分位值、抖动与丢包，形成周报，并标注假设
- 做断网、节点故障与存储降级演练，记录恢复步骤、耗时与责任分工并留档
- 逐日记录资源用量、流量与人力工时，按实际用量折算成本并核对账单，并留存记录
- 用同一套指标比较两套环境，写明结论、假设、保留意见与复核人，形成对比表
常见坑
- 用跑分工具代替真实业务，读写比例与并发形态不同，结论无法外推，验证等于没做，决策也失去依据。
- 只记录平均时延，忽略长尾，上线后少数请求超时，投诉集中出现，排查也很费时，责任还难界定，整改也慢。
- 验证期不做故障演练，故障时才暴露差异，恢复时间远超预期，业务部门对方案失去信心，推进受阻，预算容易被反复追加。
自检与验收清单
- 基准负载是否覆盖正常、批量与峰值三类请求并留档
- 链路指标是否记录分位值而非仅记录平均值，并复核
- 故障演练是否覆盖断网、节点故障与存储降级并演练
- 实际用量与人力工时是否逐日记账并归档并归档
常见问题
验证要跑多久？
两周能看出常态差异，一个月能覆盖月末或季末峰值。时间不足时优先保证覆盖峰值与故障场景，而不是延长平稳期的观察，否则结论只适用于理想状态，无法支撑采购决策。
没有生产流量怎么办？
用脱敏样本回放或影子流量。关键是保持请求比例、并发形态与数据规模接近真实，并在报告里注明假设。完全用合成数据，结论只能作参考，不能作为唯一决策依据，也不宜据此定容量。
验证不通过怎么办？
先判断是方案不匹配还是配置未调优。若是容量或网络问题，可调整后复测；若涉及合规硬约束，应直接放弃该方案，而不是靠临时措施绕过，否则上线后仍会被叫停，返工成本更高。