从上图来看，在最下面的是数据支撑，就是我们不能再摸着石头过河。数据支撑分两类，一类是资源的数据，一类是成本的数据，所以有一个资源管理的平台，还有一个成本管理的平台。那在最上面的是资源生命周期的管理，资源运营，它主要面对的是资源的管理，从预算的规划到资源的预测到执行到交付到最后运行，优化以及计费和拆账，整个的过程中我们都会参与。
整个资源的生命周期的管理，我们分为事前计划，事中控制和事后分析，并且会有多项举措。
- 在事前计划的过程中，我们关心需求的核心驱动是什么，架构方案合不合理，成本应该如何去测算。
- 在事中控制，我们关心的是资源的交付效率，资源使用率以及资源效能。
- 事后分析，我们会关注业务账单，竞品分析和一些运营效果的分析。所以围绕着整个资源生命周期的管理，以底下的数据洞察为基础，中间我们会穿插着技术降本和运营降本。
接下来，从这三个方面去着重的介绍。
第一个是数据洞察。处于洞察方面，我们会侧重两类的数据：一类是资源，一类是成本。我们基于内部的平台和资源整合了监控系统，资产管理系统还有混内部的混合云系统，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服务类的成本。那想要做到成本优化的收益最大化，想要达成我们刚开始分享的时候说到的这个业务增长，但是成本不增长的目标，那么我们实际上在各类成本资源项上都需要去投入优化。
成本优化：各类资源多管齐下
