不少团队决定上云时，第一反应是先买一台服务器再说。用起来才发现，计算、存储、数据库和网络怎么搭配，比买哪台机器更影响结果。阿里云服务产品线很全，选对了省心省钱，选错了容易资源闲置，或者架构做到一半又要返工。这篇文章按新手最容易踩的三个坑来讲：选型只看配置、所有东西堆在一台机器上、忽视成本。每个坑后面都附上能直接照着做的思路。
一、阿里云服务都有哪些板块
常用产品大致分成四类，每类解决的问题不一样：
- 计算：云服务器ECS是最常见的起点，可以随时调整配置。已经用容器部署的团队看容器服务ACK。偶发性的小任务，函数计算FC按调用次数收费，不用自己管服务器。
- 存储：图片、视频和备份文件放对象存储OSS比较合适。需要挂载到服务器上当磁盘用的，选块存储。
- 数据库：云数据库RDS支持MySQL、PostgreSQL等主流引擎。自己装数据库要管备份、升级和主从切换，交给RDS后，这些大部分由平台处理。
- 网络与安全：负载均衡SLB、专有网络VPC、安全组和WAF，分别管流量入口、内网隔离和访问边界。上线前至少要把VPC和安全组配好。
产品多不等于每样都要用。先从业务最核心的一两项开始，跑顺了再逐步加。
二、第一个坑：选型只看配置，不看负载
很多人打开控制台，照着老机器的配置买一台，或者直接选最高规格，觉得这样稳。配置高不一定合适。选之前先想清楚三件事：
- 流量曲线是否稳定。平稳的业务，包年包月或预留实例券通常更划算。峰谷差距明显的，按量付费加弹性伸缩更合适，否则高峰之外的钱基本是白花的。
- 数据有没有合规要求。涉及用户隐私或行业监管的数据，要先确认存放地域和加密方式。相关规定最好提前找法务或合规同事过一遍，事后补做的代价很高。
- 团队能不能扛运维。人手紧的团队，数据库优先用托管服务。自建MySQL的备份、主从和升级，平时看不出问题，出事时往往是半夜。
三、第二个坑：所有东西堆在一台机器上
下面这个案例是示意性的，用来说明常见思路，并非某个真实客户的数据。某区域电商团队原本把网站和数据库都部署在自有机房，每到促销就响应变慢。他们的调整分三步。
第一步，商品图片迁到对象存储OSS，前面加CDN。图片请求不再压在应用服务器上，页面加载快了，服务器带宽压力也跟着降下来。
第二步，数据库迁到云数据库RDS，并开一个只读实例分担查询。订单写入和商品浏览分开走，促销期间的数据库瓶颈松了不少。这里要留意，只读实例存在同步延迟，刚下的订单如果直接从它读取，页面可能显示不是最新状态。代码里要分清哪些查询能接受延迟，哪些必须读主库。
第三步，应用层用ECS配合弹性伸缩，按CPU使用率设阈值。高峰自动扩容，结束自动缩容，不必全年按峰值买机器。阈值怎么定要看自己的压测结果，照搬别人的数字通常不靠谱。
这个案例里值得借鉴的是，每一步都对应一个具体问题：先找出卡点，再选服务去解决。
四、第三个坑：成本失控
上云后最常见的意外，往往是月底账单。下面几个习惯可以提前养成：
- 每月固定看一次费用中心的账单明细，重点找长期没人用的实例、磁盘和公网IP。这些资源多半是某次测试后忘了释放的。
- 测试环境用按量付费，并设置非工作时间自动关机。周末没人用的机器关掉，就不再计费。
- 对象存储按访问频率选存储类型，半年没人看的历史文件转入低频或归档存储。
- 给项目设预算告警。配置写错或流量异常时，告警通常比账单先到。
五、上线后的安全与运维
上云以后，安全责任是共担的。阿里云负责底层基础设施的安全，账号权限、数据加密和应用漏洞仍然要使用方自己管。
具体操作上，建议用RAM访问控制给不同成员分配最小必要权限，主账号开启多因素认证。AccessKey不要写进代码仓库，一旦泄露，清理起来很麻烦。安全组只开放必需端口，数据库不要暴露在公网。日志方面，开启操作审计和云监控，对异常登录和资源突增设置告警，出问题时才能及时查到线索。
回到开头的问题，阿里云服务的用法是按需组合。先想清楚业务要什么，再选产品，之后持续关注成本和安全配置。新手踩的坑，多半是因为一开始没想清楚，产品本身通常不是问题所在。
