FinOps如何管理共享云成本

简介: 本页面介绍共享云成本管理,涵盖其重要性、分配方法及各方职责。通过公平、透明的成本分摊,提升财务责任与预算准确性,推动组织优化云支出。

Managing Shared Cloud Costs(共享云成本管理)

本页面包含以下内容:

  • 引言
  • 共享成本分配的好处
  • 谁会关注共享成本
  • 推荐方法
  • 成功指标
  • 致谢

引言

FinOps 的一项基本原则是:“每个人都要对自己的云使用负责”。云成本透明度对于理解和明确云成本责任至关重要。未分配的共享成本会威胁到这一点。如果不能合理拆分共享成本,工程师、产品经理及其他相关人员将无法全面了解其产品的实际总成本。

共享成本(适用于云计算场景)指的是由多个所有者、应用程序或产品共同使用或归属的费用。

共享成本分配的好处

几乎每个组织都会产生需要在多个团队间拆分和分配的云费用。随着组织对公有云资源的采用度不断提高,将共享成本分配给具体业务所有者以准确掌握成本归属的难度也日益增加。一项共享资源可能仅在某个业务部门内部共享,而非跨其他分配层级共享。

尽管如此,共享云资源仍能带来更高的可扩展性和灵活性 —— 资源可根据用户需求动态分配和配置,且用户只需为实际使用的资源付费。通过以企业整体规模采购云基础设施和基于承诺的折扣(commitment based discounts),组织可借助采购实践、私有费率卡(private rate cards)及其他折扣方式降低单位成本。然而,要实现价值最大化并确保优化效果,必须将这些成本分配回产生资源消耗的业务领域。

因此,组织必须有效标记共享成本,避免大量成本处于未标记或未分配状态。如果共享成本分配不当且缺乏相应的成本管理责任机制,共享云成本可能会失控增长。最终,组织将从共享云基础设施中获得成本节约效益,因此应鼓励对共享云资源进行成本分配,以优化云支出。

准确分配共享成本能为组织带来诸多优势。通过将成本分配尽可能贴近实际支出,许多 FinOps 能力将得到强化和完善。这种方式可带来以下显著益处:

  • 公平性(Fairness) :合理标记共享成本可确保费用分配更加公平。若成本分配不准确,部分团队或业务部门可能需要承担超出或低于其实际使用量的成本。这一点在基础设施团队需承担其他团队 / 业务部门产生的成本时,或在核算单个客户 / 产品成本时尤为关键。
  • 责任归属(Ownership) :缺乏共享成本责任机制会降低团队降低成本和监控支出的积极性。通过准确分配共享成本,组织可以培养符合 FinOps 原则的责任文化。
  • 预测与预算编制(Forecasting and Budgeting) :未分配的共享成本会给不同团队和业务部门的预测、预算编制及财务规划带来困难。合理分配共享成本能确保使用情况在财务计划中得到充分反映,从而支持更明智的决策制定。此外,由于支出信息更具可追溯性,还能预防或减少云成本异常的影响。

共享成本分配正成为许多组织日益复杂且关注的问题。尽管过程复杂,但将共享成本在整个业务中进行分配的一个优势是,能更深入地了解底层单位成本(unit cost),推动决策更贴近产品层面。通过将共享成本分配回产生支出的业务领域,可实现成本透明度。

谁会关注共享成本分配?

FinOps 从业者(FinOps practitioners)、财务人员(finance)、产品 / 业务人员(product/business)、工程与运营团队(engineering & operations)及高管(executives)均与共享成本分配息息相关。以下角色矩阵示例列出了与共享云成本相关的常见职责,以及各角色在其中的负责(Responsible)、问责(Accountable)、咨询(Consulted)和知情(Informed)关系:

  • R(Responsible):负责执行任务以完成工作的角色
  • A(Accountable):对工作完成情况承担最终责任的角色
  • C(Consulted):参与决策过程的角色
  • I(Informed):需被告知相关详情的角色
事项 FinOps 从业者 财务人员 业务 / 产品负责人 工程与运营团队 高管
制定并完善共享成本分配的适当方法 R C C C A
生成共享成本分配的告知报表(showback) R I I I A
生成并实施共享成本分配的收费报表(chargeback) C R I I A
将共享成本分配结果纳入预测和预算更新 C R/A C I I
了解产品路线图对共享成本的影响 C R A C I
了解共享服务对产品 / 服务的影响 C I A R -
审核业务及汇总产品的损益表(P&L) I C R I A
协调 / 透明度:支持共享成本所有者的成本管理目标,并向他人说明共享成本分配的方式及原因 R/A I I I -
就共享产品和服务做出决策(如重复应用程序等) C C C R/A C*

*:是否需要高管参与取决于成本规模

推荐方法

共享成本分配流程的实施可拆分为多个逻辑步骤,便于理解。这些步骤可针对全部共享成本统一执行,也可根据不同成本的复杂性或一致性单独实施。尽管以步骤形式呈现,但由于最后一步强调了流程回顾与更新的重要性,因此也可将其视为一个循环过程 —— 持续优化分配流程是确保其有效性的关键。

1. 识别共享成本

共享成本的定义因公司而异,也取决于公司的成熟度和规模。不过,有一类标准成本通常会出现在每家公司的损益表中,公司需自行决定是否将其归为共享成本。不同公司的共享成本分配方式可能不同:部分共享成本适用于整个公司,而另一些则可能分配给使用该资源的团队、应用程序或产品。

跟踪是掌握共享成本分配进度的关键。除了跟踪成本分配情况,还应制定关键绩效指标(KPIs),以衡量共享成本的准确分配比例。例如,可通过 “共享成本与专用成本的标记覆盖率百分比” 这一 KPI 来评估本步骤的执行效果。

云服务提供商(CSP)的支持费用(Support charges)是许多组织都会产生的典型共享成本。支持费用通常在主账户层面产生,要么由集中式 IT / 云团队的预算支付,要么通过收费机制(chargeback mechanisms)按照成本分配策略分配给所有团队。

随着共享平台的兴起,现代架构也带来了更多共享成本。这些平台允许多个团队使用相同的核心资源,例如基于共享 S3 存储桶构建的数据湖(data lakes),或运行在共享集群上的 Kubernetes 系统。乍看之下,这些平台的收费(chargeback)和告知(showback)似乎难以实现,但通过合理标记和利用运营数据,可实现共享成本的公平拆分。

常见共享成本类型

共享成本示例 描述 详情及示例
第三方 SAAS 及市场服务(Third Party SAAS and Marketplace Services) 这类服务通常被归为共享成本,无论其通过云服务提供商(CSP)市场支付还是单独开具发票。 云提供商提供的监控与日志工具(Monitoring and Logging tools)、数据仓库(Data Warehouses)、安全工具(Security Tools)等。
基于托管服务的云基础设施(Cloud Infrastructure via Managed Services) 指云环境中由多个业务部门或应用程序共同使用的资源和服务,且属于托管服务(如 AWS RDS、DynamoDB、Azure Cosmos DB、Azure Analysis Services、Google Cloud SQL 等)。这类资源可能支持标记,也可能不支持。支持标记的示例:托管 Kubernetes 可在集群层面标记,但可能包含代表不同应用程序的命名空间或服务;托管数据库可能被多个业务部门使用;存储(Storage)、消息队列(Message Queues)或数据湖(Data Lakes)也属于此类。不支持标记的示例:云服务提供商(CSP)支持服务、CSP 安全服务、CSP 监控与日志服务、部分网络成本(network costs)。 -
自定义内置内部服务(Custom Built, Internal Services) 由组织内部的基础设施或平台团队构建、供其他团队使用的自定义服务。由于这类服务属于共享资源,其成本通常需要在受益部门间分配。 数据工程团队构建的数据湖(Data Lake),供多个业务部门用于数据分析、机器学习和商业智能任务;微服务(microservices),如用户管理或支付处理服务 —— 由内部团队开发一次后,可跨多个应用程序或项目使用。
基于承诺的折扣(Commitment Based Discounts) 与基于承诺的折扣相关的费用可能不会直接计入使用该折扣的账户或资源。部分组织可能希望根据使用情况重新分配这些费用,或将折扣在所有组织成员间平均分配(而非仅分配给享受折扣的对象)。 预留实例(Reserved Instances)、节省计划(Savings Plan)等;适用于 Windows 服务器的 Azure Hybrid Benefit。

2. 选择共享成本拆分策略

共享成本拆分主要有三种常见方法:

  • 平均拆分(Even split) :将总成本在目标对象间平均分配。
  • 固定比例拆分(Fixed Proportional) :基于成本、使用量或其他不常更新的指标所占比例进行分配。
  • 可变比例拆分(Variable Proportional) :基于成本、使用量或其他常用于支出拆分的指标所占比例进行分配,比例会动态调整。

固定比例和可变比例拆分方法需要借助某种指标来确定各团队的支出分配比例。尽管这两种方法相比平均拆分法需要更多工作量,但能更准确地反映共享资源的实际使用情况,且比例会随时间动态调整。

可用于确定比例拆分的指标示例包括:其他相关云资源的成本 / 消耗量、收入 / 销售额、支持工单数量、主机数量或虚拟 CPU 小时数(vCPU hours)等。

注:部分组织可能会选择结合使用多种方法或其变体。

以下以企业支持费用(Enterprise Support costs)为例进行说明:某月多个业务部门产生的云服务提供商(CSP)费用如下表所示,同时产生了 12,000 美元的企业支持费用。

业务部门 成本 占总费用比例(不含企业支持费用)
销售部(Sales) 50,000 美元 50%
产品部(Product) 30,000 美元 30%
工程部(Engineering) 20,000 美元 20%
企业支持费用 12,000 美元 -
总计 112,000 美元 100%

若不分配企业支持费用,各部门需支付的费用如下:

  • 销售部:50,000 美元
  • 产品部:30,000 美元
  • 工程部:20,000 美元

12,000 美元的企业支持费用尚未分配,需确定支付方式。

(1)平均拆分(Even Split)

在平均拆分策略下,12,000 美元的企业支持费用由所有业务部门平均承担。这种方法操作简便,在小型组织中较为常用,但在大型组织中可能被认为不公平或不合适。

业务部门 原始成本 共享成本分配比例 12,000 美元支持费用分摊 总成本
销售部 50,000 美元 33.3% 4,000 美元 54,000 美元
产品部 30,000 美元 33.3% 4,000 美元 34,000 美元
工程部 20,000 美元 33.3% 4,000 美元 24,000 美元
总计 100,000 美元 100.0% 12,000 美元 112,000 美元

平均拆分策略简化了共享成本分配流程,但会对不同业务部门的预算产生不同影响。在上述示例中,与比例拆分策略相比,工程部需多承担 13% 的共享成本:

  • 销售部:54,000 美元(50,000 美元直接成本 + 4,000 美元支持费用分摊)
  • 产品部:34,000 美元(30,000 美元直接成本 + 4,000 美元支持费用分摊)
  • 工程部:24,000 美元(20,000 美元直接成本 + 4,000 美元支持费用分摊)

企业支持费用已全部分配,无需额外确定支付方式。

(2)固定比例拆分(Fixed Proportion)

固定比例拆分策略基于固定百分比按月分配共享成本。通常,这些比例是通过分析历史支出(或收入)确定的公平分配方案。以下仍以 12,000 美元的企业支持费用为例,采用指定比例进行分配:

业务部门 原始成本 共享成本分配比例(系数) 12,000 美元支持费用分摊 总成本
销售部 50,000 美元 50% 6,000 美元 56,000 美元
产品部 30,000 美元 30% 3,600 美元 33,600 美元
工程部 20,000 美元 20% 2,400 美元 22,400 美元
总计 100,000 美元 100% 12,000 美元 112,000 美元

固定比例拆分策略相比平均拆分法更公平,且计算简便。该方法依赖历史数据分析确定分配系数,但组织需内部协商确定系数的更新频率。

各部门最终支付费用:

  • 销售部:56,000 美元(50,000 美元直接成本 + 6,000 美元支持费用分摊)
  • 产品部:33,600 美元(30,000 美元直接成本 + 3,600 美元支持费用分摊)
  • 工程部:22,400 美元(20,000 美元直接成本 + 2,400 美元支持费用分摊)

企业支持费用已全部分配,无需额外确定支付方式。

(3)可变比例拆分(Variable Proportional)

可变比例拆分法根据各业务部门的原始支出占比分配企业支持费用(12,000 美元),且比例会随每月云成本的变化而调整。成熟组织通常会按月根据各业务部门的直接费用比例分配共享成本。

业务部门 原始成本 共享成本分配比例(系数)—— 支持工单数量 12,000 美元支持费用分摊 总成本
销售部 50,000 美元 40 = 40% 4,800 美元 54,800 美元
产品部 30,000 美元 30 = 30% 3,600 美元 33,600 美元
工程部 20,000 美元 30 = 30% 3,600 美元 23,600 美元
总计 100,000 美元 100 = 100% 12,000 美元 112,000 美元

各部门最终支付费用:

  • 销售部:54,800 美元(50,000 美元直接成本 + 4,800 美元支持费用分摊)
  • 产品部:33,600 美元(30,000 美元直接成本 + 3,600 美元支持费用分摊)
  • 工程部:23,600 美元(20,000 美元直接成本 + 3,600 美元支持费用分摊)

企业支持费用已全部分配,无需额外确定支付方式。

确定共享成本分配方法后,FinOps 从业者需与所有业务预算所有者和相关方沟通,确保其理解变更内容及必要性。

3. 应对复杂共享成本分配:网络成本案例研究

前文通过固定比例和可变比例等策略演示了企业支持费用的分配,解决了共享成本分配的关键问题并提供了简单示例。但对于更成熟的组织,可能需要更复杂的分配方法。

为说明这一演进过程,以下将以网络成本(network costs)为例进行深入分析 —— 该示例虽非详尽无遗,但可直观展示共享成本分配策略如何随业务运营复杂度的提升而优化。

起步阶段(Crawl):基于总成本的比例分配

在 “起步阶段”,企业通常会根据易于衡量的指标(如各业务部门的总成本)分配网络成本。这种方法操作简便,但无法反映网络使用的具体模式。

业务部门 原始成本 共享成本分配比例(系数) 20,000 美元网络成本分摊 总成本
销售部 50,000 美元 50% 10,000 美元 60,000 美元
产品部 30,000 美元 30% 6,000 美元 36,000 美元
工程部 20,000 美元 20% 4,000 美元 24,000 美元
总计 100,000 美元 100% 20,000 美元 120,000 美元

发展阶段(Walk):基于数据量的比例分配

随着企业成熟度提升进入 “发展阶段”,可能会将数据量纳入网络成本分配考量,更贴近实际网络使用成本。

业务部门 原始成本 共享成本分配比例(系数)—— 数据传输量 20,000 美元网络成本分摊 总成本
销售部 50,000 美元 500GB = 25% 5,000 美元 55,000 美元
产品部 30,000 美元 800GB = 40% 8,000 美元 38,000 美元
工程部 20,000 美元 700GB = 35% 7,000 美元 27,000 美元
总计 100,000 美元 2TB = 100% 20,000 美元 120,000 美元

成熟阶段(Run):基于网络成本类型的比例分配

最终进入 “成熟阶段” 后,企业可能会利用先进的网络监控工具,根据具体网络成本类型(如跨区域 / 跨可用区数据传输、公网 IP 地址使用等)进行分配。这种方法能实现最准确的网络成本分摊。

网络成本分配的演进过程帮助组织确保各业务部门公平承担其网络使用成本。随着分配方法的日益复杂,其也更能反映各部门对网络的具体使用和受益情况。这种更公平、准确的成本分配方式有助于优化资源使用、鼓励成本节约行为,并提升整个组织的财务透明度。

4. 应用共享成本分配方法

根据上一步确定的策略,执行必要的收费(chargeback)或告知(showback)流程,完成共享成本拆分。

与财务和会计团队协作,制定共享成本拆分的时间节点、责任主体,以及将相关信息纳入预测和预算的流程。

不存在适用于所有组织的 “完美” 共享成本分配方法,但建议尽可能遵循 KISS 原则(Keep It Simple Stupid,即保持简洁)。公司需根据自身预算核算方法、组织目标和资源情况,选择最适合的方案。通常,成熟度较高的组织会采用可变比例拆分法。

仅将云资源标记为 “共享” 并不意味着已通过适当方法明确、准确地分配了这些成本。因此,建议制定 KPI 以跟踪所有共享资源的共享成本分配比例,从而掌握分配的完整性和成熟度。

注意事项:结合多种共享成本策略和拆分方法可能会导致流程迅速复杂化。例如,支持费用可能更适合采用比例分配法,而共享资源或开发 / 测试环境的成本则可能适合采用平均拆分或固定比例拆分法。

5. 共享成本报告

成功分配共享成本是重要一步,但向相关方展示分配金额、说明分配方法及背后的逻辑,能进一步发挥共享成本分配的价值。有效的共享成本报告应包含以下内容:

  • 成本趋势分析(总体趋势及按所有者、产品等维度的趋势),以显示成本增长或下降情况;
  • 共享成本实际值与预算值、预测值的对比;
  • 支出驱动因素识别(如产生支出的服务或团队)。

报告流程的关键在于,让影响成本的团队能够理解并利用报告数据,从而有效开展成本管理工作。报告必须准确、及时,并清晰展示共享成本的分配情况。

据 FinOps 基金会社区成员反馈,仅通过向相关方提供成本报告,就能发现当前企业会计政策中可能被忽视的费用。跟踪共享成本相对于专用成本的增长情况是一项有用的 KPI,但需先建立基准评估才能准确使用。

准确核算的一个挑战是 “何时停止划分共享成本”。将某项成本归为共享成本容易,但久而久之需要拆分的共享成本范围可能会变得过大。因此,应定期回顾共享成本,确保标记为 “共享” 的资源仍具有相关性且确有必要。由于没有任何业务部门直接承担这些成本,可能会导致资源长期闲置(因无人感受到成本影响)。

6. 维持分配方法的可持续性

完成上述步骤后,组织已成功制定并应用了共享成本分配方法,并开始进行数据报告 —— 这意味着大部分繁重工作已完成。但此时不应松懈,流程的可持续性是共享成本分配的关键。必须保持警惕,建立相应流程以维持成熟度,并及时发现可能退化的领域。在构建长期可持续的共享成本分配方法时,可考虑以下问题:

  • 若公司已采用标记标准进行成本分配,如何确保标记的准确性?
  • 如何处理因缺乏适当标记、异常情况等导致的未分配共享成本?
  • 当引入新的成本中心或业务部门时,回顾流程是什么?
  • 若采用固定比例分配法,比例的回顾频率是多少?
  • 数据建模方法是否具有可持续性?
  • 流程文档的完善程度如何?
  • 有多少人了解已实施的系统?
  • 是否存在足够的知识共享,避免关键知识集中在少数人手中?

成功指标

共享成本分配方法是一个迭代演进的过程。其目标是让团队、应用程序、服务或产品能够全面了解自身的实际运行成本。随着方法的成熟,人们对分配准确性的信心应不断增强,成本中心或团队也应具备更强的优化或影响这些共享成本的能力。

判断方法是否有效的最佳方式,是评估其与组织整体成本管理方法的契合度。共享成本分配方法是否有助于推动创新和理解?这是一个重要的考量因素。尽管共享成本分配本身是一种文化变革,但它应帮助所有人更好地决策支出及背后的原因。

我们制定了适用于共享成本管理 “起步(Crawl)、发展(Walk)、成熟(Run)” 三个阶段的里程碑,可为组织提供参考。该模型并非强制性要求 —— 许多公司可能先实施发展阶段的策略,再推进起步阶段的工作,反之亦然。成本管理具有复杂性,不同成本对公司基础设施的影响也各不相同。

以下表格具有迭代性:

步骤 起步阶段(Crawl) 发展阶段(Walk) 成熟阶段(Run)
重点与回顾 从企业协议(EA)、历史发票 / 账单中识别共享成本的一般类型 基于实际运行成本,聚焦高共享成本的关键详细领域 基于运行成本、承诺使用节省(committed use savings),进行全企业范围的共享成本循环回顾(采用告知制 showback)
选择共享成本分配方法 应用共享成本模型 —— 通常为平均拆分或固定比例拆分 固定比例拆分或可变比例拆分 基于可变比例、使用量 / 指标的拆分,或多种共享成本分配方法的组合
确定需要拆分的成本领域 企业支持费用、发票、订阅费用 按应用程序、项目或基础设施拆分共享资源支出,实现成本分配告知(showback) 利用指定方法(可变比例或使用量衡量)跟踪共享成本的工具或流程;目标可能包括实时趋势分析、预测和异常检测
共享成本报告 提供满足团队 / 相关方云成本管理基本需求的共享成本分配可见性报告 增加更及时、准确的细节,展示特定业务部门或其他所有者的共享成本分配情况 向财务部门提供准确跟踪数据,以便及时响应共享成本分配的变化;实现资源优化利用和效率提升
可持续性 记录并规划共享成本分配的成熟状态;识别 KPI 缺口 记录并维护标记的有效性;建立与相关方定期回顾共享成本分配效果的流程;部署并利用 KPI 确保标记准确性;持续使用 KPI 并强制执行,以保障成本分配效果

Janine Pickard Green、Amanda Dalton、Alex Dominic Savio、Amit Doshi

最后,感谢 FinOps 基金会的内部团队:Rob Martin(项目赞助人)、Samantha White(项目管理)、Tom Sharpe(设计)、Andrew Nhem(内容创作)。

原文地址:https://www.finops.org/wg/identifying-shared-costs/

相关文章
|
8天前
|
数据采集 人工智能 安全
|
4天前
|
机器学习/深度学习 人工智能 前端开发
构建AI智能体:七十、小树成林,聚沙成塔:随机森林与大模型的协同进化
随机森林是一种基于决策树的集成学习算法,通过构建多棵决策树并结合它们的预测结果来提高准确性和稳定性。其核心思想包括两个随机性:Bootstrap采样(每棵树使用不同的训练子集)和特征随机选择(每棵树分裂时只考虑部分特征)。这种方法能有效处理大规模高维数据,避免过拟合,并评估特征重要性。随机森林的超参数如树的数量、最大深度等可通过网格搜索优化。该算法兼具强大预测能力和工程化优势,是机器学习中的常用基础模型。
298 164
|
3天前
|
机器学习/深度学习 自然语言处理 机器人
阿里云百炼大模型赋能|打造企业级电话智能体与智能呼叫中心完整方案
畅信达基于阿里云百炼大模型推出MVB2000V5智能呼叫中心方案,融合LLM与MRCP+WebSocket技术,实现语音识别率超95%、低延迟交互。通过电话智能体与座席助手协同,自动化处理80%咨询,降本增效显著,适配金融、电商、医疗等多行业场景。
311 155
|
11天前
|
SQL 自然语言处理 调度
Agent Skills 的一次工程实践
**本文采用 Agent Skills 实现整体智能体**,开发框架采用 AgentScope,模型使用 **qwen3-max**。Agent Skills 是 Anthropic 新推出的一种有别于mcp server的一种开发方式,用于为 AI **引入可共享的专业技能**。经验封装到**可发现、可复用的能力单元**中,每个技能以文件夹形式存在,包含特定任务的指导性说明(SKILL.md 文件)、脚本代码和资源等 。大模型可以根据需要动态加载这些技能,从而扩展自身的功能。目前不少国内外的一些框架也开始支持此种的开发方式,详细介绍如下。
857 6
|
5天前
|
机器学习/深度学习 人工智能 前端开发
构建AI智能体:六十九、Bootstrap采样在大模型评估中的应用:从置信区间到模型稳定性
Bootstrap采样是一种通过有放回重抽样来评估模型性能的统计方法。它通过从原始数据集中随机抽取样本形成多个Bootstrap数据集,计算统计量(如均值、标准差)的分布,适用于小样本和非参数场景。该方法能估计标准误、构建置信区间,并量化模型不确定性,但对计算资源要求较高。Bootstrap特别适合评估大模型的泛化能力和稳定性,在集成学习、假设检验等领域也有广泛应用。与传统方法相比,Bootstrap不依赖分布假设,在非正态数据中表现更稳健。
250 113