为什么云账单会失控

很多团队都是月底收到云账单那一刻才发现这个月又超预算了。云成本和买服务器不一样：它是按用量实时计费的，资源开着就持续烧钱，用不用都算。几个最常见的失控原因：资源超配、测试环境忘了关、闲置磁盘没删、买的都是按量付费。

FinOps 就是把「云花的钱」当成一个要被工程化管理的对象——不是财务事后看数字，而是研发和运维在做技术决策时就把成本算进去。这一篇就从「先看清」讲到「再优化」，最后让成本变成团队日常习惯。

云成本优化的第一步从来不是砍资源，而是先把每一分钱花在哪看清楚。
本文核心知识点
  • 成本分析按业务、按团队、按时段把账单拆开看。
  • 资源超配请求量给太大是最大的浪费来源。
  • 弹性伸缩高峰多开、低谷少开，不养着闲置机器。
  • 预算告警别等月底，花到一半就该提醒。
云成本优化与 FinOps 配图：左侧云朵形状资源立方体、中间环形仪表盘、右侧向下箭头与空钱袋轮廓的蓝色扁平科技插画
先把仪表盘看明白，再决定往哪儿省钱。

先看清钱花在哪：成本分析

云厂商控制台一般都有成本分析面板，但默认给的是「总账单」。要真正能用，得自己打标签：每开一个资源都打上属于哪个业务、哪个环境、哪个团队的标签。这样账单才能按标签拆开——业务 A 和业务 B 各花了多少、生产和测试各占多少，一目了然。

推荐一个最小动作：每周花十分钟看一次「本周成本 Top 5 的资源」。大多数团队会惊讶地发现，80% 的钱花在 20% 的资源上。把这 20% 盯住了，比全量乱砍有效得多。别一上来就想做全套成本治理平台，先把这张周报表跑起来。

最常见的浪费：资源超配

调研里反复出现的头号浪费是资源超配——申请 Pod 时给的 CPU 和内存，实际只用了零头。为什么会这样？因为开发者怕「不够用被打回来」，一上来就往大了写：

# 反例：请求量给太大，实际只用了 10%
resources:
  requests:
    cpu: "4"
    memory: "8Gi"
  limits:
    cpu: "8"
    memory: "16Gi"

# 正例：按实际监控的水位反推
resources:
  requests:
    cpu: "500m"
    memory: "1Gi"
  limits:
    cpu: "1"
    memory: "2Gi"

怎么知道真实用量？去看监控面板里这个服务过去一周的 CPU、内存水位。按实际用量加一点余量设 request，别凭感觉。这件事做完，常常能直接把集群成本砍掉三到四成——因为超配意味着你为根本没用的算力持续付费。

弹性与定时伸缩

不是所有服务都需要 7×24 满配跑着。流量明显有峰谷的业务（比如白天忙、夜里闲），完全可以用弹性伸缩：高峰自动加 Pod、低谷自动缩回去。K8s 的 HPA 按 CPU 水位自动扩缩，配合前面讲的监控，水位一上来就加副本、一降就缩回去。

还有一类更简单的省法：定时关停。测试环境、预发环境又不用 24 小时跑，夜里和周末直接停掉，工作日早上再起来。这一刀下去，测试环境那部分成本常常直接省一半以上。别觉得这点钱少——测试环境因为没人盯着，往往是最容易悄悄烧钱的地方。