如图所示，未进行数据资产化建设时，数据可能呈现离散状态，数据生产和消费不统一，容易出现数据孤岛或零利益的情况。

建设数据资产化后，我们整合不同渠道数据，构造统一的数据源，或数据采集、存储、分析的流程链路，进而统一对应的数据结构、数据关系和消费出口。

运营数据经过采集、整编后，可服务于自身决策和业务流程。

上图以场景为例，介绍了数据资产的分类。理解数据资产，就要理解数据资产所对应的三个要素，即数据类型、数据形式和数据载体。

业务指标层面，SRE关注交易耗时、交易订单量等信息；操作软件层面，SRE关注用户IP、接口调用情况等信息；基础设施层面，则关注对应的网络丢包率、内存占用或CPU使用率等信息；再深入，SRE会更加关注变更事件、发布试点或紧急变更的数量等数据。

我们根据日志类、关系类及监控类等数据的不同表现形式，选择相应存储方式，比如关系型数据库、持续性数据库、消息队列或者日志文件等。

首先，使用获得的运维数据，建设资产化平台（例如后文将要提到的CMDB）。通过这些平台，按照消费场景，对海量的运维数据进行拆分治理，进而形成资产化。

其次，依托数字资产平台，可快速构建并迭代SRE稳定性相关平台（例如SLO、容量管理等平台）。平台成功建立后，我们持续挖掘数据价值，以提升SRE关注的稳定性。

运维数据标准化面临的问题，和大数据场景下数据质量的问题类似，主要包括数据孤岛、数据质量不高、数据不可知、数据服务不够、获取数据的开发耗时长等。

这些问题导致，数据消费场景难以快速迭代，无法满足业务需求。在人力资源、服务器资源、中间件资源等投入不足的情况下，对数据标准化的建设会产生灾难性的影响。

运维数据天生是不标准的，比如，日志和日志监控的数据存储方式不同。而我们要在资源有限的情况下，进行最大化阐述，完成标准化。

针对近期业内比较火的概念，比如DataOps、AIOps等模型或场景，我们还缺少成熟、全面的数据建模方法论。

将运维数据提升为数据资产，需围绕治理方法、治理过程和技术平台三部分展开。

1）治理方法

2）治理过程

治理过程包括策略、建设与运营。整体建设方面，需要建设平台和工具，辅助自身运营。

3）技术平台

建立技术平台的主要目的是，通过工具支撑存量和增量数据。

数据治理的关键要素主要围绕四方面：组织保障、制度建设、项目落地和平台支撑。

CMDB配置管理处，主要围绕四方面进行建设：基础备案的技术台账、详细自然属性、自然关联关系、资源消费图谱。我们需要分层建立对应业务的模型，再通过自动化感知或标准化流程，实时推送配置动态。

对应配置也需要有对应的可视化界面，激发协作力量，最终，这些数据通过APP或相应离线场景，促进数据的消费场景。

个人理解，CMDB是元数据中心。如上图所示，我们配置管理的数据库CMDB，会对组织、人员、决策、权限、流程等相关数据进行清洗或组装操作。

下层对接的平台很多，比如监控平台、邮件、短信、运维的数据库等。这些数据组装完毕后，会交由上层（类似服务管理层的平台）进行数据输出，完成资产管理、配置管理等一系列服务，并进行平台建设。

以应用为中心，可以实现组织-项目-人员的关联关系，并与应用绑定。

应用运行过程中，使用对应资源（服务器资源、配置中心、可观测性指标等），再按照公司的组织架构形成从属关系，最终把组织架构视角引用到微服务视角，形成资源及其资源的关系——拓扑，其中包括应用拓扑、物理拓扑。

上图所示为CMDB，它会将基础测试设施的元数据、Paas相关数据及运行数据，提供给上层（CI平台、CD平台、服务运行平台和服务运营平台）使用，图中所示的下层平台就形成服务资源支撑平台。

这样建设的好处是，为应用的全生命周期提供基本的数据支撑，包括应用创建、应用运行时态（构建、发布、扩容、计费）、回收应用下线后资源。

上图是建设CMDB的四大阶段，我们目前处于从服务导向到价值导向的第四阶段。

部门导向：

数据导向：

场景导向：

服务导向：

价值导向：

综上所述，我们要以数据全生命周期为出发点，确定属性、理清关系、明确消费场景，借助自动化流程来保障数据的实时性与准确性。

1）模型关系定义

2）CI关系DEMO举例

3）CMDB落地实施框架

4）标准化先行

标准化先行是，落地之前的所有事项，都围绕标准化进行建设。其中包括一些强要求，比如规划要求、流程要求、组织要求和平台要求。

规范要求：

流程要求：

组织要求：

平台要求：

5）打造数据全生命周期闭环

首先，确定应用属性。应用的属性可能包括，应用的中英文名称、应用等级、唯一ID、归属业务和业务域等，属性内容主要取决于个人定义。定义应用后，应用可能与其他CI产生关系，需进一步梳理。

其次，明确应用的属性负责人。应用具有对应的负责人、研发和SRE等，针对应用构建、发布、变更，以及围绕用户进行的其他动作，我们都有对应流程，以保障应用的配置和变更审核。

最后，进行定时的采集任务，以保证应用最终的数据准确性。

6）推动配置的自动发现和更新

上图提到的“资源”还是传统意义上的资源，比如服务器资源。通过一定方式采集这些资源，最终上报到资源管理平台。

讲到资产平台，要引入“服务树”的概念。这是B站近5年来持续建设的平台，即以应用为中心的树形信息配置系统，它主要描述各个组织层级的关系。

业务线、中台、架构都可以在服务树上申请创建顶级节点，再由各层级Owner根据业务模型向下拆分子节点，目标是解决B站所有业务线和资产的管理问题。

1）服务树的定位和职责

2）服务树的业务场景

①面向业务方的资源管理

②面向资源提供方的统一资源交付

资源提供方作为租户接入服务树，并注册需要挂树的资源信息；资源挂树/回收时，服务树会校验该租户是否有资源的管理权限，保证租户间资源隔离。

商品化的资源可以定时向RA资源运营平台推送账单，RA资源运营平台也会检查该租户的身份（非该租户的资源不能接受此租户推送的账单）；最终，RA会按照业务层级聚合账单推送给业务⽅。

租户可以基于服务树来构建资源管理模型，使自己的资源管理更贴合业务，租户可以将Quota、预算、资源利⽤率、SLO等基于服务树来构建，通过这些措施，租户可以更了解业务方的资源使用情况， 实现更合理的资源调配，从而缓解B站面临的资源短缺问题。

3）服务树的核心概念

如上图所示，我们采用组织架构-业务-应用的数据结构，完成业务层级的模型概念。在业务层级，我们会梳理职能、人员、工作、产品或业务域归属关系的，由此按照不同制度产出对应的树视图，但主视图还是以组织架构为主。

我们可以在树形结构上，对资源权限模型进行管控。

首先，在应用层级，将资源模型绑定或挂载到应用节点，此处资源可能包括服务器、数据库或缓存的资源。

其次，应用节点上有对应权限设计，比如产生一些角色。B站具有5大标准角色，也支持用户自定义角色，来支撑挂表到对内节点上。角色可以授予对应的权限模型，例如，某个平台某个资源的某个动作，可以授予权限模型，同时权限也可以授予真实对应的用户或AB账号，以此统一抽象成“基于节点控制资源”的方式。

我们可以在不同节点绑定不同的资源，或梳理对应的归属，以此展现对应的权限控制。

上图是B站服务处，左侧是标准的组织树的输出，右侧是应用层级的基础信息。下图应用所使用的资源信息，包括服务器、容器、数据库、缓存和SLB等信息。

这些元信息或应用所用到的资源信息，是怎么进入到服务树的？这时则需要介绍B站针对资源定义的CI定义模型。

如图所示，我们拆分了CI模型的定义、CI与CI的关系定义和属性定义。

CI实体类型定义：

关系定义：

首先，定义应用模型及其属性资源，再定义容器模型及其属性资源、模型的Relationship。

随后进行实例化时，会按照模型信息和关系信息进行对应存储，最终形成应用运行时的资源拓扑，上图展示了容器场景中资源运行的信息。

服务树鉴权复用了IAM的鉴权体系（参照了GCP IAM的实现），主要包含四个部分：

如上图所示，落地时，首先可以看到权限点有哪些。然后，确认这个角色在此节点，会否被授予给右侧的成员。如果授予，这群成员在此节点，就具有控制资源的相应权限。

由于数据树项目的持续时间长达五年，所以存在数据治理的需求。如上图，我们以节点权限为例，分享数据治理的实例。

组织：

规范：

数据运营保障：

针对服务树，我们想从应用出发，进行应用画像。如何理解应用画像？

业内有个成熟的概念，叫用户画像。以B站为例，用户维度的内容包括：是否大会员？是否UP主？近期投稿多少？稿件最高点赞率多少？

应用画像和用户画像类似，针对单个应用进行多维度的关联性分析，随后输出应用分析报告，目前内容主要包括CI、CD平台的信息、运行情况、资源信息、调研信息、稳定性信息，并据此进行评估。

输出数据包含两个部分：应用分析雷达图、应用画像基本信息。应用分析雷达图，由服务树对上报和周边平台手机的综合数据，进行分析，目前抽取了6个概括应用的维度：

获得这些数据后，我们要进行应用标签服务化的流程，目前整个流程还在实施中，进行到数据验证部分。

数据验证需要确认：标签体系设计有哪些？平台能否提供数据源？不能提供数据源，应该使用什么方式？除此之外，数据进行离线数据库后，或开户后进行离线计算，再进行数据验证，检查是否存在问题，最后形成标签生产。标签落地后，为业务方提供数据。

Q1：模型建设是否要遵循数据库的范式？

A1：B站的服务树，所用到数据存储的引擎很多。比如，用关系型数据库，存储人员信息或其他信息；用MongoDB存储文档数据；用图数据库进行图的构建。

我们在设计关系模型时，为了建立几余度小，结构合理的数据库，设计库表的时候遵循一定的规则，而且我们的DBA会管控DDL操作，给出设计的建议。

Q2：CMDB对外提供数据如何保证安全？

A2：对外提供数据时，一般需要保证数据质量，因此我们更关注数据质量，而非数据安全。

如果数据安全指的是，不应被看到的数据是否要进行暴露。在这个维度上，需要与内审、外审沟通。因为B站每个季度或每半个季度，都会进行内审或外审，所以我们与内审、外审多次沟通，数据能否完全公开，以及这部分数据在什么场景可以公开。

在B站，部分数据对组织架构、对公司内部所有人，是完全透明的，所以这些数据是可以暴露出来的。不能暴露的核心敏感数据，可能包括这个人的职级、电话，我们具有对应的加密算法对敏感数据进行处理。如果有人要使用这部分数据，可能需要走邮件申请的流程，申请通过后，才能拿到对应数据。

Q3：建设运维数据中台有无必要？

A3：这要看贵公司的整体建设思路如何。以B站为例，建设运维数据中台是非常必要的，技术架构部、微服务相关的业务等内容，都基于SRE数据中台进行建设。

Q4：CMDB和ITSM的服务目录、知识库等关系如何界定？如何协同工作？

A4：CMDB不存储知识库的相关内容；服务目录只存储应用的相关信息，包括应用的配置信息、运行信息；事件管理承载知识库的功能需求。

Q5：运维的知识图谱和CMDB是什么关系？

A5：知识图谱基于CMDB的数据进行构建，建立知识图谱是CMDB的消费场景，所以是依赖关系。

Q6：数据资产对SRE的意义是？

A6：如果不建设数据资产平台，SRE要使用数据时，就需要到各个平台上查看。比如，某个业务限流，SRE首先要去监控查看这个接口的情况，调用可观测平台查看接口的上下游，查看 QPS是否符合预期、缓存情况如何。由此，分析时，也需要分别查看各个平台，最终定位问题。

因为B站进行了资产化建设，打通平台对应的更新分析链路。我们还配备企业微信的 H5推送，直接告诉研发/SRE，由此保障稳定性。

Q7：如何保证数据的实时性与一致性？

A7：针对不同维度、不同数据源，我们具有对应配置、告知规则和监控。如果数据不一致，达不到定义模型的数据准确性要求，对应推送会送达数据干系方和责任方。

数据大盘有模型数据的当前情况，包括总量数据、存量、在CMDB平台上的数据量、准确率，为相关人员数据治理提供参考。

Q8：时序数据库用于哪些场景？

A8：时序数据库用于存储日志和用户行为分析等信息。