FinOps成本管理平台

导读

本文主要介绍CH的云成本管理平台(CCMP,Cloud Cost Management Platform),要点包括:平台架构、计量计费、厂商对账、成本管控等。云成本管理平台是FinOps支撑工具,中间夹杂了一些必要的FinOps场景介绍。

云资源中的资源,主要指IT资源,下文中的资源、IT资源、云产品指的都是云资源。云成本管理平台,下文简称成本管理平台。

平台架构

成本管理平台,由几大部分构成:计量计费、厂商对账、成本管控、报表,如下。其中,厂商指的是各云厂商,合同指的是我方跟厂商签署的销售合同,ICSP指的是我方的内部云平台;内部云平台ICSP包装了多云资源、对内出售,是二级云服务提供商。

page.png

计量计费

计量计费,作用是:站在资源使用方(俗称甲方)的视角,统计各类云资源的用量、费用,用于后续的厂商对账、成本管控等。计费是各计费项的费用之和,即:费用 = ∑计费项(单价x用量),包含了计费项、单价、用量三个要素。

  • 计费项:主要取决于云产品的计费设计,如CPU/GPU按机型计费、足够简单,大数据PaaS服务按照集群实例计费、有点复杂
  • 单价:单价设定称为定价,定价分为厂商合同定价、ICSP内部定价两种,分别用于计算云账单和内部成本分摊
  • 用量:用量计算称为计量,计量取决于甲方在不同计费项上的技术能力,如CPU/GPU计量通过ICSP(内部云平台)、相对容易,CDN计量困难、直接使用云厂商的数据(云API、云账单)

定价分为厂商合同定价、ICSP内部定价两种。厂商合同定价,是商务或采购沟通的结果,通常以合同的方式、约定各个云产品的单价(或折扣);使用合同定价计算出来的费用,用于和厂商对账、发现厂商账单错误。ICSP内部定价,指的是ICSP以二级云服务提供商的身份、制定单价,向内部业务团队出售IT资源或产品(利润中心)、或做成本分摊(成本中心);结合业务预先提报的预算,就能做到IT资源的成本管控。如下图。

page.png

不同云产品会有不同的计费时效。不同产品的计费项复杂程度不同,我方的技术能力决定了它的计量方式;计量方式又决定了计费的时效性,如ICSP通常能做到小时级时效,云API天级、云账单月级。如下图,CPU/GPU机器能做到天级时效,CDN/S3/流量天级时效,大数据PaaS/安全产品只能月级时效。

page.png

计算链路实现上,ICSP的CMDB、公有云API、云账单产出原始数据,经过加工处理形成单价、计量事实表,再经过计费计算、产出计费事实表;单价、计量、计费均保留天级版本。计量计费是成本度量体系的数据基础,支持了上层的各种灵活需求。

厂商对账

厂商对账,作用是:对照合同、发现厂商的不合理费用,追溯并挽回损失(止损)。

账单模型,包括费用组成、费用结构等。费用组成,包括消费、退款、代金券、调账四类构成,本质都是用量和单价。费用结构,按汇总程度从高到低依次分为账号、产品、子产品、实例、计费项五个等级(L1到L5),还会叠加账期、地域两个维度。账号是甲方在云上的企业账号。产品是厂商对云产品的分类,如服务器、对象存储、公网带宽、安全产品、AI产品等,账单模型由云厂商产品模型决定。子产品是云产品下的一种具体型号的资源或组件,如ECS.C5.8xLarge机型、CKafka。实例是子产品下的一个功能组合单位,如1台机器、1个CKafka集群、1个验证码AppID。计费项则是云厂商要求的、子产品的计费模型。

对账实现,有账单数据校验、账单环比分析、独立计费对比三条链路,如下图。账单数据校验,主要检查云厂商提供的账单是否存在数据错误(自恰),很低级、但很有必要;校验主要集中在账号消费、账户代金券、产品消费上。账单环比分析,是站在时间环比角度、解释增量变化的业务原因,如12月相比11月GPU增加了160片V4卡(增幅20%)、原因是疫情爆发导致AI业务量增加了20%;环比分析能给人一种相对宏观、且可理解的的业务解释,财务人员是主要使用者。独立计费对比是绝对值比较,我方独立计算用量、按照合同约定的单价和计费项、产出一份费用账单,然后用我方账单跟云厂商账单对比、发现差异;独立计费成本过高,只能覆盖主要的SKU。

page.png

厂商对账是最有效的财务止损手段,也是FinOps的核心方向,其精度主要取决于甲方在对账上的投入。

成本管控

成本管控,以预算为目标、管控公司内部业务的资源成本,超预算时禁止新增或提升审批等级(管控)。成本管控有三个要点,即:分摊模型、预算、分摊、管控。

分摊模型

分摊模型,即成本模型、预算和分摊共用此模型,如下图所示。分摊模型共分为五级,其中资源、集群是对资源(或服务)的抽象,预单、业务、主体是对组织结构的抽象。

  • 资源:资源是云服务的统称,包括所有IaaS/PaaS/SaaS;为了便于管理,资源被划分为科目、子科目两级,如科目CPU下包含CPU在线业务、CPU数据库等子科目,子科目是资源分类的最小单位。为叙述方便,后文不区分子科目、而是用科目统一指代
  • 集群:集群是对资源的统一建模,每类资源(科目)都需要找到一个管理粒度、并将之定义为集群,如CPU在线业务的应用、对象存储-标准存储(GB)的桶、CDN(GB)的域名、带宽(GB)的IP、PaaS的集群、专线(元)的名称等。集群之下通常还可以抽象出实例
    • 对于无法提炼出集群概念的资源,使用产品名称作为集群,集群到预算再做比例分摊,如安全(元)子科目
  • 预单:预单即预算单元、技术成本中心,是从技术视角抽象出来的相对稳定的公司组织结构;预单通常包含多个服务组、又被一个技术部门包含,是资源和组织结构的结合点,资源成本通过预单、最终分摊到业务
    • 服务组无法取代预单,是因为应用微服务架构无法推广到绝大部分资源
  • 业务:商业视角的业务单元、利润中心,基本对应了公司对外提供的产品服务,用于高管、财务等角色
  • 主体:主体对应了企业法人,主要解决财税法等政策问题,用于CEO、法务、财务等角色

page.png

在实际操作中,预单是整个分摊模型的核心(技术视角),资源只有具备了预单归属、才能做进一步预算和分摊。预单之上还会有部门、用做技术视角的聚合展示,业务之上还会有业务群、用做财务/高管视角的聚合展示,部门、业务群只是特定的视图聚合不是建模核心。

按照上述分摊模型,整理出一个典型的分摊账单、如下图(集群维度太细被聚合掉了)。对于计费项复杂、尚未提炼出用量的资源,使用费用作为用量(对应单价为1),如其它科目下的专线、安全产品、技术服务费等。

page.png

预算

预算,目的是:设定成本管控的目标。预算一般以预单为组织单位、以月为时间单位、以自然年为周期,操作包括年度提报(年末提报明年预算)、季度调整(季末更新剩余预算)、不定期的业务更新(业务间调预算总额不变)。典型的预算数据(Q)结构如下。

page.png

预算管理,工作量集中在年度提报。年度提报的流程、要点,可参见文末的预算提报章节。这里只介绍预算用量的预估模型,即 「资源科目用量 = Fun(业务指标BM) - ∑技术优化」。其中,业务指标BM预估,反映了业务的增长预期,通常由商分或产品提供;用量函数Fun,是根据历史资源用量&业务指标BM的对应关系、拟合而出,历史资源用量也被称为基线、由FinOps提供;除此之外,技术人员也要背技术优化的指标 ∑技术优化,体现技术进步带来的成本降低。预算费用 = ∑资源计费项 (单价 x 用量),关键点是确定单价(定价),定价代表了ICSP的出现。

预算管理受很多因素限制。比如,预算追求逻辑自恰、无法绝对正确(玄学),团队间掰扯的情况很多,因为预算数值所依赖的业务指标BM预测、模型关系、技术优化都是预估值。比如,预算也会受到厂商商务策略的影响,满返代金券会影响预算目标制定(负预算)、月度成本管控(不定期发放),合同调整会影响ICSP内部定价,商务策略在时间、逻辑上的不确定性总是很有挑战。再比如,预算有强的人工运营属性、可以平台化但无法完全自动化,因为预算的资源科目、预算单元、增长管理等受限于公司战略下的业务结构、组织结构、收支目标等非技术因素,如下图。

page.png

分摊

分摊,目的是:将IT资源成本、分摊到各业务和主体,产出成本管控的消费数据。分摊,是资源中台从成本中心、向利润中心转变的关键。

分摊依赖资源的成本建模。根据所处的技术、业务环境,将资源分为不同科目,类似云厂商将产品分为不同服务。识别出主体科目(成本占比高如CPU、存储),进一步细化分类到集群(如CPU应用模块的集群、对象存储的桶);非主体科目一般会简化模型、不再细分集群(ROI考虑如安全产品),直接使用云账单做分摊。资源科目分类、主体科目识别带有较强的成本取舍,是FinOps的职责;资源科目的集群抽象、用量数据,由资源科目管理员提供。

分摊依赖准确的分摊比例。有了集群数据后,集群归属(按比例分摊)到预单、预单再按比例分摊到业务和主体,就完成了资源到业务的成本分摊。集群归属到预单是最复杂的环节,一方面集群数量很大、维护工作量也大;另一方面发现和纠正错误的周期较长,一般要等到超预算被考核时、由预算接口人提出;FinOps要求集群由预单独占(分摊比例100%),即便如此归属维护依然很复杂。集群归属是资源科目管理员的职责,FinOps负责监督。预单到业务通常按比例分摊,独占预单则100%,非独占则按照PV、UV、数据量等指标的占比分摊。业务通常确定的归属于一个主体,不存在1对多的情况。

分摊计算有用量费用之分、类似预算。预单粒度的分摊计算:用量 = ∑预单下的集群(集群用量 x 比例),费用 = ∑资源科目(预单用量 x 单价)。数据精度一般分为小时、天级、月级,明细数据以天级为主,低精度到高精度通过时长做归一化转换。报表产出以天级明细、月度报告为主,天级明细是集群粒度、给技术人员使用,月度报告支持预单+业务+主体等多个粒度,给技术部门负责人+业务负责人+财务+高管使用,参考如下。

page.png

page.png

管控

成本管控,以预算做为目标、以分摊做为实消(实际消费),根据是否「预算超出」的度量、由强权组织推动成本管控,这样就形成了成本管控的完整闭环,如下图。管控主要变现在控增量、修存量;控增量通过交付审批实现,超预算后审批等级会提升、直至CTO;修存量要求对应的技术团队提升资源利用率,同时优化业务实现、降低单位成本(如降低直播码率、缩短存储时长)。

page.png

成本管控是典型的「数据度量+组织驱动」的数字化运营模式。

报表

报表,目标是:以清晰易用的形态,传递信息、辅助决策。报表分类,主要是按成本场景展开,如计量计费、厂商对账、成本管控;除了展示最终结果,也会有报表展示计算过程、用于数据排障。

从报表角度回看,整个成本平台就是一个离线计算体系,如下图:

page.png

总结

在平台建设、成本运营的过程中,对成本管理平台有如下几个关键认知,

  • 价值定位:成本平台是成本数据度量平台,老板系统、辅助决策,数据必须准确全面,报表看重全局视角
    • 数据是价值底线,数据不准则平台无价值、数据少则平台价值指数递减
    • 报表是价值输出,优先匹配全局视角、避免贪多
  • 数据模型:成本数据要支持多版本,做到元数据可修改、结果可重算;数据回溯时效取决于元数据、不取决于平台功能(数仓)
    • 数据校准有两个途径,即两个独立计算的系统做数据对比(逻辑维度)、同一系统做两个周期的增量分析(时间维度)
    • 应用层相关的数据必须带版本,即使是被应用层引用的事实表;参与数据生成的维表可以不带版本,但后果是无法精确重算
  • 报表产品:报表产品分为趋势和分布两大类,报表页面遵循总分的组织结构(全局视角)
    • 报表遵循总分的组织结构,典型页面自上而下依次是:筛选栏、指标栏、图形栏、表格明细栏(四段式)
    • 报表分为趋势和分布两类,趋势典型如曲线图,横轴是时间、纵轴是指标,观察某类对象随时间的变化;分布报表典型如表格,行主键是维度、列是指标取值,观察固定日期的对象分布情况
  • 平台约束:以成本平台为例,数据平台只实现确定性功能、无法面面俱到,灵活协同通常交给Excel来做
    • 比如预算制定,需求多人线下协同,通过Excel能很好完成,平台做的话ROI太低
    • 成本运营时常有数据「从Excel中来、到Excel中去」,Excel导入导出功能是数据平台标配

以下是文末附加内容,偏细节、不系统、待完善。

设计取舍

在成本管理的过程中,遇到了一些有意思的问题,这些问题最终影响到了成本模型的设计。挑几个,

  • 分摊时,拆分用量、现金两个视角。用量视角给技术人员做分析,现金视角给财务人员做成本管控
    • 起初,为了跟财务对齐数字,将现金支付的总数、按用量计费的比例分摊给各业务
    • 现金支付的总数波动严重,原因有代金券、账期、合同定价等。这就造成了一个困惑:资源用量明明没有变化,但业务第二个月的分摊费用变多或变少了,甚至出现了用量减少、但分摊费用增加的情况
    • 为了解决这个问题,分摊改为使用用量计费、不再Follow现金支付的总数。在单价固定的情况下,分摊只受用量影响,而用量对技术人员更直观
    • 如果定价合理,在较长的观察周期内,用量视角、现金视角的分摊总数几乎相等,视角误差很小 —— 这已经在实践中证实
    • 最后,技术人员欢快的享受用量视角,财务人员则继续使用现金视角,双方都很满意
    • 值得注意的是,最终的成本管控标准依然是现金视角,用量视角只用做分析、过程管理
  • 预算时,保持一个视角,技术、财务都看到相同的预算数字。这个做法很容易受到财务异动项影响
    • 做预算时,往往会把类似满返代金券的异动项算进去,通常是一个负数。下文以满返为例
    • 预算定稿后,要求分摊也将满返、同步考虑进去;此时的满返,已经渗透到分摊(用量视角)
    • 满返的实施,是云厂商人工控制,通常无法和预算时间同步、数量同步,这就造成用量视角的预算意外超支或盈余,影响到用量视角的判断
    • 为了解决这个问题,我们并没有拆分出用量视角的预算,而是在分摊时”忽略”掉满返这一项:不管反满是否实施、用量分摊时都认为它实施了。这样,就避免了满返对分摊(用量视角)的影响。由此造成的用量视角总数字变化,都算到视角误差中 —— 这也确实是视角误差

目标定义

FinOps的出发点,首先是宏观的企业经营决策,其次才是技术角度的优化。因此,FinOps目标也应该以企业经营为底线、酌情体现技术价值。

以IT领域的预算目标为例。假设企业今年的销管支出是X元。明年因业务扩张,销管支出预计增加15%、至X1.15;根据行研13%的中位值,CEO决策 IT成本底线不应大于X1.150.13(否则就无法保障企业的IT竞争力)。在经营决策的基础上,CTO制定了5%的优化目标、来体现技术价值,即明年IT预算不能超过 X1.150.130.95。在预算目标制定的过程中,企业经营、技术优化都是自上而下决策的。值得注意的是,CEO决策的IT成本,很可能是往年真实的IT支出乘以销管增幅,这个数字通常小于行研中位值。

另一个常被提及的指标是单位成本。单位成本是一个被高度美化、过分期许的局部指标。首先,它是高度模型化的,业务越复杂、取舍和失真就越严重。其次,它要求业务形态长期稳定,否则就失去了年环比价值。基于这两点,单位成本可以作为成熟业务线的小目标,但很难作为企业的大目标。单位成本的概念之所以有市场,是因为局部视角的受众很多。

对象建模

资源对象的管理模型分为两部分:组织模型+资源模型。组织模型包括 集团、主体、业务(业务组)、预单(部门),资源模型包括 预单、科目(科目组)、集群。

预单和管单是成对儿的概念,通常预单对应资源使用方、管单对应资源提供方。从FinOps视角看,管单主要用于组件混用科目的场景,如MQ资源混在CPU在线业务;管单+预单可以实现简单的二次分摊,如MQ的某个集群,管单是资源提供方INF、预单是资源使用方直播业务。从变更管控视角看,封线需求来自资源使用方、不来自提供方,封线有两种实现方式 ①针对业务使用的资源设置封线(按预单) ②同步规则、由资源提供方自主设置封线(按管单),当前使用的是方式②。从适用范围上看,预单比管单更广泛,因为大部分资源都是明确科目或自产自消的、需要预单但不需要管单。



Prev     Next