成本优化与开发者主导的 FinOps — 把账单当成技术指标¶

这一章讲什么: 云上每一行代码都在花钱,而花钱的手是开发者的。本章把两件事讲透:云账单到底由什么构成(钱从哪个维度漏走的), 以及怎么把成本变成像延迟、错误率一样天天看的工程指标。立场一句话:成本不是财务的事后审计,是开发者的设计约束。

1. 主线例子:一个改了 Terraform 的 PR,和一条自动告警¶

本章的主线例子,是开发者日常里成本意识的两端:花钱前把关、花钱后报警。

  花钱前(每次改基础设施的 PR):
    你改了 Terraform,多加了两个节点
      → CI 里 Infracost 自动估价,在 PR 上评论:
        「本月成本 +$212(+15%)」
      → 团队按数字讨论「值不值」,而不是月底看账单时吓一跳

  花钱后(异常自动闭环,照原书例子):
    AWS Budgets 发现计算开支日增 30%
      → SNS 通知触发 Lambda,查是哪个 Auto Scaling Group 在涨
      → 摘要自动发到 DevOps 的 Slack 频道:成本影响 + 处置选项
      → 人在恶化成财务事故之前介入

  图说:反馈环的两个时点——合并前(PR 评论)与异常时(自动告警),
  把「月度惊吓」拆成「日常反馈」。
  +$212 与 30% 为结构示意(原书给了 30% 异常例子;PR 估价金额是演示数字)。

2. 云账单的六个维度¶

云的计费模型一句话:资源全部按表计量——每个 API 调用、每次数据传输、每个 CPU 周期都有价签。六大计费类别(原书表 13.1)¹:

类别	计什么	例子
计算	处理能力的运行时间	EC2、GKE 节点、Lambda
存储	存了多少、怎么访问	S3、Blob、GCS
网络	数据搬了多少、搬到哪	egress(出网流量)、跨区、跨地域
数据库	实例 + IOPS + 备份	RDS、Cloud SQL
应用服务	专用服务调用	CloudFront、BigQuery、Pub/Sub
支持与管理	企业支持、监控日志	AWS Support、CloudWatch

原书那句提醒值得贴在墙上:「你不只为用到的付钱,还为忘了关掉的付钱。」²

2.1 计算:账单大头,五种计费模型¶

模型	怎么付	适合
按需	用多少付多少,无承诺	不可预测负载、开发测试
预留/节省计划	承诺 1–3 年换折扣	稳定生产负载
Spot/可抢占	用闲置容量,可能被回收,便宜最多 80%	批处理、可重试任务
Serverless	按实际调用与执行时长	短时事件驱动
自动扩缩	跟负载弹性伸缩	流量起伏的 Web 服务

效率六招:按利用率 right-size(Compute Optimizer 等工具)、智能扩缩(用队列深度这类业务指标做触发,且必须设 max 上限防狂奔)、事件驱动用 Serverless(设超时与调用频率监控)、容器密度与 VPA 微调、 CI runner 和测试环境用完即毁(TTL 策略)、Spot 实例加重试逻辑³。

2.2 存储:无声的 accumulator(累积器)¶

存储每 GB 单价看着低,日志、旧快照、没打标签的桶会悄悄滚大。三层分级(原书表 13.3):热(常访问,最贵)→ 温(不常访问)→ 冷归档(最便宜,取回要等小时);生命周期策略自动搬家 (如 30 天后转归档)⁴。效率六招:生命周期策略、自动分层(Intelligent Tiering)、别乱开多区复制、压缩去重(GZIP/ZSTD)、版本控制要配保留策略(不然容量翻两三倍)、 定期审计孤儿卷和快照(实例删了盘还在计费!)⁵。

2.3 网络:最隐蔽的一项¶

计费规律(原书表 13.4):同可用区通常免费 → 跨可用区收费 → 跨地域更贵 → 出公网(Internet egress)按 GB 收 → CDN 按边缘分发收⁶。效率六招:服务同地域部署、内部大流量走私网互联、CDN + 压缩(GZIP/Brotli)、盯 egress 看板、API 调用合并批处理、全球分发用 CDN⁷。

2.4 跨服务的成本连锁¶

单独优化一层可能只是把成本挪个地方:日志 agent 产生数据 → 存 S3(存储费) → 传 OpenSearch(egress 费);扩缩太激进 → 计算涨的同时数据库 IOPS 也涨; 监控数据保留太长 → 存储和检索 API 双重收费。要整体看账⁸。

责任的划分:财务给预算、运维定政策、开发者产生负载——所以开发者必须答得出三个问题:什么触发计费事件?哪个代码/服务发起的?怎么监控和控制? 打标签(团队/服务/环境)是归因的基础设施(原书给了 Terraform 标签例子)⁹。

3. 开发者主导 FinOps:Inform → Optimize → Operate¶

FinOps(财务运营)= 工程、财务、业务三方协作管云钱的实践; 开发者主导是把成本可见性与决策权交到建系统的人手里。原书给了一个权重:开发者通过代码与架构直接影响 70–80% 的云开支¹⁰。

三阶段循环(原书表 13.5)¹¹:

阶段	干什么	开发者的动作
Inform(可见)	知道钱花哪了	全资源打标签、成本进 Grafana/Datadog、分环境看趋势、设预算
Optimize(优化)	消除浪费	right-size、重构高消耗的代码路径、缓存与限流、自动清理闲置、预留实例、策略即代码拦未打标签资源
Operate(运营)	防成本漂移	异常检测告警、盯单位成本(每用户/每 API 调用/每次部署)、定期 FinOps 评审、CI 成本门、新人培训

嵌入工作流的五个检查点(原书表 13.6):代码评审加成本影响清单 → CI 里 Infracost 估价 → 部署按 tag 追踪成本增量 → 监控里放成本看板 → 回顾会里成本与性能并谈¹²。

工具箱(原书表 13.7,名字全留):Infracost(Terraform 估价,PR 阶段)、 Kubecost(K8s 按 namespace/服务实时分摊)、AWS Cost Explorer、 GCP Recommender(建议缩容/删闲置)、Cloud Custodian(自动执行治理, 删未打标签资源)、Finout/CloudZero(多云成本与业务指标关联)¹³。

文化四条:共同担责、透明(成本不进财务黑箱)、给省钱团队认可、办 FinOps hackathon——成本成为与延迟、可用性并列的质量指标¹⁴。

案例(HR 科技公司,原书数字):Infracost 进 PR + Kubecost 按团队看板 + 月度三方评审 + Lambda 自动清理闲置测试环境——四个月云开支降 28%, 新员工 onboarding 里加了 FinOps 课¹⁵。

判断(我们的,不是书里的): 本章最有杠杆的一个机制是 Infracost 类的「合并前估价」:它把成本反馈的时点和代码评审重合——而代码评审是开发者唯一一个不抵触被打断的时刻。月底账单的问题是「时点上谁都不在场」; PR 评论的问题是「想不看都难」。把成本反馈嵌进已经存在的强习惯, 比建立新习惯便宜一个数量级。 如果错,会错在: 对变化频繁的基础设施,PR 估价与实际账单的偏差会积累, 数字失真后评论会被无视——此时需要定期用实际账单校准估价,而不是放弃时点。

4. 成本看板与告警:让账单变成遥测信号¶

传统成本报告是事后四周的复盘;实时化后,成本成为另一种遥测信号¹⁶。

看板设计五原则(原书)¹⁷:按服务/环境/区域/团队细分;成本与性能指标同屏; 趋势可视化(日/周/月);部署前后对比视图;可行动(链到成本驱动因素)。看板五区结构(原书表 13.8):摘要(总花费+预测)→ 计算 → 存储 → 网络 → 按团队/服务分摊。

工具(原书表 13.9):云原生三家各自的 Cost Explorer / Billing Reports / Cost Management;K8s 用 Kubecost;Grafana 接计费插件,把成本和延迟错误率放在一块屏;多云上 Finout/CloudZero¹⁸。

告警自动化五条:预算 80%/90%/100% 三级阈值;百分比 + 绝对值双阈值; 与部署事件关联;路由到 Slack/Teams/Jira;接自动动作(告警触发函数自动暂停资源或缩容)。Terraform 管预算的例子(照抄):每月 $500 计算预算, 80% 时邮件告警——预算即代码,进版本库¹⁹。

关联分析:成本与性能并看才能找到根因——数据库成本飙升关联到最近的慢查询代码变更; egress 上涨关联到网关配置错;扩缩成本关联到新功能的流量 surge²⁰。

案例(数字支付公司,原书数字):Grafana + CloudZero 实时看板取代季度复盘—— 异常检测时间从三周压到一小时;发现超配的 K8s 节点,年省 $40,000²¹。

5. 不过度花钱的高效系统设计¶

成本感知架构:把成本当设计约束,和延迟、吞吐并列。设计时就问: 这个功能最便宜的可靠交付方式是什么?能不能异步/事件驱动减计算? 按峰值静态供给还是动态扩缩?²²

架构十策(原书)²³:用各家 Well-Architected Framework 定期评审; 为弹性而非永久设计;托管/Serverless 用于突发负载、常驻高吞吐留给专属计算; 分层存储(SSD 热 / 对象存储温 / 归档冷);事件驱动架构(只在事件发生时处理, 消除轮询空转);该合就合(小微服务 = 复制 + 跨服务流量 + 监控复杂度的成本, 小规模考虑模块化单体);按负载选部署模型(短命批任务 Serverless, 长任务预留实例);数据就近(计算与存储同地域 + 缓存/CDN); 简化依赖(每个外部依赖都是钱,定期清理)。

三对平衡(破除「省钱=牺牲质量」的误解):性能与成本(重写烂算法好过升级硬件)、可靠与成本(只有使命关键才多地域高可用,其余优雅降级 + 自动恢复)、扩缩与成本(上限必须有,队列削峰好过按尖峰配容量)²⁴。

架构成本五指标(原书表 13.10):每请求计算成本、每 GB 每月存储成本、每 GB 传输网络成本、每笔查询数据库成本、每活跃用户/每功能应用成本²⁵。

治理四条:护栏(AWS SCP / OPA 防错误配置)、IaC 保可重复、模板带成本优化默认值、架构评审会里设成本检查点²⁶。

案例(物流初创,原书数字):微服务各自带库 → 跨服务流量和存储双重复; 重设计:按功能域合服务、消息队列削峰、缓存重复请求、旧数据自动归档—— 延迟降 18%,月成本降 40%;原书结论:「成本效率是架构清晰度的副产品」²⁷。

6. 边界与局限¶

所有量化案例无出处(-35%、-28%、-40%、$40,000/年);「开发者影响 70–80% 云开支」同样没有来源,引用时注明是书中口径。
Spot 实例 80% 折扣是最大额数字,但「可能随时被回收」的工程代价 (检查点、重试、可中断设计)只提了一句。
单位成本(每用户/每请求)的核算方法论没有展开——成本分摊到业务单元在实操里是最难的会计问题。
组织层面(预算是怎么定的、超支了谁拍板)只给了「三方协作」一句话。
不同云厂商 egress 定价差异巨大,跨云比较的成本没有覆盖。

7. 可带走的¶

云的账单六个维度:计算、存储、网络、数据库、应用服务、支持; 「忘了关掉的也要付钱」;
计算五种计费模型:按需(灵活)、预留(稳定负载 1–3 年)、 Spot(可中断,最多 -80%)、Serverless(短时事件)、自动扩缩(必须设 max);
存储要分层 + 生命周期策略;孤儿卷和旧快照是经典暗漏;
egress 按「区免费→跨区→跨地域→出公网」逐级变贵;同地域部署是最便宜的设计;
成本跨服务连锁:优化一层可能只是挪成本,要看整体;
三阶段:Inform(打标签 + 看板)→ Optimize(right-size + 清理 + 预留)→ Operate(异常告警 + 单位成本 + CI 成本门);
Infracost 进 PR:把成本反馈嵌进已有的强习惯(代码评审);
成本与性能同屏才能找根因;预算告警用 Terraform 管,进版本库;
成本感知架构:分层存储、事件驱动、该合就合、数据就近、依赖瘦身;
架构五成本指标里最有业务味的一个:每活跃用户/每功能的成本。

8. 原文地图¶

主题	原书章	原文位置
六类计费结构	Introduction(第 13 章)	`text/41-fm-introduction.txt:82`(搜「Category」) · `text/41-fm-introduction.txt:210`(搜「Table 13.1」)
「忘了关掉的也要付钱」	Introduction(第 13 章)	`text/41-fm-introduction.txt:58`(搜「forget to turn off」)
计算五种计费模型	Introduction(第 13 章)	`text/41-fm-introduction.txt:249`(搜「On-demand」) · `text/41-fm-introduction.txt:339`(搜「Table 13.2」)
存储分层与生命周期	Introduction(第 13 章)	`text/41-fm-introduction.txt:401`(搜「Hot/standard」) · `text/41-fm-introduction.txt:480`(搜「lifecycle policies」)
网络计费阶梯	Introduction(第 13 章)	`text/41-fm-introduction.txt:532`(搜「Intra-zone」) · `text/41-fm-introduction.txt:622`(搜「Table 13.4」)
成本连锁与标签	Introduction(第 13 章)	`text/41-fm-introduction.txt:709`(搜「Logging agents」) · `text/41-fm-introduction.txt:745`(搜「aws_instance」)
70–80% 与三阶段循环	Introduction(第 13 章)	`text/41-fm-introduction.txt:926`(搜「70-80%」) · `text/41-fm-introduction.txt:991`(搜「Inform」)
工作流五检查点与工具箱	Introduction(第 13 章)	`text/41-fm-introduction.txt:1156`(搜「Code review」) · `text/41-fm-introduction.txt:1257`(搜「Infracost」)
HR 公司案例(-28%)	Introduction(第 13 章)	`text/41-fm-introduction.txt:1417`(搜「28%」)
看板五原则与工具	Introduction(第 13 章)	`text/41-fm-introduction.txt:1459`(搜「Granularity」) · `text/41-fm-introduction.txt:1685`(搜「Kubecost」)
告警自动化与 Terraform 预算	Introduction(第 13 章)	`text/41-fm-introduction.txt:1781`(搜「80%, 90%」) · `text/41-fm-introduction.txt:1815`(搜「aws_budgets_budget」)
支付公司案例(三周→一小时)	Introduction(第 13 章)	`text/41-fm-introduction.txt:1902`(搜「three weeks」) · `text/41-fm-introduction.txt:1908`(搜「40,000」)
架构十策与物流案例	Introduction(第 13 章)	`text/41-fm-introduction.txt:1954`(搜「well-architected」) · `text/41-fm-introduction.txt:2211`(搜「18%」)
架构五成本指标	Introduction(第 13 章)	`text/41-fm-introduction.txt:2074`(搜「Cost per request」) · `text/41-fm-introduction.txt:2159`(搜「Table 13.10」)

出处:「Introduction」(第 13 章)第 70–210 段(text/41-fm-introduction.txt:210,搜「Table 13.1」)。 ↩
出处:「Introduction」(第 13 章)第 58 段(text/41-fm-introduction.txt:58,搜「forget to turn off」)。 ↩
出处:「Introduction」(第 13 章)第 219–362 段(text/41-fm-introduction.txt:249,搜「On-demand」;text/41-fm-introduction.txt:285,搜「Spot/preemptible」;text/41-fm-introduction.txt:346,搜「Right-size」)与第 794–812 段(text/41-fm-introduction.txt:809,搜「80%」)。 ↩
出处:「Introduction」(第 13 章)第 371–493 段(text/41-fm-introduction.txt:401,搜「Hot/standard」;text/41-fm-introduction.txt:455,搜「Object lifecycle management」)。 ↩
出处:「Introduction」(第 13 章)第 480–492 段(text/41-fm-introduction.txt:483,搜「orphaned」;text/41-fm-introduction.txt:492,搜「versioning」)。 ↩
出处:「Introduction」(第 13 章)第 499–622 段(text/41-fm-introduction.txt:532,搜「Intra-zone」;text/41-fm-introduction.txt:586,搜「Internet egress」)。 ↩
出处:「Introduction」(第 13 章)第 625–641 段(text/41-fm-introduction.txt:629,搜「same region」;text/41-fm-introduction.txt:635,搜「GZIP」)。 ↩
出处:「Introduction」(第 13 章)第 702–719 段(text/41-fm-introduction.txt:709,搜「Logging agents」;text/41-fm-introduction.txt:712,搜「IOPS」)。 ↩
出处:「Introduction」(第 13 章)第 722–772 段(text/41-fm-introduction.txt:745,搜「aws_instance」)。 ↩
出处:「Introduction」(第 13 章)第 926 段(text/41-fm-introduction.txt:926,搜「70-80%」)。注:该比例原书未给出处。 ↩
出处:「Introduction」(第 13 章)第 973–1045 段(text/41-fm-introduction.txt:991,搜「Inform」;text/41-fm-introduction.txt:1009,搜「Optimize」;text/41-fm-introduction.txt:1027,搜「Operate」)。 ↩
出处:「Introduction」(第 13 章)第 1132–1221 段(text/41-fm-introduction.txt:1174,搜「Infracost」)。 ↩
出处:「Introduction」(第 13 章)第 1224–1365 段(text/41-fm-introduction.txt:1257,搜「Infracost」;text/41-fm-introduction.txt:1275,搜「Kubecost」;text/41-fm-introduction.txt:1329,搜「Cloud Custodian」)。 ↩
出处:「Introduction」(第 13 章)第 1368–1391 段(text/41-fm-introduction.txt:1378,搜「Shared accountability」;text/41-fm-introduction.txt:1391,搜「metric of quality」)。 ↩
出处:「Introduction」(第 13 章)第 1394–1417 段(text/41-fm-introduction.txt:1404,搜「Infracost」;text/41-fm-introduction.txt:1417,搜「28%」)。 ↩
出处:「Introduction」(第 13 章)第 1429–1449 段(text/41-fm-introduction.txt:1449,搜「telemetry signal」)。 ↩
出处:「Introduction」(第 13 章)第 1455–1471 段(text/41-fm-introduction.txt:1459,搜「Granularity」)。 ↩
出处:「Introduction」(第 13 章)第 1598–1739 段(text/41-fm-introduction.txt:1685,搜「Kubecost」;text/41-fm-introduction.txt:1703,搜「Grafana with Cloud Billing」)。 ↩
出处:「Introduction」(第 13 章)第 1777–1866 段(text/41-fm-introduction.txt:1781,搜「80%, 90%」;text/41-fm-introduction.txt:1815,搜「aws_budgets_budget」)。 ↩
出处:「Introduction」(第 13 章)第 1869–1889 段(text/41-fm-introduction.txt:1879,搜「inefficient queries」)。 ↩
出处:「Introduction」(第 13 章)第 1892–1912 段(text/41-fm-introduction.txt:1902,搜「three weeks」;text/41-fm-introduction.txt:1908,搜「40,000」)。 ↩
出处:「Introduction」(第 13 章)第 1924–1944 段(text/41-fm-introduction.txt:1927,搜「design constraint」;text/41-fm-introduction.txt:1934,搜「cheapest reliable way」)。 ↩
出处:「Introduction」(第 13 章)第 1947–1978 段(text/41-fm-introduction.txt:1954,搜「well-architected」;text/41-fm-introduction.txt:1969,搜「modular monoliths」;text/41-fm-introduction.txt:1975,搜「same region」)。 ↩
出处:「Introduction」(第 13 章)第 1982–2034 段(text/41-fm-introduction.txt:2029,搜「limits」;text/41-fm-introduction.txt:2032,搜「queue-based」)。 ↩
出处:「Introduction」(第 13 章)第 2036–2159 段(text/41-fm-introduction.txt:2074,搜「Cost per request」;text/41-fm-introduction.txt:2146,搜「active user」)。 ↩
出处:「Introduction」(第 13 章)第 2162–2185 段(text/41-fm-introduction.txt:2172,搜「Service Control Policies」;text/41-fm-introduction.txt:2181,搜「review checkpoints」)。 ↩
出处:「Introduction」(第 13 章)第 2188–2211 段(text/41-fm-introduction.txt:2211,搜「18%」)。 ↩