导读
本文主要介绍CH的云成本管理平台(CCMP，Cloud Cost Management Platform)，要点包括：平台架构、计量计费、厂商对账、成本管控等。云成本管理平台是FinOps支撑工具，中间夹杂了一些必要的FinOps场景介绍。
云资源中的资源，主要指IT资源，下文中的资源、IT资源、云产品指的都是云资源。云成本管理平台，下文简称成本管理平台。
平台架构
成本管理平台，由几大部分构成：计量计费、厂商对账、成本管控、报表，如下。其中，厂商指的是各云厂商，合同指的是我方跟厂商签署的销售合同，ICSP指的是我方的内部云平台；内部云平台ICSP包装了多云资源、对内出售，是二级云服务提供商。
计量计费
计量计费，作用是：站在资源使用方(俗称甲方)的视角，统计各类云资源的用量、费用，用于后续的厂商对账、成本管控等。计费是各计费项的费用之和，即：费用 = ∑计费项(单价x用量)，包含了计费项、单价、用量三个要素。
- 计费项：主要取决于云产品的计费设计，如CPU/GPU按机型计费、足够简单，大数据PaaS服务按照集群实例计费、有点复杂
- 单价：单价设定称为定价，定价分为厂商合同定价、ICSP内部定价两种，分别用于计算云账单和内部成本分摊
- 用量：用量计算称为计量，计量取决于甲方在不同计费项上的技术能力，如CPU/GPU计量通过ICSP(内部云平台)、相对容易，CDN计量困难、直接使用云厂商的数据(云API、云账单)
定价分为厂商合同定价、ICSP内部定价两种。厂商合同定价，是商务或采购沟通的结果，通常以合同的方式、约定各个云产品的单价(或折扣)；使用合同定价计算出来的费用，用于和厂商对账、发现厂商账单错误。ICSP内部定价，指的是ICSP以二级云服务提供商的身份、制定单价，向内部业务团队出售IT资源或产品(利润中心)、或做成本分摊(成本中心)；结合业务预先提报的预算，就能做到IT资源的成本管控。如下图。
不同云产品会有不同的计费时效。不同产品的计费项复杂程度不同，我方的技术能力决定了它的计量方式；计量方式又决定了计费的时效性，如ICSP通常能做到小时级时效，云API天级、云账单月级。如下图，CPU/GPU机器能做到天级时效，CDN/S3/流量天级时效，大数据PaaS/安全产品只能月级时效。
计算链路实现上，ICSP的CMDB、公有云API、云账单产出原始数据，经过加工处理形成单价、计量事实表，再经过计费计算、产出计费事实表；单价、计量、计费均保留天级版本。计量计费是成本度量体系的数据基础，支持了上层的各种灵活需求。
厂商对账
厂商对账，作用是：对照合同、发现厂商的不合理费用，追溯并挽回损失(止损)。
账单模型，包括费用组成、费用结构等。费用组成，包括消费、退款、代金券、调账四类构成，本质都是用量和单价。费用结构，按汇总程度从高到低依次分为账号、产品、子产品、实例、计费项五个等级(L1到L5)，还会叠加账期、地域两个维度。账号是甲方在云上的企业账号。产品是厂商对云产品的分类，如服务器、对象存储、公网带宽、安全产品、AI产品等，账单模型由云厂商产品模型决定。子产品是云产品下的一种具体型号的资源或组件，如ECS.C5.8xLarge机型、CKafka。实例是子产品下的一个功能组合单位，如1台机器、1个CKafka集群、1个验证码AppID。计费项则是云厂商要求的、子产品的计费模型。
对账实现，有账单数据校验、账单环比分析、独立计费对比三条链路，如下图。账单数据校验，主要检查云厂商提供的账单是否存在数据错误(自恰)，很低级、但很有必要；校验主要集中在账号消费、账户代金券、产品消费上。账单环比分析，是站在时间环比角度、解释增量变化的业务原因，如12月相比11月GPU增加了160片V4卡(增幅20%)、原因是疫情爆发导致AI业务量增加了20%；环比分析能给人一种相对宏观、且可理解的的业务解释，财务人员是主要使用者。独立计费对比是绝对值比较，我方独立计算用量、按照合同约定的单价和计费项、产出一份费用账单，然后用我方账单跟云厂商账单对比、发现差异；独立计费成本过高，只能覆盖主要的SKU。
厂商对账是最有效的财务止损手段，也是FinOps的核心方向，其精度主要取决于甲方在对账上的投入。
成本管控
成本管控，以预算为目标、管控公司内部业务的资源成本，超预算时禁止新增或提升审批等级(管控)。成本管控有三个要点，即：分摊模型、预算、分摊、管控。
分摊模型
分摊模型，即成本模型、预算和分摊共用此模型，如下图所示。分摊模型共分为五级，其中资源、集群是对资源(或服务)的抽象，预单、业务、主体是对组织结构的抽象。
- 资源：资源是云服务的统称，包括所有IaaS/PaaS/SaaS；为了便于管理，资源被划分为科目、子科目两级，如科目CPU下包含CPU在线业务、CPU数据库等子科目，子科目是资源分类的最小单位。为叙述方便，后文不区分子科目、而是用科目统一指代
- 集群：集群是对资源的统一建模，每类资源(科目)都需要找到一个管理粒度、并将之定义为集群，如CPU在线业务的应用、对象存储-标准存储(GB)的桶、CDN(GB)的域名、带宽(GB)的IP、PaaS的集群、专线(元)的名称等。集群之下通常还可以抽象出实例
- 对于无法提炼出集群概念的资源，使用产品名称作为集群，集群到预算再做比例分摊，如安全(元)子科目
- 预单：预单即预算单元、技术成本中心，是从技术视角抽象出来的相对稳定的公司组织结构；预单通常包含多个服务组、又被一个技术部门包含，是资源和组织结构的结合点，资源成本通过预单、最终分摊到业务
- 服务组无法取代预单，是因为应用微服务架构无法推广到绝大部分资源
- 业务：商业视角的业务单元、利润中心，基本对应了公司对外提供的产品服务，用于高管、财务等角色
- 主体：主体对应了企业法人，主要解决财税法等政策问题，用于CEO、法务、财务等角色
在实际操作中，预单是整个分摊模型的核心(技术视角)，资源只有具备了预单归属、才能做进一步预算和分摊。预单之上还会有部门、用做技术视角的聚合展示，业务之上还会有业务群、用做财务/高管视角的聚合展示，部门、业务群只是特定的视图聚合不是建模核心。
按照上述分摊模型，整理出一个典型的分摊账单、如下图(集群维度太细被聚合掉了)。对于计费项复杂、尚未提炼出用量的资源，使用费用作为用量(对应单价为1)，如其它科目下的专线、安全产品、技术服务费等。
预算
预算，目的是：设定成本管控的目标。预算一般以预单为组织单位、以月为时间单位、以自然年为周期，操作包括年度提报(年末提报明年预算)、季度调整(季末更新剩余预算)、不定期的业务更新(业务间调预算总额不变)。典型的预算数据(Q)结构如下。
预算管理，工作量集中在年度提报。年度提报的流程、要点，可参见文末的预算提报章节。这里只介绍预算用量的预估模型，即 「资源科目用量 = Fun(业务指标BM) - ∑技术优化」。其中，业务指标BM预估，反映了业务的增长预期，通常由商分或产品提供；用量函数Fun，是根据历史资源用量&业务指标BM的对应关系、拟合而出，历史资源用量也被称为基线、由FinOps提供；除此之外，技术人员也要背技术优化的指标 ∑技术优化，体现技术进步带来的成本降低。预算费用 = ∑资源计费项 (单价 x 用量)，关键点是确定单价(定价)，定价代表了ICSP的出现。
预算管理受很多因素限制。比如，预算追求逻辑自恰、无法绝对正确(玄学)，团队间掰扯的情况很多，因为预算数值所依赖的业务指标BM预测、模型关系、技术优化都是预估值。比如，预算也会受到厂商商务策略的影响，满返代金券会影响预算目标制定(负预算)、月度成本管控(不定期发放)，合同调整会影响ICSP内部定价，商务策略在时间、逻辑上的不确定性总是很有挑战。再比如，预算有强的人工运营属性、可以平台化但无法完全自动化，因为预算的资源科目、预算单元、增长管理等受限于公司战略下的业务结构、组织结构、收支目标等非技术因素，如下图。
分摊
分摊，目的是：将IT资源成本、分摊到各业务和主体，产出成本管控的消费数据。分摊，是资源中台从成本中心、向利润中心转变的关键。
分摊依赖资源的成本建模。根据所处的技术、业务环境，将资源分为不同科目，类似云厂商将产品分为不同服务。识别出主体科目(成本占比高如CPU、存储)，进一步细化分类到集群(如CPU应用模块的集群、对象存储的桶)；非主体科目一般会简化模型、不再细分集群(ROI考虑如安全产品)，直接使用云账单做分摊。资源科目分类、主体科目识别带有较强的成本取舍，是FinOps的职责；资源科目的集群抽象、用量数据，由资源科目管理员提供。
分摊依赖准确的分摊比例。有了集群数据后，集群归属(按比例分摊)到预单、预单再按比例分摊到业务和主体，就完成了资源到业务的成本分摊。集群归属到预单是最复杂的环节，一方面集群数量很大、维护工作量也大；另一方面发现和纠正错误的周期较长，一般要等到超预算被考核时、由预算接口人提出；FinOps要求集群由预单独占(分摊比例100%)，即便如此归属维护依然很复杂。集群归属是资源科目管理员的职责，FinOps负责监督。预单到业务通常按比例分摊，独占预单则100%，非独占则按照PV、UV、数据量等指标的占比分摊。业务通常确定的归属于一个主体，不存在1对多的情况。
分摊计算有用量费用之分、类似预算。预单粒度的分摊计算：用量 = ∑预单下的集群(集群用量 x 比例)，费用 = ∑资源科目(预单用量 x 单价)。数据精度一般分为小时、天级、月级，明细数据以天级为主，低精度到高精度通过时长做归一化转换。报表产出以天级明细、月度报告为主，天级明细是集群粒度、给技术人员使用，月度报告支持预单+业务+主体等多个粒度，给技术部门负责人+业务负责人+财务+高管使用，参考如下。
管控
成本管控，以预算做为目标、以分摊做为实消(实际消费)，根据是否「预算超出」的度量、由强权组织推动成本管控，这样就形成了成本管控的完整闭环，如下图。管控主要变现在控增量、修存量；控增量通过交付审批实现，超预算后审批等级会提升、直至CTO；修存量要求对应的技术团队提升资源利用率，同时优化业务实现、降低单位成本(如降低直播码率、缩短存储时长)。
成本管控是典型的「数据度量+组织驱动」的数字化运营模式。
报表
报表，目标是：以清晰易用的形态，传递信息、辅助决策。报表分类，主要是按成本场景展开，如计量计费、厂商对账、成本管控；除了展示最终结果，也会有报表展示计算过程、用于数据排障。
从报表角度回看，整个成本平台就是一个离线计算体系，如下图：
总结
在平台建设、成本运营的过程中，对成本管理平台有如下几个关键认知，
- 价值定位：成本平台是成本数据度量平台，老板系统、辅助决策，数据必须准确全面，报表看重全局视角
- 数据是价值底线，数据不准则平台无价值、数据少则平台价值指数递减
- 报表是价值输出，优先匹配全局视角、避免贪多
- 数据模型：成本数据要支持多版本，做到元数据可修改、结果可重算；数据回溯时效取决于元数据、不取决于平台功能(数仓)
- 数据校准有两个途径，即两个独立计算的系统做数据对比(逻辑维度)、同一系统做两个周期的增量分析(时间维度)
- 应用层相关的数据必须带版本，即使是被应用层引用的事实表；参与数据生成的维表可以不带版本，但后果是无法精确重算
- 报表产品：报表产品分为趋势和分布两大类，报表页面遵循总分的组织结构(全局视角)
- 报表遵循总分的组织结构，典型页面自上而下依次是：筛选栏、指标栏、图形栏、表格明细栏(四段式)
- 报表分为趋势和分布两类，趋势典型如曲线图，横轴是时间、纵轴是指标，观察某类对象随时间的变化；分布报表典型如表格，行主键是维度、列是指标取值，观察固定日期的对象分布情况
- 平台约束：以成本平台为例，数据平台只实现确定性功能、无法面面俱到，灵活协同通常交给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、预单是资源使用方直播业务。从变更管控视角看，封线需求来自资源使用方、不来自提供方，封线有两种实现方式 ①针对业务使用的资源设置封线(按预单) ②同步规则、由资源提供方自主设置封线(按管单)，当前使用的是方式②。从适用范围上看，预单比管单更广泛，因为大部分资源都是明确科目或自产自消的、需要预单但不需要管单。