成本优化 = 工程决策的资源维度

解决什么问题：云资源浪费 = 隐性技术债—— 成本优化不是"少花钱"，而是"在 SLA 不变的前提下，提升单位成本的业务价值"。

业务问题

真实场景

场景 1：云账单失控

现象：
  - 月云账单从 5 万涨到 50 万
  - 没有预算告警
  - 没人清楚成本来源
  
调查发现：
  - 测试环境的数据库是 prod 同等规格
  - 一半 EC2 实例常年空跑（开发周末）
  - 跨 region 流量是无脑传输
  - 没有自动扩缩容（高峰期手忙加实例）
  - 没有 Spot 实例
  - 没用预留实例

失败模式

失败模式	后果
无成本可见性	不知道花在哪儿
预留 vs 按需比例失衡	多花 30-60%
过配置	资源浪费
无自动扩缩容	高峰期过配 + 低峰期空跑
跨 region 流量	流量费 > 计算费
测试环境用生产规格	测试成本 = 生产成本

控制论视角

Ch 9 §9.4："最优控制" + Ch 4 §4.8："三难困境"

成本优化 = 多目标优化
  - 性能 ↑（SLA）
  - 成本 ↓
  - 可靠性 ↑
  - 三者平衡
  
性能 vs 成本 = 控制论 Ch 4 §4.8 三难
  - 不可全部最优
  - 需要 trade-off

核心概念

FinOps 3 阶段

阶段 1：可见（Visibility）
  - 知道钱花在哪儿
  - 按团队/服务/环境分账
  - 实时成本仪表板
  
阶段 2：优化（Optimization）
  - 识别浪费
  - 自动扩缩容
  - 预留实例 + Spot
  
阶段 3：文化（Culture）
  - 团队为成本负责
  - 成本是工程决策的维度
  - 持续改进

成本维度

1. 计算（Compute）
   - EC2 / 虚拟机
   - 容器
   - Lambda / Serverless
   
2. 存储（Storage）
   - 数据库
   - 对象存储
   - 备份
   
3. 网络（Network）
   - 跨 AZ/Region 流量
   - CDN
   - 数据出口
   
4. 服务（Services）
   - 托管服务（RDS, ElastiCache）
   - SaaS 订阅
   - 第三方 API

成本优化 5 大杠杆

1. 正确规格（Right Sizing）
   - 实例类型匹配负载
   - 数据库规格匹配 QPS
   - 存储类型匹配 IO 需求
   
2. 自动扩缩容（Auto Scaling）
   - HPA（Horizontal Pod Autoscaler）
   - VPA（Vertical Pod Autoscaler）
   - Spot Instance
   - Scheduled Scaling（定时）
   
3. 预留折扣（Commitment Discount）
   - 预留实例（1-3 年）
   - Savings Plans
   - Spot（最高 90% off）
   
4. 架构优化
   - 单体 vs 微服务（成本角度）
   - 缓存策略
   - 数据分层
   
5. 文化与流程
   - 成本仪表板
   - 团队预算
   - 成本审查（类似 CR）

成本 vs SLA 的权衡

决策	SLA 影响	成本影响
多 AZ 部署	↑ 可靠性	↑ 2x 计算
多 Region 部署	↑ 灾难恢复	↑ 3-5x
数据库升级	↑ 性能	↑ 50-100%
长保留期	—	↓ 30-60%
Spot 实例	↓ 可用性	↓ 50-80%

工程实践

实战 1：成本可见性

工具：
  - AWS Cost Explorer
  - GCP Billing Reports
  - Azure Cost Management
  - Kubecost（K8s）
  - CloudHealth（多云）
  
分账标签（Tagging）：
  - team: {team-name}
  - service: {service-name}
  - environment: dev/staging/prod
  - cost-center: {cost-center-id}

实战 2：Right Sizing

步骤：
  1. 收集 30 天使用率（CPU / Memory / Network）
  2. 找 P95 使用率
  3. 选择 P95 使用率 = 60-70% 的规格
  4. 测试新规格
  5. 持续监控
  
工具：
  - AWS Compute Optimizer
  - GCP Recommender
  - 自建监控分析

实战 3：自动扩缩容策略

HPA（水平扩缩）：
  - CPU > 70% → 加 pod
  - CPU < 30% → 减 pod
  - 最少 2 个，最多 20 个
  
VPA（垂直扩缩）：
  - 自动调整 pod 资源请求
  - 适合无状态服务
  
Cluster Autoscaler：
  - 节点不够 → 加节点
  - 节点空闲 → 删节点
  
Spot Instance：
  - 批处理任务
  - 容错服务
  - 测试环境
  - 节省 50-90%

实战 4：架构层面的成本优化

优化 1：缓存
  - Redis 缓存热点数据
  - CDN 缓存静态资源
  - 数据库查询缓存
  - 节省：DB 计算 + 网络
  
优化 2：数据分层
  - 热数据：SSD
  - 温数据：HDD
  - 冷数据：对象存储
  - 归档：Glacier
  
优化 3：异步处理
  - 同步 → 异步（消息队列）
  - 长任务 → 后台 worker
  - 节省：用户等待时间 + 计算
  
优化 4：数据库优化
  - 索引
  - 查询优化
  - 分库分表
  - 读副本

反模式 vs 正模式

反模式	正模式
生产环境用过大的实例	Right Sizing
永远不开自动扩缩容	HPA + 定时
测试环境用 prod 配置	分层（dev/staging/prod）
跨 region 不考虑	流量优化 + 缓存
没成本仪表板	实时分账

性能指标

指标	衡量	健康值
资源利用率	P95 CPU/Memory 使用率	60-80%
Spot 占比	Spot / Total 实例	> 30%
预留折扣率	预留 / Total	> 50%
成本/用户	月成本 / MAU	业务决定
浪费比例	浪费 / Total	< 10%

边界判断

何时重视成本优化

• 月账单 > 10 万
• 业务规模快速增长
• 融资阶段（成本 = 跑道）

何时可以"贵一点"

• 关键业务（可靠性优先）
• 快速增长期（速度优先）
• 安全合规要求

何时用 Spot

• 容错服务（可重启）
• 批处理
• 测试环境
• 不适用：数据库主节点、有状态服务

与 L 层对位

• 性能调优
• 架构演进
• 微服务还是单体
• 集成成熟度模型
• Cattle not Pets

与四源对位

主题	cybernetics	IDDD	Event-Driven	SE@G
资源调度	Ch 9 §9.4 最优控制	—	Ch 8 工作流	Ch 25 CaaS
自动扩缩容	Ch 18 自适应	—	Ch 14 弹性	Ch 16 Monorepo
缓存策略	Ch 6 §6.3 解耦	Ch 10 聚合边界	Ch 7 状态物化	—
数据库优化	Ch 9 最优	Ch 10 聚合	Ch 7 状态	—

关键洞察

1. 成本是工程决策的维度——不是后期考虑，是设计阶段就考虑。
2. 可见性 > 优化——不知道花在哪就别优化。
3. 浪费 vs 必要——不要为了省钱牺牲 SLA。
4. 预留 + Spot = 主要杠杆——通常能省 30-50%。
5. 架构决定成本——微服务天然贵，单体不一定便宜。
6. 与 cybernetics 同构：Ch 9 §9.4 最优控制 = 性能/成本最优配比。

阅读路径

新手：
  1. FinOps 3 阶段（基础）
  2. 成本 5 大杠杆（操作）
  
深入：
  3. 自动扩缩容策略
  4. 架构层面优化
  
实战：
  5. 成本可见性（工具 + 标签）
  6. Right Sizing 流程

相关链接

• 四源对位索引 — 本文在 cybernetics + SE@G 对位中的位置
• 业务主题索引 — 9 个业务主题全图
• 性能调优 — 成本 vs 性能的最优配比
• 架构演进 — 架构决定成本结构
• L2 设计层 — 三难取舍 + 最优控制的 L 层根