我们砍掉了 60% 的云账单，但差点把 CI/CD 管道炸了：FinOps 2.0 与 Spot 实例实战复盘

凌晨三点十四分，我的手机震动了。不是服务器宕机报警，而是 AWS 发来的账单预警短信：“您的账户本周预估支出超过阈值。”我瞬间从床上弹起来，打开 CloudWatch，看着那条从上周三开始飙升的折线图，感到一阵窒息。对于一个刚融资的初创公司来说，这笔钱意味着我们要烧掉下个季度的现金流。我盯着屏幕，发誓要搞清楚这钱到底花哪儿了。这不是理论问题，这是生存问题。

作为干了8年的 DevOps，我见过的云账单失控案例太多了。有的团队为了赶上线，把测试环境的实例保留到了下个月；有的团队在 CI/CD 管道里配置了“按需”实例，每次构建都要启动昂贵的 CPU 资源；还有的团队完全忽略了 Spot 实例的潜在风险，结果在业务高峰期被 AWS 强制驱逐，导致服务大面积不可用。今天，我不想跟你谈什么“理论最佳实践”，我想掏出我的血泪经验，聊聊在 FinOps 2.0 时代，我们是如何通过多云策略和 Spot 实例技术，把云成本砍掉 60%，同时保证系统稳定性的。

凌晨三点被账单短信叫醒：云成本失控的真相

为什么我们的云账单会失控？很多时候不是因为我们要跑的代码多，而是因为我们搞不清楚“谁在用多少钱”。在 FinOps 1.0 时代，我们只是被动地看账单，然后问财务：“这钱怎么花的？”但到了 FinOps 2.0 时代，我们必须主动去治理资源生命周期。

资源泄漏：看不见的“僵尸”实例

最常见的原因是“资源泄漏”。这通常发生在开发流程不规范的时候。比如，一个测试脚本在本地跑通了，但部署到测试环境时，由于忘记设置自动停止策略，或者环境变量配置错误导致服务一直挂起却没报错，这台机器就一直运行着。一个月下来，几台 32 核的 c5.2xlarge 实例可能就在那里“吃”了几千美元的电费。（延伸阅读：Google那篇关于FP8的论文里说能省50%显存，但当我把Llama 3.1跑在Blackwell上时，我的Loss却炸了）

我遇到过一次惨痛的教训。我们在一次灰度发布中，为了测试高并发，启动了一组 ECS 实例。灰度结束后，开发人员以为自动伸缩组会回收这些实例，结果因为负载均衡器（ELB）的配置问题，导致实例始终处于“运行中”状态，但流量为 0。这持续了一个周末，账单直接涨了 40%。从那以后，我强制要求所有非生产环境的资源必须有 TTL（生存时间）。

未打标签：成本分摊的“黑盒”

云厂商提供按小时计费，这导致了一个现象：开发者只关心“能不能跑起来”，不关心“跑在什么规格上”。如果没有标签，成本分析工具就无法将支出分摊到具体的团队、项目或服务。这就像你请了一群人吃饭，却不知道是谁点的菜。

我们在引入成本分摊机制时，踩过最大的坑就是“标签一致性”。起初，我们要求团队打上 `Project`、`Environment`、`Owner` 三个标签。结果一个月后，成本报表依然乱成一团，因为团队打标签太随意，有的写 `Project-A`，有的写 `project-a`，有的干脆不写。这直接导致我们无法在 Terraform 中实现基于标签的自动删除策略。没有标签，就没有治理。

多云管理的复杂性

如果你的业务只跑在一个云上，成本控制相对简单。但很多企业级用户为了容灾或特定技术栈，选择了多云架构。AWS、Azure 和 GCP 的计费模型不同，定价策略也各不相同。比如，同样的 m5.large 实例，在 AWS 东京区和 GCP 东京区的价格差异可能高达 15%。如果你盲目地在所有云上部署相同的服务，成本会成倍增加。FinOps 2.0 的核心之一，就是要在多云环境中找到“性价比”和“稳定性”的平衡点。

FinOps 2.0：别只盯着账单，要盯着“资源生命周期”

FinOps 2.0 不仅仅是省钱，它是将成本意识融入开发流程。它要求我们从“事后审计”转向“事前规划”和“事中控制”。

从“发现”到“行动”的闭环

在 FinOps 1.0 中，我们使用工具（如 CloudHealth 或 CloudZero）来发现异常支出，然后发邮件给团队，等待他们去修改配置。这个过程效率极低，往往需要数周才能解决一个问题。

在 FinOps 2.0 中，我们建立了自动化闭环。当系统检测到某个资源超过预算，或者某个标签为空的资源超过 24 小时未使用时，它会自动触发操作。比如，自动停止测试环境的实例，或者自动发送 Slack 通知给相关负责人。这种“不干预就不干活”的文化，才是降本的关键。（延伸阅读：别只盯着ChatGPT：ESP32-S3跑TinyLlama 2bit，我找到了LLM的最低硬件底线）

组织文化的变革

技术手段只是工具，真正的变革在于组织架构。你需要建立一个跨职能的团队，包括 DevOps、财务、架构师和业务负责人。这听起来很官僚，但在实际操作中非常有效。当业务负责人看到他的项目每月在云上的成本，并且知道这笔钱花在哪里时，他才会主动去评估“这个功能值不值得花这么多钱”。我们曾经通过这种机制，砍掉了两个正在开发但 ROI（投资回报率）极低的数据分析项目，直接节省了每月 5000 美元的成本。

实施步骤：别试图一步到位

如果你现在才开始做，不要试图一次性改变所有东西。我建议分三步走：

1. 发现与标记： 先用工具扫描所有资源，打上标准标签，解决“不知道钱花在哪”的问题。
2. 优化与控制： 针对高成本资源进行优化。比如，将不稳定的 Spot 实例替换为预留实例，或者调整实例规格。同时，设置预算告警。
3. 自动化与治理： 编写脚本和配置，让优化措施自动化。比如，每小时检查一次未打标签的资源并报警，或者每天凌晨停止所有测试环境的实例。

多云策略：AWS、Azure、GCP 的价格博弈与策略选择

对于企业级用户，多云策略往往是为了容灾，但也可以是为了成本。不同云厂商在不同区域、不同实例类型上的定价差异巨大。我们不能只看品牌，要看数据。

区域定价的陷阱

AWS 的 Spot 实例价格在不同区域差异很大。比如，新加坡区域的 Spot 价格可能是东京区域的 1.5 倍。如果你的业务对延迟不敏感，完全可以选择价格更低的区域进行部署。我们曾将一个非核心的日志分析服务从新加坡迁移到东京，同时利用了 AWS 的跨区域复制功能，虽然增加了 1ms 的延迟，但每月节省了 20% 的算力成本。

混合云的算力调度

在多云环境下，我们需要一个智能的调度器。当 AWS 的 Spot 实例价格过高时，是否应该切换到 Azure 的 Spot？还是直接使用本地机房的资源？这需要根据实时价格数据来做决策。

我推荐使用像 Nomad 或 Kubernetes 这样的编排工具，配合多云插件。例如，Kubernetes 的 Cluster Autoscaler 可以配置优先级策略。我们可以定义：如果 AWS Spot 价格高于某个阈值，则停止扩容，转而使用本地节点或 Azure Spot。

实例规格的对比与选择

很多时候，我们为了追求性能，选择了过度配置的实例。比如，一个只需要 2 核 CPU 的应用，我们却配置了 8 核的实例。实际上，AWS 的 vCPU 计费是按核心数来的，而不是按物理核。如果你的应用 IO 密集型较高，选择内存更大但 CPU 核心数少的实例（如 Memory Optimized 系列），性价比往往更高。

Spot 实例实战：用 10% 的钱干 100% 的活，前提是你敢这么干

Spot 实例是云成本优化的“核武器”。它的价格通常是按需实例的 10% 到 30%。但是，它的本质是“租用云厂商闲置的算力”，云厂商有权随时收回这些实例。这对稳定性提出了极高的要求。（延伸阅读：Google那篇关于RAG延迟的论文里假设了“无限带宽”，但我的Jetson Orin NX的内存带宽只够喝汤）

数据批处理：Spot 的天然主场

对于数据批处理、视频渲染、机器学习训练这类任务，它们天生具备“中断可恢复”的特性。我们可以利用 AWS Batch 或 Kubernetes 来调度 Spot 实例。

在 AWS Batch 中，我们可以配置 `nodeProperties` 来指定 Spot 实例。关键在于，我们需要处理 Spot 实例被驱逐的情况。AWS Batch 提供了重试机制，但如果 Spot 实例被驱逐，任务会进入 `FAILED` 状态。我们需要在作业定义中设置 `retryStrategy`，让任务在失败后重新排队，直到在按需实例或预留实例上成功运行。

apiVersion: batch/v1
kind: Job
metadata:
  name: data-processing-job
spec:
  template:
    spec:
      backoffLimit: 6  # 最多重试6次，总共7次机会
      activeDeadlineSeconds: 3600  # 作业最多运行1小时，防止无限挂起
      restartPolicy: Never
      containers:
      - name: processor
        image: my-registry/processor:latest
        command: ["python", "process.py"]
        resources:
          requests:
            memory: "4Gi"
            cpu: "2"
          limits:
            memory: "8Gi"
            cpu: "4"
      # 关键点：使用 Karpenter 或 AWS Node Group 调度 Spot 实例
      # 这里假设使用 Karpenter 的 CRD 来定义 Spot 节点池
      # 注意：实际配置中需要配合 Karpenter 的 Interruptible 特性

CI/CD 管道中的 Spot：我们用 Runner 节点省下了 80% 的构建费

CI/CD 管道通常是按需付费的，每次构建都启动一个高性能实例，构建完成后立即释放。这是典型的“短时高负载”场景，非常适合 Spot 实例。

我们曾使用 AWS Fargate 和 GitHub Actions，但成本依然很高。后来，我们引入了 GitHub Self-Hosted Runners，并部署在 Spot 实例上。我们使用 Karpenter 来管理这些 Runner 节点。

这里有一个巨大的坑：CI 构建通常需要几分钟时间，而 Spot 实例可能只有 2 分钟的预留时间。如果构建还没完成，实例就被驱逐了，构建就会失败。为了解决这个问题，我们使用了 GitHub 的 `runner-max-duration` 参数，并结合 Karpenter 的 `ttlSecondsAfterEmpty` 参数。我们配置 Karpenter，让 Spot 实例在闲置 10 分钟后自动终止，但在运行作业时，我们通过 `nodeSelector` 或 `tolerations` 确保作业能跑完。

另一个坑是 Spot 实例的网络稳定性。Spot 实例可能会出现网络抖动，导致 SSH 连接中断。我们在 Runner 脚本中加入了健康检查，如果 Runner 挂了，GitHub Actions 会自动尝试恢复，但由于 Spot 的不可预测性，这经常导致构建失败。最终，我们采用了“混合模式”：高优先级的构建任务在按需实例上跑，低优先级的构建任务（如 Lint、单元测试）在 Spot 实例上跑。这虽然牺牲了一点点速度，但将 CI/CD 的成本从每月 2000 美元降到了 400 美元。

稳定性保障：如何避免 Spot 驱逐导致的服务中断

对于核心业务（如电商网站、支付网关），使用 Spot 实例是绝对禁忌。但对于非核心服务，我们如何保障稳定性？（延伸阅读：AWS Lambda 新计费模式：我用“按需付费”策略省下 30% 服务器成本，但踩了一个大坑）

首先，不要在 Spot 上运行状态敏感的服务。如果服务需要保存内存状态，Spot 驱逐会导致数据丢失。其次，使用高可用架构。即使一个 Spot 节点挂了，Kubernetes 的控制器也会在其他节点上重启 Pod。最后，监控 Spot 的价格和可用性。我们可以通过 AWS CLI 定时查询 Spot 价格，如果价格飙升，就自动降低实例数量。

CI/CD Runner 的实战配置

下面是一个基于 Karpenter 和 Spot 实例的 Runner 配置示例。这个配置定义了一个支持 Spot 的节点池，并设置了驱逐策略。

apiVersion: karpenter.sh/v1
kind: Provisioner
metadata:
  name: spot-runner
spec:
  requirements:
    - key: karpenter.sh/capacity-type
      operator: In
      values: ["spot"]
    - key: kubernetes.io/arch
      operator: In
      values: ["amd64"]
    - key: kubernetes.io/os
      operator: In
      values: ["linux"]
    - key: node.kubernetes.io/instance-type
      operator: In
      values: ["c5.large", "m5.large"]  # 选择性价比高的 Spot 实例类型
  limits:
    resources:
      cpu: 1000
      memory: 1000Gi
  providerRef:
    name: default
  taints:
    - key: spot
      value: "true"
      effect: NoSchedule  # 标记为 Spot，CI 任务需要容忍这个污点
  # 关键配置：闲置多久后自动回收
  ttlSecondsAfterEmpty: 600
  # 关键配置：实例最多存活多久，防止实例被 AWS 长期锁定
  ttlSecondsAfterCreation: 86400 

自动化治理：必须打标签，否则你的成本中心就是黑洞

如果说 Spot 实例是省钱的神器，那么标签就是治理的基石。没有标签，Spot 实例优化就是无源之水。我们需要建立一套强制性的标签规范，并通过自动化工具来执行。

标签规范：建立统一标准

我们制定了一套严格的标签规范，所有资源必须包含以下标签：

• Project：项目名称，如 “payment-service”。
• Environment：环境，如 “prod”, “staging”, “dev”。
• Owner：负责人邮箱。
• CostCenter：成本中心代码。
• ShutdownTime：预期的关闭时间（用于自动化停止）。

通过 Terraform 强制打标签

我们使用 Terraform 来管理所有基础设施。Terraform 的 `resource` 块支持 `tags` 属性，我们可以定义一个 `locals` 变量，包含所有共享的标签，然后在每个资源中引用它。这样，无论谁创建资源，都会自动带上这些标签。

locals {
  common_tags = {
    Project     = "payment-service"
    Environment = var.environment
    Owner       = var.owner_email
    ManagedBy   = "Terraform"
  }
}

resource "aws_ecs_service" "main" {
  name            = "payment-service"
  cluster         = aws_ecs_cluster.main.id
  task_definition = aws_ecs_task_definition.main.arn
  launch_type     = "FARGATE"  # 也可以在这里切换为 "EC2" 并指定 Spot
  
  # 强制应用标签
  tags = local.common_tags
}

# 对于 EC2 实例，我们需要在 provider 配置中全局设置标签
provider "aws" {
  default_tags {
    tags = local.common_tags
  }
}

自动化清理脚本：每天凌晨的“大扫除”

即使有 Terraform，还是会有手动创建的资源或者意外泄漏的资源。我们需要一个脚本，每天凌晨自动扫描这些资源，并采取行动。

我们使用 AWS CLI 和 Python 编写了一个自动化脚本。它会扫描所有未打 `Owner` 标签的 EC2 实例，或者 `Environment` 为 “dev” 且 `ShutdownTime` 早于当前时间的实例。对于这些实例，脚本会先发送通知，等待 10 分钟确认无操作后，再执行停止操作。

#!/bin/bash

# 配置
AWS_REGION="us-east-1"
EMAIL="devops-team@company.com"
TIMEOUT_SECONDS=600  # 10分钟宽限期

# 获取当前时间（UTC）
CURRENT_TIME=$(date -u +"%Y-%m-%dT%H:%M:%SZ")

# 查找符合条件的实例（未打标签 或 标签指定了关闭时间）
# 注意：这里使用了 AWS CLI 的 --query 参数进行过滤
INSTANCE_IDS=$(aws ec2 describe-instances 
  --filters "Name=instance-state-name,Values=running" 
            "Name=tag:Environment,Values=dev" 
  --query 'Reservations[].Instances[].InstanceId' 
  --region $AWS_REGION 
  --output text)

if [ -z "$INSTANCE_IDS" ]; then
  echo "No instances to stop."
  exit 0
fi

echo "Found instances: $INSTANCE_IDS"

# 对每个实例进行检查
for INSTANCE_ID in $INSTANCE_IDS; do
  # 获取实例的标签
  TAGS=$(aws ec2 describe-tags 
    --filters "Name=resource-id,Values=$INSTANCE_ID" "Name=key,Values=ShutdownTime" 
    --region $AWS_REGION 
    --output json)
  
  # 如果有 ShutdownTime 标签，检查是否过期
  if echo "$TAGS" | jq -e '.Tags[] | select(.Key=="ShutdownTime")' > /dev/null; then
    SHUTDOWN_TIME=$(echo "$TAGS" | jq -r '.Tags[] | select(.Key=="ShutdownTime").Value')
    
    # 比较 ShutdownTime 和当前时间
    if [ "$(date -u -d "$SHUTDOWN_TIME" +%s)" -lt "$(date -u -d "$CURRENT_TIME" +%s)" ]; then
      echo "Instance $INSTANCE_ID is scheduled to stop."
      
      # 发送通知（这里可以替换为 Slack API 或 Email API）
      # curl -X POST $SLACK_WEBHOOK_URL -d "{"text":"Instance $INSTANCE_ID is stopping due to expired ShutdownTime."}"
      
      # 执行停止
      aws ec2 stop-instances --instance-ids $INSTANCE_ID --region $AWS_REGION
    fi
  else
    # 如果没有 ShutdownTime 标签，强制停止
    echo "Instance $INSTANCE_ID has no ShutdownTime tag. Stopping..."
    aws ec2 stop-instances --instance-ids $INSTANCE_ID --region $AWS_REGION
  fi
done

echo "Cleanup script completed."

治理工具的集成

除了脚本，我们集成了 Cloud Custodian。这是一个强大的云治理工具，可以用 YAML 配置规则。例如，我们可以配置一条规则：“如果资源没有打 `Project` 标签，且创建时间超过 24 小时，则自动打上 `Project:unknown` 标签，并通知负责人。”这比手写脚本更灵活，也更易于维护。（延伸阅读：我让 Vercel v0 一晚上搭完了一个暗黑模式 Dashboard，代码量比以前少了一半）

监控与告警：别等月底结账单时才想起来修

成本优化不是一次性的工作，而是一个持续的过程。要实现这一点，你必须有完善的监控和告警体系。

成本仪表盘：可视化你的支出

我们使用 Grafana 结合 AWS Cost Explorer API 来构建成本仪表盘。这个仪表盘实时显示各部门、各项目的云支出。它不仅仅是一个数字，更是一个趋势图。我们可以清晰地看到某个项目在某个月的支出激增，并追溯到具体的资源。

我们遇到过一次情况，仪表盘显示某天 AWS 账单激增了 10%。我们立即排查，发现是一个开发人员误操作，将数据库实例的存储从 100GB 扩容到了 1TB。幸好有告警，我们及时发现问题并止损。如果没有这个仪表盘，我们可能要等到月底结账单时才会发现。

预算告警：在超支前发出警告

在 AWS 中，我们可以设置预算。比如，设置月度预算为 5000 美元。当支出达到 80%（4000 美元）时，发送邮件告警。当支出达到 100% 时，自动停止非核心服务的实例。

这里有一个坑：AWS 的预算告警是基于预估支出的，而不是实际支出。有时候预估会不准确，导致我们提前停止了实例，影响了业务。后来，我们调整了策略，将告警阈值设为 90%，并设置了一个 5% 的缓冲区。

Spot 价格监控：动态调整策略

Spot 价格是波动的。我们需要实时监控 Spot 价格，并根据价格调整实例数量。我们编写了一个简单的 Python 脚本，每小时运行一次，查询 Spot 价格。如果价格超过某个阈值（比如按需价格的 50%），脚本会自动减少实例数量。

这个脚本需要与 Kubernetes 集成。我们可以使用 Karpenter 的 `limits` 配置来限制最大实例数，或者使用 Cluster Autoscaler 的 `scale-down` 策略。当 Spot 价格过高时，Cluster Autoscaler 会自动停止节点，从而降低成本。

实例使用率监控：拒绝“裸奔”

很多时候，我们启动了实例，但它们处于空闲状态。我们需要监控实例的使用率。如果 CPU 使用率连续 1 小时低于 5%，或者内存使用率低于 10%，我们可以考虑降级实例规格或停止实例。

我们使用 Prometheus 和 Grafana 监控 Kubernetes 节点的使用率。当节点使用率过低时，我们触发一个自定义的告警，通知运维人员检查是否有资源泄漏。

多云成本对比

为了更好地决策，我们制作了一个多云成本对比表。这个表格显示了不同云厂商在不同区域、不同实例类型上的价格差异。

从表格中可以看出，Spot 实例的价格优势非常明显。AWS 和 GCP 的 Spot 实例价格通常比 Azure 更低。但是，Azure 的 Spot 实例在某些情况下更稳定，因为它通常提供更长的预留时间。

避坑清单：从实战中总结的经验

经过这一年的折腾，我们总结了一份避坑清单。如果你也想实施云成本优化，请务必注意以下几点：

• 不要盲目使用 Spot：对于核心业务，Spot 实例是毒药。只用于非核心任务、批处理和 CI/CD。
• 标签是命脉：没有标签，就没有治理。从一开始就强制打标签，否则你会被资源淹没。
• 监控是眼睛：不要只看月底的账单。你需要实时的仪表盘和告警，才能及时发现异常。
• 自动化是关键：手动优化成本是不可能的。你需要编写脚本和工具，让优化自动化。
• 沟通是桥梁：成本优化不仅仅是技术问题，也是管理问题。你需要让业务团队理解成本，并愿意配合优化。
• 预留实例比 Spot 更稳定：对于长期运行的任务（如数据库、缓存），预留实例可以提供更好的性价比和稳定性。
• 不要忽视网络成本：跨区域的数据传输费用很高。尽量将数据存储在同一个区域，减少数据传输。
• 定期审计：成本优化是一个持续的过程。你需要定期审计你的资源，清理僵尸实例，调整配置。

云成本优化是一场持久战。它需要技术、管理和文化的结合。只有当你真正把成本意识融入到每一个开发流程中，你才能在享受云带来的便利的同时，控制住成本。希望我的经验能给你带来一些启发。