多云成本管理平台

导读

本文主要介绍CH的多云成本管理平台(CCMP,Cloud Cost Management Platform),要点包括:平台架构、成本分摊、预算管理、成本优化、知识总结等。

多云资产中的资产,主要指IT资产。多云成本管理平台,下文简称成本管理平台。

背景

成本管理平台的产生、完善,依赖如下公司环境:

  • 文化保障: 公司有尚俭文化传统,对各种成本的控制一直很严格,并在价值观、组织结构、制度、技术等多方面做了设计
  • 组织保障: 产研团队是帝国模式,中心式的组织架构、CTO强权,中心决策、自上而下能够强力执行
  • 技术保障: 基础设施公有云原生,IT资产全部来自公有云,多云厂商在产品功能、计费模式、结算方式上基本打平

平台架构

成本管理平台,由几大部分构成:计费、对账、预算、分摊、报表,如下。

page.png

本平台重在度量,成本管控由更上层的云资产准出平台实现。

计费

计费,是:站在甲方的视角,统计各类云资产的用量、费用,用于后续的对账、分摊、及更远的成本管控。计费的业务场景,如下图。

page.png

计费场景是对计费项、计量、时效性三个维度的折中。计费项的难易程度,主要取决于云产品计费设计,如CPU/GPU按照机型计费、足够简单,大数据PaaS服务按照集群实例计费、有点复杂。计量取决于甲方的技术能力,如CPU/GPU通过CMDB计量相对容易,CDN带宽则很难计量。时效性取决于计费&分摊需求,可选方式包括基于CMDB、多云API、日账单、月账单;此四者,计费时效性依次变差、实现难度依次降低。在不考虑全局增益的情况下,我们更倾向于:大头儿资产重点照顾、选择最优方案,小众资产选择实现难度更低的方案。

计费产出用量、费用两组数据,向上支撑对账、分摊两个功能。从用户群里来看,技术人员更喜欢用量,因为用量区分不同产品、更容易理解;财务人员更喜欢费用,因为费用做了打平、更直观汇总。

对账

对账的目的,是:判断云厂商有没有多收甲方的钱,是为了财务止损。我们通常会将云资产分为账号、产品、组件、实例、计费项五个等级,从绝对量、增量两个角度来做对账分析,如下图。

page.png

云资产的对账等级设计,既取决于云厂商的计费精度,也取决于甲方在对账上的投入(平台+人)。

绝对量分析,包括核对云厂商账单数据(数据自恰)、跟我方独立计费的对比(逻辑独立链路)两个途径。云厂商账单通常由消费、退款、代金券、调账四类构成,我方使用账单数据、按照相同的算法、计算账单费用,跟云厂商提供的费用做对比(偶尔也会投入两个人、独立核对)。跟我方独立计费的对比,通常是对比用量、单价两项,而不是费用;因为技术人员更擅长用量视角(单价是为了弥补用量和费用之差异),也因为计费容易被单价调整影响准确性。

增量分析,目的是让人更容易理解账单的变化原因,重在言之有理。因此,增量分析通常是对云账单做月度费用环比,对于费用变化给出合理的用量解释。财务人员是增量分析的主要使用者。

对账是财务止损手段,当前依赖人工、还无法完全自动化。FinOps小领域中,第三方独立计费是一个发展方向、可以实现绝对量分析。增量分析的需求,在将来可能会消亡。

预算

预算的目的,是:生成成本目标元数据。预算,是运营范畴、不是技术范畴。预算管理,依赖财务建立完整的预算管理流程、技术建立可理解的预算预估模型,然后作为目标、约束各业务方向的成本投入。具体如下,

预算提报流程

预算提报和更新流程,是重度运营过程。一个参考样例,如下:

  • 10.08 财务发出公司预算启动邮件
  • 10.14 财务组织产研预算启动会
  • 10.18~10.21 运维准备工作
    • 10.18 规划: 和财务对齐目标,定义里程碑(2H)
    • 10.18 接口人: 整理预算接口人名单(4H)
    • 10.18 启动: 发启动通知,建立沟通渠道(1H)
    • 10.19 基线: 整理预算基线,提供给预算接口人、并答疑(8H)
    • 10.20 平台: 开放预算更新入口(2H)
    • 10.20 数据: 更新预算模板之预单和科目(4H)
    • 10.21 权限: 授权预算接口人(2H)
  • 10.19~11.10 产研提报预算
    • 10.19~10.26 业务做预算
    • 10.22~10.26 业务录入预算平台
    • 10.27~10.28 运维初核预算
    • 10.28 运维准备预算报表,包括年度、部门、科目对比,单位成本分析等
  • 10.29~11.02 产研内部核对预算
    • 10.29 运维核对,和财务同步初版
    • 10.29 架构核对,产出有问题的部门
    • 11.01 产研核对,产出改进目标
    • 11.02~11.03 业务调整预算、再次提报
  • 11.03~11.10 财务核对预算
    • 11.03 财务和架构初核预算
    • 11.06 财务进行利润中心分摊
    • 11.10 财务和产研中心核对预算
  • 11.10~12.10 公司核对预算
    • 11.11~11.25 财务核对公司整体预算
    • 11.26~12.03 财务和利润中心沟通预算分摊
    • 12.06~12.20 财务和CEO对预算
  • 12.21~12.30 产研发起预算流程
    • 12.21 产研中心发起新预算审批
    • 12.25 CEO审批通过新预算
    • 12.26 预算平台生效

预算预估模型

为简化云资产的预算预估,我们采取了简化计费项、统一定价、固化预估模型。具体如下,

  • 简化计费项:独立计费的云产品抽象为一个计费项,简化用户的理解成本。如,
    • CPU机器 抽象为CPU核数,屏蔽机型差异(机型包括了CPU、MEM、磁盘等计费项)
    • 对象存储 抽象为存储空间,屏蔽掉请求次数、出网流量等计费项
  • 统一定价:技术人员只提报产品用量,运维做统一定价后、得出预算费用
    • 一旦统一定价,成本管理平台就具备了「二级云服务提供商」的财务特点(二级CSP)
  • 固化预估模型:用量、业务指标要做到公式相关,如
    • 预估用量 = 固定用量 + 业务指标 * “业务/资产-相关系数” * 优化系数,优化系数通常体现了性能优化、架构优化等技术侧主动降成本的效果预期
    • 业务/资产-相关系数,举例:1K次搜索峰值需要1个CPU,1K个学生上课需要1TB的存储空间

预算追求逻辑自恰,不追求绝对正确。因为,预算预估所依赖的公司增长目标、成本目标都是预估值,预算预估本身很难做到绝对客观。从这个意义上讲,预算更像是一门玄学。

预算管理约束

预算管理无法做到完全自动化,受制于公司战略下的组织结构、业务结构、收支目标等非技术因素。如下图,运维在预算准备阶段至少需要做到权限管理、基线准备、预算科目维护,这三个事项无法自动化、甚至无法平台化。

page.png

分摊

成本分摊,目的是:将云资产消耗的技术成本、合理分摊到各利润中心。分摊模型如下图,元素间关联关系为: 资产实例 - 服务/业务线 - 预算单元 - 成本中心 - 利润中心,不同元素的关联关系既有1:1的独占、也有1:N按比例,部分中台预算单元也支持二次分摊。

分摊的难点在于,资产实例到预算单元的关联经常变化,资产实例到服务/业务线关联会被业务结构影响,服务/业务线到预算单元的关联会被组织结构、业务结构影响。元数据运营需要大量人工投入。

page.png

我司早期,运维团队借助成本分摊的需求、建立起了资产元数据体系,之后又通过在关键路径复用这份元数据、聚向保障了元数据的质量,有效降低了元数据的维护成本。

值得注意的是,分摊、对账使用不同的单价。分摊使用公司内部约定的预算单价,和预算保持一致、方便做预算目标管理;对账使用真实的财务单价,和云服务提供商保持一致、方便对账。从分摊的角度讲,我们完成了对云厂商的二次封装,对内提供了一套完整的公有云服务(二级云服务提供商CSP)。

报表

报表主要用于辅助决策,严格Boss Trigger,基本遵循总分结构。

整个成本度量体系,就是一个数仓计算模型,报表展示尤其如此。此处直接贴图,略去数仓模型的一万字,不懂请谷歌。

page.png

对于报表的一些体会,

  • 报表可以按照总分结构展开。典型的是,自上而下依次 筛选栏、指标栏、图形栏、表格明细栏(四段式)
  • 报表分为趋势、分布两种类型。趋势载体是TS,横轴是时间、纵轴是指标、维度用做对象筛选;分布载体是表格,行主键是维度、列是指标取值、时间用作对象筛选
  • 数据平台提供不同的时效性。Prometheus延迟不宜大于1小时,Mysql延迟不宜大于1天,离线数仓延迟在天级及以上。目前还没有用上流批一体的解决方案,之前用过Druid、太贵下线了
  • Grafana做报表的潜力巨大。之前一直把Grafana作为实时监控的工具,有失偏颇,后续尝试在统计领域加大Grafana的使用度

成本优化

成本优化,学名资源效能,遵循解决问题的工程范式: 发现问题 -> 分析问题 -> 抽象模型 -> 度量指标 -> 建设目标 -> 关键路径 -> 组织保障,如下图。

page.png

成本模型

资源成本 = ∑( 单价 * 资源用量) ∝ 单价 * ( 业务量 * 单位业务资源用量 / 资源利用率 ) ∝ 单价 * 单位业务资源用量 / 资源利用率

其中,业务量由公司业态决定,是IT成本不可决策之基础,本模型不加考虑

技术抓手

提升资源效能的技术手段,主要有,

  • 降单价:多云议价,产品集采,硬件新品(如AMD机型、SSD云盘),高性价比资源(如环京IDC、本地盘、归档存储)
    • 硬件每年都有更新换代,及时Follow云厂商新品、控增量治存量很重要
  • 提升资源利用率:避免浪费,容量基线管控(如双云冗余)、弹性扩缩(如ServerLess),调度策略优化,在离线混部、潮汐算力利用,程序优化
  • 降单位业务资源用量:降业务效果(如降低拍搜识别率、降低直播码率、降低数据时效性、缩短数据存储时长),合理外采(如自建RTC切TRTC)

组织保障

任何项目都需要组织保障,组织保障也是多方面的。这里主要有,

  • 组织机制:招标采购、商业谈判,成本委员会、业务纵向组织,平台支持定价结算(在合乎逻辑的情况下定价结算模型越简单越好)
  • 加强运营:财务核算(止损),预算目标管理,常态运营、定期扫除

注意事项

  • 找准方式,明确哪些是运维擅长的
  • 数据驱动,决策要有清晰的数据模型
  • 做大ROI,抓大放小
  • 既要整存量、又要控增量,整存量要沉淀为运营能力、控增量要沉淀为平台能力

大部分成员会把成本优化当做政治任务,只追求做到预算达标,一些措施会被刻意保留下来、应对将来更繁重的优化目标。这种做法,对公司显然是不利的,这其中既有打工人聪明的狡黠、也有老板激励手段的不到位。

设计取舍

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

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

认知总结

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

  • 价值定位:老板系统、辅助决策,数据必须准确全面、报表只需全局视角
    • 数据是关键,数据不准则平台无价值、数据少则平台价值指数递减;报表是价值输出,匹配全局视角、避免贪多
  • 数据模型:成本数据支持多版本,做到元数据可修改、结果可重算(支持指定范围);数据时效性取决于原始数据,不取决于计算任务,接近数仓
    • 新Feature引发数据回溯是一个常态
  • 数据校准:数据校准有两个途径,即两个独立计算的系统做数据对比(逻辑维度)、同一系统做两个周期的增量分析(时间维度)
  • 工程范式:发现问题 -> 分析问题 -> 抽象模型 -> 度量指标 -> 建设目标 -> 关键路径 -> 组织保障,组织保障很重要
  • 对成本管理平台自身的一些认识,
    • 内部云平台:成本分摊更进一步就是二级云服务提供商CSP,对公司内部来说,技术人员只需要知道内部云平台、不需知道背后的一级商
    • 云服务选型:计费方式是否足够简单,也应该做为云服务选型的条件
    • 独立计费:费用总值通常取决于三要素,用量、单价、计费模式;将计费模式归一化后,独立计费就可以蜕化为用量、单价的对比,大大简化对账逻辑、不用再follow和打平多云厂商的计费模式


Prev     Next