青岛的制造企业、电商团队和小型互联网公司，最近常问三件事：服务器放哪里，系统怎么搭，出了问题找谁。青岛阿里云服务能回答其中不少问题，但选对产品和服务商，以及业务怎么拆、迁移怎么做，影响往往更大。下面按实际决策的顺序说一说。
先想清楚业务跑在哪里
上云前，先把业务分成三类看：面向客户的网站和小程序，内部使用的ERP、OA，还有和设备打交道的生产数据。三类的访问量、延迟要求和安全要求差得很远。如果硬塞进同一套配置，要么为了高峰买得太多，平时空转；要么为了省钱压得太紧，一到峰值就卡住。
- 对外网站和小程序：访问量忽高忽低，适合用弹性伸缩和对象存储，峰值过去后资源能自动收回。
- 内部业务系统：访问比较平稳，重点放在数据库备份和权限管理上。
- 设备数据和生产监控：数据量大、对延迟敏感，一般要在车间侧先做采集和过滤，再把结果送到云端。
案例一：食品厂订单系统迁移（示意）
这是一个示意案例，用来说明迁移的顺序。某速冻食品厂原来把订单系统放在办公室的旧服务器上，每到季度促销，网站一卡，客户就转去别家下单。他们把网站和订单库迁到阿里云，前端用负载均衡加自动伸缩，数据库使用云数据库并开启每日备份。
迁移前，团队在测试环境跑了两周压测，发现高峰时数据库连接数是瓶颈，于是先调整连接池参数，再排期正式切换。切换放在凌晨，原服务器保留一周，出问题可以直接切回去。这个案例值得借鉴的，是先压测、再切换、留好退路这个顺序，而不是某个产品名。
案例二：跨境电商的成本控制（示意）
另一个示意场景是小型跨境电商团队。最初他们按高配包年包月买了服务器，大部分时间闲置，钱花在了几乎用不到的算力上。后来改成促销时段按量付费，平时只保留最小规格，成本降了不少。商品图片则迁到对象存储，并设置生命周期规则，半年以上没有访问的图片自动转为低频存储。
成本控制基本靠三件事：付费方式跟着业务走，闲置资源及时清掉，冷数据放到更便宜的存储层。每一件都要配账单告警。资源一多，月底账单经常超出预期，如果没人及时发现，问题就会一直存在。
案例三：设备数据的分层上云（示意）
第三个示意场景是一家机械加工企业，车间里有几十台数控设备。如果原始数据全部直传云端，带宽开销大，网络一断，数据还可能丢失。方案是在车间部署边缘网关，先在本地完成采集和初步过滤，只把聚合指标和异常数据上传。历史存储、报表和远程告警交给云端。
这样网络波动时车间照常记录，上传流量也远小于原始数据量。分层的好处在于，本地负责不丢数据，云端负责看全局。
选服务商前，先问清楚这几件事
服务商的宣传页面看起来大同小异，真正的差别多半在合同和交付细节里。跟销售或技术顾问沟通时，可以直接问下面几点：
- 技术支持的响应时间和服务等级协议（SLA）怎么写，故障赔付按什么方式计算。
- 迁移有没有专人协助，还是只给操作文档，由你们自己完成。
- 备份和恢复有没有实际演练过。如果只有一份策略文件，真出事时就来不及了。
- 续费价格、流量超出后的计费规则是否写进合同，有没有容易忽略的收费项。
- 将来想换云或撤出数据，导出方式是否可行，大概需要多长时间。
上云前的几个实际提醒
账号和权限要分开管理。不要让所有人共用一个主账号，人员离职后，访问权限要当天收回。密钥不要写进代码，也不要贴在微信群里，放到密钥管理服务中更稳妥。
备份要在上线前恢复一次。备份文件能不能还原，只有演练过才知道，备份用不上的情况并不少见。资源也要打上项目和负责人标签，否则半年后，没人说得清哪台机器是做什么的，也不敢随便关。
青岛阿里云服务能让本地企业用较低门槛拿到计算、存储和安全能力。但效果多半取决于迁移前的规划、迁移中的验证，以及迁移后的持续运维。
