上云规划最容易犯的错误，是一开始就进入产品清单。真正决定架构形态的，是业务目标与约束。

1. 用户在哪里，访问高峰是什么时候？

用户分布决定区域、CDN 和网络策略。除了平均流量，还要了解发布、促销或活动带来的峰值倍数。

2. 哪些链路不能中断？

给业务链路分级，分别定义可接受的恢复时间（RTO）和数据丢失范围（RPO）。不是所有服务都需要同等高可用。

3. 数据如何增长？

梳理结构化数据、文件、日志和缓存的规模与访问方式。数据库类型应匹配查询和一致性需求。

4. 当前系统有哪些依赖？

列出外部 API、固定 IP、许可证、本地文件和定时任务。这些经常成为迁移中的隐藏阻塞项。

5. 安全责任如何划分？

云厂商保护云本身，团队仍负责身份权限、数据、配置和应用安全。最小权限与审计应从第一天开始。

6. 团队能维护多复杂的架构？

技术上先进不等于适合。优先选择团队能理解、监控和恢复的方案。

7. 成本边界是什么？

同时估算稳定成本与峰值成本，并为日志、网络流量、备份等容易忽略的项目留出空间。

下一步

把这些答案整理为一页约束清单，再画出最小可用架构。产品选型会因此变得清晰。