内容来源：2018年2月5日，优维科技CEO王津银在“当代CMDB模型应有的破局之道 - EasyTalk - 01期 ”进行《新一代CMDB模型构建指南》演讲分享。IT 大咖说（WeChat_ID：itdakashuo）作为独家视频合作方，经主办方和讲者审阅授权发布。

阅读字数：3087 | 8分钟阅读

获取嘉宾完整演讲视频及PPT，请点击：http://t.cn/EyZ0Nny

摘要

今天我为大家带来的分享主题是新一代CMDB模型的构建指南，主要分为四大部分。

困境：当前CMDB模型面临的普遍困境

很多CMDB建设前期做得风风火火，而后期维护渐渐被开发、运维等角色抛弃，成为废墟。究其原因，部分是系统本身的各种因素阻碍，但更多是方法论问题，总以为找到了很强的驱动力来建设资源维护的流程和场景，其实都是自己的一厢情愿。 

从常规部门的角度看，数据中心的基础设施部门统揽 CMDB 所触及的配置建设和管理，但是资源部门根本不关心（也无法关心）资源所关联的上层应用。整个问题看似走进了无解的胡同。 

那么行业今天的CMDB模型问题点究竟在哪？这些问题可以从哪些视角去拆解分析？

破局：构建CMDB模型的正确思路

在这里我比较主张分层进行 CMDB 建设，业务和资源层 CMDB 分开建设，但一定要以应用的 CMDB 建设为主，并倒推资源层的 CMDB 建设完善。 

但思路归思路，从实际的业务场景出发，真实存在的物理世界又如何精确映射到模型世界？ 

我们又该如何构建匹配一切实际场景的模型，是不是你也认为CMDB的模型设计就是和设计数据库表一样简单？基于新思路构建推演的CMDB模型和过去的CMDB模型到底有什么差异？做这样改变的原因是什么？

体系：模型标准框架

CMDB即IT资源管理系统，能有效支撑反应一个应用运行的占用资源。应用占用的服务器是一种资源、占用的内存是一种资源、占用的存储是一种资源、占用的负载均衡是一种资源。 

但大家一定要注意，这个资源更多是以一种后端服务形式出现的，比如说IaaS 服务或者是 PaaS 服务。

本次分享会提出IaaS、PaaS和应用层的标准模型框架。这个框架改变了过去简单二维表的描述，真实构建反映一个符合现当下绝大多数IT体系背景的CMDB模型到底应该是什么样。

论证：模型的应用场景推演

当然，基于构建模型，我们还会进行各个CMDB场景的推演，从而验证新CMDB模型的适应性。 

而且本次提出的运维管理新思维经过众多项目落地实践证明切实有效，给过去的很多未解问题提供了解决方案。贴近业务的资源，驱动力最强。

当前CMDB模型面临的问题

当前CMDB的模型问题

当今很多CMDB的模型还是聚焦在底层资源。这个底层资源指的一部分是IaaS层的资源管理，另一部分是PaaS层中间件的资源管理。到上层应用这块，其实它的模型表述特别简单，只有一些应用的基本信息。

第二个要讲的问题是无应用视角。今天我们创建管理了这么多资源对象，但不知道是给谁用的，其实真正的着力点是应用。这个我将其总结为无应用层的理解力。

模型的动态性不强。每个模型对象调整它的属性或者关系的时候，在传统数据库里技术端的特点带来的代价特别高。我把模型的动态性抽象成两个维度，第一是模型对象之间在CI级别的动态性，第二个就是实例级。

第四个问题是场景过渡的设计。我认为场景是可以预设的，但是细粒度的模型会带来很大的管理负担。有时候会把场景考虑得过于复杂，导致这里面的模型管理后续负担特别重。从简到繁很容易，但是从繁到简很难。

技术限制想象力。受CMDB平台技术本身的能力限制，导致无法扩展这个模型。

欠缺IT架构思考力。我要讲的是从业务架构到应用架构再基础架构。业务架构中还包含了基础设施架构和数据架构。弄清楚这三者的关系后，就能表达出在每一层架构上所带来的本质上的关系连接到底是什么。

CMDB系统截图

构建CMDB模型的正确思路

新一代CMDB到底新在哪儿？

新思维：突破配置管理的认知，导致边界不清。配置往IT资源方向转变。

新方法：自上而下的推动CMDB落地，而不是自下而上。

新模型：模型重构，传统的关系模型无法满足。

新技术：使用新的技术，新的功能架构，重新定义功能边界。

CMDB元数据的两类用途

CMDB模型最终是要实例化数据和关系的，正确的模型构建可以为多变的场景提供数据基础。

第一个是面向管理层的ITSM流程。在很多传统企业里面，CMDB还是要为ITSM的流程做好数据支撑服务。

第二个是面向执行层的DevOps过程。端到端整个IT交付过程需要完整的元数据，特别是应用层面的元数据。

两层CMDB，构建不同管理视角

CMDB架构分基础资源层架构和应用资源层架构。应用层资源架构把相关的资源以应用为中心实现资源整合。资源及其资源的关系称之为拓扑（应用拓扑、物理拓扑），资源管理方式有人工维护和自动发现两种方式，流程是人工维护的一种复杂场景和手段。

基础CMDB建设五原则

1、面向IaaS和PaaS设计，能够管理底层的一切资源。

2、状态控制借助运维流程自动化完成。

3、CI的维护要深度使用自动发现，而不是人工维护。

4、资源信息必须能为上层应用提供服务。

5、必须满足基础资源的CI管理需要。

应用CMDB建设气原则

1、提供统一的应用元数据管理能力，和应用类型无关。

2、核心诉求是应用生命周期管理。

3、以应用为中心，而非基础资源为中心。

4、从应用资源的角度构建起与IT资源的弹性关系。

5、为应用资源、动作、状态的统一管理提供支撑。

6、以统一的基础资源层CMDB作为基础。

7、核心场景就是持续交付。

应用CMDB模型层次化理解

应用CMDB是面向资源的完整描述，应用的资源分成应用的部署资源、服务资源和动作资源。

部署资源是一次应用部署所依赖的资源，一般又称本地资源，比如说主机Host、程序包等等。

服务资源是应用运行依赖的资源，一般有称之为附加资源（来自于12factor），比如说应用的服务接口、应用依赖的PaaS资源、应用依赖的应用资源等等。

场景动作是资源其上附加的动作描述，是资源的管理方法。

新模型的标准化框架

新一代CMDB的资源模型框架

核心准则：一个资源能够提供服务，还要看它关联的资源，因此必须采用立体化模型方案。

IaaS层硬件对象模型

针对每一个象实例化描述它们就可以了，无非就是属性和关系。

IaaS层软件定义对象模型

如上图所示，把IaaS层软件定义对象模型整理成三个层次。最底下的层次其实应该叫做依赖的运行资源，主机只是其中的一种。

这三个层次中必须要包含服务、组件实例和主机。服务运行过程中起了哪些运行实例、这些实例进程在哪些主机上，主机延伸出来就是IP列表。

组件实例有两种，一种是自有实例，当程序运行的时候需要的应用包实例化。一种是依赖实例，就是将依赖组件实例化。

自有服务是自己启动的服务对外提供的时候以怎样的方式暴露出去。依赖服务则是运行时还关联了哪些服务。

这个模型表达方法和PaaS层对象比较类似。

PaaS层对象模型核心概念

一定要深刻理解服务、实例和主机之间的层次关系，并且要精确表达注意组件和集群的区别，例如Mysql组件和Mysql集群。

应用层对象模型核心概念

应用层对象也要深刻理解服务、实例和主机之间的层次关系，并且要精确表达。

今天的分享就到这里，谢谢大家！

Q&A

Q：虚拟化的资源怎么描述呢？

A：我们今天把虚拟化和物理机的资源对象叠加在一起管理。在主机对象表里增加了一个字段，就所属母机，仅此一个维度的区别。

Q：像磁盘、网络这些有没有介绍？

A：我把磁盘、网络归纳到底层IaaS的一部分。对于IaaS那部分对象CI的描述其实也比较简单。比如硬盘就归类为硬盘大小、分类信息等等，只是一些硬件信息而已，没有特殊的。网络这块要分开，要分为各种网络，像接入、汇聚跟核心可以归为一类的网络设备，防火墙则要归为另外一类。网络方面比较需注意资源信息。

Q：应用如何自动发现？资源自动发现能详细介绍一下吗？ 

A：应用层要真正想做到自动发现，肯定还需要依赖规则库。系统、子系统、应用组件，这三个名称其实是一个逻辑的概念，只有人才能准确地知道。如果要把机器运行的实例信息和我们大脑中所记录理解的应用组件关联起来，这就需要依赖规则了。所谓的规则无非就是根据实例所扫描上来的一些信息去整理规则。底层的资源自动发现，有接口就写接口，有命令就跑命令，没什么特别的。因为资源层自动发现的复杂度不在于它的技术，而在于它本身基础设施的复杂度。

编者：IT大咖说，转载请标明版权和出处