瓶颈 #04：成本效益

了解主要成本驱动因素

重要的是从确定主要成本驱动因素开始。首先，成本优化团队应收集相关的发票——这些发票可能来自云提供商和 SaaS 提供商。使用分析工具对成本进行分类非常有用，无论是电子表格、BI 工具还是 Jupyter 笔记本。通过跨不同维度进行聚合来分析成本可以产生独特的见解，这有助于识别和优先考虑工作，以实现最大的影响。例如

**应用程序/系统**：某些应用程序/系统可能比其他应用程序/系统贡献更多成本。标签有助于将成本与不同的系统相关联，并有助于识别哪些团队可能参与工作。

**计算 vs 存储 vs 网络**：一般来说：计算成本往往高于存储成本；网络传输成本有时可能是意外的高成本项目。这有助于确定托管策略或架构更改是否可能有所帮助。

**预生产 vs 生产（环境）**：预生产环境的成本应该远低于生产环境的成本。但是，预生产环境往往具有更宽松的访问控制，因此它们比预期成本更高并不罕见。这可能表明非生产环境中积累了太多数据，甚至缺乏对临时或 PoC 基础设施的清理。

**运营 vs 分析**：虽然没有关于公司运营系统成本与分析系统成本相比应该如何的经验法则，但工程领导层应该了解公司运营与分析环境的规模和价值，可以将其与实际支出进行比较，以确定适当的比率。

**服务/能力提供商**：在项目管理、产品路线图、可观察性、事件管理和开发工具方面，工程领导者经常对使用的工具订阅和许可证数量以及它们的成本感到惊讶。这有助于识别整合的机会，这可能还会带来更好的谈判优势和更低的成本。

对驱动因素和相关成本的清单的结果应为成本优化团队提供一个更好的了解，即哪种类型的成本最高以及公司的架构如何影响它们。当考虑历史数据（例如过去 3-6 个月的成本）以将成本变化与特定产品或技术决策相关联时，此练习在识别根本原因方面更加有效。

确定主要成本驱动因素的成本节约杠杆

在确定成本、趋势和驱动因素之后，下一个问题是——我们可以使用哪些杠杆来降低成本？下面介绍了一些更常见的方法。当然，下面的列表远非详尽，正确的杠杆通常取决于具体情况。

**调整规模**：调整规模是指更改工作负载的资源配置，使其更接近其利用率。

工程师通常会进行估计，以查看他们需要什么资源配置才能完成工作负载。随着工作负载的不断发展，很少会进行初始练习的后续工作，以查看初始假设是否正确或仍然适用，这可能会导致资源未充分利用。

为了调整 VM 或容器化工作负载的规模，我们将 CPU、内存、磁盘等的利用率与已配置的利用率进行比较。在更高的抽象级别，Azure Synapse 和 DynamoDB 等托管服务有自己的已配置基础设施单位和自己的监控工具，这些工具可以突出显示任何资源未充分利用的情况。一些工具甚至可以推荐给定工作负载的最佳资源配置。

有一些方法可以通过更改资源配置来节省成本，而无需严格减少资源分配。云提供商有多种实例类型，通常，不止一种实例类型可以满足任何特定的资源需求，但价格不同。例如，在 AWS 中，新版本通常更便宜，t3.small 比 t2.small 便宜约 10%。或者对于 Azure，即使纸面上的规格看起来更高，E 系列也比 D 系列便宜——我们帮助客户通过切换到 E 系列节省了 30% 的 VM 成本。

最后一点建议：在调整特定工作负载的规模时，成本优化团队应注意任何预购承诺。一些预购承诺（如预留实例）与特定实例类型或系列相关联，因此，虽然更改特定工作负载的实例类型可以节省该特定工作负载的成本，但可能会导致预留实例承诺的一部分未被使用或浪费。

**使用短暂基础设施**：通常，计算资源的运行时间比实际需要的时间更长。例如，由在特定时区工作的科学家使用的交互式数据分析集群可能全天候运行，即使它们在科学家工作时间之外没有使用。同样，我们已经看到开发环境全天候运行，而使用它们的工程师只在工作时间内使用它们。

许多托管服务提供自动终止或无服务器计算选项，确保您只为实际使用的计算时间付费——所有这些都是需要牢记的有用杠杆。对于其他更基础设施级别的资源（如 VM 和磁盘），您可以根据您的设置条件（例如 X 分钟的空闲时间）自动关闭或清理资源。

工程团队可能会考虑迁移到 FaaS 作为进一步采用短暂计算的一种方式。这需要仔细考虑，因为它是一项需要进行重大架构更改和成熟的开发人员体验平台的重大工作。我们已经看到一些公司在进入 FaaS 时引入了许多不必要的复杂性（极端情况：lambda 弹球）。

**整合现货实例**：现货实例的单位成本可能比按需实例低至 70%。当然，缺点是云提供商可以随时收回现货实例，这会导致运行在它们上的工作负载中断。因此，云提供商通常建议将现货实例用于更容易从中断中恢复的工作负载，例如无状态 Web 服务、CI/CD 工作负载和临时分析集群。

即使对于上述工作负载类型，从中断中恢复也需要时间。如果特定工作负载对时间敏感，现货实例可能不是最佳选择。相反，现货实例可能非常适合预生产环境，在这些环境中，时间敏感性不太严格。

**利用基于承诺的定价**：当初创公司达到规模并对使用模式有明确的了解时，我们建议团队将基于承诺的定价纳入其合同。按需价格通常高于通过预购承诺获得的价格。但是，即使对于规模扩大，按需定价对于使用模式尚未稳定的更具实验性的产品和服务仍然有用。

基于承诺的定价有多种类型。与按需价格相比，它们都有折扣，但具有不同的特征。对于云基础设施，预留实例通常是与特定实例类型或系列相关的使用承诺。储蓄计划是与每小时使用特定资源（例如计算）单位相关的使用承诺。两者都提供从 1 年到 3 年不等的承诺期限。大多数托管服务也有自己的基于承诺的定价版本。

**架构设计**：随着微服务的流行，公司正在创建更细粒度的架构方法。我们经常遇到在中期数字原生公司中遇到 60 个服务的情况。

但是，没有考虑消费者而设计的 API 会向消费者发送大型有效负载，即使他们只需要该数据的一小部分。此外，一些服务，而不是能够独立执行某些任务，而是形成一个分布式单体，需要多次调用其他服务才能完成其任务。如这些场景所示，不适当的域边界或过于复杂的架构可能会表现为高网络成本。

重构您的架构或微服务设计以改进系统之间的域边界将是一个大型项目，但将在许多方面产生巨大的长期影响，而不仅仅是降低成本。对于尚未准备开始此类旅程的组织，而是正在寻找一种战术方法来应对这些架构问题带来的成本影响，可以采用战略性缓存来最大限度地减少聊天。

**执行数据归档和保留策略**：任何存储系统中的热层都是纯存储中最昂贵的层。对于不太常用的数据，请考虑将它们放入冷层、冷层或归档层以降低成本。

重要的是首先审查访问模式。我们的一支团队遇到一个项目，该项目将大量数据存储在冷层中，但仍然面临着不断上升的存储成本。项目团队没有意识到他们放入冷层的数据经常被访问，导致成本增加。

**整合重复的工具**：在列举服务提供商方面的成本驱动因素时，成本优化团队可能会意识到公司正在为同一类别（例如可观察性）中的多个工具付费，甚至想知道是否有任何团队真正使用特定工具。消除未使用的资源/工具并整合类别中的重复工具无疑是另一种节省成本的杠杆。

根据整合后的使用量，可以通过获得更好的定价层级，甚至利用增加的谈判优势来获得额外的节省。

按努力和影响优先排序

任何潜在的节省成本的机会都有两个重要特征：其潜在影响（潜在节省的规模）以及实现它们所需的努力程度。

如果公司需要快速节省成本，从成本为 50,000 美元的类别中节省 10% 自然比从成本为 5,000 美元的类别中节省 10% 更好。

然而，不同的成本节约机会需要不同程度的努力才能实现。一些机会需要更改代码或架构，这比配置更改（例如调整大小或利用基于承诺的定价）需要更多努力。为了更好地了解所需的努力，成本优化团队需要从相关团队获得输入。

图 2：客户优先级排序练习的示例输出（对不同公司进行的相同练习可能会产生不同的结果）

在本练习结束时，成本优化团队应该有一份机会清单，包括潜在的成本节约、实现这些机会所需的努力以及与实施前置时间相关的延迟成本（低/高）。对于更复杂的机会，需要指定适当的财务分析，如后文所述。然后，成本优化团队将与支持该计划的领导者一起审查，优先考虑要采取的行动，并提出执行所需的任何资源请求。

成本优化团队应该理想地与受影响的产品和平台团队合作执行，在向他们提供足够关于所需行动和理由（潜在影响和优先级）的背景信息后。但是，如果需要，成本优化团队可以提供能力或指导。随着执行的进行，团队应该根据从已实现的节省与预计节省以及业务优先级中获得的经验教训重新确定优先级。

将成本管理的责任分散

对于减少阶段，我们建议组建一个成本优化团队，与相关团队合作执行优先的成本节约机会。为了维持优化的成本水平，成本管理的责任需要从成本优化团队转移到各自的团队。

我们合作过的大多数初创公司都采用了产品团队模型（包括平台工程产品团队），这意味着他们中的许多团队都清楚地了解自己拥有的系统。产品团队拥有运行其产品所需的自定义软件，以及其功能所需的任何独特的第三方系统。平台团队拥有与其提供的功能相关的系统。这可能是 CI/CD 或可观察性等技术能力，也可能是一种可重用的业务能力，例如支付。

然而，即使在组织良好的初创公司中，一些系统也会随着时间的推移而成为孤儿，有时是悄无声息地，通过组织重组和自然减员。

为了验证团队对其所有权边界有多清晰，初创公司可以审查他们拥有的系统和现有的所有权分配。在许多组织中，此信息将作为一项持久资产维护，例如服务目录，应与团队一起审查以验证其有效性。

没有此类服务目录的组织可以从对技术环境进行快照开始（例如，使用C4 模型列出或可视化系统），并与团队合作将每个组件标记为其各自的所有者。从长远来看，最好将其转变为一个活生生的工件，例如服务目录（即使是轻量级的——文档而不是完整的门户网站）。

理想情况下，通过该过程，任何已识别的孤儿系统都将被分配给所有者。实际上，根据业务关键性、成本影响或其他维度进行优先级排序是合理的。

然后，团队领导者（工程经理、技术主管、产品主管）需要对他们团队拥有的系统的成本负责。这最初可能是一种期望，即他们以合理的节奏审查成本——这可以融入他们现有的仪式（每月同步、季度审查等）。最终，成本指标应嵌入到这些团队的 KPI 中。

将成本放在首位可以增强组织能力，并帮助传递这样一种信息，即每个人都应该考虑其决策的成本影响，并且管理人员对此负责，就像我们考虑安全性和质量一样。

然而，就像安全性和质量一样，公司需要意识到成本考虑的二阶效应。团队不应该过度节俭；他们可以咨询相关的公司领导者以帮助他们做出关于成本的决策。通常，在初创公司中，如果这意味着更快的上市时间，尤其是在实验性功能方面，团队承担会产生额外成本的技术债务是有意义的。诀窍在于要有纪律，能够发现成本何时呈上升趋势并进行纠正。

虽然将责任下放到团队层面至关重要，但一些成本管理行动，例如协商批量购买承诺和优化整体技术组合，只能通过考虑更广泛的组织背景来最佳地完成。因此，成本责任也需要在团队层面，在产品组层面承担。

使成本可见

为了支持所需的联邦责任级别，运行系统的成本需要报告并归因于拥有组织级别（团队、产品组）。实现此目标的方式取决于服务类型。例如，云基础设施或服务可以通过标签层次结构归因于其所有者，而运行在共享 Kubernetes 集群上的工作负载可以通过标签、命名空间或服务名称归因回来（Kubernetes 特定的成本监控工具允许根据标签、命名空间和服务名称将共享 Kubernetes 集群的成本分解到团队）。

虽然很难将每个服务或基础设施组件完美地归因于产品或团队，但保持报告的可发现性、可理解性和可操作性至关重要，使工程师能够了解其技术决策的成本影响，并使领导者能够了解是否需要进行任何纠正。

这些报告的详细程度很重要。当受众更接近团队级别时，提供更细粒度的數據并更频繁地更新报告会有所帮助。团队在日常开发工作中做出影响成本的决策，因此每两周或每月提供一次报告，与季度报告相比，可以更快地让他们了解改变方向的指示。

对于团队级别以上的领导者，重点是检测更大的趋势并了解是否需要对合同结构或技术策略进行任何更改。报告可能会跨不同维度汇总成本，例如在了解主要成本驱动因素中涵盖的维度，但报告通常不需要像团队级别报告那样频繁更新。

让团队更容易做正确的事

成本管理中经常被忽视的一部分是让人们更容易做到预期的事情，即对他们负责的技术环境的一部分的成本负责。与其创建一个强硬的治理流程，不如寻求实现期望的行为和结果。如果最简单的方法是最具成本效益的，技术人员自然会遵循最佳实践。

为了创造一个容易实现预期结果的环境，我们可以使用推动。理查德·塞勒在他的书《助推》中详细讨论了这个话题。他使用的一个例子是无限自助计算的良好类比：“无托盘自助餐厅。自助餐厅经理一直对减少食物浪费很感兴趣。看到人们很容易在托盘上装满额外的食物，而这些食物通常会吃不完，以及额外的餐巾纸，这些餐巾纸通常不会使用，纽约阿尔弗雷德大学的好奇的经理和学生在两天内测试了无托盘政策。当没有提供托盘时，食物和饮料的浪费减少了 30% 到 50%！”

Backstage 开发者门户网站是一个很好的工具示例，它可以推动人们做正确的事情。使用模板可以推动工程师走上黄金之路（Spotify 的铺好的道路版本）。它还具有关于文档的记分卡，以推动工程师添加属性，使其更有用和可读。

以下是一些将推动应用于提高成本效率的示例

审查和管理技术组合

组织的技术组合包括其内部系统以及第三方工具、语言和框架。组合中的项目越多，组织的责任范围就越大，导致更高的成本，包括财务投资和认知负担。虽然技术组合中的每个项目最初都是出于特定原因引入的，但这些原因可能会随着时间的推移而失效或变得无关紧要。因此，以减少碎片化的方式管理技术组合有助于降低成本。

管理初创公司技术组合的第一步是清点其拥有的系统以及每个系统的功能。通过这样做，更容易识别重叠的功能并识别冗余的系统或工具。例如，组合中的多个系统可能具有自己的 CMS 实现，或者初创公司可能会发现，在不同的团队中，有多种工具用于提供 CI/CD 功能。

一旦充分了解了组合的最新状态，我们的团队经常依靠几个工具来帮助优化组合。

一个沃德利地图可以让工程领导者可视化支持业务的技术能力，它们对用户/客户的可见度以及它们所处的演化阶段（无论是实验性的，还是相当成熟但对业务定制/特定的，还是商品）。这将开启关于这些能力对业务的差异化程度以及是否需要进行任何投资转变的对话。沃德利地图帮助团队审查其产品组合，并识别出即使随着时间的推移，更低成本的“购买”选项变得更具吸引力，但仍然在内部开发和维护的能力。

我们喜欢的另一个工具是用于语言和第三方工具和平台的技术雷达。

技术雷达本身是 Thoughtworks 的行业出版物，但该模型已被多个组织（如Zalando）用于传达语言和工具的综合景观。通过向组织内的工程师传达安全的语言/工具选择、不推荐使用的工具以及处于不同实验阶段的技术，它引导工程师沿着期望的路径前进，避免碎片化，进而帮助降低成本。有多种方法可以开始使用自定义技术雷达，例如通过构建自己的雷达工具包或Backstage 技术雷达插件。

在考虑对技术组合或任何重大架构变更进行更改时，重要的是与您的财务合作伙伴进行财务分析，以评估潜在的投资回报率 (ROI)。财务分析中的主要考虑因素是实施变更的劳动力成本、如果被替换的工具本身的成本、由于新方法而产生的潜在效率收益或损失以及维持现状的成本。此分析必须涵盖组织的劳动力和影响范围，因为不仅仅是实施变更的团队可能会受到影响。

我们的一位客户考虑迁移到新的可观察性工具，因为当前工具的成本可变性令人担忧，并且该工具难以管理。经过仔细考虑，包括来自新供应商的报价、预期人工成本的估计以及他们选择的时间范围内成本降低的分析，客户决定保留当前工具，因为 ROI 为负。

优化费率

云和 SaaS 服务提供商会奖励客户的承诺（例如，预留实例或节省计划购买）和规模。但是，如果实际使用量与估计不符，批量购买计划可能会成为负债。长期承诺代表着更大的风险，因为公司的系统、用户和市场机会的演变和变化速度快于其合同条款。我们的一位客户与 AWS 签署了为期三年的承诺（计算节省计划），但一年后决定停用其系统的一部分，导致承诺的计划未得到充分利用。

反之亦然：如果公司总是承诺不足，它总是为资源支付更高的价格。这需要与业务进行仔细的平衡和持续的对话，以了解他们如何管理这种风险。

大多数 SaaS 产品会为公司分配一名客户经理，他们应该能够告诉他们有哪些合同结构可供他们选择以获得最佳价格。要求折扣永远不会有坏处。一些 SaaS 提供商会以无形利益作为回报提供折扣，例如成为可参考的客户或提供其产品测试版的反馈。我们建议定期与客户经理会面，因为他们会跟踪公司的使用情况，并在有更好的选择时通知他们。

将组织（或部门）的费率优化责任集中起来，比将责任分散到多个团队中更能实现高效的采购策略。组织的规模可能证明投资 FinOps 团队是合理的，以管理最能实现公司范围内规模经济的定价模型。