在我们承接的迁移项目里，超过一半的延期不是因为技术难度，而是因为前期没确认清楚。割接当晚才发现某个数据没同步、某个依赖服务在云上没有对应产品、某个合规要求没落实——这些问题都可以在迁移前一周用一张清单避免。
下面这 8 项，是我们认为每个上云项目开工前必须确认的内容。
1. 业务依赖关系是否清晰
这是第一项，也是最容易被跳过的一项。迁移前必须画出完整的调用关系图：哪些系统依赖这个数据库、哪些定时任务在读写这张表、哪些第三方系统通过回调接口与它交互。
实战经验：某客户的订单系统迁移后连续两天下不了单，排查发现是支付网关的回调地址白名单没有同步更新。这个依赖在原机房是本地调用，不需要额外配置；上了云就变成了跨网络调用，必须提前报备。
- 梳理完整的系统间调用关系与数据流向
- 标出强依赖（不可用即业务中断）与弱依赖
- 确认所有外部接口的 IP 白名单与回调地址
- 识别定时任务、批处理作业的调度依赖
2. 数据分层与存储选型
不同数据不需要同等强度的存储。把数据按访问频次与生命周期分层，既能满足性能要求，也能显著优化成本。
- 热数据（高频读写）→ SSD 云盘或高性能云盘
- 温数据（低频访问）→ COS 标准存储
- 冷数据（归档备份）→ COS 归档 / 深度归档
- 明确各层数据的生命周期规则与删除策略
常见反模式是"所有东西都放对象存储"或"所有东西都放高性能云盘"——前者取数性能不达标，后者账单超出预算。
3. 合规基线是否落地
政务、金融、医疗类业务有明确的监管要求，这项必须在架构设计阶段就确定，而不是等到上线前才补。
- 明确等保级别与对应的技术要求项
- 确认数据加密要求（传输 TLS / 存储加密 / 密钥托管 KMS）
- 落实日志审计留存期限与操作留痕
- 涉及个人信息的，确认数据分类分级与脱敏方案
- 如需信创适配，提前验证国产软硬件兼容性
4. 容量测算是否有数据支撑
资源规格不能拍脑袋定。至少需要采集近 3 个月的真实运行数据：CPU 与内存的 P95 / P99 使用率、磁盘 IOPS 与吞吐、网络带宽峰值、数据库连接数与慢查询分布。
- 按 P99 峰值配置，而不是按平均值
- 预留 30%–50% 弹性余量应对业务增长
- 区分稳定负载与突发负载，分别选择包年包月与弹性伸缩组合
- 数据库单独核算存储增长曲线，避免上线即需扩容
5. 高可用与容灾方案是否闭环
高可用不是买两台机器就完成了。必须确认故障场景下的切换路径是否真的跑得通。
- 明确 RTO / RPO 目标并确认方案能否达成
- 单可用区故障时的流量切换路径是否验证过
- 数据库主从切换的触发条件与自动/手动策略
- 如涉及两地三中心，确认异地中心的带宽与同步延迟
6. 割接演练是否做过
割接演练是降低风险最有效的手段，也是最容易被跳过的一步。演练至少要验证三件事：数据传输的完整性与一致性、切换脚本的可执行性、回退方案的可行性。
- 在准生产环境完整走一遍割接流程
- 制定明确的回退决策条件与回退操作手册
- 确定割接窗口、业务冻结范围与对外公告口径
- 明确各方职责：谁做验证、谁做决策、谁执行回退
7. 监控告警是否覆盖全链路
上云后如果仍靠"用户投诉才知道出问题"，那这次迁移就没有真正完成。
- 覆盖计算、网络、存储、数据库四类基础指标
- 业务层关键路径埋点与告警（如下单成功率、支付成功率）
- 配置容量水位预警，提前发现扩容需求
- 明确告警接收人、升级路径与响应时限
8. 运维责任与流程是否明确
系统上了云，运维由谁做、故障找谁、变更谁批——这些必须在切换前写进文档并让所有相关方确认。
- 划分云平台侧、应用侧与业务侧的运维职责边界
- 明确日常巡检项目与周期
- 确定变更管理流程与灰度发布策略
- 约定故障升级机制与关键联系人
写在最后
这 8 项里，任何一项的缺失都会在割接当晚被放大。它们的共同特点是：确认成本很低（通常半天到一天），但缺失成本极高（可能是数周的返工甚至业务事故）。
如果贵司正在筹备上云项目，欢迎把现状发给我们，我们可以帮您做一次免费的迁移前评估，输出一份针对性的检查结果与建议。