过去几年，企业上云的问题已经变了。大家已经不太讨论要不要上云，更关心怎么上才划算。把服务器和数据库搬到云上只是起点，决定成效的，是业务系统能否借助云的弹性、数据能力和生态资源重新组织起来。围绕阿里云和蔡华相关的讨论，绕不开的也是这几个问题。
从搬资源到搬能力
早期上云更像搬家。虚拟机、数据库、存储原样迁到云上，计算资源可以按需购买，机房和硬件维护的压力小了。但如果业务流程没有变，成本降不了多少，系统的瓶颈也只是换了个地方继续存在。
这两年，更多企业开始把订单处理、风控判断、客户服务这类能力拆开，做成可复用的服务，再用云原生架构组合起来。技术团队要学的东西变多了，云厂商的角色也从提供机器，慢慢变成提供方法和工具。
一个制造业案例
下面的案例是行业常见情形的示意，具体数字要以实际项目为准。
一家中型机械零部件制造商，最开始只是把ERP系统迁到云上。每年省下一部分硬件采购费用，但生产排期仍然靠老师傅的经验，库存积压一直没解决。
后来，他们把生产数据、设备传感器信息和订单数据汇入云端的数据平台，用机器学习模型预测下游需求，再据此动态调整排产。半年后，原材料库存周转天数缩短了，紧急插单造成的停机也少了。
这个例子里，云带来的变化超出了降本。数据实际进入了排产和采购决策，业务流程才跟着变。如果只做迁移，不改数据的用法，很难得到同样的结果。
上云前先回答三个问题
很多企业规划云上架构时，容易先追新技术，再回头找场景。更稳的做法是先把下面三个问题讲清楚。
- 业务优先级：先列出哪些系统直接影响营收，哪些只是后台工具。前者通常需要更高的可用性保障和更严格的变更流程，后者可以选更省的方案。
- 数据边界：客户资料、财务数据、生产工艺哪些可以放公有云，哪些要私有部署或走混合架构。合规要求最好请法务或信息安全负责人提前确认，别等项目进入中后期再返工。
- 团队能力：云原生意味着新的开发和运维方式，容器、CI/CD、监控告警都需要有人会用。团队没有经验时，培训和过渡期的人力投入要写进预算，不能只算软件费用。
这三个问题并不新鲜，却决定了项目能否从试点走到规模化。很多项目卡住的原因，往往是边界没划清，谁负责哪一段也没说清楚。技术先进与否，通常排在后面。
选平台时，退出成本也要算
云平台的竞争早已不止比单个产品。选型时，除了看计算和存储的性能指标，还要看合作伙伴网络是否成熟，相关开源社区是否活跃，接口和数据格式是否开放。封闭体系短期省心，时间一长，议价能力和迁移自由度都会变弱。
评估时可以问几个具体问题：数据能否完整导出，导出格式是否通用；核心服务是否依赖厂商专有接口，改写成本有多大；合同里有没有明确的数据归还和迁移支持条款。把这些写进评估表，比只比较一次性折扣更能看出长期成本。
结语
回到开头的问题，企业上云的路并不神秘。先想清楚业务，再把数据能力一点点积累起来，最后落到团队和生态的配合上。阿里云的实践和蔡华在相关讨论中的思路，给企业的启发其实是同一个：把云看成需要长期经营的基础设施，别当作一次性采购的东西。
