很多企业把上云当成数字化的第一步。服务器搬进机房，业务跑在弹性资源上，项目看起来就算完成了。现在的问题换了个样子：云上资源越来越多，账单越来越难对齐，安全和合规的要求也越来越细。阿里云吴明的相关讨论大体反映了这种变化。[待核实：吴明的职务、履历和公开发言出处]
从搬家到改造
早期上云的目标很简单，就是把本地系统原样搬到云端，省掉机房运维。这一步确实有价值，但它只解决了基础设施的问题。业务系统的结构没动，云上的弹性能力就用不上，资源账单甚至可能比机房还贵。
现在更常见的是改造。系统拆成微服务，数据库按业务拆分，计算资源按需伸缩。进度卡住的原因往往在人身上。开发、运维和业务团队要重新协作，原来的审批流程和责任划分都得改。
零售企业：大促前后的资源账
某全国连锁零售企业（以下简称“A企业”）过去每年大促前都要临时采购服务器。活动一结束，设备大量闲置，折旧和电费照常发生。流量峰值通常只持续几个小时，峰值之外的资源利用率长期低于20%。
A企业把订单、库存和支付系统迁到云上，并按流量指标设置自动伸缩规则。大促期间，系统能在短时间内扩到平时的数倍容量，活动结束后自动缩回去。团队还设了成本告警：单个服务的资源用量超过预算阈值，就通知负责人。
这个案例里，资源是跟着业务量走的。[待补充：该企业的具体成本降幅和数据来源，需与客户确认后再写入]
银行：数据留在哪里，谁能看
某区域性银行（以下简称“B机构”）上云时最担心两件事：客户数据存在哪里，谁能访问。监管要求明确，部分敏感数据必须留在指定区域，访问还要可审计。
B机构采用了分层方案。核心交易数据留在专属环境中，客户查询和营销分析放在公有云上。两边通过加密通道和脱敏接口连接，每次数据调用都有日志，审计部门需要时可以逐条回溯。
代价是架构更复杂，运维人员得同时熟悉两套环境。对金融机构来说，这笔代价通常可以接受。
选型前先回答的五个问题
规划上云或深度用云时，可以先把下面几个问题过一遍，再定技术路线。
- 业务流量波动大吗？波动越大，弹性伸缩越划算。流量平稳的系统，可以考虑预留资源来压低成本。
- 数据属于哪一类？涉及个人信息、金融数据或行业监管内容的，先确认存放区域和访问审计要求，再谈迁移。
- 团队会不会做自动化？如果运维还以手工操作为主，直接重构容易翻车。可以先把部署和监控自动化，再逐步拆服务。
- 成本能不能分到业务线？没有按业务线分摊的账单，就很难看出哪个系统值得优化。
- 将来能不能迁走？依赖单一厂商的接口和专有服务，迁移成本会随时间越滚越大。关键系统应尽量保留可移植的设计。
三个常见坑
第一个坑是把云当成无限资源。自动伸缩一定要设上限，否则代码缺陷或恶意请求会让费用失控。第二个坑是监控不够。上云后故障点变多，没有完整的日志和指标，问题很难定位。第三个坑是一次性全部迁移。分批迁、逐个验证，出了问题也好回退。
接下来看什么
云服务的竞争正从资源价格转向服务能力。企业关心的已经不只是机器便宜不便宜，还包括能不能更快上线新业务，数据保护是否扎实，成本能不能算清楚。这些能力要靠时间积累，也需要企业内部的组织配合。
[待补充：结合吴明关于行业趋势的公开观点，补充一段有明确出处的论述；如无法核实，删除本段]
