万字解读B站FinOps落地经验与方法论...

云成本优化（FinOps）一词，变得越来越流行。

尽管FinOps在国内提及不多，但早在2020年12月，中国信通院就牵头成立FinOps产业推进方阵，推进规模化实践。而在那些率先拥抱云原生的互联网大厂内部，云成本优化的种子也早就生根萌芽，形成了最佳实践方法论，如阿里集团、腾讯、字节跳动、B站等。FinOps的出现，让大厂们的成本优化经验得到了更体系化的表达。

8月29日，优维「UGeek大咖说」的直播间，邀请到了中国信通院云大所业务主管尚梦宸和B站技术专家叶翠，为大家带来了一场精彩的技术盛宴，分享了FinOps资源运营标准及B站在FinOps上成功落地的经验与方法论，非常具有借鉴意义。

下面，跟着鹿小U一起来回顾本期精彩内容。

直 播 回 顾

PART2：突破成本困局：B站FinOps经验与案例分享-叶翠

本期「UGeek大咖说」的主讲嘉宾是来自哔哩哔哩B站的技术专家叶翠，重点分享了B站在推进FinOps落地和技术降本上的思路及方法论。

>> 为什么要降本增效？

实际上外部就是云计算市场在持续的增长，云原生部署也在持续的增高，但是云上的成本浪费也是比较严重的，成本管理是一个比较大的挑战。

那对于B站来说，作为一个视频的网站，IT成本在逐年的增长，2022年我们公司的目标，是要做到收支平衡，为了业务的一个可持续的发展，需要综合考虑之后再去做一些业务的决策，所以降本增效势在必行。

外部：云计算市场在持续增长

根据Gartner的这个报告，全球最终用户公有云支出2022年达4903亿美金，预计2023年有20.7%增长。Flexera 2022年云计算市场发展报告指出，32%的云上支出被浪费。

那对于B站来说，我们面临到的IT的成本的挑战，主要是来自于三个方面，第一部分是多活的建设，多活稳定性的建设，需要多点部署，就会带来资源的一些冗余。第二部分就是业务的增长，业务的持续的增长会带来资源需求的增加。第三部分就是新增的一些项目，例如今年很流行的大模型，AI GC等等新的项目也会带来新的资源的投入。

这边列了一个B站刚发布的23年二季度的一个财报，然后我们的业务增长的实际上是这样的一个情况，特别是我们的整体播放量还在以同比30%的增速在增长。那我们在22年初提出了一个目标，就是全年的IT成本的支出不能超过上一个财年。这意思也就是说，我们要面临着业务增长的压力。

业务增长，但是成本不增长。为了能够达到目标，B站才开始推进FinOps落地的方向。

以前的成本控制：以预算为中心

原来B站的成本管理是什么样的模式呢？就是以前的成本控制是以预算为中心的。

年初，我们会定好一版预算，定预算的同时，也会定好优化的项目以及项目具体的目标是什么。在年中的时候，就会去推一些优化项目的落地，这些项目基本上都是预算规划内的项目，会定期的去review这些预算的目标是不是达成，以及如果业务有采购需求的时候，会以预算为一个白名单来看，如果有需求了，在预算里面只要有预算就可以去采购。到年底的时候，会做一个总结，除了总结成本优化的收益和不足以外，也会为整个下一个财年的预算去做一个数据分析，然后以预算为控制，以预算为中心的这个降本，实际上是比较难做成本控制的。

预算的整体逻辑

B站整体的预算逻辑是这样的，就是IT的成本管理主要针对预算的管理，每个财年开始的时候完成整个财年的预算编制。在编制的这个过程中，我们会把业务的目标转化成成本。

首先业务会提出他来年的这个DAU、MAU以及播放、投稿数量、主播数等等的目标。技术会将这些业务目标转化成技术的资源需求，在转化成制约需求的过程中，会结合技术的优化方案，这样的话就会定下来降本的目标，业务目标，业务增长的目标，再加上降本的目标。最后就可以知道我们整体的这个成本预算是个什么样子的，预算定好了，那降本目标也就定好了。其中这个预算里面最核心的就是中间北极星指标单位成本的CostDown，对视频内播放来说，它可以是单VV的成本。那对于直播业务来说，它可以是单PCU的成本。

那预算定好以后是不是就按部就班的执行就好了，这中间也暴露出来了几个问题。

预算控制的问题

• 第一个问题是预算的过程中，技术中台参与不够，业务是直接把它的业务表转化成了资源需求，直接提交给了资源运营的负责人。这样的话，技术中台实际上是最后一个被告知资源需求的。

• 第二个问题是在老的这样的一个管理模式下，预算内的需求就变成了白名单，只要它是这个预算内的，就会直接pass掉业务提的采购需求一路通过，预算控制的力度就不够，很容易造成浪费。

• 第三个问题是缺乏业务视角的权益，账单业务对成本没有感知，预算外优化的动力就不足，基本上也就是做年初我们规划的那些优化项目成本控制，也就很难超预期，甚至还有可能不达预期。其中最重要的就是最后一个问题，就是业务对资源效率和成本没有感知，那么降本的收益也就难以评估，那业务去配合一起去做降本的动力就会不足。

综合以上这三个问题，发现实际上难以在预算制定的阶段就规划出一个能达到前面提到的目标。实际上，我们不管怎么样去删减，怎么样去PK，怎么样去沟通，这个预算都难以控制在上一个财年的实际花费之下。但是既然降本的目标已经下达了，那这个行动就是一定要落实的。

在22年年初的时候，我们就引入了FinOps的理念。同时，我们也和多家公有云厂商进行了交流和学习云财务管理规范的文化和实践。

FinOps框架（finops.org)

这里列了FinOps框架的几个方面。从原则上来说，FinOps强调团队协作，强调目标和责任驱动，以及集中化的一些成本决策，监控分析和定时的成本报告等等，那参与FinOps的角色也很多，有FinOps的实践者，企业高管，业务的owner，财务和采购，以及技术和运维团队。FinOps的生命周期为三个阶段：成本洞察、成本优化和成本运营。

B站FinOps的组织协同

基础架构部的资源运营团队，承担了FinOps实践者的角色，作为FinOps的核心，我们的主要工作：

• 一是成本感知，让各个业务能够了解它的成本配额，也就是预算成本，以及做成本分摊和成本分析，以及展示成本是什么样子。

• 二是资源优化，在资源的优化里面，我们着重要看资源利用率和效率，资源使用量的优化，计费策略的优化，异常的管理，还有一些决策和调度。

• 三是最组织的协同，我们会推动技术优化的落地，并且跟踪每一笔预算的执行。原来以白名单形式去执行的预算，现在变成黑名单的形式，也就是每一笔预算都要经过我们的审核，每一笔预算在执行的过程中，都需要去基于当下的情况去做，有去做这个review和决策，所以我们会参与到这个成本的决策中，实现集中化的一个成本的管理。

B站FinOps实践路径

从上图来看，在最下面的是数据支撑，就是我们不能再摸着石头过河。数据支撑分两类，一类是资源的数据，一类是成本的数据，所以有一个资源管理的平台，还有一个成本管理的平台。那在最上面的是资源生命周期的管理，资源运营，它主要面对的是资源的管理，从预算的规划到资源的预测到执行到交付到最后运行，优化以及计费和拆账，整个的过程中我们都会参与。

整个资源的生命周期的管理，我们分为事前计划，事中控制和事后分析，并且会有多项举措。

• 在事前计划的过程中，我们关心需求的核心驱动是什么，架构方案合不合理，成本应该如何去测算。

• 在事中控制，我们关心的是资源的交付效率，资源使用率以及资源效能。

• 事后分析，我们会关注业务账单，竞品分析和一些运营效果的分析。所以围绕着整个资源生命周期的管理，以底下的数据洞察为基础，中间我们会穿插着技术降本和运营降本。

接下来，从这三个方面去着重的介绍。

第一个是数据洞察。处于洞察方面，我们会侧重两类的数据：一类是资源，一类是成本。我们基于内部的平台和资源整合了监控系统，资产管理系统还有混内部的混合云系统，CMDB等基础数据，我们为了快速的上线，基于数据平台的数仓的能力，快速的搭建了资源的数仓数据看板和资源报警，基于资源效能的历史数据，然后来支持业务的一些资源的预估协助业务制定一些降本的目标，评估业务降本的优化的收益。

第一站的成本大头实际上是带宽和服务器，我们设立了带宽资源和计算资源的利用率相关的指标，并且在全公司推进统一的标准。带宽资源覆盖了各类CDN的带宽云，上面的带宽和IDC的带宽计算资源，我们覆盖了自有服务器，云虚拟机租赁的裸金属服务器等等资源。

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

那成本账单这块儿，我们有一套自研的资源成本平台，支持基于某一个产品或者是某一个部门的维度进行查账和对账。还有另外一套系统是云资的系统，这个是采购阿里的一套云资平台去做管理。

那成本洞察这块儿，我们在资源效能的模型上来说，我们参考了百度抽象出来的这一套资源效能的模型，这个效能是总成本除以总收益，也就类似于这种机房的PUE，它实际上是越低越好。如果这个数据越高，就说明资源的损耗是越大的。那资源效能，等于TCO除以资源量，最左边的这一块，实际上除下来就是它的单价。单位资源的成本，中间就是理论资源量和可售卖的，已经售卖的和已使用的资源量的一些评估，就能够看出我们资源运营的一些效率。最右边，就是业务关注的已经使用的这些资源量，然后怎么样去转化成业务的一些revenue。

成本洞察：资源效能模型示例

成本洞察可以举一个例子，例如说容器平台的这个例子，容器平台它的整个的水位线就是整体的资源，就是它理论的资源量，它是可售卖的资源，平台通过虚拟化的技术，最终可以售卖的。已经售卖的资源量是已经分配给用户的资源量，那么它已使用的资源量是它分配给用户的资源中用户实际使用的那部分的资源量。我们给公司内的各类的技术中台建立了效能模型，不同平台的模型是不一样的。

数据洞察成本账单

成本数据这块儿，主要核心一点就是让业务能够知道它的成本情况，然后给业务出账单。就是业务之前，业务如果想知道自己的这个成本数据很长一段时间的业务可能只是有一个预算的大概数字，它其实并不了解这个细节，也自然就不会重视这个成本优化。没有了量化分析的基础，就很难明确优化的目标和方向。所以为了更好的衡量技术成本，把每一笔IT资源的采购成本折算到每个业务，甚至是每一次的活动里面，让业务线能清楚的知道钱花到哪里去了。我们做了三件事情：

第一个是资源归属。所有的资源都归属到产品，例如说直播的产品或者是电商的产品。每个产品会归属到对应的部门和团队，并且有负责人。在这个基础上，我们会给公司所有的成本出账，并且能够支持对账。这里的挑战，就是公司的组织架构调整后，这些资源归属也需要对应的去做些调整，有的时候就是简单的组织架构调整实际上是很容易去做资源归属调整的，但是如果是把一个业务它分拆开来的话，那么这个资源归属的调整就会比较麻烦。

第二个是资源映射。左边的服务数，实际上就是我们公司内的CMDB，然后这个数据里面维护我们所有的APP的ID，那我们的账单就可以出到这个，通过这个映射可以出到这个应用力度。右边，工作空间，是我们大数据的一个维度，大数据相关的账单，去映射到工作空间。我们面临到的挑战就是个人使用的资源是很难映射的，这块需要人工的一些维护。

第三个是定价策略，我们把Campex就是资本性的支出会转化成Opex，也叫运营支出。硬件这块，会统一按照会计科目折旧，去计算出来服务器每个月的TCO，我们会以统一的标准去计算出来，最后基于各个平台它提供出来的一些SKU，去做一些定价。整体的定价的策略，是把平台的整体成本算出来，然后去除以平台可售卖的资源，这中间就含了平台的一些资源利用率，那资源效能的数据，也会在这里有所体现。最后算出来的这个单价我们会去评估，用来评估我们的私有云平台和公有云平台，如果是有类似的这样的一些竞品的话，我们会看是内部的私有云平台，能否做到像公有云平台这样的一些成本上的竞争力。在这样的模式下面，能够很好的去联动业务和中台。

成本洞察：联动业务和中台

我们引入了财务中的两个概念，Campex对应到的就是预算的现金流口径，指的是实际支出的金额，而Opex对应到的就是硬件，一般是固定资产，那我们的计算方式是小于和财务对齐，小于5000元以下的就不算固定资产，5000以上的才算把它的一次性支出会按照36个月去做折旧。对于非硬件类的，那Campex和Opex实际上没有很大的区别。

技术中台关注Campex，然后去控制我们实际支出的金额。业务研发关注Opex。然后对于这个用量去负责，更多的这个业务方，他看到账单以后，他会愿意选择收费更低的共享类的资源、那服务器，就是我们自由采购的服务器或者云主机，这些资源，原来从归属给业务方，逐渐的会转向归属给技术中台，这样就使得技术中台能够承担更多的容量管理的工作，原本在公司采购服务器的流程里面，会是业务去评估需求，转化成机器数量，然后再提采购，然后中台去做交付，中台不会过多的参与到机器的资源的评估业务，基本上是需要买多少服务器就买多少。现在，整个流程就会改进成业务去评估需求，然后转化成中台对中台的需求，中台会去评估它全局的这个算力的缺口，基于它实际的这个容量，去按区去提出采购中台，它会收集各个业务的需求，再结合自身存量的资源再去评估。

所以，中台拥有了资源之后，他就可以去出具账单，然后业务不对资源负责，他只负责核对这些账单。中台可以去优化它的单价，主要从这几个方面，例如说架构升级优化，提升资源效能，使用廉价的资源，然后也要能支持多供应商的切换，能够找到更便宜的资源。那业务方面，主要需要做的事情就是，业务逻辑的优化，业务策略的优化，例如对于业务来说，它是不是真的需要这么高的清晰度，或者是它的数据，真的是不是要存这么长时间以及应用服务治理一些规范化能够上平台的东西尽量上平台。然后数据生命周期的管理，那账单生成好了，业务也去旅六账单，这中间会有一个问题，就是对于账单的这个对账和确认，一开始其实并不是那么顺畅的业务，刚开始收到一份账单是很难看懂，需要资源运营的同学去翻译一下，因为业务它是业务视角，而账单是一个资源视角，一个业务或者是一个功能，对应到哪些资源上面都需要有解释和说明。整个账单的对账都是在我们自研的一套成本系统里面去闭环实现。业务每个月，业务负责人在收到系统推送的账单以后，他需要去完成对账review，如果他对账单的细节有疑问，他是可以在系统里面去标注，然后由出账的平台再去修正账单。通过这一套出账系统，我们就实现了这样一个闭环，就是平台出账到业务对账到账单分析，再到最后针对性优化，然后优化效果可以反映到下一个周期的账单里面。

这样的一套闭环的过程中，我们也会强化成本责任制，为后续的成本优化去打好基础。

>> 成本优化

接下来就会介绍一下成本优化相关的工作。成本账单也有了效能的，大盘也有了，接下来该在哪些方向上去推进成本优化呢？

首先，我们来看一下成本数据。B站的主要业务是点播，直播，电商，游戏等等。作为一个以视频为主的网站，B站每年的IT成本花费中带宽是最大的，其次是硬件，最后是共有云和其他IT服务类的成本。那想要做到成本优化的收益最大化，想要达成我们刚开始分享的时候说到的这个业务增长，但是成本不增长的目标，那么我们实际上在各类成本资源项上都需要去投入优化。

成本优化：各类资源多管齐下

从业务的角度上来看，不同的资源需求，实际上是有着不同的成本模型。而从资源的角度上来看，不同的计费方式也有着不同的优化思路。所以我们需要多管齐下。B站是一个拥有自有IDC和公有云共存的混合云架构。从云资源的分类上来说，我们是可以分为公有云和私有云。这里，从业务的分层角度来说，对应到现在在用到的一些资源。当然了，这里只是一些简单的罗列，实际上远比这还要多和复杂。

从客户端来看，我们用到了很多的SDK。接入层，我们用到了CDN，加速产品等等，还有防空机。SaaS层，我们用到了一些就是云测，这个云上面的一些其他的SaaS类的服务。然后PaaS层面，就是一些日志服务负载，均衡缓存消息队列等等。IaaS层，主要是一些云主机，裸金属服务器，存储等等。最底层的是自建的IDC，会有服务器，机房，网络设备，负载均衡，以及一些商业存储防火墙，专线或者是裸签。

那这些资源的成本优化，主要做些什么呢？这里大概列了一下我们的优化项目，实际上我们这里面的每一个项目，都能拿出来做一个专题来分享，基本上每个项目都会有不同的团队去负责推进。

成本优化：技术降本项目

带宽

• 点播：窄带高清转码系统，VAI编码，廉价带宽，冷内容聚边调度，CDN专线回源等。

• 直播：去中心化，边缘计算性能优化，冷热流分层调度，回源协议合并，视频编解码优化。

服务器

• 硬件配置优化，CPU升级换代，GPU替代CPU，国产vGPU，硬件加配。

• PaaS统一合池，VPA，HPA，在线<->离线混部，潮汐混部，GPU混部，存算分离。

云服务

• 和云厂商合作共赢，云上机型优化，混合云（自由机房+公有云）

• SaaS服务替换为IaaS+自研

• 动态BGP=>静态BGP，BGP=>单线

以上就是B站在带宽、服务器、云服务等方面做的优化，技术降本在基础设施层面还做了网络的一些升级，机柜的优化，短信，SDK等等。应用层面还会做业务的素材统一模板，然后缓存的策略预分发带宽错峰，hp压缩等等这一系列的优化。基本上就是能看到的优化点都会推进业务去做，这就是整体的一些技术优化。

>> 运营优化

运营优化主要是两块，一块是成本的运营，一块是资源的运营。

成本运营就是对于技术方案，我们会先考虑成本，选择成本更优的方案去做推进，提前准备好资源规划。实际上很多时候，就是在以前不关注成本的时候，就凡是能用钱解决的问题，都不是问题的时代就过去了，那么我们其实会更倾向于说让业务提前做好这些预测和准备，因为一般如果说业务一紧急的时候来找我们要资源的话，那么实际上这个时候是用用成本来换时间。

资源会根据业务需求，我们会推荐给业务最适合的资源，关注业务的整个资源生命周期的管理，特别是这个业务经常会遗漏的，就是资源的清退。常量的资源，更多的会倾向于在IDC，像峰值的资源，或者是经常会有这个容量变换的资源，例如说像游戏。会更适合在云上。

成本运营：事前事中事后全面管控

• 事前，我们会做成本预测，监控业务情况和预测资源成本，掌握成本波动的情况，然后做成本核算，在项目初期，根据成本模型去选择成本追究的方案。

• 事中，我们会做预算控制，就是为了极致的降本，再根据实际情况，会review并且调整预算执行，实际执行的一些内容。

• 事后，会做成本的分析，会明确成本升或者降的原因，每个月会定期的去review，并且出具成本分析报告，给出各个业务成本优化的建议，并且我们还会做账单的解读，然后帮助业务去理解账单，从业务角度出发为降本去提供依据。

整体上，我们其实上做成本运营的目标是希望：一浪费可感知；二降本需要是很便捷的，知道浪费，还要知道如何优化；三是过程可跟踪；四是设立奖惩奖惩机制，然后激发业务能够去主动的自主的去降本。

其实，成本、效率和稳定性方面，这三块是不可兼得的，这是一个不可能的三角形。所以我们努力在这个成本，也就是利用率，稳定性，用户体验，还有效率，就是我们迭代速度之间需要去寻求平衡。我们要不要限制变更来寻求稳定性，那如果业务的首位跑高了，是不是稳定性就没有？是不是这个稳定性就没有提升空间了？那我们的资源的这个水位上了以后，是不是一定会对稳定性会带来威胁等等，都是会挑战业务，然后在这里面会去寻求一些平衡的点。那便宜的资源实际上都是不稳定的，不稳定的资源，需要更多的运维和更多的上层应用的高可用的一些保证，没有完美的资源配置，只有最适合当下的方案，对于一个具体的业务来说，成本其实并不是全部，那业务它还面临着其他的稳定性和业务压力，然后它的人也是有限的。所以需要从更大的一些视角去进行取舍，所以并不是推进这些降本的动作，或者是去追求成本，还是追求稳性，还是追求效率，实际上我们会跟着业务一起商量去选择，并不是在每次的取舍中都会去选择成本。

资源运营：资源的全生命周期管理

前面提到过资源，我们要做全生命周期的管理，那么公有云的云主机，我们会结合利用率监控，混合利用我们的混合云平台以及供应商的账单数据，我们会去看其中不合理的一些冗余的用量，以及不再使用的资源要及时的去推进。比如，我们在实际做分析资源的过程中，发现实际上就是因为以前的平台或者是系统的不完善，有很多的业务，它清退了云主机以后，也并没有清退负债均衡实例。那么这些实例，在线上残存了上万个负债均衡的实例，而每个实例，实际上也都是要收费的，这就是一个很典型的就是业务没有及时清退和缩容的一个例子。

那对于云服务，我们会做一些资源巡检，如果发现没有人认领或者是没有清退完全的资源，例如闲置，没有挂载，但是仍然在计费的云硬盘，还有一些历史悠久的快照等等，我们会定期公示出来，并且去联系业务，然后一起去做推进清退的一些动作，还有就是IDC的服务器，对于一些利用率极低的服务器，我们会把它纳入到容器的资源池里面去，尽量的去让它做容器化并且接入混部。

最后总结一下，就是通过落地的这个闭环数据洞察资源优化和成本优化和运营优化，最终我们能够达成在业务增长的情况下，成本不增长。22年的时候是业务增长达成了，成本不增长，甚至还做的更好。

PART3：Q&A

Q1:有没有好的开源工具，支持国内的云厂商的成本可视化。

叶翠：这块就是我了解到的是一些大的云厂都会提供一些FinOps的工具，一般会集成在账单中心里面。那B站，我们自己实际上是一套自研的成本系统，然后外加阿里云提供的一套云资系统，这套云资系统它会去兼容到各家云，然后所有云上成本在这套云资系统里面，自研的这套系统会结合到云上的成本和我们自建的Idc的一些成本。所以目前是没有看到，开源的一些产品。

尚梦宸: 我们也讨论过这块，确实相关开源工具是比较少的，可能更多的，就像咱们这种，是自以为主。在国内来看开源工具也是比较少的，可能更多就是我们自己去建一些这种，根据我们自己企业一些情况去做一些资源的管理工具，然后去适应我们自己的企业内部的一些情况。

Q2：如何预测带来的这个收益？

叶翠：我们的成本实际上等于单价乘以用量，所以收益来自于两个方面，一个就是单价的降低，另外一个就是用量的降低。那单价的降低，可能是采购谈判更低的折扣，或者是切换到更适合的一些计费方式，或者是切换了根据性价比的这种产品。那用量的降低，主要就是资源利用率的提升，或者是资源的混部复用以及资源的及时清退，其实就是我们在预测收益的时候，就是从这两个因素去考虑，基本上就能够计算出来。当然了，这个并不一定是完全准确的，因为实际上我们的这些收益也夹杂着业务的持续波动，那我觉得大家在做收益预测的时候，需要将项目的时间风险考虑进去，就是不要满打满算，给自己留一点余地。

尚梦宸: 我想补充一点，就是从建设来说的话，叶老师说的可能就是一些具体的。从技术角度或者说从我们管理角度去做一些实践的一些方式，那我想就说的一点就是可能没有提到的，就是这个理念的这个事儿，因为就是说它其实一方面是说我们从技术手段怎么去管理我们的资源呢，其实还有一方面就是说怎么把FinOps的理念文化去传递给我们刚刚提到的这三类人员，包括管理人员，财务人员以及我们的业务人员。把这个理念如果给大家去贯彻到以后，比如从业务人员角度出发，那他可能再去做需求的时候，可能就需要考虑，实现这个需求可能需要多少资源，这个资源可需要花费到多少的成本，怎么去把理念贯彻到的不同人员，让他理解这个事的意义，在日常工作中，就会把这个理念就是潜移默化的，带到工作中来，从而更好的去帮助企业降低成本。

Q3：如何设计可信的成本模型体系？

叶翠：从我的观念来看，设计一个可信的成本模型，它的前提基础是你对业务需求的理解，对业务技术架构方案的了解，以及你对底层资源的了解，就是在这个基础之上，你可以基于你的技术方案确定你需要的一些资源的类型，然后你可以基于你的压测的数据，或者是历史的一些容量数据，去确定你需要的资源数量，这样就能形成一个资源清单，然后补充单价，这样就完成了整个的这样一个成本的模型。其实可信的关键点觉得，一是技术方案的可行性，需要有验证或者是灰度的这样的一个过程，二是资源清单里面不要有遗漏，这块儿实际上是可以基于就是你对业务了解，或者是对历史账单的分析去做一些查缺补漏。我们曾经就遇到过，一个项目因为它里面遗漏了某一类的某一个资源的一个计算，然后导致这个项目本来应该是一个cos大的项目，最后实际上使得这个优化的效果大打折扣，因为最后有一类资源，实际上支出还是比较大。所以，实际上是可以代入历史的一些数据，做一下验证，这样的话，能够让你整个成本模型会更加的靠谱一些。

Q4：实际成本治理未达成目标的过程中，最难的是什么？

叶翠： 就以我的经验最难的实际上是推动业务的配合，因为业务它是有自己的业务目标的，它的业务目标很可能跟你的一样，那怎么样去推动业务去配合你优化，然后协调到对应的人，以及在业务的策略上怎么样能够让他考虑到这些。众所周知，B站是一个不赚钱的这样的一个还在处于亏损的业务，且B站的这些主站的这些业务，实际上既然不挣钱，也就很难去衡量。

Q5：对账之后不是会导致账单波动吗？这个事怎么解决？

叶翠：对账之后导致账单波动，对账基本上就是一个账期结束了以后才会对账，基本上不会有波动，但是会对于这个账期，我们一般是一个月对这个账期的里面的资源的这种情况，就是会看看数据核对是不是真实的，是不是实际的资源情况。如果说业务有质疑的话，那么大家去进行协商，最后去修改这个账单，所以对账的过程，实际上就是账单的review和确认的过程。

Q6：应用及数据自然增加(大数据，数据库用量自然增加)业务没增成本增加如何解决?

叶翠：业务的用户没增长，它的场景可能会变复杂了，或者是说它的这个策略上面，有一些其他可以优化的地方，那么导致它整体的这个数据量增长，所以像大数据这块儿，公司也可以看到我们公众号里面分享的文章，我们公司是有一个书委会这样的一个组织，书委会会专门推各个业务去做优化。书委会会从最底层的就是数据存储，一直到上面的这个数据，根据数据，它被读取访问的一些频率，推动大家去做一些优化。