如何掌控复杂的云端成本

本文要点：

• 云提供商的复杂定价策略让用户在选择服务时很容易陷入困惑，并且缺乏准确透明的账单常常会导致用户预算偏离预期。

• 云端预算管理的责任不清是造成资源超支和利用率不足的一大原因所在。预算管理需要与交付一样成为项目生命周期的一部分，并且团队需要以全新的方式协作，以了解需求并确定成本管理的优先级。

• 团队可以通过两种实用的方法来管理云端成本并节省资金：实施一致、全面的标记流程，或使用某种可提供成本可见性和精确拆解的第三方产品。

• 在团队层面管理云端预算的流程会浪费时间和资源——可见性的上移会让团队无需费时费力做研究，并让开发人员也参与到讨论中来。

在本地环境中，你会很清楚自己在基础架构上都花了哪些钱；这部分开支包括了前期的资本投入。向云端转型带来了灵活性、众多服务以及托管部署的能力，但可能要付出一定的代价（双关语）。云端计费对很多人来说是一个陌生的领域，可能会很难把握，因为费用是在你消费一个个项目时收取的。在你的企业中，如果没有强有力的成本管理实践，预算就很容易失控。

当团队在云中启动一个新项目时，开发人员和交付团队往往不会优先考虑预算管理的事宜。项目流程通常是这样展开的：CFO 确定并监督总体预算。产品负责人确定了项目的上线日期，然后努力确保所有人都跟上节奏。在为这个新项目配置资源之前，人们并不会按每月预算或总体云托管成本预期来体现成本，能见到的只有交付时间表。开发人员需要资源，运营人员则忙于尝试迭代并满足前者的需求，同时还要保证安全性。最紧迫的优先事项是在截止日期之前交付安全的应用程序，而不是试图了解令人困惑又复杂的云服务定价和利用率。

成本不断增加，一开始还没有引起注意，直到开始支付月度账单时，首席财务官才希望搞清楚为什么云端成本会如此昂贵。到那时问题已经爆发了，应用程序团队却很难找到预算爆表的问题源头，因为没有任何资源标记上了有用的信息。这一循环不会停止，没有人能完全掌控成本，或搞清楚云服务到底吞噬了多少项目预算。

到 2020 年底，云端项目预计将占企业所有技术支出的70％。因此，随着公司支出的增长，组织越来越需要妥善处理混乱的云端开支，并夺回预算的控制权以优化成本。

云端定价（欠缺）透明度

这是一个同云计算一样古老的故事：头部云服务提供商（AWS、Microsoft Azure 和 GCP）的定价模型并不像本地部署那么简单。结果，很多组织试图在迷雾中寻找方向时会浪费时间、预算，并错过潜在的成本节约机会。今年《云状况报告》的受访者估计，企业在云计算上将超支 23％，同时还会浪费云端总支出的 30％。

云提供商并没有为你提供原有基础设施计费方案的简单 1：1 映射。他们的重点是简化将 IT 迁移到他们的环境中的过程，并提供这一过程所需的所有服务。

以 AWS Lambda 为例。假设你有一个使用 Cloudfront CDN 的 Web 应用程序。当用户与应用程序交互时，它会通过一个 API 网关触发一个 HTTP 请求，而这个 API 网关会调用一个 Lambda 函数，该函数会获取数据并将其存储在 DynamoDB 中。

这里的需求看起来很简单，但你现在其实在使用四个 AWS 云服务：用于缓存的 CloudFront CDN，用于路由 HTTP 请求的 API Gateway，用于执行和处理请求的 Lambda 以及用于根据用户请求存储数据的 DynamoDB。每一种服务都有自己的定价结构，并混有一些免费套餐。

1. CloudFront 每月免费提供 50GB 数据传输和 2,000,000 个 HTTP 请求，免费期一年，但随后收取的数据费用会因数据层所在的各个区域，以及各个区域的 HTTP 请求的定价而异，无效请求的定价为每个无效路径请求 0.005USD，此外还有每 10,000 个请求每字段级别加密的定价、每 1,000,000 个实时日志请求的定价，等等。

是不是已经头晕了？

2. API 网关的定价也有免费套餐，包含 1M RESTful API 请求、1M HTTP API 调用、1M 消息和 750k 连接分钟数。此外，每百万次 API 调用有一些根据调用次数区分的区间定价；如果你决定按每个缓存内存分配的大小开始缓存，那么还会有按缓存次数计算的定价；十亿次以内的消息传输是一个价格，按照每百万次传输计算，还有一个每百万连接分数的 0.25 倍费用。

你还跟得上吗？

3. Lambda 定价因地区而异，但每百万请求有一个价格，还有一个每 GB 秒钟的持续时间成本。持续时间成本取决于你为函数分配的内存量，每 100ms 的每个内存段的持续时间成本各不相同。然后还有额外的，用来提高速度的并发能力收费，在配置期间的并发数量方面也存在成本。除此之外，你可能会在你所在地区以外进行数据传输，这属于 EC2 数据的标准数据传输费率范围（这又是一套完全独立的定价结构）。

我可以继续讲一讲 DynamoDB，但我觉得上面这些已经足够说明问题了！

这些复杂的计费点需要你甚至在开始之前就了解自己的最终状态才行，这就是导致团队在估算近似成本时容易犯错误的原因所在。唯一合乎逻辑的云端实践就是开始使用它，并在迭代时跟踪你的支出。

条款太多了

在多个云服务之间货比三家是很难的，因为每家提供商都使用了不一样的术语。Azure 的“虚拟机”在 GCP 上称为“虚拟机实例”，在 AWS 上仅称为“实例”。一组实例在 Amazon 和 GCP 上均称为“自动缩放组”，但在 Azure 上称为“缩放集”。由于命名约定不同，甚至搞清楚你要购买的究竟是什么产品，以及是否还有可替代的竞品服务都是很难的事情。

就像上面那个只使用了 Lambda 的简单 Web 应用程序的例子那样，人们需要花费大量时间才能对比一个 Web 应用程序托管在一个云中与另一个云中的花费。我们需要掌握每个云提供商的技术知识，才能搞清楚这个服务商的服务和另一家提供商的服务如何对应，要对比定价就更困难了。

用多少花多少

云端计价使用的是按需模型，这与本地的情况相去甚远。在本地部署中，你可以部署很多事物并让它们 24/7 工作，却不会增加成本（除了电费）。在云中，一切费用都取决于你使用服务的时间，以每小时、每分钟、每个请求、每个数量或每秒为基准。日志的存储方式、你使用的数据库，甚至是托管的国家/地区最终都会影响你支付的费用。

如果你忘记关闭一个虚拟机或配置了你实际上不需要的东西，那就是在浪费金钱。由于云的弹性，用户可以随时轻松订阅许多资源；因此，如果你为了满足性能要求而超额配置，那么你就会浪费很多成本。根据Quocirca的一项研究，组织平均只使用了他们云端服务器的 37%能力。但从另一方面来看，云资源是“计量”的，这意味着你只需要配置（并支付）所需的资源即可。

没有单一的云定价单位

前面提到，云端并没有单一的有形定价单位。你需要为托管所需的计算和内存资源付费，但存储、数据库和其他组件也有收费项目。云服务还有几种类型：基础架构即服务（IaaS）、平台即服务（PaaS）、函数即服务（FaaS）、存储即服务（STaaS）和安全即服务（SECaaS），所有这些类型的计费标准都不一样。

如何控制成本

根据 Flexera 的2020年云状态报告，受访者预计 2020 年企业云支出将增加近 50％，但精确预算仍然非常困难。于是，节省成本连续第四年成为了企业云计划中的最优先事项。

公司可以通过以下两种方式之一来管理自身的云成本，从而节约支出：

1. 实施一种在设计生命周期中增加成本指标的方法，或者

2. 使用一种可以简化成本数据并提高可见性的产品。

3. 使成本指标成为生命周期的一部分

为了让团队能够自己管理自己的成本，预算意识必须从一开始就融入团队的工作方式中，并且一直都要作为优先事项。与交付一样，成本计算应成为生命周期的一部分。

预先思考如何提高成本的透明度是很重要的。如果你要让几个团队混用云端账户，就不能将云帐户/项目 ID 用作分隔点了。这意味着你将需要一种严格的标记方法，和一种围绕云服务供应的良好有形业务分类法，才能让人们了解哪些成本主要来自哪些团队。

从团队的角度来看，他们可能希望按照微服务和环境来组织成本。于是，每个云服务都需要使用各个环境、各个团队使用的各个微服务来标记。

团队可能还有成本中心数据，这是很有用的。这样当公司收到账单时，这些账单就以归属到特定的成本中心，从而简化的业务的充值工作。

在了解你的支出金额时，应该通知哪些人呢？在云中设置预算并通知预算负责人和开发团队，是鼓励正确工程行为的关键环节。将你的年度预算细分为月度计划，可以更好地为团队设置预算目标。所有云提供商都有实现这一目标的机制，但如果没有良好的细粒度标记结构，你就不见得能知道如何对预算做出反应，因为面对如此庞大的账单，你很难弄清楚哪种服务对应的是哪种环境。

预算与合适的大小

开发时随时考虑成本指标意味着效率提升措施可以融入应用程序的设计中，并且开发人员会知道在不使用某些事物时应将其关闭，或者正确地调整事物的大小。预算编制应该可以更好地塑造团队行为，并且每个职能部门都应发挥自己的作用，包括具备云和运维技能的 DevOps、具备应用工程技能的开发人员，以及具有远见并了解预算的产品负责人/经理。

那么，团队可以使用哪些技术来简化成本节约工作呢？Github 上已经针对各大云提供商提供了一些有用的工具，这些工具使用云提供商的函数即服务在特定时间内关闭云资源。但讽刺的是，你得花钱运行一项服务来关闭另一项服务，才能节约云服务支出。

你还可以使用云调度服务，这种服务允许使用调度程序来启动和停止计算实例，但同样的，这种服务也会产生成本，并且仅限于标准计算机，不适用于其上的其他服务。

如果你有了 Kubernetes 之类的东西，就可以在集群中运行一些工具（例如 Kube Downscaler），并允许 Dev/DevOps 团队缩减他们的应用程序，接着触发自动缩放器以缩减实例，就可以开始节约开支了。在各大云服务中还为每种服务提供了针对性解决方案，例如 Appvia 编写的一种使用 Kubernetes 关闭 AWS 中 RDS 的工具，称为 rds-scheduler。它很像 Kube Downscaler，接收 Cron 风格的时间参数，来指定要关闭事物的时间。

正确调整和自动扩展基础架构的大小基本上是一个连续的评估过程，需要在多个环境中定期对应用程序和基础架构做好监视工作。围绕未充分利用的资源设置监视警报是和预算一样重要的环节，并且能帮助团队根据需要调整基础架构。

2. 用一种产品简化成本管理

想要以一种可行的方式实施上述过程，需要在实施方法上花费时间、精力并做一些前瞻性思考。并不存在用于云预算管理的通用流程，公司需要优先考虑内部管理流程或寻找一种第三方产品来简化成本可见性。你可以自己做实践，以保持对团队和预算的控制，但这需要大量人力工作，需要不断维护标记并审核。为了保持这套流程正常运行，团队需要共同理解成本支出，就像他们理解发布周期一样。

你的团队可能并没有这些行为，并且不想将大量资源用于计划、标记、消费行为、合理调整规模和预算管理。你希望你的团队能从这些工作中解放出来，加速迭代并更快交付。因此你遇到了麻烦：优化预算还是敏捷团队？

传统上，开发人员在处理项目财务时会陷入困境，但他们具备构建技能和理解能力，能够评估哪些地方可以节省成本。可以使用一种产品来为你的团队提供更高的可见性，使他们无需花费时间研究成本和标记服务。你可以使用每个项目的支出见解来代替常见的汇总视图，以帮助优化预算并防止支出失控。

云端支出的未来

现有的云端预算管理流程浪费了大量时间和资源。挫折和效率低下无处不在，这会损害员工的士气，影响团队运作。而且，当你在不需要的云资源上浪费金钱时，不仅会对团队造成损害，而且也会对整个创新过程产生巨大的负面影响。如果你的团队把注意力放在了如何达成预算目标，并且努力完善流程、工具和工程实践以支持预算方案，他们就不会专注于设计业务应用程序创新了。

无论是完全在内部管理成本还是利用第三方的成本可见性产品，云支出优化的最重要环节是沟通。运维人员和开发团队需要分享见解，但如果当前流程限制了可见性并需要全方位的研究时，分享见解就会变得很困难。

可见性的上移会消除团队发起耗时的研究来人工对比成本的需求，并让开发人员可以参与到讨论中来。预算制定能够让团队步入正轨，避免意外的开支。

作者介绍

Jonathan Shanks 是 Kubernetes 交付平台Appvia的首席执行官和联合创始人。他是一名 DevOps 专家和企业家，在研发领先的开发人员和工程师扩展和交付解决方案方面拥有近二十年的经验。他领导着一支极富才华的工程师和开发人员团队，致力于构建一个突破性的工具平台，使大型组织能够快速安全地创建创新产品和服务，并利用 Kubernetes 的强大功能简化基础架构、加快交付并降低成​​本。在加入 Appvia 之前，Jonathan 是内政部主管兼技术主管。他的角色涉及与工程师团队合作，为多个数字项目提供解决方案。Jonathan 率先采取了旨在振兴内政部技术基础设施方面的举措，从而节省了大量时间和金钱。Jonathan 曾在纽约泛欧证券交易所担任 Linux 架构师，在 Betfair 担任高级 Linux 工程师，从中获得了丰富的经验。

原文链接：

Taking Control of Confusing Cloud Costs