CMDB是运维的基础核心系统，全部的元数据和共享数据管理源,相似于业务中的帐号平台的做用。本篇文章，我将从概念篇、模型篇、到实现与实施篇具体的进行阐述。数据库
CMDB也称配置管理，配置管理一直被认为是 ITIL 服务管理的核心，由于其余全部流程均须要使用配置管理数据库 (CMDB)。在上篇的平台体系中，CMDB位于最底层的支持系统位置上，可见其做用。配置管理为何起到核心的做用，这个地方不作逐一介绍，简单举个例子，好比说变动系统发起了一个部署请求，要部署某个版本到现网，部署完成以后，上层的变动系统会把变动的结果写到CMDB中，对配置进行归档；在某个机器down机，此时能够快速的知道该机器的具体用途，肯定影响的业务；当机器须要从新恢复的时候，能够快速的根据CMDB中的信息进行恢复。服务器
1、概念篇
运维
一、配置管理和配置文件管理。测试
ITIL所讲的配置管理是从软件工程管理角度出发的，把一切对象都当作配置，好比说源代码、文档、人员、服务器甚至硬盘和内存等等。因此说他和业务程序的配置管理有着本质的不一样，为了有效区分，咱们又习惯说业务程序的配置管理叫配置文件管理。但又有着必定的联系，在ITIL中，业务程序的配置可能会以一个配置项存在，附属在应用程序上，具体什么是配置项后面再解释。spa
二、配置管理和资产管理设计
既然把一切资源对象都当作配置来看待，特别是服务器、机房、机柜等等，那他和咱们的资产管理又有着什么样的不一样呢？其实这两个系统的区别在不少时候你们都不是很清楚，会混为一谈。具体的区别我以前作过一个总结，以下：3d
在上图中，你把握核心的区别点就是导向，配置管理是面向业务管理，而非成本，这个会决定配置管理的粒度。当前若是业务很是简单，不须要对服务器端口进行管理，此时则不须要考虑归入端口的管理，不然增长管理的代价。日志
三、配置项orm
配置项是指要在配置管理控制下的资产、人力、服务组件或者其余逻辑资源。从整个服务或系统来讲，包括硬件、软件、文档、支持人员到单独软件模块或硬件组件（CPU、内存、SSD、硬盘等等）。配置项须要有整个生命周期（状态）的管理和追溯（日志）。对配置项的分类，我通常从逻辑资源和物理资源两个角度来分解，而后层次化分解，这个思路会让你特别清晰，不会混乱。对象
四、属性
一个配置项就是一个对象，有对象便有属性，属性是一个配置项的具体描述。好比说服务器这个配置项，他的具体描述有在哪一个机房、哪一个机柜的哪一个位置、如今是否有业务运行、具体谁负责等等。在后面的模型篇里会对属性作全面的梳理，完成现实世界到模型世界的转换。另外配置项和属性能够转换，好比说IP地址，他确定是一个资源对象存在。可是从服务器的角度来讲，它做为一个属性存在，更准确的说是网卡的属性。
2、模型篇
我为何把模型单独提取出来，由于它是CMDB建设的核心，缺乏对业务的准确理解，则无法准确的提取配置项及其属性。在这个环节中，模型的核心职责，就是把配置项和属性逐条的梳理出来。本人在模型整理的时候，重点作了四个方面工做，而后造成规范手册。
一、配置管理系统的角色
能够简单分红几类角色，第1、应用运维，负责服务器上的业务信息维护；第2、基础运维，负责机房、机柜及其服务器物理信息的准确性；第3、配置管理员，负责基础信息的维护，好比说业务分类，人员信息；第4、查询类角色，好比研发。CMDB是核心的资源信息管理系统，通常不轻易开放权限。
二、配置项识别与定义
这是重点工做，没有简单的方法可循，细致活，基于上图的【配置项】的物理资源和逻辑资源的不断分解，根据业务须要最终识别出要管理的配置项。而后对每个配置项进行整理，肯定要管理的属性。造成相似的下表：
就拿最核心的服务器资源来讲，会造成以下表的信息整理：
逐个进行整理，在上表中有几个方面须要注意：
第1、每一个配置项目肯定了维护角色，他在后续的过程当中，须要对这个准确性负责，肯定维护的职责边界。
第2、要整理出配置项的关联，好比说上表中的所属机房、所属机柜。
第3、这个表不是数据库的设计表，具体数据库的设计表是开发人员根据这个模型参考实现。
三、基于场景的配置管理规范
配置管理的核心目的是为了确保配置信息集中管理，而且是准确的管理。在这个里面须要作两个核心的工做。
第1、配置项的规范化管理；
第2、面向配置项的流程规范化管理，没有一套与之匹配的配置流程，最后配置管理都会混乱不堪，这个系统也就形同虚设。
此时没有捷径，识别配置管理的场景，把每一个流程清晰的画出来，好比说服务器管理，它就涉及到服务器上架、服务器搬迁、服务器下线、服务器申请、服务器回收等流程。好比拿服务器回收流程来讲，流程图以下：
注意上图中，在服务器回收的过程当中，行是角色，列是阶段，在每一个阶段，服务器的状态可能发生变化，此时也须要作备注。方便后续开发人员在作相应的流程实现的时候，控制这类状态。状态的转换对监控也有影响。
四、状态变迁图
用一张图来讲明资源状态的变化，便于更好的基于场景和变动来控制配置项状态的变动，其实也就是它的生命周期管理。举例以下：
这些方法都是之前面向对象设计里面的内容，我以为在CMDB配置管理工做中，有很大的做用，在一张纸上，你就能够看到状态如何变化，而后是哪一个场景促使变化，这些场景最终就会转换成CMDB的某个功能或者某个流程。
3、实现篇
系统实现很是简单，简单理解就是一个配置的信息管理+流程管理，一个开发熟手，一个月就能够开发完成。难点仍是在配置项识别，必定要作足功夫，把配置项的属性、流程、状态都整理清楚，最后按照这个来系统实现就OK了。不过在系统建设中，有一个经验你们能够参考：CMDB必定要变成运维和运维研发的共同项目，而且具体的配置项管理人要全程参与，好比说需求讨论、测试、上线验收等等（运维研发项目均可以遵循该模式）。像上面的配置项最好能找一个对全局了解的人来作，不必定是研发。
4、实施篇
其实CMDB真的是很是简单的系统，至少在两家公司作的CMDB都是很是短的时间完成，最多两个月。可是其实施的过程不少经验能够分享。
一、致使CMDB失败的因素
A、缺乏管理层承诺----没有管理层的承诺，CMDB不可能成功。
B、在复杂流程上消耗太多的时间---咱们是建立一个CMDB库，不是一个流程系统。
C、没有建立相应的工做指导文档---指导如何管理和维护CMDB。
D、没有指定配置项负责人----确保配置项有人专职维护。
E、目标过大，涵盖太多的功能----好比说IT采购和预算管理等等。
F、颗粒度不合适----配置合理的CMDB的配置项层次和粒度很是重要。
G、存在组织隔阂----CMDB是一个集成体系，靠流程中的每个人通力协做，而不是某我的。
二、致使CMDB成功的因素
A、业务导向。好比说咱们在CMDB的新的系统中实时加入QR码技术，为了下降资产盘点的工做量。
B、能自动发现就自动发现，下降配置管理的成本，但自动发现的信息不能用来作告警。
C、配置项的管理员必须全程参与，需求定型、测试及验收等等。
D、CMDB系统建设完成以后，其余系统必须和他联动。好比说监控、质量、容量等等，用场景驱动配置项的管理。
E、流程必定要平台化，不要让流程脱离CMDB存在，好比说搞一个OA流程，这个是很致命的。
F、CMDB要持续演进，特别是云端资源的管理。
G、配置项和流程必需要文档化，后期要进行CMDB培训。