内容来源：2018年2月5日，优维科技CEO王金银在《打破当代CMDB模型应有局面之道——第01期》中发表《新一代CMDB模型构建手册》的演讲分享。 IT大师作为独家视频合作伙伴，表示是经过主办方和主讲人审核授权后发布的。
阅读字数：3087|8分钟阅读
概括
明天给大家分享的主题是新一代CMDB模型构建手册，主要分为四个部分。
困境：当前CMDB模型面临的普遍困境
前期很多CMDB建设都是仓促完成的，但是后期的维护逐渐被开发、运维等角色抛弃，变成了废墟。 究其原因，一部分是制度本身的各种激励因素，但更多的是方法论的问题。 我一直认为我找到了构建资源维护的流程和场景的强大驱动力，虽然这都是我自己的一厢情愿。
从常规部门的角度来看，数据中心的基础设施部门负责CMDB所触及的配置建设和管理，而资源部门根本不关心（也很难关心）与资源相关的底层应用。 整个问题似乎陷入了悬而未决的西街。
那么业界明天的CMDB模式存在哪些问题呢？ 可以从什么角度来拆解和分析这个问题呢？
破局：构建CMDB模型的正确思路
这里我更提倡分层CMDB建设，业务层和资源层CMDB分开建设，但一定要以应用CMDB建设为主，逆向建立资源层CMDB建设。
但想法就是想法。 从实际业务场景出发，如何将真实的化学世界精准映射到模型世界？
我们应该如何改进匹配所有实际场景的模型？ 您是否也认为CMDB的模型设计就像数据库表的设计一样简单？ 基于新思路推导出来的CMDB模型与过去的CMDB模型有哪些区别？ 造成这一变化的原因是什么？
体系：模型标准框架
CMDB是一个IT资源管理系统，可以有效支持和反映应用程序运行所占用的资源。 应用占用的服务器是一个资源，占用的显存是一个资源，占用的存储是一个资源，占用的负载均衡器是一个资源。
但一定要注意vmware虚拟化物理机教程，这个资源更多地表现为前端服务，比如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流程提供数据支撑服务。
第二个是以执行为导向的流程。 整个端到端的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是一个完整的面向资源的描述。 应用资源分为应用部署资源、服务资源和动作资源。
部署资源是应用程序部署所依赖的资源，通常也称为本地资源，例如主机、程序包等。
服务资源是应用程序依赖的资源，通常被称为附加资源（来自），例如应用程序的服务套接字、应用程序依赖的PaaS资源、应用程序依赖的应用程序资源等等。
场景动作是附加在资源上的动作描述，是资源的管理方式。
新模型的标准化框架
新一代CMDB资源模型框架
核心原则：只有一种资源可以提供服务，而且还依赖于其关联的资源，因此必须采用三维模型解决方案。
IaaS 层硬件对象模型
对每一个图像进行实例化和描述就足够了，无非就是属性和关系。
IaaS 层软件定义的对象模型
如上图所示，IaaS层软件定义对象模型分为三个层次。 最内层好像叫依赖操作资源，主机只是其中之一。
这三个级别必须包括服务、组件实例和主机。 服务运行过程中启动了哪些运行实例，这些实例进程在哪些主机上vmware虚拟化物理机教程，主机的后缀是一个IP列表。
组件实例有两种，一种是它自己的实例，应用程序包在程序运行时实例化。 一种是依赖实例，就是实例化依赖组件。
自有服务是自启动的服务对外暴露的形式。 依赖服务是指在运行时关联的服务。
该模型的表达与PaaS层对象的表达类似。
PaaS层对象模型的核心概念
需要深入理解服务、实例、主机之间的层次关系，准确表达组件和集群之间的区别，比如Mysql组件和Mysql集群。
应用层对象模型核心概念
应用层对象还应对服务、实例、主机之间的层次关系有深入的理解，并准确地表达出来。