云成本优化:别让账单吃掉利润

把业务搬上云那天,老板最常说的一句话是"以后不用买服务器了,省钱"。三个月后账单飘到 CFO 桌上,画风就变了——为什么这个月比上月贵了 40%?为什么我们一台测试环境的机器比生产还多?为什么有人凌晨跑了个批处理任务,数据传输费直接翻倍?

云的账单是温水煮青蛙。它不像自建机房那样一次性砸一笔 CAPEX 让人心疼,而是每天一点一点地扣,等你回过神来,利润已经被啃掉一大块。这篇文章把云成本优化讲透:为什么会失控、几个最有效的杠杆、怎么用监控和 FinOps 文化把成本摁住。

一、云成本为什么容易失控

先认清云的计费逻辑。云是 按用付费(pay-as-you-go)+ 弹性 + 隐性费用 三件事叠加的产物:

• 按用付费意味着"用得多花得多",听起来合理,但它假设"你会主动管用量"——大多数人不会。
• 弹性意味着"想要多少给多少",于是大家习惯性往大了配,"以防万一峰值来了扛不住"。
• 隐性费用才是真正的杀手。CPU、内存这些你看得见,但跨区流量、NAT 网关、负载均衡器、公网 IP 占用、托管服务的按调用计费——这些藏在角落里,平时不显山露水,月底一拉账单能占掉三成。

一个典型场景:工程师为了测试起了 5 台机器,测完忘了关,周末两天没人看,周一回来发现花了几百块。乘以 N 个团队、N 个环境、365 天,这就是一笔大账。

这就是 FinOps 兴起的背景。FinOps = Financial Operations,理念来自 DevOps——把财务、工程、业务三方拉到同一张桌子上,让成本像 CPU 利用率一样可看见、可问责、可优化。它不是省钱运动,是"让每个花云钱的人都知道自己在花多少、为什么花"。

二、计算:预留、竞价、右配三件套

计算通常是云账单的大头(60-80%),杠杆也最多。三件事必须做:

第一,预留实例 / 承诺使用折扣。你的数据库、核心 API、常驻服务,这些是 7×24 跑的稳定负载,用按量计费(on-demand)就是浪费。AWS 的 Reserved Instances / Savings Plans、GCP 的 Committed Use Discounts、Azure 的 Reserved VM Instances,本质都是一回事——你承诺用一年或三年,换 30-70% 的折扣。

实务上,先用一个月观察"哪些实例 7×24 在跑",把这些迁到预留,账单立刻能砍一刀。但别一上来就锁三年——技术栈在变,锁太死等于把灵活性的价值贴进去了。一年期通常是性价比甜点。

第二,竞价实例 / Spot 实例。批处理、训练任务、CI runner、夜间 ETL——这些能被中断的负载,直接上 Spot。原理是云厂商把空闲产能便宜卖给你,但要价是"我随时能抢回去"。折扣能到 70-90%,代价是可能被中断。

Spot 的正确用法是配队列 + 检查点:任务跑前先存中间状态,被中断了能从断点续跑;多实例类型组成队列,某个被抢了换另一个 AZ 接着干。无状态、可重试、可水平扩展的任务都适合,在线服务别碰——用户请求被中断的体验比省的钱贵得多。

第三,右配(right-sizing)。这是 ROI 最高、但做得最差的一件事。绝大多数云上机器是超额配置的——CPU 平均利用率长期在 5-15% 徘徊,内存占用不到 30%,但机器规格是按"峰值假设"开的。

# 用 CloudWatch / Cloud Monitoring 拉过去 30 天的利用率
# 看 p95 CPU、p95 内存,而不是平均值
# 经验法则:连续 14 天 p95 < 40% 的,降一档
# 数据库连接池占用内存大头,降机器前先看连接数是否调优过

右配要按 p95 而不是平均值看,平均值会被夜间低谷拉低。常见做法是降一档观察一周,稳了再降一档,直到出现压力信号就停。一台 m5.2xlarge 降到 m5.large 就是 50% 的差额,集群里乘个几十台就是真金白银。

三、存储:分层、清理、生命周期

存储成本常常被低估——单 GB 便宜,但累积起来惊人,而且未管理的存储只增不减。

分层存储是基础。AWS S3 / GCS / Azure Blob 都支持分层:热层(频繁访问)贵、冷层(Infrequent Access / Coldline)便宜、归档层(Archive / Glacier)极便宜但取出来要钱。

热数据(近 7 天访问):    标准层
温数据(月内偶尔访问):   IA / Nearline
冷数据(合规留存,几乎不读):Archive / Glacier

配 生命周期策略(lifecycle policy) 自动迁移:对象创建 30 天后转到 IA,90 天后转到归档。规则一次写好,后面新数据自动按规则走。一个有 PB 级冷数据的公司,光分层就能省六位数。

清理未用的资源是另一块肥肉。最容易忘的:

• EBS / Persistent Disk 快照:每天自动快照,删了实例但忘删快照策略,一年后几百 GB 的孤儿快照躺在那里。定期 describe-snapshots 找出"对应卷已删除"的,清掉。
• 未挂载的卷:实例删了卷留着,这是经典漏点。脚本扫 volume-state == available 超过 7 天的,直接清。
• 旧镜像 / AMI:每次构建存一个,一年后几百个,每个背后还挂着快照。保留最近 N 个,老的注销并删快照。
• 未使用的负载均衡器、闲置公网 IP:LB 按小时计费、公网 IP 不挂实例也按小时收钱,这些是纯浪费。

跑个资源巡检脚本每周扫一次,这是最直接的省钱手段。

四、网络:出站流量才是隐藏账单

很多人到月底才意识到:云的网络费用不是按"用了多少带宽"算,是按"流出了多少数据"算。而且跨区、跨云、出公网的价格天差地别。

• 同区同可用区通信:基本免费或极便宜。
• 跨可用区:收一点,双向都收(进出都算)。
• 跨区:贵,几个 G 就能花出几十块。
• 出公网(egress):最贵,每 GB 几毛到一块,大量下载场景直接吃掉利润。

杠杆有三:

第一,用 CDN 省回源。把静态资源(图片、JS、CSS、视频)放到 CDN(CloudFront、Cloud CDN),用户从边缘节点取,回源到原始服务器的流量大幅减少。CDN 流量单价低于源站出公网,而且用户体验更好(就近访问)。一个图片站用上 CDN,出站流量费常常砍掉一半以上。

第二,同区部署省跨区费。数据库和应用放同区同 AZ,服务间调用不走跨区。微服务架构里,调用链一长,跨区流量乘起来非常可怕。如果有多区域,每个区域自带完整的本地依赖(DB 副本、缓存),而不是跨区去查。

第三,数据出口规划。大量数据要导出给客户或合作伙伴?考虑物理出口(AWS Snowball、GCP Transfer Appliance)一次拉走,比走网络便宜。或者把分析类负载直接放到数据所在的云内跑(出报表给客户只发聚合结果,不发原始数据)。

五、托管服务:别为了省事用贵的

云厂商很乐意卖你托管服务——RDS、ElastiCache、托管 Kafka、托管 K8s……确实省心,但贵。同一套 Redis,自建社区版和托管版,价格能差 2-4 倍。

判断要不要用托管,算一笔账:

• 托管溢价 = 托管价格 - 自建硬件成本
• 自建运维成本 = 人力 + 高可用方案 + 备份恢复 + 监控告警

如果托管溢价远高于运维成本,自建更划算;如果运维成本高到要专门养人,托管更划算。小团队、非核心组件,托管省心;核心组件、规模上去了,自建常常更便宜,而且技术能力沉淀下来。

但有个反例要警惕:别为了省钱把数据库自建在云虚拟机上。数据库的高可用(主从切换、自动备份、灾备)自己搞很容易踩坑,数据丢了比省的钱贵一万倍。数据库这类有状态、强一致、丢不得的服务,该托管就托管。

无状态服务(缓存、队列、计算节点)则适合自建或用开源方案,因为即使挂了重启就回来。有状态服务托管,无状态服务自建——这是一个不错的起手式。

六、监控:成本看板、分账、异常告警

你优化不了你看不见的东西。云成本优化的地基是监控,而且要像监控 CPU 那样监控账单。

成本看板:用云厂商的 Cost Explorer / Cloud Billing,或者开源的 CloudCusto(OpenCost),搭一个 Grafana 看板,按服务、按团队、按资源类型切片展示。每天看一眼比每月看账单管用——账单来时已经晚了。

按团队/项目分账:这是关键工程动作。用 tag/label 给每个资源打上 team=payment、env=prod、project=checkout,然后按 tag 聚合成本。强制所有资源必须带 tag(没 tag 的不让创建——用策略引擎如 AWS SCP、GCP Organization Policy 强制)。没有分账,你永远说不清"哪个团队花了多少钱",问责也无从谈起。

异常告警:账单突增必须报警,而不是等月底。设两个阈值:

• 日花费比过去 7 天均值高 50% → 告警(可能有人开了大机器忘关)
• 单服务花费比预算高 20% → 告警(可能流量异常或资源泄漏)

预算(Budget)配告警,能让"忘关机器"这种事在 24 小时内被发现,而不是下个月账单出来才拍大腿。

七、FinOps 文化:让工程师有成本意识

工具都到位了,但成本还是降不下来?那是因为工程师做决策时没考虑成本——这是文化问题,不是技术问题。

FinOps 文化的三原则:

• 成本可看见:每个团队、每个服务的成本摆在看板上,所有人都能看,而不是藏在 CFO 抽屉里。
• 成本可问责:某个服务花了多少,谁负责清清楚楚;季度 review 里把成本和性能、可用性放在同一张表上对齐。
• 工程师有成本意识:做架构决策时,不仅问"这样设计性能好吗",也问"这样设计每月花多少"。开个新机器前看一眼利用率,加个新服务前算一下月成本。

具体的落地动作:

1. 成本纳入 code review。新增资源、改实例类型的 PR,review 时看一眼是否合理。CI 里加个成本估算注释:"这次变更预计每月增加 $X"。
2. 成本挑战赛。给团队一个目标——"这个季度把单位请求成本降 20%",达标了有奖励。游戏化比说教管用。
3. 共享指标。SRE 和财务共用一套看板,让运维知道钱花在哪,让财务知道为什么花钱。

FinOps 不是省钱运动,是让花钱的人有知情权、让决策的人有成本视角。它和 DevOps 一样,本质是打破部门墙——这次拆的是工程和财务之间的墙。

小结

• 云成本失控的根源是"按用付费 + 弹性 + 隐性费用":看得见的 CPU 不贵,看不见的跨区流量、NAT、闲置资源才吃利润。先认清账单结构,再谈优化。
• 计算三件套:预留 + 竞价 + 右配:稳定负载锁预留折扣,可中断任务上 Spot,p95 利用率低的机器坚决降配。这是 ROI 最高的三步。
• 存储靠分层 + 清理:热温冷自动迁移,生命周期策略一次写好;孤儿快照、未挂载卷、旧镜像是纯浪费,每周巡检一次。
• 网络优化核心是减少出站流量:上 CDN 省回源、同区部署省跨区、规划数据出口,出公网是云上最贵的单价之一。
• FinOps 是文化,不是工具:成本可看见、可问责、工程师有成本意识,把账单当指标一样监控,把"省钱"变成工程习惯。

一句话收尾:云上的钱不是省出来的,是管出来的——把成本变成第一公民的工程指标,你才不会在月底对着账单怀疑人生。