在运维人员看来，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资源图谱的四大定位和五大类场景谈谈他的必要性。
首先说说它的四大定位，这也是我一直在和客户不断说的四个方面：数据地图、基础数据、数据总线、数据治理：
一、数据地图（边界）
IT资源图谱需要构建一个数据地图的能力，全面构建资源实体对象及对象关系，这个定位有利于控制它的边界。在现实中有各类地图，地图本身维护各类经纬度数据（点）以及点到点之间的路径关系，而基于地图的应用则很多，比如说衣食住行类应用等等。IT平台也是如此。在一体化运维平台体系中，上层的场景丰富多样，需要底层这样的一个数据地图来描述数据和数据之间的关系。
二、基础数据（能力）
基础数据是一种可供数据消费的能力，IT资源图谱需要开放所有的数据供外围场景平台消费，比如监控平台、自动化平台、安全平台等等。基础数据平台要解决数据的生成和数据的消费两个方面问题。数据生成一方面依赖自动发现，另外一方面就要依赖流程；数据消费要基于开放式的API能力，供外围场景平台和它联动。
三、 数据总线（整合）
在IT运行过程中，很多地方，比如说自动化和场景平台，自动发现发现某条记录进入IT资源图谱、云管平台分配一台主机进入IT资源图谱，此时外围安全、4A平台、监控等诸多平台需要消费，此时需要一对多的数据发布能力，IT资源图谱平台是最好的数据聚合点。在这个聚合点，可以在数据入库前做相应的校验，数据发布后做发布的确认等等。
四、数据治理（治理）
它也是一个IT资源数据治理的平台。随着IT应用系统和基础设施架构越来越复杂，资源及其关系错综复杂，纳入这么多的资源数据进入到平台，需要对原始数据进行数据的甄别、数据清洗、数据转换和数据融合的过程，从而变成高质量外围平台可消费的数据。还有一个场景化的数据治理思路，是和上面的变更服务耦合在一起的。
很多人会说，费这么大的力气建设一个IT资源图谱平台，到底是干嘛呢？一定是价值/场景消费导向，我把场景分成五大类：
一、流程服务类
ITIL里面包含很多流程类的服务，如服务台、事件、问题、变更等等，这些流程服务都可以和CMDB关联起来，在不同的流程服务里面需要消费的数据不一样。不知道大家有主要到没有，配置服务流程是ITIL里面实施最差的流程，为什么？从流程设计上来说，变更流程执行完成之后，发起配置流程修改配置，但是很少人这么做，一次变更触发了哪些配置项修改，估计实施的人都不知道，别说发起流程选择变更的配置项和属性了，特别是全流程自动化场景。这就牵扯到ITIL轻量化的话题，在此不展开。
二、可视化
CMDB里面很多数据是被关系理解的，这个关系从不同的角色角度去看，需要看到的拓扑和关系视图是不一样的，网络管理员、主机管理员、系统管理员等等，他们都是实例资源拓扑的场景化表达。上层应用架构拓扑是非常复杂的，不容易场景化理解的。可视化的核心是把关系数据有意义的表达出来。
三、自动化类
自动化是变更的主要实现，在这个场景之下一般都会触发资源变更，因此和自动化场景的关联是一种强关系。
IT自动化可以从资源交付自动化到应用交付自动化两层去分解。资源交付自动化可以从资产到资源自动化整个生命周期过程来分解；应用交付自动化就是今天行业所说的DevOps CICD过程，从持续集成开始一直上线到持续反馈，应用作为一个核心的IT资源对象，它自身有新上线、升级、运营服务、下线这样一个生命周期过程。覆盖如此复杂的IT过程，需要有一个基础IT资源数据平台存在，串联整个过程。这套方法我给写进了证券行业的自动化运维规范之中。
四、数据化类
监控、IT运营分析（容量、性能、可用性、连续性、成本、用户体验、质量）等各类数据场景都和资源图谱平台紧密关联。本质上来说，所有的数据都是这些资源的状态数据，而资源图谱提供了一个元数据基础，它首先解决的是一个到底有多少资源需要数据化。孤立的数据价值越来越小，关联整合的数据价值越来越高。关系是维度的体现，基于维度的数据聚合是很常规的运维需要，比如说从机房、从业务系统、从集群的角度去聚合流量。
五、智能化类
随着AIOps应用越来越多，在一些智能化运维场景中，比如说故障根因分析、事件关联分析等等，需要和资源图谱的数据全面关联，相当于一个知识标签库，相比较AIOps的标签库，资源图谱是基于场景维护产生的标签库，有着准确性高，实时性好，全面性广等特点。
我们今天正在在招商银行实践从CMDB到IT资源图谱的升级，改变过去的配置管理思维，全面落地IT资源图谱。
建设IT资源图谱，需要从四个定位出发，强调它的职能边界、数据生产和消费能力、基于数据总线的整合和面向多源数据的治理。同时要面向五个消费场景，强调这份数据建设的价值——流程和可视化是最基本的场景，也可以说是弱场景；自动化是一种强场景，直接影响资源数据变更；数据化消费资源图谱数据的重要场景，直观体现这部分数据价值；智能化是一个资源语义网络，理解资源和资源关系，提升特定智能场景的价值。
声明：本文来自互联网运维杂谈，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。
