4.17 云成本优化——FinOps 实践与 Spot Instance 策略

3. Spot Instance（竞价实例）

Spot Instance 是云厂商用闲置资源以折扣价出售的实例，价格通常是按需价的 10%-30%。适合无状态、可中断、容错性好的工作负载。

# K8s Spot 节点池配置（阿里云 ACK）
apiVersion: v1
kind: NodePool
metadata:
  name: spot-pool
spec:
  instanceTypes: ["ecs.g7.2xlarge", "ecs.g7.xlarge"]
  scalingConfig:
    minSize: 0
    maxSize: 10
    desiredSize: 3
  labels:
    node-type: spot
  taints:
  - key: spot
    value: "true"
    effect: NoSchedule
---
# 工作负载容忍 Spot 节点
apiVersion: apps/v1
kind: Deployment
metadata:
  name: batch-worker
spec:
  template:
    spec:
      tolerations:
      - key: spot
        operator: Equal
        value: "true"
        effect: NoSchedule
      nodeSelector:
        node-type: spot

Spot 回收应对：被回收不是事故

Spot 的意义在于「便宜但可能被回收」。回收前云平台会提前通知（AWS 约 2 分钟、阿里云约 5 分钟），应用只需回答一个问题：收到通知后能否在时限内优雅退出？

# K8s 侧三条防线：
# 1. PDB：保证回收时存活副本数不低于底线
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: batch-worker-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: batch-worker

# 2. 节点打污点 + topologySpreadConstraints 分散副本，避免单节点故障全灭
# 3. 工作负载监听 SIGTERM 优雅退出：批处理任务记录 checkpoint，
#    重启后从断点续跑——这是「可重试」的真正含义

4. 预留实例与节省计划

5. 自动化成本治理

# 成本告警脚本（阿里云账单 API）
#!/bin/bash
# 每月 1 号检查上月支出
COST=$(aliyun bssopenapi QueryBill --BillingCycle 2026-01 \
  | jq -r '.Data.OutstandingAmount')

if (( $(echo "$COST > 5000" | bc -l) )); then
    echo "上月云支出 $COST 元，超过预算 5000 元" | \
      curl -s -X POST "https://oapi.dingtalk.com/robot/send?access_token=xxx" \
      -H 'Content-Type: application/json' \
      -d '{"msgtype":"text","text":{"content":"'"告警：云支出 $COST 元"'"}'
fi

开发环境定时开关机

# cron + 云 API：工作日 9 点开机、20 点关机（阿里云）
0 9 * * 1-5  ali sh ecs StartInstance --InstanceId i-xxx
0 20 * * 1-5 ali sh ecs StopInstance --InstanceId i-xxx
# AWS 版：aws ec2 start-instances / stop-instances

# 更稳的做法：按标签批量操作，新实例自动纳入，不用维护实例清单
aliyun ecs DescribeInstances --Tag key=env,value=dev \
  | jq -r '.Instances.Instance[].InstanceId' | while read id; do
    aliyun ecs StopInstance --InstanceId $id
  done
# 批量停 20 台以上实例前先发群通知，防止误停有人正在用的

闲置资源回收 runbook

# 每周巡检四项，发现即回收（先发群通知，24 小时无人认领再执行）：
# 0. 先导出本月全量资源清单，与上月的 diff 找出新增资源
# 1. 孤立 EIP / 弹性公网 IP：未绑定实例的按小时计费
aliyun ecs DescribeEipAddresses --Status Available \
  | jq -r '.EipAddresses.EipAddress[].AllocationId' \
  | xargs -r -I{} aliyun ecs ReleaseEipAddress --AllocationId {}

# 2. 未挂载云盘：删除实例未随删的孤盘
# 3. 空闲 NAT 网关 / SLB：7 天无流量（看监控指标）即回收
# 4. 未使用快照：超过 180 天的重复快照按策略删除
# 5. 回收后更新资源台账，月度汇总「自动化回收总节省」

# 巡检脚本放入 cron + 告警：每周一 9 点自动跑，
# 产出「待回收清单 + 预估节省金额」推到群，确认后执行

回收原则：先通知、再回收、后复盘。任何回收动作前 24 小时发群通知并附预估节省金额；回收后记录实际节省，月度复盘汇总自动化回收的总节省——这是治理效果最直观的证明。

进阶优化手段

RI / Spot / 按需混合策略

Karpenter 与 Cluster Autoscaler

集群按需扩缩容能直接消除空闲节点成本：Cluster Autoscaler 以"存在 Pending Pod"为信号增减节点；Karpenter 更进一步，按 Pod 实际资源请求直接选择最便宜的实例，原生支持 Spot 混合与碎片整理。

# Cluster Autoscaler：配合 HPA，按负载水平扩缩
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: api-server
spec:
  minReplicas: 2
  maxReplicas: 20
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 60
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api-server

# Karpenter：NodePool 声明可用实例类型与预算
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: default
spec:
  template:
    spec:
      requirements:
      - key: karpenter.sh/capacity-type
        operator: In
        values: ["spot", "on-demand"]
      - key: node.kubernetes.io/instance-type
        operator: In
        values: ["m6i.large", "m6i.xlarge", "c6i.large"]
  disruption:
    consolidationPolicy: WhenUnderutilized
    expireAfter: 720h

存储分层（S3 / OSS 生命周期）

# S3 生命周期：日志 30 天转低频、90 天转归档、临时目录 7 天删除
aws s3api put-bucket-lifecycle-configuration --bucket my-app-data \
  --lifecycle-configuration '{
    "Rules": [
      {"ID": "tier-logs", "Status": "Enabled",
       "Filter": {"Prefix": "logs/"},
       "Transitions": [
         {"Days": 30, "StorageClass": "STANDARD_IA"},
         {"Days": 90, "StorageClass": "GLACIER"}]},
      {"ID": "expire-tmp", "Status": "Enabled",
       "Filter": {"Prefix": "tmp/"},
       "Expiration": {"Days": 7}}
    ]}'

# 阿里云 OSS：控制台"生命周期管理"或 ossutil 配置
ossutil lifecycle --method put oss://my-bucket --config lifecycle.xml

日志类数据通常占对象存储费用的 60% 以上：按"30 天转低频、90 天转归档、180 天删除"落地，存储成本可下降 70-80%。

6. 单位成本（Unit Economics）

总成本会随业务增长自然上升，只有「单位成本」才能衡量优化是否真实有效——成本涨幅是否跑赢业务涨幅：

# 用 Cost Explorer 数据 + 业务表 JOIN 生成单位成本曲线
# 月成本（按 product/team 标签汇总）÷ 当月业务量（从业务库导出）
# 单位成本环比下降 → 优化有效；持平或上升 → 成本增速跑赢业务，立即复盘
# 建议把单位成本做成月度看板并写入周会，比绝对金额更能推动决策

FinOps 组织实践

FinOps 不是财务部门单方面的事，而是财务、技术、产品三方协作的持续流程。以下是可落地的组织运转方式：

责任矩阵

例会节奏

• 每日（自动）——未打标资源、预算超支 120%、环比突增超过 20% 的异常自动推送到钉钉/企微群，无需人工开会。
• 每周——15 分钟站会：只过 Top 5 变化项与待办，技术侧汇报优化进度。
• 每月——成本复盘会：按团队/项目出趋势图，识别异常，确定下月优化目标并写入团队 OKR。
• 每季度——预留实例/节省计划利用率审查，决定续购或释放；同时检讨分摊模型是否仍然合理。

预算与告警机制

# 预算基线：历史 3 个月平均支出 +20% 作为预算上限
# 告警分级：
#   一级 90% 预算  → 通知团队负责人
#   二级 100%     → 通知财务与 CTO
#   三级 120%     → 自动执行降级动作（暂停开发环境、Spot 缩容）

# AWS Budgets 示例：月度 5 万美元预算，90% 触发邮件告警
aws budgets create-budget \
  --account-id 123456789012 \
  --budget '{"BudgetName":"monthly-cost",
             "BudgetLimit":{"Amount":"50000","Unit":"USD"},
             "TimeUnit":"MONTHLY","BudgetType":"COST"}' \
  --notifications-with-subscribers \
  '[{"Notification":{"ComparisonOperator":"GREATER_THAN",
      "Threshold":90,"NotificationType":"ACTUAL"},
     "Subscribers":[{"Address":"finops@example.com",
      "SubscriptionType":"EMAIL"}]}]'

# 阿里云：费用中心"预算管理"同样支持按百分比分级通知

常见错误

1. 资源未打标签导致无法分摊成本：部分云资源（如 ELB、NAT 网关）创建时未打标签，月底账单无法归属到团队。解决：在 Terraform 中用 default_tags 强制统一标签，定期用云平台的"未标记资源"报告清理遗漏。
2. Spot 实例频繁被回收导致服务中断：将有状态服务（如数据库）部署在 Spot 节点上。排查：检查云平台的回收通知，确认工作负载是否真正无状态；对核心服务使用按量或预留实例，Spot 仅用于可中断的批处理任务。
3. 预留实例到期后费用飙升：忘记续费或业务缩减后预留实例闲置。排查：设置到期前 30 天告警，定期审查预留实例利用率，利用率低于 60% 的考虑在到期后切换为按量。
4. 开发环境 24x7 运行浪费严重：开发/测试实例未设置定时开关机，下班和周末持续计费。排查：用云平台的"实例运行时长"报告识别高时长实例，配置 Terraform 或云监控定时任务在非工作时间自动关机。
5. 成本告警阈值设置不合理：告警过于频繁导致"狼来了"效应，或过于宽松导致超支未发现。解决：按历史支出的 120% 设置一级告警，150% 设置二级告警并自动通知负责人，避免无效告警。
6. 单位成本没有业务量分母：只看绝对金额，业务增长 30% 时成本增长 20% 会被误判为「控制住了」。必须把成本除以业务指标（订单/请求/租户数）再环比。
7. Spot 回收前未做优雅退出演练：批处理任务没有 checkpoint，节点回收时任务从头重跑，Spot 节省的成本被重跑算力吃掉。定期手动回收节点验证。

最佳实践

1. 标签规范先行：在创建任何云资源之前定义标签规范（Environment、Team、Project、CostCenter），并在 Terraform provider 块中用 default_tags 强制注入，从源头杜绝遗漏。
2. 混合计费策略：核心稳定负载（数据库、API 网关）用预留/包年包月锁定折扣，弹性负载（CI/CD、批处理）用按量 + Spot 组合，开发环境用定时开关机。不要"一刀切"全用按量或全用预留。
3. 定期做成本复盘：每月召开 FinOps 会议，拉出按团队/项目的成本趋势图，识别异常增长。将成本指标纳入团队 OKR，让"省钱"成为每个人的责任而不是财务部门的事。
4. 自动化治理：用脚本或云平台原生工具实现：未标记资源自动告警、闲置资源自动回收、预算超支自动暂停非核心服务。减少人工干预，避免"知道该省但没人做"。
5. 先看见，再优化：不要跳过 Inform 阶段直接砍资源。先花 2-4 周建立完整的成本可见性（标签、分账、告警），再基于数据做优化决策，否则可能误砍关键资源。
6. 按标签批量治理：所有运维动作（关机、扩容、扫描）都按标签执行而非维护实例清单——实例是流动的，标签是稳定的。
7. 单位成本进周报：把单位成本做成月度看板并写入周会，比绝对金额更能推动优化决策。
8. 回收先通知再执行：任何闲置资源回收前 24 小时发群通知并附预估节省金额，无人认领再执行——回收是治理手段，不是惊喜。

练习题

1. 用 Terraform 为你的云项目编写一个标签检查脚本：扫描所有 ECS 实例，输出未打 Team 和 Project 标签的实例列表，并生成 CSV 报告。
2. 设计一个 Spot + 按量混合的 K8s 节点池方案：编写 YAML 配置，要求批处理任务（batch-worker）调度到 Spot 节点，API 服务（api-server）调度到按量节点，并配置相应的污点容忍和节点选择器。
3. 编写一个成本告警脚本，每天检查云账户余额，当余额低于 1000 元时发送钉钉告警，低于 500 元时自动停止所有非生产环境实例。思考：如何避免误停生产环境？
4. 给你的业务算一次单位成本：定义合适的业务指标（订单/请求/租户），画出最近 6 个月的单位成本曲线，找出成本增速跑赢业务增速的月份并归因。
5. 写一个「Spot 回收演练」脚本：手动终止一台 Spot 节点，记录批处理任务的断点恢复行为，输出一份演练报告。
6. 模拟一次账单突增排查：人为创建一台无标签实例并制造跨区域流量，用账单 API 从产品 → 区域 → 实例 ID 逐层下钻定位它，记录每一步耗时。

本章总结

FinOps 的核心是把云成本责任带回每个团队：先用标签与分账建立完整可见性，再通过右配、Spot 与预留实例的组合优化支出。优化决策必须基于数据，并配合预算告警、定期复盘与自动化治理持续运营。

延伸阅读