优维科技老王:与其说建设CMDB,不如说建设IT资源图谱

2019-09-10 15:58:25 采集侠

原文来自公众号:互联网运维杂谈

在运维人员看来,CMDB是一个绕不开的字眼。在ITIL时代,太多的CMDB落地项目,但鲜有成功。而我之前有一个观点,CMDB中的配置字眼要从这个里面去掉,重新给它设定一个边界。在这个边界划分上,我曾经提出过CMDB经历过三个阶段,资产管理、配置管理到今天我主张的IT资源管理。

资产管理围绕硬件属性、采购属性、成本属性、采购属性、固件管理等等;配置管理围绕服务管理、配置管理等等,但配置范畴太广,导致容易管理失控,比如说应用配置、环境配置、中间件参数管理等不适合进入CMDB,分布式配置中心Apollo、Nacos便是佐证;IT资源管理进一步缩小其管理能力范围,把不能够产生服务能力的东西都剥离出去,不纳入管理范围。

 那到底什么是IT资源?一切能直接或者间接产生业务服务价值的IT实体都可以称之为资源,比如说应用系统的业务服务、网络带来的网络服务、F5带来的负载均衡服务、存储资源带来的存储服务、主机带来的计算/网络/存储服务等等。那它和配置管理服务有什么区别?我认为配置是资源的版本化描述,比如说网络配置是对网络服务的版本化描述、主机上会有各类配置(CPU、网络和存储、环境配置)等等,而这种版本化的描述可以通过配置中心来管理。

一旦我们收敛了CMDB的管理边界是IT资源,此时就需要知道构成资源服务能力的不仅仅是资源自身,还有其关联的资源,资源图谱概念由此产生。资源图谱旨在描述IT世界中存在的各种实体与资源及其关系,构成一张复杂的实体与资源关系图,节点表示资源实体,边则由关系构成。

在资源图谱的概念中,对现实世界的图谱描述有两层,第一层是实体层,第二层是资源层,最后是他们的关系表达。实体是从真实的世界出发,直观看到的,比如说网络、防火墙、应用系统、数据库中间件等等,通常一个实体代表一类服务能力。再往下,实体构成对外的服务能力一定是其关联的资源实现的,比如说网络上的端口、应用系统的部署和服务资源、基础设施主机上的CPU/网络/存储等等资源。这两者在过去,统一用CI来表达,我认为是欠妥的,容易对这个世界平面化的描述,但其实他们是层次化的。针对每一个实体和资源都要用结构化表达,这是另外技术建模的问题,在此不多讲。其次说到关系,实体之间的关系是由资源的关系构成的,主机和主机之间没有关系,而是上面的端口资源访问产生的业务关系,交换机与主机没有关系,是因为交换机端口和主机之间物理连接产生的关系;A和B应用系统因为他们之间的API服务访问产生的关系。

 到底哪些应该纳入到资源图谱管理呢?上至服务、应用系统及组件,下到数据、基础设施架构等等,员工也属于资源的一种。API是越来越重要的资源,行业也开始出现各类管理平台,如swagger;应用系统是由N个组件组成,也是一种资源;组件从安装部署态算起,一直到运行态,由大量的关联资源组成,主机、制品包、关联的依赖库、关联的进程端口、提供的服务等等;数据服务关联了各类中间件服务信息,cache类、DB存储类等;基础架构的资源分解很简单,就是上面关联的核心资源管理,比如说交换机的端口、F5上面的vspool/irules等。

CMDB到底要不要建设?我觉得可以不要,但IT资源图谱平台要不要建设?我觉得很有必要。我会从IT资源图谱的四大定位和五大类场景谈谈他的必要性。

首先说说它的四大定位,这也是我一直在和客户不断说的四个方面:数据地图、基础数据、数据总线、数据治理:

优维科技老王:与其说建设CMDB,不如说建设IT资源图谱

一、数据地图(边界)

IT资源图谱需要构建一个数据地图的能力,全面构建资源实体对象及对象关系,这个定位有利于控制它的边界。在现实中有各类地图,地图本身维护各类经纬度数据(点)以及点到点之间的路径关系,而基于地图的应用则很多,比如说衣食住行类应用等等。IT平台也是如此。在一体化运维平台体系中,上层的场景丰富多样,需要底层这样的一个数据地图来描述数据和数据之间的关系。

二、基础数据(能力)

基础数据是一种可供数据消费的能力,IT资源图谱需要开放所有的数据供外围场景平台消费,比如监控平台、自动化平台、安全平台等等。基础数据平台要解决数据的生成和数据的消费两个方面问题。数据生成一方面依赖自动发现,另外一方面就要依赖流程;数据消费要基于开放式的API能力,供外围场景平台和它联动。

三、 数据总线(整合)