企业上云这些年，问题已经从要不要上转到怎么上、上什么。阿里云在不少企业、开发者和地方政务项目里都有实际合作。它提供的除了算力，还有把复杂技术能力拆成服务的方式，用的时候调用，不用的时候不占成本。这篇文章不谈概念，只结合几个典型场景，说说阿里云与企业数字化之间的关系，以及实际操作中哪些地方容易出问题。
云计算为什么会成为基础设施
以前企业要上系统，得先自建机房，买服务器、拉网络、招运维，钱还没产生业务价值就先花出去了。更麻烦的是流量不稳定，大促那几天服务器不够用，平时又大量空着。云计算改变的正是这笔账的算法，资源变成弹性服务，用多少付多少。阿里云依托自研的飞天操作系统等底层技术，在电商大促这种流量忽高忽低的场景里积累了不少经验，后来这些能力陆续通过产品对外提供。对中小企业来说，这意味着可以直接使用别人已经打磨过的基础设施，而不必从机柜开始搭。
三个典型案例
一家区域连锁超市的库存系统迁移
某区域连锁超市原来用本地服务器跑进销存系统。每到节假日促销，门店收银数据同步就开始拖，总部看到的库存往往滞后半天。后来该企业把核心数据库迁到云上的托管数据库服务，报表和分析任务单独拆出来运行，不再和交易系统挤在同一套资源里。迁移之后，促销期间的数据延迟从小时级降到了分钟级，运维人员也不用再半夜爬起来处理硬件故障。
这个案例里起作用的是按负载特点拆分系统。交易和分析对资源的需求完全不同，硬放在一起，忙的时候谁都跑不快。上云只是条件，拆分才是把问题解决的那一步。
小团队的低成本试错
一家做校园应用的团队，早期只有三名开发者。他们在云上使用容器服务和对象存储，测试环境按小时计费，不用的时候直接释放。第一个版本上线时，服务器月成本控制在几百元以内。用户慢慢变多之后，团队再逐步加入自动伸缩策略，不再为偶尔的访问高峰长期预留资源。
小团队最怕的是需求还没验证，钱已经花在机器上了。云把这个门槛降下来，团队才有余力去打磨产品。但按小时计费的测试环境如果忘了关，账单照样会涨，这一点在后面谈成本时还会提到。
某机械零部件厂商的数据与智能化
该厂商希望通过设备数据提前发现异常，难点在于设备型号多，数据格式也不统一。项目组先在云上搭建数据接入与存储平台，把各条产线的传感器数据统一采集起来，再用机器学习服务训练故障预测模型。模型刚出来的时候效果并不理想，团队花了不少时间清洗数据、调整特征，最后才把关键设备的停机预警提前到了一段时间之前。
这类项目很容易被想成买一个模型就能完事。实际上，数据能不能统一、业务人员能不能讲清楚设备的故障规律，往往比选哪个算法更影响结果。
选型时要看哪几件事
不管最后选阿里云还是其他云服务商，下面几件事都要在签合同之前想清楚。
- 业务匹配度，先写清楚要解决的问题，再挑产品。如果列出来的服务，团队里没人能说出用途，多半是在为概念买单。
- 迁移成本，盘点现有系统的改造量。边界清楚、依赖少的模块适合先迁，先用一个小模块跑通流程，再动核心系统。
- 安全与合规，先对数据分级，再定访问权限，最后对照所在行业的监管要求。顺序反过来，容易出现权限先放得很宽、事后再收的情况。
- 人才储备，云上的网络、权限和监控，和过去机房的运维习惯不一样。培训最好在迁移前开始，等出了故障再学，代价会大得多。
- 可迁移性，优先选择标准接口和开放数据格式。以后想换供应商时，数据能完整导出，比合同里写多少条款都实在。
成本不能只看单价
很多企业上云后账单超出预期，问题通常不在单价，而是资源长期闲置、测试环境没有关停、存储里的旧数据没人清理。这些属于日常管理的问题，采购时谈价解决不了。
建议把成本纳入日常管理。给每个项目设置预算告警，给资源打上标签，让每一笔费用都能对应到具体负责人。定期复盘资源利用率，发现长期没人访问的实例就及时处理。阿里云提供的成本管理工具可以辅助这类分析，但真正决定账单走向的，还是团队的使用习惯。
最后说几句
阿里云与企业的合作，落到实处就是把技术能力变成按需使用的服务。对企业来说，先想清楚业务缺什么，再决定用哪些资源，新名词可以之后再看。上面三个案例侧重点不同，却有个共同点，每一步都从真实问题出发，没有先从工具出发。
