如何看懂一张云账单？

对云账单的剖析

本章将研究公有云服务计费的基本原理，以及这些费用在账单数据中的体现形式。理解云账单是 Fin Ops 生命周期后续成本分配与优化的云环节的关键。与云支出相关的组织架构决定了特定的优化操作由谁来执行，以及 FinOps 相关工作委派给谁。

我们不拘泥于单一的计费项目，而是比较公司对各云资源之间计费的细微差别。只有怀揣这种理念，FinOps 实践者才能撰写出有效报告，帮助所有团队理解云账单。

云计费的复杂性

云账单数据非常复杂。仅 AWS 一家公司就有超过 20 万个产品库存单位（SKU），其中部分产品甚至按秒计费。这些数据经由每日多次更新，与实例运行时长、存储大小及数据传输等消耗所产生的费用存在着复杂的联系。我们见到的某些大型云客户每月支出高达数十亿美元。

市场上有些平台能够代替公司处理复杂的云计费，团队中也至少需要一位深入了解数据的 Fin Ops 实践者。这不仅有助于公司其他团队理解和分析账务信息，也更容易让团队解释来自 FinOps 平台的数据和相关推荐。

财务部门看到的发票数据可能会与正在分析的详细账单信息（例如 AWS 成本与使用情况报告）有出入。一个架构良好的 Fin Ops 平台中的实践者能在每月的发票对账中保持两者数据一致，但发票所应用的分期付款、混合费率或承诺使用折扣的粒度级别可能仍与服务或账户 / 订阅级别的详细账单数据不同。因此，团队应该尽早设定期望值，即只用发票记录应付账款数据，而非分析云支出。

通过发票上显示的每月详细信息与云服务等级，我们得以确定服务背后的成本驱动因素。

AWS、GCP 和 Azure 都配备了可靠的入门级成本工具，在较高层次上对云支出进行分析，这也是实现可视化关键的第一步。然而，一旦公司实现了多云计算，定制了协商费率，公开了支出数据，并建立团队责任制或者进入容器成本分配时，这些工具往往就不起作用了。

账单数据的基本格式

我们将从三大云服务供应商的大部分账单数据的基本格式入手。在这些文件中，每一行都列举了特定类型资源的使用量。云计费项目往往具备保留特定时间段内使用情况的快照的属性。以下因素将被附加至“使用情况”行 ：

●时间段。

●资源使用量。

●此时间周期内的费率详情（用于收费）。

●按地域划分后的位置信息。

●资源 ID。

●用于将支出分配至产品账户或项目等的元数据属性。

在第 9 章中，我们将介绍何为标签，以及如何利用标签推动问责制。在此之前，我们需要观察各个主要云供应商的账单数据实例，以了解支持 FinOps 程序的原始要素。

图 5-1 展示了每日收到的数亿账单数据中的一行。数据从表面上看可能不太连贯，但你能从中发现一些重要属性，例如 ：

●使用资源的时间。

●应用于账单的费率及费用。

●正在收费的资源。

●是否有订购申请，如有，是哪一项。

●成本分配的标注信息（元数据）。

●收费地区与服务。

在开始 FinOps 实践时，这些细粒度的账单赋予了 FinOps 团队强大的能力。但这些细粒度信息也提高了数据的复杂程度，导致最终账单数据的规模之庞大，已经无法使用电子表格记录。你必须求助于计算机管理系统。

图5-1  AWS CUR账单数据的样本行

理解这种复杂性，能让你在 FinOps 这条路上尝试一些非常酷炫的事情，比如当一些“小”变化发生时，引入异常自动检测机制。之所以说是“小”变化，是因为云效率的反馈往往会被多次削减。想象一下，公司每月在云计算的支出是 1  000  000 美元，一个团队在

集群上运行着 50 个计算实例却不使用，每日都将导致 5000 美元的浪费。考虑到两者在规模上的差异，当回顾服务层级总结或每月汇总时，你甚至都不会注意到任何变化，然而每月这两笔“小”金额加起来已经超出 150  000 美元，也就是每月总花费的 15%。你必须通过计算机学习，来分析数据的微小变化，以免造成巨额成本浪费。幸运的是，云供应商通过提供账单数据详单，能够帮助你洞察用量变化，在小规模浪费变成无法挽回的巨额成本之前解决这个问题。

放过我，时间！

20 世纪90 年代，胡蒂和河豚（Hootie and the Blowfish）乐队发布了一首名为《时间》的歌曲，他们歌颂着时间如何“带你展望明天及所有的痛苦与悲伤”“明天只是另一个今天……我不相信时间”。

鉴于此，可以猜想胡蒂和河豚乐队大概率对 Fin Ops 不感兴趣，毕竟云计费的本质就是时间问题。每笔费用都有时间限制，即使固定费率项目也会按每月或每年收费。而更常见的情况往往是需要你支付每秒的计算费、每月储存费，以及某个查询完成所需时间而产生的费用。

当然，此规则也有例外。无服务器与数据传输并非基于时间，而是基于用量。两者仍然属于相同的用量 × 费率的计费模型。例如，720GB 的数据传输费率可能为 0.02 美元 / GB，235  000 次函数调用费率为 0.001 美元 / 次。然而示例也要基于使用情况。你用过它吗？用了就付费，没用就不必付费。这也体现了云计算的可变支出模型与私有化部署的固定支出模型之间的区别。

云服务提供商是如何对实例 / 虚拟机 / 计算进行收费的呢？一般是基于资源的运行时间。尽管大多数供应商以秒计费，但此处我们以小时为例来简化此概念。每月有 30 天，即720 小时，或 31 天，即 744 小时（我们稍后讨论二月）。

所以，一项资源在一月运行的计算费用如果按小时计算，你会看到一行数据，显示该资源的计算使用时间为 744 小时。当然，它还包括 744 小时的费用。在 744 小时中，可能每小时的计费率相同 ；也可能其中 200 小时使用了预留实例进行结算，剩余 544 小时未使用。如果是后者，将出现两行数据，一行按需列出 544 小时，另一行则预留实例 200小时。

不积小流，无以成江海

将每一笔小支出相加，汇总成每项服务或每月的总费用。但每一笔小的支出都有其细微的差别和属性，如果研究得更细致些，你就能发现其中丰富、有用的使用数据。记住，要按资源使用的实际运行时间收费，不是看资源是否被使用，而是观测资源何时开始运行。

我们常常这样向公司解释 ：“不要依恋资源，你买的不是资源实物，而是一定时间内资源的部分使用权。”这句话可能难以理解，但却在实践中变得清晰。早在 20 世纪 90 年代，夏威夷的凯克天文台就以当地海滩的名字命名了每台服务器 ：哈普纳、基霍洛、考瑙阿、毛梅。但现在计算资源并未被独立管理。

就如我们稍后会进一步解释的，即使是预留实例也不拘泥于其附属于哪个服务器，它们只是被简单附加至一个匹配其特定属性的对象服务器。当你将同样的思维应用至云计费时，你会意识到你购买的是时间，而非实物。尽管这看起来对某些人显而易见，但这个概念是财务团队理解和管理云账单的关键。

云账单的数据简史

坦白地说，我们对云支出数据一无所知。大家可能会在 AWS  re ：Invent 或 Google  Next上看到我们发表的内容，回顾过去十年 AWS 账单文件的各种迭代，以及每次迭代解锁的功能。冒着重蹈覆辙的风险，这些迭代完美地映射了一家公司开启 Fin Ops 实践的经典过程。迭代的每一步都反映着这个时代最先进的云用户的成熟度。如果其他公司没有跟上那段时间 Fin Ops 发展的步伐，那么他们目前很可能正在走相似的路。因此，我们必须秉持着应用爬、走、跑战略的态度，来快速、深入地了解过去十多年 AWS 账单文件更新的情况。

2008 年 ：发票

这是一切开始的起源。通过发票，我们看见了月度账单与服务账单，没有标签等公司自管理的元数据，也没有帮助理解变更因素或驱动因素的细粒度。基于这一点，

财务团队常常会问 ：“这张发票的数据有错吗？”而要回答这个问题，则需要查看账单数据的下一次迭代。

2012 年 ：成本分配报告（CAR）

早在 2012 年，AWS 用户就试图回答以下问题：“我知道我这个月要花 100 000 美元，但这些钱是哪些团队花的，又花在哪些产品上？”于此，成本分配报告文件设计了各个标记值与其连接账户之间的单独数据行。在当时，这是一个巨大的飞跃，我们总算可以进行支出分配了。但成本分配报告的缺陷是，由于支出每月报告一次，无法判断支出何时出现，以及何时出现峰值。成本分配报告文件上还有未标记支出的合计行，但无法查询这些支出的源头。

2013 年 ：详细账单报告（DBR）

详细账单报告针对每项服务支出引入了时间序列。你不仅能查询一项服务在特定月份中的支出，还能看到服务在该月产生支出的具体时间，你能体会其弹性与月内变化如何反馈至支出。但是，剧透一下，详细账单报告缺乏一项关键数据，而它将彻底改变以往的成本管理。

2014 年 ：附有资源项和标注的详细账单报告（DBR-RT）

附有资源项和标注的详细账单报告改变了操作模式，它为各时间段使用的资源设置了单独行，为每个标注键设置了单独列。此后的数据增长令人咋舌 ：大客户的详细账单报告极少超过兆字节，而其附有资源项和标注的详细账单报告则运行了数百 GB 的 CSV（逗号分隔符）数据。一些大客户的一个文件中可能包含数十亿个逗号。通过这些文件，我们了解到在哪个特定时间段，哪个特定的资源 ID 及标注导致成本支出，以及在那个时间段内是否应用了预留实例，任何细微变化都无处遁形。早期 FinOps 实践者即据此提供更佳的优化建议。

2017 年 ：成本和使用报告（CUR）

在账单文件的发展过程中，成本和使用报告文件的代号为“Origami”，它颠覆了以往的计费模式。这是 AWS 的全新尝试，不再使用逗号分隔符，而以 JSON 格式替代，便于程序读取。演进过程中，某些数据（如费率）被拆分为独立的 JSON 文件。而此前，大家为了寻求简化的详细账单报告格式，创建了各自的账单数据读取器，单个 JSON 文件使数据读取变得愈发困难。不过，成本和使用报告有个微妙的优势 ：它在文件中显示是否应用了预留实例，以及在那个时间段内应用的具体实例（或实例部分）。于此，你能更清晰地了解预留实例，及其告知额外资源购买与决策修改的方式。

了解完这段短暂的历史，你可以发现它遵循着爬、走、跑的理念，总结如下 ：

1.向云服务提供商付款前，你可以查看你服务的支出总额。（发票）

2.你希望看到哪些团队或哪些产品负责这项服务，进而推动费用展示或费用分摊。（成本分配报告）

3.你开始关心资源使用的具体时间。（详细账单报告）

4.现有的详单开始无法满足你的需求，你开始意识到需要精确定位具体资源动向及费率应用，并确定何处存在分配差距。（附有资源项和标注的详细账单报告）

5.最终（至少就目前而言，因为 Fin Ops 永远在进化），你开始尝试将越来越多的 FinOps 工作程序化，并试图回答关于投资回报率的问题及预留实例等使用承诺的价值。（成本和使用报告）

这种演进同样在 Apptio  Cloudability 公司出现过。2011 年，他们的平台仅仅是一组登录至 AWS（使用根凭证，因为 IAM 即“身份与访问管理模式”仍未出现），通过屏幕获取账单信息，解析云支出项目，并且将具体数字每天发送到邮件的脚本。直到今天，每日邮件功能“仍是平台的核心，推动着团队的反馈闭环。但为了匹配日趋复杂的账单数据，所有 FinOps 平台都演进了相关功能”。

前文所述的历史都基于 AWS 的账单数据，因为在写作本书时，AWS 发展最成熟。但请你放心，其他供应商也正经历着（或已经经历了）与之类似的计费周期。

每小时数据的重要性

你可能疑惑为什么需要关注每小时（甚至每秒）级数据及资源级粒度。标记级别中的每日或每周的粒度还不够吗？确实不够。而且一旦你的 Fin Ops 实践越过初级（爬）阶段，这种不充足将体现得更为显著。

执行如规划预留实例等更高级别的 Fin Ops 任务需要每小时数据。购买预留实例的行为取决于你在特定时间内运行了多少特定类型资源，这与预订资源的盈亏平衡点紧密相关。如果你以月为时间单位计算资源，你就会忽略这种重要的细节。要确定究竟需要多少资源，必须查看每小时（甚至每秒）正运行的资源数量及使用水位线。

由于我们的介绍仍处于初级（爬）阶段，对于上述内容，此处不做赘述。但请谨记， AWS、GCP 和 Azure 所提供的细粒度可视化对于访问可变资源是至关重要的，毕竟这些资源都是以秒或分钟为单位存在于服务器并进行收费的。

一个月不再是一个月

想象一下，一家公司在年初采用了新的成本优化计划，它从 1 月 1 日生效，列举了一系列削减成本的措施 ：“我们取消了‘僵尸实例’，调整了一些不合适的规格，购买了一些预留实例。”之后的一个月，云账单显示成本下降了 10%。大获全胜！

但仔细想想，2 月份的天数只有 1 月的 90%，这似乎显而易见，但拿 2 月的数据与其他月份相比，成本下降的幅度让团队产生了“降低成本的策略是有效的”的错觉。之后，不可避免的是，到了 3 月 31 日，大家开始恐慌，因为成本在以每月 10% 的速度上涨。

值得再次强调的是，云账单与时间密切相关。不同于财务团队习惯的数据中心按月计费模式，云计费的粒度要细得多。比如，你想比较两项同类资源，都必须在相同时间长度内做比较，无论是 10 天还是 10 小时。

拒绝瀑布式分期付款计划，即不再将一年支出简单地除以 12 个月，这对你来说会是一个巨大的飞跃。然而旧习难改。我们遇到过财务部门批评分摊到每小时的精确计算的数据有 10% 的偏差，最终发现是因为财务部门把分期付款额简单地除以 12，而正确的计算方式是用每秒（或每小时）的分期付款成本乘以所使用的小时数。这个例子也说明了 FinOps 的发展需要全新的理念。

一美元不再是一美元

虽然我们研究的是同类资源的比较，但请务必记得 ：特定行中特定资源类型的费率与同类型但不同时间段内资源的费率可能不同。在内部部署中，你可以在选定时间内为资源设置相同费率 ；而云费率则随云供应商应用的资源预留或批量折扣的情况而大不相同。

此外，预留实例或承诺使用折扣的早期预付款分期付款可能会进一步改变以上结果，这取决于你是否将这些因素纳入用户可见范围。我们的建议是纳入，因为其显示的金额代表着之后你能收回的款项。但这些假设是以公司已经处在分配阶段为前提的。

如果你选择不纳入分期付款预付款，尤其在 AWS 和 Azure 提供前期预付费示例时，团队可能会低估实际支出。如果不将这些内容纳入考虑范围，则应用部分使用的账单数据那一行将显示 0.00，团队以为他们成本降低的措施是有效的，但这个速度未免过于“高效”了。

谨记，即使团队不改变基础架构，费率和支出仍是可变的。

支出计算公式

云账单的计算公式非常简单 ：

支出 = 用量 × 费率

用量可能是使用资源的小时数（AWS 和 GCP 云以秒为单位）。费率是每小时（或每秒）使用该资源或特定类型储存所支付的金额。光看公式很简单，使用率或费率的上升，都会导致支出上升 ；若两者都增加，则支出将大幅提升。

这个简单的公式是决定如何优化及委派何人优化的关键。接下来我们按照顺序，先讨论如何优化，再研究该由谁进行优化。

影响账单的两个杠杆

根据前面的公式，FinOps  提出了影响云支出的两个基本杠杆。

第一个杠杆是降低资源用量。这就是所谓的规避成本，具体而言，你可以终止闲置资源、调整超规格资源、减少非高峰时间运行的资源数，或是在晚上（或者周末）完全停止资源使用。

第二个杠杆是为使用的资源少掏钱。这就是所谓的降低费率，可以通过利用云计费结构

（例如，预留实例（AWS 或 Azure）及承诺使用折扣）来实现（GCP）。其他方式包括采用基于使用量的批量折扣（如 GCP 的可持续使用折扣），一些云供应商也会为大规模用户提供定制定价计划。一些公司还会使用竞价实例或可抢占实例，这两种实例在生产系统出现突发的资源损失时，可以有效地辅助工程团队快速恢复潜在的业务系统影响。无论使用上述何种方式，都能降低资源使用的成本。

谁该规避成本，谁该降低费率

当细分优化任务时，谁该为哪个流程负责通常都会引发争论。八年以来，经过与未能很好执行 Fin Ops 流程的数百家公司和小部分迈入高级运营阶段公司的探讨，我们对此有着坚定的看法 ：

其中最成功的那部分公司都进行了去中心化用量优化（即规避成本）和集中费率优化（即降低费率）。

控制大部分云支出的去中心化决策者往往是应用程序的所有者。他们最清楚何时应该关闭资源使用、调整资源规格或更改需求。由于他们非常熟悉工作负荷需求，所以能根据规格优化报告来决定，究竟是保留还是关闭看似空闲的实例。集中化的基础架构决策不可能是高效的，应该充分授权，让工程师或应用程序所有者从业务角度出发，做出正确的决策。

美中不足的是，这些应用程序所有者往往会忘记购买预留实例或承诺使用折扣。更有甚者，会搞混它们的工作原理。而这时，FinOps 中心团队就能纵观全局，在整个云产业中，寻找降低成本的机会。不但如此，他们还具备采购及财务分析的技能，理解现金流分析的细微差别。

衡量 Fin Ops 团队工作有效与否的指标 ：预留实例 / 承诺使用覆盖率是否上升 ；空置率是否下降 ；是否利用批量折扣或协商定价。

集中降低费率

预留实例及承诺使用折扣等降价产品非常复杂，云服务提供商也在不断更新他们的产品（本书出版时就可能有新产品出现）。因此，让每个团队去花时间学习如何应用、追踪、优化及操作这些已有的折扣计划是低效的。

你的组织想要以折扣费率运行的云资源往往来自不同团队。大型公司运营的产品与项目需要成百上千的云资源，集中管控所有预留实例意味着共享覆盖率的提高。

单个预留实例或承诺使用折扣可被应用至多个资源，以 AWS 为例，穿梭于各个客户之中，让单个团队进行费率降低项目的管理往往会导致总体覆盖率偏低、个体覆盖率过高，或造成其他浪费。而此时，如果出现一个全面了解相关内容的中心团队，就能实现成本的大幅节省。正如我们将在第 14 章介绍的预留实例战略，除了考虑预留实例承诺的资源类型，还有许多方面值得斟酌。我们还将讨论公司为购买这些产品将如何进行资金部署，以及如何引入财务团队的参与。

比如，一个团队在白天的资源使用率很高，而另一个团队在晚上的资源使用率很高。根据它们各自的使用情况，如果两个团队各自购买预留实例都会产生资金浪费。但纵观一天的使用情况，公司必须在 24 小时内都有资源配备。此时，就轮到中心团队发挥作用，通过购买预留实例，为双方团队降低各自的资源付费率。

在走和跑阶段，保持预购率增长及浪费数据下降需要保持始终如一的持续管理。此外，初次购买涉及的因素太多，很难正确决策（案例显示，一次错误的预购可能导致数百万美元的损失）。FinOps 团队降低了资源浪费的可能性，同时优化了资源覆盖率。

警告：出于某种原因（比如，有非常特殊的资源需求），集中化对一些团队来说并无意义。这种情况将在第 14 章进行具体讨论。

为什么要去中心化优化用量

伴随着中心化费率降低的战略推进，规避成本（减少使用）成为公司中所有团队都需要积极参与的活动方案。在公司范围内，每天的云成本可能来自不同团队和不同工程师的成百上千个操作，这些服务支持着公司运行，它们是创新机器的核心引擎。

为了推动创新机器更快速地运行，公司应统一生成使用优化建议。首先，公司通过监控系统收集资源使用情况，并借助 FinOps 平台为资源生成替代方案，以匹配其运行的工作负载。然后，将此方案按照常规步骤，在阈值预警的基础上（对中级阶段公司而言）推送至各团队，或通过 JIRA（对高级阶段公司而言）进入软件开发迭代周期。这些方案的具体标准将在第 11 章进行详细介绍。

该模型保证了资源所有者有机会在实时变更方案之前进行审查。因为资源所有者比其他人更清楚资源如何使用、被谁依赖，如果更改资源是否会影响正在运行的服务，以及背后潜在的原因。

FinOps 从业者为工程团队提供资源可视化与数据访问入口，确保他们能在近乎实时的情况下做出最佳技术决策。与此同时，他们引入了潜在成本节省、支出影响，以及另一些工程团队已跟踪的项目，作为成本指标。

总结

云计费很复杂，但正是借助这种复杂性，我们得以分析推动支出的因素，各团队也获得了专属的优化决策报告。即使利用 FinOps 平台生成自动报表与可视化，也需要了解云供应商的数据格式，才能从数据中得出正确结论。除此之外，我们还应该设定标准的成本指标格式，对整个公司的文件报告进行标准化。考虑到公司与云供应商的定制折扣、收取的支持成本，“标准化”很可能是一个未借贷、分期付款的利率。为避免团队间对数据的理解产生偏差，引起困惑，标准化是一个必经的过程。

总结如下 ：

●账单数据几乎永远基于事件要素。

●只有深入了解账单数据，才能对其进行详细分析。加强原始数据的学习将帮助你成为真正的 FinOps 专家。

●云账单中的小变化会快速累积产生质变，因此，需要通过自动异常检测和差异报告来实时追踪变化，从而确定其趋势。

●云账单的简易计算公式：支出 = 使用量 × 费率，其中，可通过改变“使用量”与“费率”两个杠杆因素来优化账单，即减少使用资源的用量和降低资源费率。

●去中心化处理降低使用率的问题（减少资源使用量），同时集中处理降低费率的问题（减少支出）。

●应由中心团队管理可付费实例和承诺使用折扣，因为他们能查看完整的云资产分布，有能力管理大量使用承诺。

●获得中心团队给出的优化建议后，每个团队都应听取建议并进行用量优化，具体如何操作由应用程序所有人决定。

以上就是本书第一部分的内容，我们通过介绍何为 Fin Ops、为什么需要 Fin Ops、如何进行文化转变，以及云账单的内容，为之后的研究奠定了基础。第二部分的内容很有趣，我们将带你了解一家公司如何实现 FinOps 生命周期管理。

本文选自《FinOps云成本优化》，出版社授权首发。

作者是J.R. Storment和Mike Fuller。

本书收录了来自FinOps基金会社区大量的实践案例，能让读者了解成功的云成本优化故事，以及背后成功的原因。此外，对主流云厂商提供的技术能力做了剖析，让读者在选择云技术解决成本优化问题时有所参照。

《FinOps云成本优化》是第一本系统性解读什么是FinOps，以及如何实施FinOps 的书：它定义了在云成本优化领域的众多技术术语、财务术语，分享了企业要推动云成本优化所必须完成的组织架构调整、流程推动、职责划分，以及所需要依托的常见技术手段，等等。本书收录了来自FinOps 基金会社区大量的实践案例，能让读者了解成功的云成本优化故事，以及背后成功的原因。此外，对主流云厂商提供的技术能力做了剖析，让读者在选择云技术解决成本优化问题时有所参照。

特约折扣购书，请扫码（仅限100名）。

Tips：在本文下留言，评论区点赞前3的朋友，获得小编赠书一本。（36小时内）