运维平台之CMDB系统建设.pdfVIP

【平台篇】运维平台之CMDB 系统建设 CMDB 是运维的基础核心系统，所有的元数据和共享数据管理源,类 似于业务中的账号平台的作用。本篇文章，我将从概念篇、模型篇、到 实现与实施篇具体的进行阐述。 CMDB 也称配置管理，配置管理一直被认为是 ITIL 服务管理的核心， 因为其他所有流程均需要使用配置管理数据库 (CMDB)。在上篇的平台 体系中，CMDB 位于最底层的支持系统位置上，可见其作用。配置管理为 什么起到核心的作用，这个地方不做逐一介绍，简单举个例子，比如说 变更系统发起了一个部署请求，要部署某个版本到现网，部署完成之后， 上层的变更系统会把变更的结果写到CMDB 中，对配置进行归档；在某 个机器down 机，此时可以快速的知道该机器的具体用途，确定影响的 业务；当机器需要重新恢复的时候，可以快速的根据CMDB 中的信息进 行恢复。 一、概念篇 1、配置管理和配置文件管理。 ITIL 所讲的配置管理是从软件工程管理角度出发的，把一切对象都 当做配置，比如说源代码、文档、人员、服务器甚至硬盘和内存等等。 所以说他和业务程序的配置管理有着本质的不同，为了有效区分，我们 又习惯说业务程序的配置管理叫配置文件管理。但又有着一定的联系， 在 ITIL 中，业务程序的配置可能会以一个配置项存在，附属在应用程序 上，具体什么是配置项后面再解释。 2、配置管理和资产管理 既然把一切资源对象都当做配置来看待，特别是服务器、机房、机 柜等等，那他和我们的资产管理又有着什么样的不同呢？其实这两个系 统的区别在很多时候大家都不是很清楚，会混为一谈。具体的区别我之 前做过一个总结，如下： 在上图中，你把握核心的区别点就是导向，配置管理是面向业务管理， 而非成本，这个会决定配置管理的粒度。当前如果业务非常简单，不需 要对服务器端口进行管理，此时则不需要考虑纳入端口的管理，否则增 加管理的代价。 3、配置项 配置项是指要在配置管理控制下的资产、人力、服务组件或者其他 逻辑资源。从整个服务或系统来说，包括硬件、软件、文档、支持人员 到单独软件模块或硬件组件（CPU、内存、SSD、硬盘等等）。配置项 需要有整个生命周期（状态）的管理和追溯（日志）。对配置项的分类， 我一般从逻辑资源和物理资源两个角度来分解，然后层次化分解，这个 思路会让你特别清晰，不会混乱。 4、属性 一个配置项就是一个对象，有对象便有属性，属性是一个配置项的 具体描述。比如说服务器这个配置项，他的具体描述有在哪个机房、哪 个机柜的哪个位置、现在是否有业务运行、具体谁负责等等。在后面的 模型篇里会对属性做全面的梳理，完成现实世界到模型世界的转换。另 外配置项和属性可以转换，比如说IP 地址，他肯定是一个资源对象存 在。但是从服务器的角度来说，它作为一个属性存在，更准确的说是网 卡的属性。 二、模型篇 我为什么把模型单独提取出来，因为它是CMDB 建设的核心，缺少 对业务的准确理解，则没法准确的提取配置项及其属性。在这个环节中， 模型的核心职责，就是把配置项和属性逐条的梳理出来。本人在模型整 理的时候，重点做了四个方面工作，然后形成规范手册。 1、配置管理系统的角色 可以简单分成几类角色，第一、应用运维，负责服务器上的业务信 息维护；第二、基础运维，负责机房、机柜及其服务器物理信息的准确 性；第三、配置管理员，负责基础信息的维护，比如说业务分类，人员 信息；第四、查询类角色，比如研发。CMDB 是核心的资源信息管理系 统，一般不轻易开放权限。 2、配置项识别与定义 这是重点工作，没有简单的方法可循，细致活，基于上图的【配置 项】的物理资源和逻辑资源的不断分解，根据业务需要最终识别出要管 理的配置项。然后对每一个配置项进行整理，确定要管理的属性。形成 类似的下表： 就拿最核心的服务器资源来说，会形成如下表的信息整理： 逐个进行整理，在上表中有几个方面需要注意： 第一、每个配置项目确定了维护角色，他在后续的过程中，需要对 这个准确性负责，确定维护的职责边界。 第二、要整理出配置项的关联，比如说上表中的所属机房、所属机 柜。 第三、这个表不是数据库的设计表，具体数据库的设计表是开发人 员根据这个模型参考实现。 3、基于场景的配置管理规范 配置管理的核心目的是为了确保配置信息集中管理，并且是准确的 管理。在这个里面需要做两个核心的工