多云资产成本度量平台

导读

本文主要介绍CH的多云资产成本度量平台,要点包括:平台架构、成本分摊、预算管理、成本优化、知识总结等。

多云资产中的资产,主要指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)。

报表

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

page.png

报表主要用于辅助决策,严格遵循Boss Trigger。

成本优化

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

page.png

成本模型

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

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

技术抓手

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

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

组织保障

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

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

注意事项

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

认知总结

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

  • 价值定位:老板系统、辅助决策,要求数据准确全面、报表灵活多样
    • 数据是关键,数据不准则平台无价值、数据少则平台价值指数递减;报表是价值输出,匹配老板视角
  • 数据模型:成本数据支持多版本,做到元数据可修改、结果可重算(支持指定范围);数据时效性取决于原始数据,不取决于计算任务,接近数仓
  • 数据校准:数据校准有两个途径,即两个独立计算的系统做数据对比(逻辑维度)、同一系统做两个周期的增量分析(时间维度)
  • 工程范式:发现问题 -> 分析问题 -> 抽象模型 -> 度量指标 -> 建设目标 -> 关键路径 -> 组织保障,组织保障很重要
  • 内部云平台:成本分摊更进一步就是二级云服务提供商CSP,对公司内部来说,技术人员只需要知道内部云平台、不需知道背后的一级商


Prev     Next