不会建数据资产体系的SRE，不是一名好运维

一、认识数据资产

1. 数据资产——企业IT价值

图片

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

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

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

2. 数据资产——以运维场景为例

图片

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

• 数据类型：运维特征的信息描述

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

• 数据形式：数据储存于数据载体的形式

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

• 数据载体：为运维数据提供存储的方式

3. 数据资产——提升SRE价值

图片

根据获得的运维数据，首先建设一个资产化平台，例如后文提到的CMDB。利用这些平台，根据消费场景对大量的运维数据进行分解和管理，从而实现资产化。

另外，我们可以利用数字资产平台快速建立和改进与SRE稳定性相关的平台，如SLO和容量管理平台。一旦平台建立成功，我们将持续探索数据的潜在价值，并提升SRE所关注的稳定性。

二、数据治理-方法论

1. 运维数据标准面临的问题

图片

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

这些问题导致，数据消费场景难以快速迭代，无法满足业务需求。当人力资源、服务器资源、中间件资源等不足时，数据标准化建设将带来灾难性的影响。

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

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

2. 建立运维数据治理模型

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

图片

1）治理方法

• 主数据管理：将SRE关注的数据进行定义和拆分。比如，主机和CLP等数据可作为主数据，我们对其进行生命周期管理。
• 广义元数据管理：这些数据在闭环的上报流程中，进入到CMDB，就是广义元数据管理。以CMDB的模式为代表，向上层提供相应的数据支撑。
• 关键治理链路：基于数据标准、治理质量和安全基线三个维度，梳理整个治理链路，即数据标准、质量目标、整个变更的基线要求。

2）治理过程

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

3）技术平台

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

3. 聚焦数据治理关键要素

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

• 组织保障：为解决人力资源问题，我们明确成员角色和职责分工。由产品、运营和研发三种角色，组成数据治理专项团队。
• 制度建设：需要建设标准化流程，并保证其有序落实，比如资源接入、资源开发、资源数据模型等规范。
• 项目落地：开始整体的专项治理，数据治理是长效的过程，而非简单的运动式作战。如果数据质量严重不达标，我们会成立专项小组，采取运动式的作战方式，紧急修复数据质量的问题。但建立长效治理手段需根据数据产品，输出对应的治理方法论，并将其落实为产品化的平台手段，以此驱动数据责任方进行数据治理。
• 平台支撑：平台建设主要围绕精细度量、执行治理效率等维度进行。

三、CMDB平台建设

1. CMDB配置管理库

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

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

2. CMDB在ITIL时代的定位——元数据中心

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

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

3. CMBD在新时代的定位——以应用为中心

、

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

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

4. 以应用为中心的CMDB优势

图片

5. 应用在运行期间与元数据中心的关系

图片

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

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

6. CMDB建设的四大阶段

图片

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

部门导向：

• 不论有无CMDB系统，实际都存在CMDB需求，以部门为单元维护配置信息；
• 信息是孤立的、不及时的，无法保证完整性和正确性。

数据导向：

• 各部门都关心的数据及相互关系统一纳入CMDB管理，并建立配置管理流程制度；
• 由于消费场景不明确，造成消费价值与生产成本的失衡。
• B站数据生产成本建设并非很高，但是数据消费产品建设特别多，或是业务侧经常定制场景需求，CMDB需要定制介入开发，完成业务侧诉求。由此暴露出问题，CMDB有300多个OKACI，不便于维护。

场景导向：

• 局部数据标准化程度，准确性较高；
• 由于使用场景单一，总体消费价值不高，生产成本相对较高。

服务导向：

• 数据供给服务，支撑日常操作管控，如自动化、监控、作业流管理、运维分析等；
• 引入多样化的数据生产/消费手段，逐步平衡消费价值与生产成本。

价值导向：

• CMDB全面支撑服务及业务发展，如服务容量管理、可用性管理，成为IT运维的基石；
• 主动推动组织IT管理水平的提升。

7. CMDB模型如何构建

图片

• 定义数据类型：包括主机、交换机、应用、应用配置文件，配置人员接到需求后会对此进行调研。
• 定义数据核心属性：以主机为例，需要上报或采集IP、序列号、机房、云厂商等资源核心属性。
• 构建数据模型直接关系：梳理资源与资源之间的对应关系，如包含关系、依赖关系、运行关系等，以便后续制作资源拓扑。例如，应用使用一种数据类型，主机使用另一种数据类型，那么应用运行时会依赖主机，主机反过来可以组成应用。
• 消费场景确认：确认消费场景，就是确认数据用于哪些阶段。如果用于集群部署，可能需要到应用维度进行相关部署，或对应的运维作业。
• 确立数据规范：生命周期（从创建、生产到部署）是怎样的过程？数据状态变化后，平台如何感知？

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

1）模型关系定义

图片

2）CI关系DEMO举例

图片

3）CMDB落地实施框架

• 现状评估：当前是否有CMDB平台？这个平台建设程度如何？这部分数据质量如何？组织架构和技术架构如何？未来上线的过程中，需要用到的资源状态如何？
• 项目启动：启动时，需要定义接入资源的 CI模型和关系、后期消费场景、数据来源、CI干系方。
• 数据实例化：进行数据实例化检测时，会搭建测试环境，导入CI模型或实例化数据。
• 数据校验：在UG环境内，查看数据上报和实际产出的对比情况，确认数据质量能否达标。数据质量达标后，需要建设生产环境，以检测数据在生产环境的状态。
• 数据场景消费：数据落到生产环境后，需查看数据消费的场景，我们要与运营平台或SRE平台进行对接。

4）标准化先行

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

规范要求：

• 明确定义CMDB平台的作用，以及其他业务系统间的关系；
• 明确定义资源的管理过程、责任人和责任平台；
• 明确定义资源的基线标准以及偏差管理办法；
• 从服务业务场景的视角，规划和建设配置管理能力。

流程要求：

• 能够真实反应资源状况；
• 能够完整包含所有资源信息以及资源间关系；
• 全局唯一的权威数据源；
• 数据能够被用户及系统方便、及时、高效地获取。

组织要求：

• 成立统一的配置管理能力建设主体；
• 各个业务团队明确配置消费和完善的责任；
• 形成配置管理讨论、优化和需求收集的机制。

平台要求：

• 逐步实现配置自动发现、自动维护；
• 实时跟踪资源的状态及配置变化；
• 模型灵活，能够根据业务需求实时扩展和调整；
• 配置可视化，能够支持资源问题的分析和快速定位。

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

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

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

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

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

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

• 建设完善的配置采集能力，杜绝人工维护的场景；
• 自动发现资源和应用的配置信息；
• 对接流程、管理平台和设备，实时获取和更新配置状态；
• 建立资源配置和使用规范，通过CMDB进行合规检查；
• 推动实现配置消费闭环，通过消费反馈，自动维护数据可靠性。

以上是不会建数据资产体系的SRE，不是一名好运维的详细内容。更多信息请关注PHP中文网其他相关文章！