几年前，不少企业老板聊上云，想的还是省服务器的钱。现在再谈，问题变了。系统稳不稳、数据安不安全、业务能不能跑快一点，以及云上的投入能不能算清楚，才是大家真正关心的。阿里云吴翰清这些年一直在参与和观察这轮转变，他的不少判断放到今天的企业数字化里，仍然有参考价值。
这篇文章不讲行业大词。我们从几个具体场景入手，说说企业上云时会碰到的麻烦，以及可以直接借鉴的做法。
一、上云要重新设计，光搬家不够
很多企业第一次上云，习惯把本地机房里的服务器、数据库和应用原样搬到云上。搬这一步不难，麻烦在搬完之后：成本没降，性能没升，运维反而更乱。
某区域性零售连锁企业就是这样。它的会员系统部署在自建机房，每逢大促要提前采购硬件，促销一结束，大半设备闲着。上云初期，团队同样把虚拟机整体搬过去，账单一直降不下来。后来他们把会员查询、积分计算等模块拆开，按流量弹性伸缩，非实时的报表任务则转到离线计算服务上跑。半年后，资源成本下降不少，大促期间系统也更稳。
这个案例说明，上云要看业务架构怎么改。云的弹性、标准化和自动化能力，只有架构配合了才用得上。吴翰清在公开交流中也多次提到类似看法。
二、数据安全先守住底线
企业对上云最大的顾虑，通常是数据安全。数据放在别人的机房里，出了问题怎么办？这份担心有道理。但如果就此认定“云不安全”，又会走向另一头：为了安全拒绝上云，最后错过发展窗口。
比较成熟的做法一般有四步：
- 给数据分级。先列清楚哪些可以放公有云，哪些应放在专有云或混合云环境里。
- 账号按最小权限分配，不要让一把访问密钥打通所有系统。密钥泄露时，影响范围会小很多。
- 开通日志审计和异常告警，出了事能查到是谁、从哪里、做了什么。
- 定期做备份和灾备演练。备份做了却没验证过能否恢复，等于没有备份。
一家做医疗影像的中型公司就是这样推进的。患者原始影像放在符合监管要求的专属区域，训练 AI 模型用的脱敏数据则放在公有云上，借助云端算力加快研发。分区处理既守住了合规线，也保留了云的效率。
三、成本要能对到具体团队
上云后的第二个难题是成本失控。按需付费本是云的优点，但如果没有配套管理，资源随手开、用完不关，账单会悄悄变大。
一家互联网教育公司的做法可以参考。它为每个业务团队设置独立的成本中心，并给资源打上标签，每一笔钱花在哪里都能查到。它还定期清理闲置实例：长期稳定的负载买预留计费，波动大的任务用弹性或抢占式实例。方法不复杂，难的是坚持，要让成本数据进入团队的日常决策。
四、人和组织，常常比技术更难
选型可以请厂商帮忙，但决定上云效果的，往往是团队能不能用好这些工具。习惯管理物理服务器的传统 IT 团队，转到云上做资源编排、持续集成和自动化运维，需要一段适应期。
务实的做法是先挑一两条业务线试点，积累经验后再推广。开发、运维和安全人员最好放在一起协作，否则很容易各干各的，出了问题互相推。有些企业会设一个内部云平台团队，负责定规范、沉淀最佳实践，让后面的项目不用每次从零摸索。
五、开工前先想清楚的几件事
如果你所在的企业正准备上云，或者要扩大云上业务，可以先把下面几点写清楚：
- 目标排个序：最想解决的是成本、弹性，还是上线速度？目标不同，先上哪些系统、选什么架构都会不同。
- 给系统分批次：看每个系统的依赖关系和改造难度。边界清楚、依赖少的系统适合先搬，核心交易系统通常留到后面。
- 盘点团队能力：看现有人员会不会容器、自动化和云上权限管理。缺的部分用培训或外部伙伴补上。
- 定好衡量指标：比如单位业务量的云成本、发布频率、故障恢复时间，每月看一次，判断方向对不对。
上云是持续推进的过程，没有一步到位的方案。吴翰清谈到的这轮思考，落点很实在：让技术服务业务，让云能力落到具体场景里，少谈概念，多看结果。
