节省数亿IT成本，B站FinOps优化实践

叶翠, 马永智 2024-02-19 09:54:30

作者介绍

叶翠，哔哩哔哩技术专家；

马永智，哔哩哔哩高级运维工程师。

一、背景

当前，降本增效是各大互联网公司的重要方向，IT成本则占据了互联网公司成本的大头。如何有效的降本？如何推动各业务线配合？如何平衡成本、质量和效率？本文将介绍B站的IT成本管理和优化的思路，介绍B站通过落地FinOps，推进成本洞察、技术优化和运营优化，提升资源效率的经验。2022年，在B站DAU稳步增长的情况下，IT成本花费金额低于21年同期，为公司节省了数亿成本。项目团队也获得了公司2022年度技术突出贡献奖。

二、历史

IT的成本管理主要是针对预算的管理，每财年开始的时候完成整个财年的预算编制。在预算编制的过程中，将业务目标转化为成本，结合技术优化方案，定下来降本目标。业务增长目标加上降本目标得出成本目标。

预算定好了，降本目标也定好了，那是不是按部就班的执行就好了？这中间暴露出来几个问题：

预算过程中技术中台参与不够，业务直接提预算，技术中台最后被告知资源需求。

预算内的需求变成白名单，采购流程时直接pass，预算控制力度不够，容易造成浪费。

缺乏业务视角的全域账单，业务对成本无感知，预算外的优化动力不足，成本控制很难超预期，甚至可能不达预期。

其中最重要的是最后一个问题，业务对资源效率和成本无感知，那么降本的收益也就难以评估，业务的降本动力就会不足。

三、效能大盘——感知资源利用率

既然降本目标已经下达，行动就迫在眉睫。

一开始我们延续传统思路，提到降本增效，第一反应就是各类资源利用率。与所有互联网公司的敏捷性相同，我们基于内部的平台和资源，整合监控系统、资产管理系统、混合云HCRM系统等基础数据，使用数据平台的数仓能力，快速搭建了资源数仓、数据看板与告警机制。基于历史数据，希望支持业务资源预估和制定降本目标等活动。

根据B站的成本占比数据，我们重点设立了核心关注的是带宽资源和计算资源的利用率相关指标。

带宽资源涵盖各类CDN带宽、云带宽和IDC带宽；

计算资源则涵盖自有服务器、云虚拟机、租赁裸金属服务器等资源。

当前我们已经实现，针对对不同供应商，将同类资源的不同指标进行归一化，例如多云场景下不同云厂商的指标对齐。对于GPU这类资源，还会考量训练、推理等不同场景下的利用率等。

为了更好的联动其他团队，我们还给公司内各类技术中台建立效能模型，注重计算、存储等各类平台模型都有不同，以容器平台为例：

关注以上指标，可有效评估容器平台的资源效能，支持平台做资源水位线管理，度量使用效率和技术优化空间。

经过一段时间的实践，尽管拉着资源使用者聊利用率、巡检各部门空闲机器、甚至定期制作各类排名榜单，我们还是发现降本工作推进缓慢。技术中台与业务部门间难以联动、研发人员缺乏成本意识、无法量化降本产出等核心问题依旧难以解决。

那段时间，碰上行业内越来越多公司开始重视降本增效，在与其他公司的相关从业者多次交流讨论后，一个概念逐渐出现到我们眼前——FinOps（Financial Operations）。

四、FinOps概念——确定行动步骤

按照FinOps Foundation给出的定义，FinOps是一种不断发展的云财务管理规范和文化实践，通过帮助工程、财务、技术和业务团队，基于数据驱动，在支出决策上展开合作，使得组织能够获取最大的业务价值。

当前云原生成为技术选型的共识，B站内部平台和系统也大多选择了云原生的道路。B站的云原生是搭建在私有云、公有云的多云环境上的，其中私有云底层资源为租赁IDC和自有服务器资产。FinOps的整个框架不仅适用于公有云上的资源和成本管理，也同样适用于私有云，整体的工作思路和逻辑是一致的。

从上面FinOps Framework可以看到，参与Finops的角色很多：

企业高管
业务负责人
工程和运维团队
财务和采购
FinOps实践者

做为FinOps实践者，需要联合业务、平台、运维、基础工程、财务和采购团队一起，对IT成本进行有效管理和优化。

FinOps的生命周期分为三个阶段：

成本洞察
成本优化
成本运营

在反复研究相关理论后，我们定下了B站基于FinOps视角下降本的实验路径：

成本量化打基础，通过账单提升业务对成本的感知。

技术降本和运营降本“双驾马车”并行推进。

通过事前计划、事中控制、事后分析多项举措，将成本的指标纳入业务方案和商务采购的考量，成本控制贯穿在整个资源生命周期的管理。

五、引入财务视角——洞察技术成本

所有技术需求的开展都离不开其底层资源，而各类IT资源的成本，需要纳入财务对各业务线的ROI考核中。但在之前很长一段时间内，业务线可能只有一个预算的大概数字，并不了解细节，自然也不能引起重视。也就没有量化分析的基础，很难明确优化的目标和方向。

为了更好的衡量技术成本，将每一笔IT资源的采购成本，折算到每个业务甚至每次活动中，为了让每个业务线都能清楚钱花到哪里去了，了解其IT成本及具体构，我们首先引入财务中的两个概念。

1、CAPEX和OPEX

CAPEX（Capital Expenditure，即资本性支出）：对应预算现金流口径，指实际支出的金额。

OPEX（Operating Expense，即运营支出）：硬件一次性支出按照会计科目折旧计算，带宽服务类非一次性支出和CAPEX一致。

想要将CAPEX转化为OPEX，就需要计算TCO（Total Cost of Ownership），将采购硬件资产的一次性成本分摊到该资产的生命周期里。以一台服务器为例，直接采购成本即为CAPEX，将采购成本分摊到今后使用的每个月，再增加服务器每月配套使用的其他资源成本，即可得到TCO模型：

（1）其中Server_Tco-month为一台服务器每月的TCO金额。

（2）Depreciation为按照标准会计准则，单台机器的每月折旧金额。

（3）Net为租赁IDC中所有网络设备的每月折旧。

（4）Idc为当月IDC中发生的所有成本，含机柜、电力、维护等。

（5）Line为连接IDC间内网专线线路的每月费用。

（6）f_1是单台服务器分摊函数，以算出除折旧外，单台服务器的每月其他成本。

2、定价

B站的业务搭建在公有云和私有云上，想要各个业务了解成本，需要公有云和私有云都能计费和拆帐。将IT资源和对应的成本挂钩。技术中台想要和公有云一样具备计费、出账和对账的能力，则需要统一设计和升级。各技术中台需设计计费的SKU（即平台售卖的产品），定好价格策略，然后统计各业务的资源用量，最终实现向内部业务计费出账。

SKU设计时即考虑和公有云平台对齐，以便和公有云成本对比。又需要兼顾公司的实际业务场景需求。例如，容器平台的一种CPU产品定价模型如下：

（7）Cost_total是该类容器平台SKU对应自有服务器的总成本，n为该SKU对应的所有服务器。

（8）Price_cpu为CPU定价。

（9）Ratio_cpu为CPU成本系数，用于折算服务器中CPU关联的成本。

（10）Cpu_total是对应所有机器的总逻辑核数。

（11）loadfactor为利用率水位线，参考值为近期该SKU对应物理服务器的合理水位线。

（12）(Cpu_total*loadfactor)就为理论上的总服务量。

对于其他技术中台的SKU，基本适用以上“单价=SKU对应TCO/理论总服务量“的模式。由于技术中台没有盈利压力，账单只是为了合理的反应业务成本，推动业务提升使用资源的效率，所以平台资源利用率的提升让可售卖的资源更多了，降低了单个资源的单价，业务从成本上也能受益。

3、计费

成本=单价*用量。单价有了，接下来需要确定业务各SKU的计费用量了。我们大致将用量的统计方式分成了两类，共享与独占。还是以容器平台的上述SKU为例：

（13）t为资源使用时长。

（14）Usage_shared为共享类资源用量统计方式，Limit是该服务申请容器的CPU资源限制。

（15）Usage_exclusively为独占类资源用量统计方式，Capacity为该服务所在pool的所在物理资源上限，loadfactor为该资源利用使用率上限。

在实际计算中，即使A（独占类）、B（共享类）两个服务实际消耗的CPU相同，A的计费用量也会高于B的。因为A所在资源池就算无服务运行，其独占的特性也使其他服务无法调度进来，造成浪费。因此在成本量化上，按其资源池理论最大使用量进行收费。相对的，共享资源池内的空闲节点可调度其他服务，按服务实际申请容器的limit进行收费。

通过区分独占、共享用量统计逻辑，更多的业务方选择收费更低的共享类资源，服务器资源的归属逐渐从业务方，转向技术中台，这使得中台承担更多的容量管理工作。原本在公司采购服务器流程中：预估业务目标->转化机器数量->提出采购需求->中台交付资源，技术中台不会过多参与整机数量评估，业务需求采买多少服务器，中台最终就交付、托管多少台的服务。

而现在，整个流程改进为：预估业务目标->中台转化算力需求->评估全局算力缺口->提出采购需求。中台会收集各业务需求，再结合自身存量资源，提出缺口算力对应的采购需求，从而减少资源采买。

4、账单

“成本=单价*用量”，可以从折旧（Opex）的角度，客观反映出平台空闲与超卖情况，推动技术中台和业务协同优化，并量化成本收益。

技术中台：角色转变为对单价负责，通过提升资源利用率、技术架构升级，减少平台底层资源采买，多供应商的议价能力，降低各类SKU的单价，各优化项目可以明确的转化为成本收益，让技术中台的成本更具竞争力。

业务方：通过治理应用实例的数量/存储量、规模、使用时长、共享与独占方式切换，降低SKU的用量。

双方齐头并进，合作共赢，优化IT成本。

账单生成好了，下个主要问题是让业务负责人了解账单并Review成本，从而确定后续优化方向。账单的确认流程由统一的出账系统实现，具体成本分摊的规则、资源定价和出账的流程都在系统里定义。系统里还有各类资源IT成本模型，能够量化资源与成本关系，最终将每一种IT成本以统一的形式发送给业务方。

依托于出账系统，公有云和私有云成本都能在统一的账单里展示，业务查看账单就能知道完整的IT成本构成。每月各业务技术负责人在收到系统推送的账单后，需完成对账Review，并在系统中确认账单。如对账单细节有疑问可在系统中标注反馈，出账平台将修正账单。

这里其实包含了很多的沟通成本，业务刚开始收到一份账单，是很难看懂账单的，需要有人"翻译"一下。业务是业务视角，账单是资源视角，一个业务或者一个功能对应到哪些资源上，各类资源的含义都需要解释和说明。

对账中最困难的其实是“资源归属业务”的准确性问题。挑战来自公司组织架构的各种调整，业务和资源的不断变化，还有历史包袱，有些历史资源归属不清等等。

为确保归属的准确性，归属映射关系从服务树（CMDB）同步。每一个微服务应用都有自身的APPID（Application Identification）。出账系统通过APPID来进行应用的唯一定位与关联相关资源的项目、部门和负责人等信息。基于CMDB的APPID（服务/应用粒度）=>项目=>组织架构=>业务的关系，实现多维度的成本视角，应用视角，部门视角或者业务视角。

非服务树（CMDB）支持的资源，则通过各平台自身维护的归属映射，以实现多种方式的成本归属。例如大数据平台基于工作空间的归属关系。

与此同时，成本数据的实时性也影响到成本监测和优化分析的有效性。日级别或者更加实时的账单，能协助业务快速发现和定位成本问题，及时调整项目投入。提升实时性也是后续账单系统的迭代方向。

总结一下，整个流程就是：平台出账=>业务对账=>账单分析=>针对性优化=>优化效果反映到下一出账周期的资源对账，这样一套闭环流程。通过对账，将IT成本及时同步给Finops中各类干系人，强化成本责任制，为IT成本优化决策提供数据支撑。同时反映IT成本优化效果、预算执行情况等指标。

六、成本优化思路——实操经验总结

成本账单有了，效能大盘也有了，接下来该在哪些方向上推进成本优化呢？如何有效推进成本优化落地呢？

首先让我们来分析一下成本数据。B站的主要业务是点播、直播、电商、游戏等，做为一个以视频为主的网站，B站的每年IT成本花费中，带宽占比最大，其次是硬件，最后是公有云&其他IT服务类成本。想要做到成本优化的收益最大化，那么在各类成本资源项上都需要投入优化。

从业务角度看，不同的资源需求有着不同的成本模型。

从资源角度看，不同的计费方式有着不同的优化思路。

带宽计费：一般云厂商为日95月平均，也有月95，即每5分钟打点，取一个周期打点的95峰值。也有包端口的带宽计费方式。可以通过削峰填谷的方法优化成本。

机柜计费：月租为主，也有电柜分离的计算方式，通过机柜电力合适的配比优化成本。

服务器：一次性成本，通过维保增加从而减少摊销成本。通过提升CPU利用率减少硬件采购。

配件：通过改配，打破硬件的瓶颈，提升硬件性能，节省成本。

云服务：按照用量计费，不同云服务的计费方式差异大，弹性是最大的优势。对弹性需求高的业务适用，例如游戏。

1、带宽成本优化

带宽成本是成本的最大头，从使用角度可以分为点播带宽、直播带宽、Web带宽。其中Web带宽又细分为动态带宽和静态带宽。

点播带宽：点播业务使用的流媒体带宽。成本最高，优化投入最大。

直播带宽：直播业务使用的流媒体带宽。成本仅次于点播带宽，优化方向区别于点播。

Web动态带宽：动态接口使用的带宽，CDN回源率100%，不可缓存。

Web静态带宽：图片、js、apk等静态文件使用的带宽，可缓存。

（1）点播带宽成本模型

下面以点播带宽举例，点播带宽的成本模型如下：

点播带宽成本 = 平均单次播放带宽 * 点播播放次数 * 带宽单价。

平均单次播放带宽：是用来衡量单次播放的成本，这里的带宽计算的是95计费值，所以不完全等于码率，但是和码率趋势相同。码率低则单次播放带宽更低，码率的优化效果会体现在此指标上。编码团队通过窄带高清转码系统，AV1等技术方案优化15%的带宽。

点播播放次数：和业务发展相关，难以准确预测，如超预期增长，则整体IT成本会有不小的增加，有超预算的风险。

带宽单价：点播使用的带宽资源多样，既有云厂商提供的点播带宽，又有自建CDN带宽，还有PCDN、mCDN等廉价带宽。不同资源单价不一样，这些带宽的占比影响了点播的综合单价。

（2）点播带宽优化思路

从上述简化的模型分析可以分析出点播带宽的优化主要是思路是降低码率和降低单价，实际推进的优化项目主要如下：

通过窄带高清编码系统，上线并扩大AV1覆盖，进一步降低码率

基于机器学习做优化转码预测，提升优化码率的覆盖

优化视频播放的清晰度策略

提升廉价带宽PCDN、mCDN占比，降低带宽平均单价

自建CDN专线互联，降低回源成本

内容分层，冷的内容调度到聚边资源，降低回源带宽量

削峰填谷，和其他业务带宽共峰复用

除了点播带宽，上述的直播、Web动态、Web静态都同步推进优化，思路也是从成本模型数据分析出发，优化前核算成本，优化后验证收益。

2、服务器成本优化

服务器硬件优化不同于带宽，主要使用利用率来衡量优化效果，同时采用TCO或者Opex来核算和评估技改优化方案。

（1）服务器硬件迭代

英特尔CPU从Skylake => Cascadelake => Icelake =>Sapphire Rapids，每一代在功耗和单核性能上都有提升。

AMD CPU从Rome => Milan => Genoa，每一代工艺和性能上都有提升。

GPU从T4、V100、A10、A100到A800，工艺和性能也在变化。

网络的架构也从10Gbps，到25Gbps，再到100Gbps甚至200G。

硬件的迭代速度是飞速的，每一次的硬件迭代，也刷新了单位算力的成本的下限。既然新的硬件更有成本优势，那么应该尽量引导业务配合硬件升级，每个硬件代次的迭代成本优化效果都是非常显著的。

同时，硬件功耗的增长也是飞速的，机柜从3KW、4KW、8KW到10KW，机柜和电力成本优化的收益也会非常可观。在IDC的布局和选择上，可以选择更加廉价的资源，将接入的POP点和IDC解耦，以达到性能和成本的最优。

（2）服务器虚拟化和混部

基于K8S构建的私有云容器平台，是服务器成本优化的主力。平台也发表过多篇文章分享混部和VPA技术。让我们来整体看下优化思路，还记得前面讲的效能模型吗？容器平台的优化就是基于资源的效能模型。

提升容器总资源量：将服务器资源尽量都容器化，让更多的业务都搭建在容器之上，不止业务应用，其他的技术中台的应用也要尽量接入到容器平台中。

提升池化率（可售卖的资源量/总资源量）：提高池化率主要是在有限的资源上，尽量增加可售卖的资源量，让更多的资源都是通过统一的容器调度。

提升分配率（已售卖的资源量/可售卖的资源量）：不同分配率的资源池可以考虑合并，减少资源碎片和冗余。

提升利用率（使用资源量/已售卖的资源量）：利用率不足将造成资源的极度浪费，通过建立应用画像，利用超卖、VPA、HPA等有效手段，资源利用率得到大幅提升。

除了以上的手段，混部也是提升利用率的一大利器。利用不同业务的潮汐效应，分时复用资源。转码做为算力密集型业务，最早尝试混部。目前B站已经对离线-离线，在线-离线间进行了混部，也有相关的技术分享文章。

当前在推进的主要是AI场景下的混部，也就是推广搜业务的混部。AI业务不仅是计算密集型，访存带宽也非常高，会触达硬件瓶颈，造成雪崩效应，因此混部策略需要更加谨慎。

3、公有云成本优化

不同于服务器资源，公有云承担弹性保障、降低延迟、海外部署等用途。而公有云的成本优化，是为在支持业务正常发展的前提下，最大程度使用公有云资源即买即用的特性。

根据资源类型与其对应的计费方式，公有云上资源大致可分为网络流量、云服务器等IaaS资源、云上SaaS服务等资源。不同资源，需对症下药。

（1）根据业务特性适配资源

云上项目根据业务特性，会产生波形截然不同的网络流量，而云厂商提供的网络流量产品也根据特点还有不同的计费方式。需同时考虑此二者关系，才能做到网络成本最优。

常见的网络类产品计费模式有按带宽计费和按流量计费：

按带宽计费：适用于业务流量峰值在不同时间段分布平均，无明显的流量波动场景

按流量计费：适用于业务流量波动较大，有突发的场景。

除计费模式外，网络线路类型也有不同选择，例如动态BGP、静态BGP、三大运营商单线、公网或混合云专线等，会让成本有较大差异，同样需要根据业务的架构方案及成本模型进行选择。

对于带宽、运营商占比稳定、且技术方案可兜底单点故障的项目，优先使用三大运营商单线。

对于带宽波动大、三大运营商无法覆盖、海外部署或流量较小的项目，优先使用BGP。

而跨地域带宽较高、回源量大的项目则考虑使用混合云专线。

在此基础上还可考虑其他策略，例如将多个项目的网络流量放进一个共享带宽包，可实现带宽的共峰收益。

（2）预先规划与定期释放

IaaS类资源多以实例*使用时长的形式计费，因此可在申请阶段就控制新增资源量。大型项目的容量、实例组合和付费策略在申请时就要求有明确规划。

申请方提交资源需求后，FinOps各方会基于业务特点、成本等考虑，确定供应商、地域、资源型号等事宜。

（3）自研or公有云

通常情况下，公有云的SaaS类服务拥有快速部署、简易维护等优势，但相较自建乃至云上IaaS产品会有更高的定价。

同类自研产品在公司内私有云已投入大量前期成本，拥有较为成熟的技术积累和专业运维团队，在经过一定的标准化改造，可满足云上同类产品的功能需求。而对于自研暂无法替代或改造收益不高的产品，会通过调整使用场景、计费方式或寻找价格更优的同类产品替代。

随着B站自建机房节点与传输网络建设程度提升，后续更多云上项目可复用基础服务和基础设施，做到常量私有云+公有云混合部署，突发公有云弹性兜底，实现此类服务的混合云方案。基于上述执行办法的实践，B站的自研HTTPDNS域名解析、DSA动态加速等服务，已节省超过一半的成本。

4、小结

如下图，IT成本除了带宽、服务器、公有云，还有很多其他资源成本，各项成本FinOps都需要分析并推动优化。在分析和推进的过程中，形成了一套完整的成本模型。随着业务不断的发展，成本模型和优化方案也在不断进步。

七、运营优化——多方沟通协同

运营优化是围绕两个方面开展的：

成本运营，依托于预算、成本账单和成本模型，及时和各方同步成本情况和问题。

资源运营，依托于资源效能大盘数据，及时发现并制止资源浪费现象。

1、成本运营

预算控制：为了降本做到极致，达到成本最优，预算控制需要更加严格。预算实际执行采购的时间可能和预算规划时间已经间隔比较长了，内部和外部都发生了变化，需要及时根据变化进行调整，尽量减少金额。

决算分析：每月基于账单数据进行成本分析，将超预算或者其他有改进空间的成本项进行重点沟通，沟通范围为业务研发负责人、基础平台负责人、财务、采购等FinOps各角色。对超预算的风险进行预警，共同商议改进措施和策略。

账单分析：协助业务理解账单，从业务角度触发，分析单DAU成本，为业务降本提供指标和决策依据。

成本核算：对于技术改造的新方案或项目，构建成本模型，决策出成本改进的最优解。

成本决策：成本的模型搭建不难，难的是如何在追求成本更优的情况下，兼顾稳定性和效率。成本优化通常伴随着技术升级和技术改造，大量的人力投入会影响原来计划的迭代效率，系统升级也常常会带来不稳定因素。追求廉价资源的使用，也会影响系统的质量，需要系统设计上能考虑到容错和兜底策略。总的来说，如果没有强有力的管理层做成本决策，降本增效的效果将会大打折扣。