ToB企服应用市场:ToB评测及商务社交产业平台

标题: 怎样看懂一张云账单？ [打印本页]

作者: 罪恶克星 时间: 2024-8-9 11:59
标题: 怎样看懂一张云账单？

对云账单的分析

  本章将研究公有云服务计费的根本原理，以及这些费用在账单数据中的体现情势。明白云账单是 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小时内）

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。

欢迎光临 ToB企服应用市场:ToB评测及商务社交产业平台 (https://dis.qidao123.com/)