坦率地说：对于许多组织来说，FinOps没有合理的投资回报率（ROI），也没有建立 FinOps团队的商业理由。

这并不意味着组织不应该管理他们的云财务。这只是意味着他们不需要以一种与他们在本地数据中心历史上管理 IT 支出方式不同的方式来管理他们的云财务。我在此口语化地使用 “FinOps” 一词，表示组织采用一种不同于他们已经建立的本地 IT财务管理方式的云财务管理方法和流程。

有许多常见的原因，你的组织可能不需要 FinOps。例如：

你的开发人员、应用管理工程师、数据科学家和其他技术终端用户没有直接的自助访问云服务。相反，所有云设计和供应都由一个中央基础架构和运营（I&O）团队完成，或者，所有云请求都通过服务目录进行手动审核和批准。因此，在中央 I&O的知识或控制之外，云上不会发生任何事情 —— 这可能允许你像在本地一样管理预算。

你的应用程序被分配了静态的基础架构，或者它们的使用几乎完全可预测（例如，它们在月底的最后一周自动扩展，然后在月底关闭后自动缩小）。因此，每个应用程序的云账单每个月基本相同。你仍然应该配置预算警报，以防发生什么奇怪的事情导致使用量飙升，但这可能只是在应用程序首次部署时进行一次性操作，可能需要每年进行一次审查。

如果你在云上的花费不多，即使你可以通过淘汰不再使用的所有云开发 / 测试虚拟机来实现显著的支出降低（例如，可以直接关闭它们），也不会有太多的硬性节省。自动设置使未使用的基础架构自动休眠或取消设置可能会有有用的投资回报率（ROI），但是，如果采用手动操作方式（涉及许多人员，包括文书工作或实际操作基础设施），几乎肯定会浪费更多的劳动时间，而不是节省云成本。

企业通常没有数字原生公司中普遍存在的贪婪的扩展云本地应用程序，或者他们只有一小部分这些应用程序。你在云上花费了大量的资金，但这些资金分散在几十个、几百个甚至几千个小型应用程序中。因此，即使你可以将给定应用程序所需的容量减半，也不会产生很多的月度成本节省 —— 很可能不足以证明做这项工作的人所花费的时间。

许多企业在一个或两个 VM 上运行乏味的日常 “文书工作” 应用程序（或者现在是一个或两个容器）。单个 VM 应用程序通常最多运行 40% 的利用率，因为云 VM 大小采用 2 的幂次方，所以减小一个 “T-shirt” 大小会导致容量减半，可能会达到 90% 的利用率，许多企业感到不舒服。许多组织在整个企业中都略微超标，因为他们从他们的云迁移工具中采取了 “安全” 的容量需求估计。

购买 FinOps 工具并分配人员进行 FinOps 实践可能会导致成本更高。

大多数人通过购买某种云成本优化工具（即 “FinOps 工具”）来启动 FinOps 实践。复杂的 FinOps 流程和（或）需要在云成本治理框架中纠集许多团队和应用程序，可能会导致真正需要购买第三方 FinOps 工具的情况 —— 但这些工具可能在你每年支出至少一百万美元后才能获得正面的投资回报率。此外，你必须记住，这些工具的云支出百分比定价方案可能意味着你为它们无法优化的服务元素支付了一大笔钱。

但在许多情况下，工具的成本将被员工开销所淹没，尤其是那些试图雇用一个 “FinOps 团队” 的组织。FinOps 不仅代表财务和采购开销，还代表云操作和工程开销 —— 而且，最重要的是，开发人员开销（以及要求进行云优化工作的任何其他技术团队的开销）。如果进一步雇用了一个执行性能工程的团队，那些人非常稀缺且昂贵。

换句话说，在云上有些超标或应用程序代码有些低效是一种隐蔽的技术债务形式，但这是一种倾向于持续存在的技术债务，因为当你审视实际去追求那些技术债务的商业案例时，无法证明其具有足够的投资回报率。

事实上，在本地，人们历来不太关心这个问题。他们用硬件来解决问题，并且运行都大量超标。没人考虑这个问题，因为有资本预算来购买设备，一旦购买了设备，就没有多少理由思考这些钱是否被有效地使用。

此外，你的企业是否真的希望你那些高薪的应用程序开发团队去追踪他们代码中的性能问题，或者他们想增加新功能以向企业提供新功能、在业务流程的其他地方节省资金或提供吸引顾客的东西，从而增加你的收入？

我认为，几乎所有组织都需要进行一些云财务管理，他们可能会通过工具来支持。他们必须做到云成本健康的基本要求（以防止明显的浪费），预算警报（以快速了解意外情况），支出分配（showback/chargeback）和与折扣相关的规划（为提交、预留实例、储蓄计划等做好必要准备）。但即便如此，努力也需要与潜在成本节省成比例。

但是，全套的 FinOps 通常更适用于那些云工程师或开发人员的努力可以对成本产生重大影响的大型资金消耗应用程序，或者对于没有成本要求的大量自助服务的组织，或者对于支出庞大的组织，即使在像基本支出这样的事情上稍微做一点改进，也会节约很多费用。