首页 > 运维 > 安全 > 正文

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

WBOY
发布: 2023-07-22 15:33:51
转载
1058 人浏览过

一、认识数据资产

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

二、数据治理-方法论

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

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

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

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

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

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

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

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

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

1)治理方法

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

2)治理过程

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

3)技术平台

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

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

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

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

三、CMDB平台建设

1. CMDB配置管理库

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

6. CMDB建设的四大阶段

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

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

部门导向:

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

数据导向:

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

场景导向:

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

服务导向:

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

价值导向:

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

7. CMDB模型如何构建

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

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

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

1)模型关系定义

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

2)CI关系DEMO举例

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

3)CMDB落地实施框架

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

4)标准化先行

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

规范要求:

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

流程要求:

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

组织要求:

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

平台要求:

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

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

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

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

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

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

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

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

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

相关标签:
来源:51cto.com
本站声明
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系admin@php.cn
热门教程
更多>
最新下载
更多>
网站特效
网站源码
网站素材
前端模板