摘要
分配是一项核心流程,通过层级结构、标签和标记将技术成本准确分配给特定所有者、部门或项目,以实现成本展示(showback)和成本回收(chargeback)。对于FinOps从业者而言,协作制定并实施元数据策略至关重要,其中包括“成本中心”(Cost Center)和“环境”(Environment)等必填标签,并在整个组织内强制执行——需注意标签无法追溯应用。从业者还应关注衡量分配实践成熟度的关键指标,例如提高标签合规成本的占比,以及缩短成本发生到向终端团队展示的时间差。
目录
- 摘要
- 定义
- 优势
- 策略
- 谁负责成本分配?
- 与其他FinOps框架能力的交叉点
- 指标
- 结论
- 致谢
- 附录
摘要
随着资源的持续创建和销毁,云计算会生成海量账单数据。所有这些账单数据必须在组织的多个财务和运营维度中进行准确核算。
本文旨在通过深入解析成本分配策略及相关利益相关者,拓展FinOps成本分配能力的内涵。
定义
详细的云账单和使用数据汇总后,会产生数千至数百万条记录,这使得将成本合理分配给组织内相关责任部门变得极具挑战性。成本分配是指通过云服务提供商(CSPs)或第三方工具平台提供的结构化层级、标签和标记,识别、分类并将云计算资源成本分配给组织内特定用户、部门、项目或其他相关分组的过程。
FinOps从业者实施成本分配策略的主要目的通常是实现成本回收和/或成本展示。然而,用于成本分配的结构化层级、标签和标记也可用于其他组织和报告用途。设计合理且执行到位的成本分配策略将带来更详细、准确的成本回收、成本展示和报告功能。
在继续阅读前,需说明本文中“标签(tag)”一词的使用范围:标签是由键值对组成的关键字或术语,分配给资源或层级结构,用于描述元数据。通常,标签被赋予资源以明确所有权、描述资源属性,并最终为财务核算目的分配成本。并非所有云服务提供商(CSPs)都使用“标签(tag)”这一术语描述该功能,但为统一表述,本文将“标签(tag)”作为所有云服务提供商同类功能的通用指代。
优势
成本分配的实施方式将直接影响组织所能获得的收益。以下是实施云成本分配可带来的部分直接优势:
- 财务透明度:通过明确哪些成本与特定项目、部门、环境等相关联,成本分配有助于提升云使用成本的透明度。
- 问责制:通过将成本清晰归因于责任所有者,成本分配可增强问责性。
- 成本回收/展示:成本分配使组织能够实施成本回收模式,即向部门或项目收取/展示其消耗的特定云资源费用,从而提升成本意识和财务责任感。
- 成本优化:通过跟踪并将成本分配给特定用户、部门或项目,组织能够识别可优化支出的领域。
成本分配还能为其他FinOps框架能力带来显著的下游收益,详见“与其他框架的交叉点”部分。
策略
由于详细账单数据包含海量记录,且组织可能需要通过多种维度划分成本,因此拆分云服务提供商的发票或账单颇具挑战性。缺乏明确策略的成本分配难以实现预期目标。
一旦层级结构和标签/标记的实施方法得到明确界定、妥善执行和维护,组织就能充分发挥成本分配的价值。成本分配策略和实施路径多种多样,主要包括以下两类:
层级结构
云服务提供商提供了将资源组织为层级结构的方式。这些层级结构允许终端用户以有意义的方式命名和组织资源,以便理解资源内容及相关账单数据。下图对比了AWS、Azure和GCP的层级结构:

尽管这些层级结构看似不同,但部分元素具有直接可比性:
- AWS:通过“组织(Organizations)”构建结构化层级,提供账户目录。标签可应用于目录的不同层级,该层级及下属层级的账户和资源将继承所属层级及其父层级的标签。
- Azure:允许用户创建“资源组(Resource Groups)”来组织和标记资源。在资源组层级分配标签,对组内可标记和不可标记的资源均有益处。
- GCP:在资源层级中提供“文件夹(Folders)”用于组织项目。GCP标签可在组织层级创建,并由子资源继承;此外,GCP还提供“标记(Labels)”功能作为资源元数据收集的补充方式——与标签不同,标记仅应用于资源层级,且不会被子资源继承。
有关各云服务提供商的具体信息,详见附录中的“层级结构”部分。
标签与标记
所有云服务提供商均支持为大多数单个资源添加标签作为元数据;当用户启用相关功能后,标签将显示在包含成本和使用数据的详细账单报告中(详见附录中的“云服务提供商指南”)。
所有云服务提供商都配备了相应工具,允许用户管理标签、设置层级分组并适当应用元数据。账户、资源组、项目和文件夹的命名规范也有助于确定任何资源组的所有者。
标签策略与资源标签分类密切相关:策略定义了标签的标准化要求、必填标签类型及其价值(如增强问责制、支持成本展示/回收、完善指标体系、提升可见性、优化监控等)。
以下是成本分配中常用于成本回收或展示的标签分类示例:
| 标签 | 描述 | 示例值 |
|---|---|---|
| 业务标签 | ||
| 名称(Name) | 应用程序名称 | ABCapplication |
| 环境(Environment) | 定义资源所属环境 | production(生产环境) |
| 成本中心(Cost Center) | 标识资源关联的成本中心 | CC12345 |
| 业务所有者(Business Owner) | 标识资源的负责人 | Businessowner@myorg.com |
| 安全标签 | ||
| 合规性(Compliance) | 标识合规要求等级(如HIPAA、PCI、GDPR等) | HIPAA、PCI、GDPR |
| 加密状态(Encryption) | 标识资源是否加密 | 是/否(Yes/No) |
| 自动化标签 | ||
| 日期/时间(Date/Time) | 标识资源的启动、停止、轮换、终止等时间 | 2003年8月5日 下午3:05:15(08/05/2003 03:05:15 PM) |
| 选择加入(Opt In) | 标识资源是否应自动纳入自动化活动(如调整大小、删除等) | 是/否(Yes/No) |
上述示例主要用于成本分配和报告,组织还可根据资源管理、变更管理、调度/自动化、安全合规等其他需求设置更多实用标签。制定成本分配标签策略时,务必考虑所有利益相关者的需求。
标签的分配方式对组织和流程至关重要:通常,最好在资源和源数据附近直接分配标签(即直接在云服务提供商的生态系统中应用),确保标签随成本和使用数据同步流转至下游系统——但这一方式可能并非适用于所有组织。
需注意,部分云服务提供商的特定成本标签需手动启用,才能在工具或使用/账单数据中显示;若未启用,这些标签将不会出现在报告中。此外,标签无法追溯应用:
例如,若某资源在月底才被标记为“生产环境(Production)”,则该标签仅对后续报告生效;若生成过去30天的报告,该资源在报告期内除最后一天外均显示为“未标记”状态。
部分组织可能选择在配置管理数据库(CMDB)系统中为成本分配分配标签元数据,并将订阅、账户、资源组等与该元数据关联。
有效的成本分配需以元数据(描述数据的数据)策略为前提。该策略应包含标签/标记分类、标签描述及价值说明、标签示例值(如业务单元、损益组、成本中心、应用程序、服务、产品等),以及标签是否为合规、监管或其他要求下的必填项。
组织可根据需要添加其他标签,但需平衡标签数量(避免过少或过多)。成本分配数据和分析通常需要多层标签支持,因此强烈建议在资源标记前,由所有利益相关者共同定义并确认标签策略,以确保标签标准化,并从一开始就落实执行机制。
标签最终可为不同角色提供清晰的成本分配依据。制定成本分配策略需要多个角色的投入和理解——尤其是工程、财务和高管团队。深入了解各利益相关者的需求,是成本分配策略制定和实施成功的关键。例如:财务部门可能需要按成本中心汇总成本,而工程团队则受益于按服务、应用程序、资源类型或环境的更细粒度拆分,所有角色都能从单位经济效益数据中获得价值。
部分组织可能选择利用第三方成本分配系统,因为这些系统可能比云服务提供商的原生工具具备更丰富的功能和价值。
归根结底,组织的标签策略、实施方式和执行力度将决定其作为成本分配方法的有效性。若标签策略仅部分实施或执行不到位,将导致数据不完整、不准确,进而引发对成本数据的不信任。
有关各云服务提供商的具体分配指南,详见附录中的“分配”部分。
共享成本
云服务提供商提供的成本分配结构有助于组织将成本合理分配给相关责任部门——当特定应用程序、服务等的成本归属于单一所有者时,这一过程相对简单(此类成本称为“专属成本”,即产生成本的资源具有1:1的所有权比例)。然而,部分云费用无法分配给单个业务单元、应用程序或成本中心,而是由多个业务单元、应用程序或成本中心共同承担,这类成本被称为“共享成本”。
共享成本有时可通过标签等成本分配结构处理,有时则无法处理。在共享成本场景下,将成本合理分配给相关责任部门的难度更大。
有关共享成本的更多信息,详见《云共享成本分摊指南》(A Guide to Spreading Out Shared Cloud Costs, finops.org)。
合规与执行
定义并实施层级结构和标签策略是成本分配成功的关键,但维持策略的有效执行颇具挑战。与策略制定和实施阶段一样,策略维护也需要多方参与。云服务提供商为确保组织标签政策的合规性和执行力度提供了相关指南(详见附录中的“合规与执行”部分)。以下是与成本分配合规相关的关键绩效指标(KPI)指南:
在所有其他策略确定后,从业者必须明确如何确保标签合规性及策略执行。这需要深入了解云服务提供商提供的相关功能,识别并处理未标记资源。此外,构建强大的FinOps文化至关重要——技术手段的作用有限,而文化建设能带来更显著的成效。
建议遵循以下指导原则:
- 识别所有产生成本但未标记的可标记资源,明确这些资源持续未标记的影响;
- 识别所有不符合已定义分类和值的标签,明确这些不合规标签的影响;
- 向工程师宣传新资源和现有资源标记的重要性;
- 与工程师协作,为现有资源添加标签,填补当前缺口;
- 通过向所有角色展示标签合规性仪表板和报告,施加同伴压力,引发关注并推动改进;
- 探索通过云服务提供商的功能启用标签强制机制(例如,AWS可通过服务控制策略(SCPs)强制要求资源标记);
- 探索通过云服务提供商的功能识别不合规标签。
在执行上述操作时,最佳实践是优先审查和修订高成本资源的标签,平衡修正工作的投入与修正成本的价值。
谁负责成本分配?
简而言之,所有参与云资源使用或监控的人员都对成本分配负有责任。
财务部门
人们通常会认为财务部门负责成本分配——准确报告和跟踪收入及支出是财务职能的核心活动之一。财务部门最终负责将正确的支出分配到对应的成本中心/业务线,以实现准确的盈利能力衡量。若无法准确报告(并预测)产品线或业务线的盈利能力,组织将无法在定价决策、产品增强和功能投资时机及规模、甚至是否退出市场等一系列相关问题上做出合理判断。
因此,从RACI责任分配矩阵的角度来看,财务部门无疑是确保成本分配准确、及时执行的“责任方(Responsible)”。
工程部门
要实现企业层面的准确成本分配,财务部门并非唯一的责任方。财务部门需要利用层级结构、账户、成本中心等属性,或应用程序ID标签等元数据才能完成成本分配。
由于云服务的采购通常采用分散式方式,工程师和开发人员自主决策,因此他们处于确保成本准确归因的第一线,是成本分配准确性的关键角色。根据组织的基于角色的访问权限设置,他们可能还负责生成报告或运行报告并提交给财务部门。在简单场景中,若某服务已标记应用程序ID,财务部门至少可将相关成本分配给该应用程序所属的业务线。
需注意,发票或账单中不会直接体现这些细节——账单仅包含高层级汇总数据,这往往导致财务部门无法了解云资源的使用情况和成本流向。若缺乏额外信息,可能会引发对组织支出的不信任或误解。从RACI矩阵来看,工程/开发部门可被视为“问责方(Accountable)”和/或“咨询方(Consulted)”:
他们至少在应用正确元数据方面需要被咨询,甚至作为资源使用的发起者,直接了解资源部署方式,应承担主要问责责任。
业务/产品部门
业务/产品角色是成本分配的直接使用者和影响者。该角色的成本通常包括直接归属其产品或业务领域的成本,以及间接成本(即共享成本)(即使他们不是共享成本的所有者,也是接收者)。产品或产品领域通常因内部存在互操作性或关联性而整合,这使得产品负责人在提供正确元数据或分配分类法方面发挥关键作用,以确保成本以最有效的方式分配。
产品负责人还关心与其无直接关联的共享成本分配——他们需要了解成本分配的方法和驱动因素,以便为产品开发决策提供依据。由于业务/产品角色通常是成本分配流程产生的信息(报告、运营数据等)的接收者,从RACI矩阵来看,他们属于“知情方(Informed)”;
但由于他们通常是工程/开发部门与高管之间的桥梁,其在组织层级中的位置使他们上升为“问责方(Accountable)”——他们往往是最先发现问题或不准确之处的人,并且能够在必要时影响广泛资源的变更。
高管
高管角色不可或缺——如前所述,他们通常与业务/产品角色对齐,有一个或多个业务/产品团队向其汇报。他们最终负责签署其业务单元的成本分配结果,因此必须参与成本分配机制的制定,以确保充分理解并对结果负责。
成本分配策略的设计需要与业务、产品和工程/开发角色密切合作,了解应用程序“交易”的关键驱动因素及其对资源使用的潜在影响。若不借助辅助应用程序(即第三方云管理工具),可能无法实现预期规模或效果的稳健成本分配方法。
此类工具的选择及相关投资规模需由高管层决定。归根结底,高管对其监管的业务单元的盈利能力负责,因此需要深入了解支持业务的技术架构。
与其他FinOps框架能力的交叉点
异常管理
通过策略性标签实现的更高财务透明度和问责制,有助于更好地理解异常支出。当标签提供的详细信息与异常警报结合时,从业者能够更清晰地分析异常事件,并明确调查成本增长的方法、方向及相关参与人员。
预算编制与预测
预测和预算管理是FinOps框架中两个独立且复杂的能力。这些能力可为成本分配策略和流程提供支持(甚至指导),促进更细粒度、准确的决策。例如,用于成本回收的成本分配结构应与云支出预测和预算编制的结构保持一致——预测可能已按业务单元、应用程序或其他维度拆分成本,成本分配也需采用相同维度。
当然,若预测仅为高层级汇总,则无需强制对齐。同样,任何成本分配实施都应考虑当前和未来的预测能力及需求。
了解预测的制定方式和原因,有助于设计或调整成本分配模型,同时也能明确组织已有的数据资源。预测通常部分依赖历史支出数据,而成本分配模型的确定可能也需要相同数据。
成本分配的核心是将实际支出分配给相关责任单元,而预测则可能基于该模型进行前瞻性推演。尽管并非所有组织都需要使这两个流程完全同步,但它们都能从共享流程中受益。
其他优势
通过成本分配实现的财务透明度和成本优化,为证明云原生技术是降低成本、提高效率的最佳解决方案提供了依据,进而推动云原生技术的应用。
本地、数据中心、私有云与云成本分配的对比
当组织首次从本地基础设施服务迁移至云时,服务接收方可能会对成本分配策略产生疑问。
例如,云服务提供商的虚拟机按小时计费,而内部虚拟机可能按CPU和内存消耗计费。
为确保可比性,组织可能需要将现有基础设施服务与云服务进行对比——最简单的方法是采用相同的计量单位,以便轻松比较单位成本。此外,确保本地团队和云团队使用相同的术语和参考标准进行沟通和报告,对于成本对比至关重要。
计算单元(Compute Units)是机器的处理单元,主要包括内核(Cores)和内存(Memory)。通过基于计算单元进行成本分配,组织可以识别是否需要根据内核和内存的使用情况切换到不同类型的机器。
对于大多数归类为“计算优化型”的云服务,单位成本增长的主要驱动因素是内核数量;对于“内存优化型”云服务,单位成本的主要驱动因素仍是内核,但内存的权重更高。
这种成本分配方法可应用于所有依赖服务器托管的云服务,因此涵盖虚拟机、数据库和容器编排工具。
对于本地基础设施服务,计算单元成本计算中还需包含空间和许可费用——这意味着,对于内核和内存配置相同的机器,本地环境的成本可能略高于云环境。
需注意,在对比本地环境和云环境时,应明确成本构成——可能存在未纳入计算单元对比的其他云服务,为实现“同类对比(Apples-to-Apples)”,这些服务也应纳入考量。
通过采用相似的计算单元进行成本分配,组织能够推动那些能从云规模经济中受益的云服务的采用。云服务的接收方也能更轻松地衡量其业务单元迁移至云的投资回报率(ROI)。
示例:
| 类型 | 内核数 | 内存 | 空间 | 计算单元 | 成本 |
|---|---|---|---|---|---|
| 本地服务器 | 4 | 32GB | 1 | 9 | 1,520.00 |
| 本地虚拟服务器 | 4 | 32GB | 0.06 | 5 | 844.00 |
| 云虚拟机 | 4 | 32GB | 0.0042 | 2 | 336.00 |
| 总计 | - | - | - | 16 | 2,700.00 |
指标
与任何实施项目一样,成本分配策略的成效也可通过指标衡量。以下是云成本分配相关的标准KPI,可用于评估组织的成熟度并建立对报告数据的信任:
| 关键绩效指标(KPIs) | 0级 | 1级 | 2级 | 3级 | 4级 |
|---|---|---|---|---|---|
| 可标记/不可标记成本占比 | <30% | 31–79% | 80–85% | 86–90% | >90% |
| 已分配/未分配成本占比 | <30% | 31–79% | 80–85% | 86–90% | >90% |
| 标签合规成本占比 | <10% | 10–20% | 21–50% | 51–80% | >80% |
| 成本分配准确性(标签值修订次数或因标签值不当导致无法分配的支出占比) | 15次及以上问题或修订 | 7–15次问题或修订 | 4–7次问题或修订 | 1–3次问题或修订 | 0–1次问题或修订 |
| 成本分配透明度(收到的成本分配相关咨询次数) | 15次及以上 | 7–15次 | 4–7次 | 1–3次 | 0–1次 |
| 成本分配透明度(成本发生到向终端团队展示的时间差) | >30天 | 10–29天 | 5–9天 | 1–4天 | <1天 |
| 推动采用率(按团队、业务单元、创建者分配的成本占比) | <30% | 31–79% | 80–85% | 86–90% | >90% |
上述仅为部分成本分配指标——各组织可根据自身目标和成熟度制定适合的指标。
在成熟度模型中处于较高水平的组织,能够充分实现上述部分或全部优势(财务透明度、问责制、成本回收/展示能力及整体成本优化)。由成本意识和度量驱动的成熟度提升,应能带来更好的支出控制和跨团队问责制。将成本分配透明度等指标的成熟度从30天提升至数小时,需要整个组织投入时间、资源和工具支持。
结论
本文提供的指南,希望能为新的FinOps从业者或希望更新知识的资深从业者提供足够信息,帮助其理解成本分配的定义、优势、已知策略,以及其他FinOps角色在该能力的产出和流程中的责任。成本分配是FinOps框架的核心能力,我们的社区将继续在此基础上拓展,使任何公司、组织或企业的从业者都能着手构建持久、有价值的FinOps实践。
若您希望参与相关工作,可通过以下方式加入:
- 在我们的Slack频道讨论和咨询成本分配相关问题;
- 联系我们加入工作组(Working Group),在未来的迭代中帮助我们持续改进和完善相关内容。
致谢
FinOps基金会衷心感谢以下工作组成员为编写本文档并与社区共享知识所做的贡献:
- Larry Advey(CloudZero)
- Peter Brent
- Janine Pickard-Green(MagicOrange)
- Amanda Dalton(Deloitte)
感谢支持者和受访者
我们还要感谢技术咨询委员会(TAC)联络人、苹果公司的William Bryant,以及以下本文的支持者:
- Dmitry Gomel
- Mike Ebels
- David Leiyian Motongo
- Brian Robbins
最后,特别感谢FinOps基金会支持团队的辛勤付出,使本项目得以落地:
- Ashley Hromatko(员工赞助人)
- Samantha White(项目管理)
- Tom Sharpe(设计)
- Andrew Nhem(内容创作)
附录
各云服务提供商均提供了其环境中标签/标记的实施文档,链接如下:
通用资源
- 云标签策略指南(cio.gov)
AWS
- 简介——使用多个账户组织AWS环境(amazon.com)
- AWS组织的组织单元最佳实践 | AWS云运营与迁移博客(amazon.com)
- AWS账户结构考量——奠定基础:为成本优化搭建环境(amazon.com)
- 使用AWS成本分配标签——AWS账单(amazon.com)
- (示例)为数字银行定义AWS多账户策略
- (示例)为电信公司定义AWS多账户策略
Azure
- 使用标签继承分组和分配成本——Microsoft成本管理 | Microsoft Learn
- 资源命名和标签决策指南——云采用框架 | Microsoft Learn
- 定义标签策略——云采用框架 | Microsoft Learn
GCP
- 创建和管理标记 | 资源管理器文档 | Google Cloud
- 创建和管理标签 | 资源管理器文档 | Google Cloud
层级结构
- AWS:标记AWS组织资源——AWS组织(amazon.com)
- Azure:为逻辑组织标记资源、资源组和订阅——Azure资源管理器 | Microsoft Learn
- GCP:创建和管理组织 | 资源管理器文档 | Google Cloud
合规与执行
- AWS:使用AWS标签政策和服务控制策略(SCPs)实施AWS资源标签策略 | AWS云运营与迁移博客(amazon.com)
- Azure:资源标记的政策定义——Azure资源管理器 | Microsoft Learn
- 教程:管理标签治理——Azure政策 | Microsoft Learn
- GCP:使用标签设置组织政策 | 资源管理器文档 | Google Cloud
最后更新日期:2025年10月10日