可观测性与 FinOps：用数据驱动云成本优化

云原生时代，资源弹性带来的便利让成本变成了可伸缩的数字。然而，当账单上的数字持续膨胀，企业才意识到：没有可观测性的 FinOps，就像没有仪表盘的飞机——你只知道自己正在飞翔，却看不清方向和油耗。本文将探讨可观测性如何成为 FinOps 的核心驱动力，以及如何通过数据实现真正的成本治理。

什么是 FinOps

FinOps 是"云财务管理"（Cloud Financial Operations）的实践框架，它并非简单的"省钱"，而是在速度、成本、质量之间建立动态平衡。FinOps 遵循共享责任模型：工程团队负责资源使用效率，财务团队负责预算规划，而可观测性系统则为双方提供统一的数据语言。

FinOps 的三个生命周期阶段：

• Inform（通知）：揭示真实成本，打破"云成本黑洞"
• Optimize（优化）：基于数据执行具体的成本削减动作
• Operate（运营）：建立持续的成本监控与治理机制

其中"Inform"阶段高度依赖可观测性，没有指标支撑的成本报告，价值接近于零。

可观测性为什么是 FinOps 的关键

传统成本管理依赖云服务提供商的账单（Billing），存在三个致命缺陷：

1. 滞后性：账单通常延迟数小时至数天，无法实时感知资源浪费
2. 粗粒度：无法精确映射到业务线、团队或功能模块
3. 被动性：只能事后审计，难以预防式治理

可观测性系统的三大支柱——Metrics、Logs、Traces——恰好弥补了这一缺口。当 Prometheus 实时抓取容器 CPU 利用率，当 Jaeger 追踪每条请求的资源开销，当 Grafana 将这些数据聚合成成本视图，团队便可实现"所见即所付"。一句话概括：Metrics 驱动成本决策。

成本分摊：从集群到团队的可视化

在多租户 Kubernetes 环境中，成本分摊（Cost Allocation）是 FinOps 的首要难题。我们需要在以下维度建立标签化（Tagging）体系：

建议通过 Kubernetes Labels 和云厂商标签的映射实现统一标签策略。OpenCost 支持将 Kubernetes 资源标签直接映射为成本归因维度，无需手动维护标签映射表。

核心指标：利用率与资源对齐

FinOps 的可观测性指标体系中，最关键的并非总成本，而是利用率对齐度。以下 Prometheus 查询可用于构建核心看板：

# 容器 CPU 实际利用率 vs Request（按 Pod 聚合）
sum(rate(container_cpu_usage_seconds_total{image!=""}[5m])) by (pod, namespace)
/
sum(kube_pod_container_resource_requests{resource="cpu", image!=""}) by (pod, namespace)

# 容器内存实际利用率 vs Request
sum(container_memory_working_set_bytes{image!=""}) by (pod, namespace)
/
sum(kube_pod_container_resource_requests{resource="memory", image!=""}) by (pod, namespace)

# 命名空间级别 CPU 分配率（Capacity vs Request）
sum(kube_pod_container_resource_requests{resource="cpu"}) by (namespace)
/
sum(kube_node_status_allocatable{resource="cpu"}) by ()

利用率持续低于 20% 的服务是 right-sizing（资源适配合适化）的优先目标。建议设定阶梯化阈值告警：

• CPU < 15%：触发资源 request 下调评估
• CPU > 85%：触发扩容评估
• 内存 > 90%：触发告警与 HPA 弹性策略审查

Kubecost 与 OpenCost：开源成本监控实践

OpenCost 是 Kubecost 开源的核心项目，提供 Kubernetes 成本的实时计算与分摊，已成为 CNCF 沙箱项目。其核心理念是：每个 Pod 的成本 = (资源请求 × 节点单位价) + 比例分摊的闲置成本 + 比例分摊的管理成本。

OpenCost 基础部署配置：

# opencost-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: opencost
  namespace: opencost
spec:
  replicas: 1
  selector:
    matchLabels:
      app: opencost
  template:
    metadata:
      labels:
        app: opencost
    spec:
      serviceAccountName: opencost
      containers:
        - name: opencost
          image: ghcr.io/opencost/opencost:latest
          env:
            - name: PROMETHEUS_SERVER_ENDPOINT
              value: "http://prometheus.monitoring:9090"
            - name: CLOUD_PROVIDER_API_KEY
              valueFrom:
                secretKeyRef:
                  name: cloud-provider-credentials
                  key: api-key
          ports:
            - containerPort: 9003
              name: http
          resources:
            requests:
              cpu: "500m"
              memory: "512Mi"
            limits:
              cpu: "1000m"
              memory: "1Gi"

对于中小型集群，OpenCost 足以满足基础成本分摊需求。若需更细粒度的预算告警、异常检测和成本预测，可升级至 Kubecost 商业版。

Spot 实例与可观测性：智能中断预测

Spot（抢占式）实例可将计算成本降低 60%-90%，但伴随随时被驱逐（Eviction）的风险。可观测性在此场景下扮演了"风险预警系统"的角色：

1. 中断率监控：通过 Prometheus 抓取 AWS Spot Instance Interrupt Warning，提前 2 分钟获得驱逐信号
2. 工作负载塑形：对无状态、可快速重建的任务（如批量数据处理），通过预配置响应完成优雅终止
3. 节点池策略：将可中断负载与核心负载分池运行，避免驱逐级联影响

# Spot 实例驱逐事件计数（基于 Kubernetes Event Exporter）
increase(kubernetes_event_reason{reason="Preempting"}[1h])

# Spot 节点存活性指标
up{job="kubelet", label_eks_amazonaws_com_capacity_type="SPOT"}

可观测性数据还能反过来驱动 Spot 节点池的容量规划：当某可用区的 Spot 中断率连续 7 天超过 10%，该区域的实例配比应自动下调。

存储成本：容易被忽视的隐形支出

存储通常是云账单中占比第三大的开销，且因其"被动增长"特性而极易失控。可观测性应重点覆盖以下指标：

以下查询用于定位"僵尸存储"：

# 30 天内无读写流量的 PVC
kube_persistentvolumeclaim_info
unless on (persistentvolumeclaim, namespace)
  (
    sum(rate(container_fs_reads_bytes_total[30d])) by (persistentvolumeclaim, namespace)
    +
    sum(rate(container_fs_writes_bytes_total[30d])) by (persistentvolumeclaim, namespace)
  ) > 0

基准成本：将开销映射到业务价值

FinOps 的终极目标是回答一个商业问题：每一块钱能产生多少业务价值？ 因此需要建立"单位经济模型"（Unit Economics）。

核心基准指标：

• 每请求成本（Cost per Request）：总云支出 / API 调用总数
• 每活跃用户成本（Cost per Active User）：总云支出 / DAU
• 每事务成本（Cost per Transaction）：支付/订单/消息等核心链路成本

# 每请求成本示例（假设已导出每日云支出指标）
cloud_daily_cost_dollars
/
sum(increase(http_requests_total[1d]))

# 分解到命名空间级别
sum by (namespace) (namespace_cloud_cost[1d])
/
sum by (namespace) (increase(http_requests_total[1d]))

这些指标使 FinOps 从技术领域扩展到商业决策领域。当"每活跃用户成本"连续两季度攀升时，CAPEX 团队有充足依据审视架构效率。

案例研究：通过可观测性洞察降低 40% 云支出

某中型 SaaS 公司的月度 AWS 账单从 $180K 膨胀至 $280K，传统手段无法定位根因。通过引入可观测性驱动的 FinOps 体系，六个月内实现了 40% 的成本削减：

1. Month 1 - 数据采集：部署 OpenCost + Prometheus，建立命名空间级别成本归因。发现 3 个开发环境命名空间的资源 request 是实际使用的 400%。

2. Month 2 - Right-sizing：使用 VPA（Vertical Pod Autoscaler）推荐数据，将 200+ Pod 的 request 下调至 P95 使用量的 120%。仅此一项减少 22% 的预留实例（RI）需求。

3. Month 3 - Spot 落地：将批处理工作负载迁移至 Spot 节点池，结合预占位通知实现优雅中断。计算成本下降 65%。

4. Month 4 - 存储治理：识别出 12TB “孤儿 PVC”（已删除部署但未删除的持久卷），以及 2 年未访问的 S3 对象。迁移至 Glacier 后存储成本下降 30%。

5. Month 5-6 - 持续运营：建立 FinOps 看板周会制度，团队通过 Grafana 自主审视成本趋势。单位请求成本从 $0.0042 降至 $0.0025。

关键结论：没有一次性"成本优化项目"能持续生效。可观测性驱动的 FinOps 必须成为组织运营（Operate）的一部分，而非一次性的工程任务。

总结

可观测性不是 FinOps 的可选项，而是基础设施。从实时成本分摊到利用率优化，从 Spot 实例风险管理到存储治理，从技术指标到单位经济模型，每一次数据驱动的决策都在验证同一个命题：你不可能优化你无法衡量的东西。

将 Prometheus 作为成本数据的神经中枢，将 OpenCost 作为分摊引擎，将 Grafana 作为沟通桥梁——让云开销从"月末惊吓"变成"日常透明"。这才是云原生时代应有的成本治理范式。