optimizing-costs

成本优化

目的

云成本优化通过 FinOps 生命周期（知情、优化和运营），将不受控的支出转变为战略性的资源分配。本技能提供决策框架，涵盖基于承诺的折扣（预留实例、Savings Plans）、资源规格调整策略、Kubernetes 成本管理，以及多云环境中的自动化成本治理。

何时使用本技能

在以下情况下调用 cost-optimization：

• 通过系统化优化将云支出降低 15-40%
• 实施成本可见性仪表板和分摊跟踪
• 建立预算告警和异常检测
• 优化 Kubernetes 资源请求和集群效率
• 管理预留实例、Savings Plans 或承诺使用折扣
• 自动清理闲置资源并提供规格调整建议
• 为内部团队设置成本展示／成本分摊模型
• 通过 CI/CD 成本估算（Infracost）防止成本超支
• 响应财务团队削减云成本的请求

FinOps 原则

FinOps 生命周期

┌─────────────────────────────────────────────────────┐
│  INFORM → OPTIMIZE → OPERATE (continuous loop)      │
│    ↓         ↓           ↓                          │
│ Visibility  Action   Automation                     │
└─────────────────────────────────────────────────────┘

知情阶段： 建立成本可见性

• 启用成本分摊标签（Owner、Project、Environment）
• 为工程团队部署实时成本仪表板
• 集成云账单数据（AWS CUR、Azure Consumption API、GCP BigQuery）
• 设置 Kubernetes 成本监控（Kubecost、OpenCost）

优化阶段： 针对成本驱动因素采取行动

• 购买基于承诺的折扣（节省 40-72%）
• 调整过度配置资源的规格（目标利用率为 60-80%）
• 为可容错工作负载使用 Spot／可抢占实例
• 清理闲置资源（未挂载的卷、旧快照）

运营阶段： 自动化并实施治理

• 设置预算告警及逐级通知（50%、75%、90%、100%）
• 编写闲置资源自动清理脚本
• 通过 CI/CD 成本估算防止成本意外增加
• 通过异常检测持续监控

FinOps 核心原则

1. 协作： 跨职能团队（财务、工程、运营、产品）
2. 问责： 团队负责其服务产生的成本
3. 透明： 所有成本对利益相关者可见且易于理解
4. 优化： 持续提升成本效率

有关 FinOps 成熟度模型和组织结构的详细信息，请参阅 references/finops-foundations.md。

成本优化策略

1. 基于承诺的折扣

预留实例（RIs）： 承诺 1-3 年可享受 40-72% 的折扣

• 标准 RI： 实例类型固定，折扣最高（承诺 3 年可享受 60% 折扣）
• 可转换 RI： 实例类型灵活，折扣适中（承诺 3 年可享受 54% 折扣）
• 适用场景： 数据库（RDS、ElastiCache）、稳定的生产 EC2 工作负载

Savings Plans： 灵活的计算资源承诺

• Compute Savings Plans： 适用于 EC2、Fargate、Lambda（承诺 3 年可享受 54% 折扣）
• EC2 Instance Savings Plans： 绑定实例系列（承诺 3 年可享受 66% 折扣）
• 适用场景： 实例类型或区域会发生变化的工作负载

GCP 承诺使用折扣（CUDs）： 可享受 25-70% 的折扣

• 基于资源的 CUDs： 承诺使用 vCPU、内存、GPU
• 基于支出的 CUDs： 承诺固定金额（灵活）
• 持续使用折扣： 持续使用可自动享受 20-30% 的折扣（无需承诺）

决策框架：

Reserve when:
├─ Workload is production-critical (24/7 uptime required)
├─ Usage is predictable (stable baseline over 6+ months)
├─ Architecture is stable (unlikely to change instance types)
└─ Financial commitment acceptable (1-3 year lock-in)

Use On-Demand when:
├─ Development/testing environments
├─ Unpredictable spiky workloads
├─ Short-term projects (<6 months)
└─ Evaluating new instance types

有关承诺策略和 RI 覆盖率分析的详细信息，请参阅 references/commitment-strategies.md。

2. Spot 和可抢占实例

折扣： 相比按需定价可节省 70%–90%（可中断，并提前 2 分钟发出警告）

适合使用 Spot 的场景： CI/CD 工作节点、批处理任务、ML 训练（支持检查点）、Kubernetes 工作节点、数据分析
不适合使用 Spot 的场景： 有状态数据库、实时服务、不支持检查点的长时间运行任务

最佳实践：

• 采用多种实例类型，并分散到多个可用区
• 实现平滑关闭处理程序
• 容量不可用时自动回退到按需实例
• Kubernetes：混合使用 70% Spot 节点和 30% 按需节点，并配置污点和容忍度

3. 资源规格优化策略

目标利用率： 平均 60%–80%（为峰值留出余量）

计算资源规格优化：

• 分析 30 天以上的实际 CPU／内存利用率
• 将平均利用率低于 40% 的实例降配
• 整合利用率不足的工作负载
• 切换实例系列（计算优化型与内存优化型）

数据库资源规格优化：

• 分析连接池使用情况（最大连接数与已分配连接数）
• 如果存储 IOPS 利用率低于 50%，则降低其配置
• 评估是否需要只读副本（能否用缓存替代？）
• 考虑无服务器选项（Aurora Serverless、Azure SQL Serverless）

Kubernetes 资源规格优化：

• 将 requests 设为平均用量（而非峰值）
• 将 limits 设为 requests 的 2–3 倍（允许突发使用）
• 使用 Vertical Pod Autoscaler（VPA）自动提供建议
• 找出 CPU 使用率为 0% 的 Pod（可考虑整合）

存储资源规格优化：

• 删除未挂载的卷（EBS、Azure Disks、GCP Persistent Disks）
• 删除旧快照（超过 90 天且无需保留）
• 实施生命周期策略（S3 Intelligent-Tiering、Azure Blob Lifecycle）
• 压缩／去重数据

资源规格优化工具：

• AWS Compute Optimizer： 基于 ML 提供 EC2、Lambda、EBS 建议
• Azure Advisor： 虚拟机规格优化、预留实例建议
• GCP Recommender： 虚拟机、磁盘和承诺用量建议
• VPA（Vertical Pod Autoscaler）： 自动配置容器资源 requests

4. Kubernetes 成本管理

资源 Requests 和 Limits：

# Set requests = average usage (enables efficient bin-packing)
resources:
  requests:
    cpu: 500m        # 0.5 CPU cores (average usage)
    memory: 1Gi      # 1 GiB memory (average usage)
  limits:
    cpu: 1500m       # 1.5 CPU cores (3x requests, allows bursting)
    memory: 3Gi      # 3 GiB memory (3x requests)

命名空间配额： 防止资源消耗失控

• ResourceQuota：限制每个命名空间的 CPU／内存总量
• LimitRange：设置每个 Pod 的默认／最大 requests
• PriorityClass：确保关键 Pod 获得资源

集群自动扩缩容：

• 缩减空闲节点以降低成本
• 在非工作时间将开发集群缩至零
• 使用多个节点池（混合 Spot 和按需实例）
• 设置节点数上限，防止超支

成本可视化：

• 部署 Kubecost 或 OpenCost，按命名空间跟踪成本
• 按标签分配成本（团队、项目、环境）
• 跟踪闲置成本（未分配给工作负载的集群容量）
• 生成成本分摊／成本回收报告

如需了解 Kubernetes 成本优化模式的详细信息，请参阅 references/kubernetes-cost-optimization.md。

成本可视化和监控

用于成本分摊的标记

必需的标记：

• Owner 或 Team - 负责的团队／部门
• Project 或 Application - 业务部门或应用名称
• Environment - prod、staging、dev、test
• CostCenter - 财务成本中心代码

启用成本分摊标记：

• AWS： 在 Cost Allocation Tags 控制台中激活标记
• Azure： 通过 Azure Policy 强制应用标记
• GCP： 对所有资源使用标签，并导出到 BigQuery

如需了解全面的标记策略，请参阅 references/tagging-for-cost-allocation.md。

监控与仪表板

原生云工具：

• AWS Cost Explorer： 分析支出模式、预测成本
• Azure Cost Management + Billing： 预算跟踪、成本分析
• GCP Cloud Billing： 导出到 BigQuery 以进行自定义分析

第三方平台：

• Kubecost： Kubernetes 成本可见性与优化
• CloudZero： 单位成本经济分析、异常检测
• CloudHealth： 多云成本管理
• Infracost： 在 CI/CD 中估算 Terraform 成本

需跟踪的关键指标：

• 每月云支出总额（随时间的趋势）
• 按服务/团队/项目划分的成本（分摊准确性）
• 单位成本指标（每位客户、每笔交易的成本）
• 预留实例/节省计划的使用率（目标 >95%）
• 空闲资源浪费（目标 <总支出的 5%）
• 预算偏差（预测值与实际值）

预算警报与异常检测

级联预算警报：

50% of budget  → Email to team lead (informational)
75% of budget  → Email + Slack to team (warning)
90% of budget  → Email + Slack + PagerDuty (urgent)
100% of budget → Automated shutdown (non-prod only) or escalation

异常检测： 对意外的成本激增发出警报

• 每周成本增长 >20%
• 意外的每日成本激增 >$500
• 新资源类型（异常支出模式）

预算粒度：

• 组织级（云支出总额）
• 部门级（工程、数据、营销）
• 项目级（按应用/服务划分）
• 环境级（生产环境与开发/预发布环境）

决策框架

框架 1：承诺折扣决策树

Should we purchase Reserved Instances / Savings Plans?

STEP 1: Analyze Historical Usage (6-12 months)
├─ Identify steady-state baseline (minimum usage)
├─ Exclude spiky/seasonal workloads
└─ Calculate: (baseline usage) / (total usage) = commitment %

STEP 2: Choose Commitment Type
├─ RESERVED INSTANCES
│   ├─ Pros: Highest discount (up to 72%)
│   ├─ Cons: Instance type locked (unless convertible)
│   └─ Use for: Databases, stable production workloads
│
├─ SAVINGS PLANS
│   ├─ Pros: Flexible (across instance types, regions)
│   ├─ Cons: Slightly lower discount than RI
│   └─ Use for: Compute workloads, Lambda, Fargate
│
└─ COMMITTED USE DISCOUNTS (GCP)
    ├─ Resource-based: vCPU/memory commitments
    └─ Spend-based: Dollar amount commitments

STEP 3: Determine Commitment Period
├─ 1-year commitment
│   ├─ Lower discount (40-50%)
│   └─ Less risk if architecture changes
│
└─ 3-year commitment
    ├─ Higher discount (60-72%)
    └─ Only for mature, stable workloads

STEP 4: Monitor and Optimize
├─ Target >95% RI/Savings Plan utilization
├─ Sell unused RIs on AWS Reserved Instance Marketplace
└─ Adjust commitments quarterly based on usage trends

框架 2：资源规格调整优先级矩阵

成本影响与工作量：

高影响、低工作量（优先执行）：

• 空闲资源（100% 浪费）：已停止的实例、未附加的卷、旧快照
• 未使用的 NAT 网关（每个 $32/月）
• 过度配置的数据库（连续 30 天 CPU 使用率 <20%）
• 未设置资源请求的 Kubernetes Pod

高影响、中等工作量（其次执行）：

• 过度配置的计算资源（连续 30 天 CPU/内存使用率 <40%）
• 最大内存 >已用内存 2 倍的 Lambda 函数
• 存储优化（S3 Intelligent-Tiering、gp3 与 gp2）

低影响、高工作量（最后执行）：

• 应用代码优化（需要性能分析和重构）
• 架构重新设计（迁移到无服务器架构、多区域优化）

每周优化例行流程：

1. 删除空闲资源（自动化脚本）
2. 检查成本最高的 10 项驱动因素（手动分析）
3. 每周调整 3-5 个实例的规格（渐进式方法）
4. 监控影响（跟踪 4 周的成本趋势）

框架 3：Spot 与按需实例决策

Should this workload use Spot/Preemptible instances?

├─ Is the workload fault-tolerant?
│   ├─ NO → Use On-Demand
│   └─ YES → Continue
│
├─ Is the workload stateless (or has checkpointing)?
│   ├─ NO → Use On-Demand (data loss risk)
│   └─ YES → Continue
│
├─ Can the workload handle interruptions gracefully?
│   ├─ NO → Use On-Demand
│   └─ YES → Continue
│
└─ Workload Type Assessment:
    ├─ Batch Jobs / CI/CD → ✅ Use Spot (70-90% savings)
    ├─ ML Training → ✅ Use Spot (with checkpointing)
    ├─ Kubernetes Workers → ✅ Use Spot (mixed with on-demand)
    ├─ Production API Servers → ⚠️ Mixed fleet (70% spot, 30% on-demand)
    ├─ Databases → ❌ Use On-Demand (or Reserved)
    └─ Real-time Services → ❌ Use On-Demand (or Reserved)

工具选择指南

按平台划分

平台	成本可见性	规格调整	自动化
AWS	Cost Explorer、CUR	Compute Optimizer	AWS Budgets、Lambda 清理
Azure	Cost Management	Azure Advisor	Azure Policy、Automation
GCP	Cloud Billing	Recommender	Budget Alerts、Cloud Functions
Kubernetes	Kubecost、OpenCost	VPA	Cluster Autoscaler
多云	CloudZero、CloudHealth	Densify	ParkMyCloud

按用例划分

用例	推荐工具	主要功能
K8s 成本可见性	Kubecost	按命名空间实时分摊成本
Terraform 成本估算	Infracost	在 PR 评论中显示成本差异
多云聚合	CloudHealth	统一查看 AWS/Azure/GCP 成本
自动化优化	nOps（AWS）、CAST AI（K8s）	基于 ML 的自动化
单位成本经济分析	CloudZero	跟踪每位客户/每笔交易的成本
Spot 实例管理	Spot.io	自动化 Spot 编排

如需详细的工具比较和选择标准，请参阅 references/tools-comparison.md。

特定云平台策略

AWS 优化策略

1. 启用 Cost & Usage Reports（CUR）： 将详细账单导出到 S3
2. 使用 AWS Compute Optimizer： 基于 ML 的 EC2 规格调整建议
3. 实施 Savings Plans： 比 Reserved Instances 更灵活
4. S3 Intelligent-Tiering： 自动优化存储类别
5. 调整 Lambda 规格： 调整内存分配（CPU 会按比例扩展）
6. 迁移到 EBS gp3： 性能相同，成本比 gp2 低 20%

Azure 优化策略

1. 启用 Azure Advisor： 获取 VM 规格调整和 Reserved Instance 建议
2. Azure Hybrid Benefit： 使用自有的 Windows Server 许可证以享受折扣
3. Dev/Test 定价： 非生产工作负载享受优惠费率
4. Azure Spot VMs： 可中断工作负载最多可享受 90% 折扣
5. 存储生命周期管理： 自动将 Blob 分层到 Cool/Archive 层

GCP 优化策略

1. 将账单导出到 BigQuery： 使用 SQL 进行自定义成本分析
2. 持续使用折扣： 自动享受 20-30% 折扣（无需承诺）
3. 承诺使用折扣： 承诺 3 年可节省 52-70%
4. Preemptible VMs： 批处理工作负载最多可享受 91% 折扣
5. GCP Recommender： 检测闲置 VM 并提供规格调整建议

如需深入了解特定云平台，请参阅 references/cloud-specific-tactics.md。

实施清单

阶段 1：建立可见性（第 1-2 周）

• 启用成本分配标签（Owner、Project、Environment）
• 在云账单控制台中激活成本分配标签
• 部署 Kubecost 以查看 Kubernetes 成本（如果使用 K8s）
• 创建成本仪表板（Grafana、CloudWatch、Azure Monitor、GCP）
• 设置每周成本报告（通过电子邮件发送给团队负责人）

阶段 2：建立治理机制（第 2-3 周）

• 创建预算告警（50%、75%、90%、100% 阈值）
• 启用异常检测（周环比增幅 >20%）
• 实施标签策略强制执行（Azure Policy、AWS Config、GCP Org Policy）
• 建立 showback 报告（按团队/项目划分成本）
• 记录成本归属（哪些服务由谁负责）

阶段 3：快速见效（第 3-4 周）

• 删除闲置资源（未挂载的卷、旧快照）
• 停止/终止未使用的开发实例
• 调整前 10 个过度配置实例的规格（利用率 <40%）
• 实施 S3 Intelligent-Tiering 或生命周期策略
• 评估 Reserved Instance/Savings Plan 覆盖率

阶段 4：承诺折扣（第 2 个月）

• 分析 6-12 个月的使用历史
• 计算用于确定承诺规模的基准用量
• 为数据库购买 Reserved Instances
• 为计算工作负载购买 Savings Plans
• 监控 RI/SP 利用率（目标 >95%）

阶段 5：自动化（第 2-3 个月）

• 部署自动清理脚本（每周定时运行）
• 将 Infracost 集成到 CI/CD 流水线中
• 为开发/测试环境实施自动关机（非工作时间）
• 为 K8s 启用 Vertical Pod Autoscaler（VPA）以调整规格
• 设置 Spot 实例自动化（Spot.io、CAST AI 或原生方案）

阶段 6：持续优化（持续进行）

• 每周与工程团队进行成本审查
• 每月开展优化冲刺（针对主要成本驱动因素）
• 每季度调整承诺（RI/SP 覆盖率）
• 每年进行一次 FinOps 成熟度评估

常见陷阱

陷阱 1：成本不可见

❌ 问题： 财务团队到月底才看到云账单，届时处处都是意外 ✅ 解决方案： 部署实时成本仪表板，每天向工程团队发送 Slack 报告

陷阱 2：Reserved Instance 利用率不足

❌ 问题： 购买了 100 个 RI，却只用了 60 个（40% 的承诺被浪费） ✅ 解决方案： 每周监控 RI 利用率（目标 >95%），在市场上出售未使用的 RI

陷阱 3：缺少 Kubernetes 资源请求

❌ 问题： Pod 未设置资源请求 → 装箱效率低下 → 节点资源浪费 ✅ 解决方案： 使用 VPA 自动生成建议，并通过准入控制强制执行

陷阱 4：闲置资源未清理

❌ 问题： 50 个已停止的 EC2 实例（仍需为 EBS 付费）、200 个未挂载的卷 ✅ 解决方案： 每周自动清理闲置超过 7 天的资源

陷阱 5：未设置预算提醒

❌ 问题： 意外地让测试集群一直运行，收到 10K 美元账单时大吃一惊 ✅ 解决方案： 在 50%、75%、90%、100% 时触发预算提醒，并通过 Slack/PagerDuty 发送通知

相关技能

• resource-tagging： 成本分配标签支持成本分摊/成本转嫁模式
• kubernetes-operations： 通过 K8s 资源规格调整、VPA、集群自动扩缩容来优化成本
• infrastructure-as-code： 使用 Infracost 进行 Terraform 成本估算和策略即代码
• aws-patterns： AWS 专属成本优化策略（EC2、RDS、S3、Lambda）
• gcp-patterns： GCP 专属优化方案（Compute Engine、BigQuery、Cloud Storage）
• azure-patterns： Azure 专属优化方案（VM、Storage、App Service、Functions）
• platform-engineering： 内部 FinOps 平台和自助式成本仪表板
• disaster-recovery： 平衡成本与 RTO/RPO（温备与冷备）

示例

请参阅 examples/ 目录：

• terraform/：AWS、Azure、GCP 成本优化基础设施（预算、提醒）
• kubernetes/：Kubecost 部署、资源配额、VPA 配置
• ci-cd/：Infracost GitHub Actions、成本审批工作流
• dashboards/：Grafana 成本仪表板、CloudWatch 警报

脚本

请参阅 scripts/ 目录：

• cleanup_idle_resources.py： 自动清理 AWS/Azure/GCP 闲置资源
• ri_coverage_report.py： 预留实例覆盖率分析
• cost_allocation_report.py： 生成成本分摊/成本转嫁报告
• spot_savings_calculator.py： 估算使用竞价型实例节省的费用
• k8s_rightsizing_audit.py： 查找缺少资源请求的 K8s Pod

要点总结

1. FinOps 是一种文化： 财务、工程和运维团队之间的协作
2. 先实现可见性： 无法衡量就无法优化（标签和仪表板必不可少）
3. 承诺带来节省： 预留实例/节省计划可提供 40-72% 的折扣
4. 持续调整资源规格： 目标利用率为 60-80%（为负载突增预留余量）
5. 自动清理： 闲置资源完全是浪费（每周自动删除）
6. Kubernetes 成本不易察觉： 使用 Kubecost/OpenCost 查看命名空间级别的成本
7. 将成本意识左移： 在 CI/CD 中使用 Infracost，防止成本意外增加
8. 预算提醒可防止超支： 在 50%、75%、90%、100% 时逐级发送通知
9. 容错型工作负载使用竞价型实例： 可享受 70-90% 的折扣（CI/CD、批处理作业、ML 训练）
10. 单位成本指标驱动价值： 跟踪每位客户的成本、每笔交易的成本