作者：杭菲璐 欧玮 李申章郭威 廖莹璐 李寒箬 来源：《中国新通信》 2017年第14期
一、引言
在移动化办公系统中，CMDB 是重要的核心支持模块，它的主要目的是有效管理生产环境当中的移动设备，并对其它的服务管理流程实现支持。鉴于CMDB 的逻辑独立性和数据统一性，可以通过CI 件的关系，帮助运维人员和服务提供商在产生故障时能够迅速定位到故障位置，并能分析出受影响服务的深度和广度。
CMDB 对于企业IT 服务管理能力的重要性勿庸置疑，但在实际的实施过程中，却往往出现差强人意的局面，设计时面临对CI 深度和广度的定义困难，构建CMDB 时面临数据采集的巨大工作量，维护CMDB 时面临数据无法及时更新的窘境，使CMDB 难以达到预期的效果。
这种局面的出现并不是偶然的，实际上，如果不充分考虑信息化系统建设的普遍规律，为CMDB 而CMDB，结果也必然会成为为信息化系统建设失败的例子。本文首先从信息化系统建设的角度对CMDB 的建设进行一些思考。
二、对CMDB 的理解
2.1 认识CMDB
什么是CMDB ？“CMDB 是一种包含每一个配置项（Configuration Item，CI）全部关联细节，以及配置项之间重要关联细节的数据库”，这是标准的定义，对于其定义以及解释已经很多，这里不再赘述。但光解释是不够的，作为一个软件系统的模块，CMDB 的作用是什么，为什么要用CMDB ？这也有很多的叙述了，这里只是我们从实际出发所理解的最根本的方面。
首先，CMDB 用基本概念－配置项，把现实环境中要管理的对象全部抽象出来，把不同的东西看成统一的一种对象，这种视角的转换对信息系统来说是再好不过了，经过这种转换，本来纷繁复杂的世界只剩下了三种东西：配置项、属性和关系。
然后，配置项和它们的属性代表了现实环境的对象，再用关系把它们在现实环境的关系表现出来，就得到了一个简单有效的模型，可以用统一的方法来进行管理。
通过这样的模型，像移动化办公系统这种面对各种不同类型的终端、不同操作系统及各种复杂设备元件的系统，才能通过有限的边界实现所有需要的功能。
由此可见，使用CMDB 是为了用简单的、通用的数据模型来简化移动化信息系统的数据结构，根本原则在于简化。
2.2 CMDB 建设中的问题
CMDB 具备联邦性、协调性、同步性、映射和可视化四大特性，根据目前国内在信息化系统建设中的实践，联邦性往往是最不容易实现的，首先是因为不同数据的维护部门不同，作为CMDB 建设者的IT 相关部门并不一定具备获取这些数据的权限，或者能够获取一份拷贝，至多通过ETL 方式进行定期的数据更新，而这并不能真正地实现联邦性提倡的多数据源存储，CMDB 仍然是一个独立的数据库，更新受到很大的限制。
其次是CMDB 开发厂商把CMDB 的开发局限在自己的专有架构中，使CMDB 变成一个孤立的数据库，CMDB 的重要目标就是消除信息孤岛，把不同来源的信息整合在一起，但如果在建设中处理不当，那么CMDB 本身会成为一个最大的孤岛。
三、CMDB 的对象的定义
CMDB 对象的定义主要有对象分类及不同类型对象的属性集，对象的分类根据需求会有不同的变化，但主要根据硬件设备、软件系统等资源的不同类型为分类依据，再根据分类为不同类型的对象定义属性。配置项间的关系类型也根据实际需求进行定义。
作为信息化成功建设的基本原则，业务需求永远是放在第一位的，配置项的定义，包括分类和属性定义，都必须以实际的业务需求来驱动，尤其是不同配置项的属性，必须根据实际需求来进行定义。
根据业务需求，不同的应用部门和用户对配置项的属性要求是不同的，只有业务需要的属性才需要被定义，也只有业务实际使用到的属性才能被关注、被及时的更新。在对属性进行定义之前，我们首先可以根据不同的应用部门核用户的需求，对属性进行分类。下面的分类例子
是根据国内机关企事业单位在手持终端设备管理方面的现状，将配置对象的属性分为以下三类：
3.1 设备相关属性
由于大多数配置项都是IT 环境中的物理设备，而这些设备都是相关单位的固有设备，同时有专门的行政管理职能，维护着不同的终端设备台帐，因此设备相关属性是一组重要的属性，往往包括采购信息（合同、单价、编号、投运日期、保修年限等）、所属信息（所属单位、使用部门等）。
从用户的角度看，维护设备相关属性的部门一般是财务部门和IT 主管部门（对于桌面设备，有的单位是由行政部门进行台帐管理），这一组信息的更新主要和设备台帐管理相关，工作中，主要是财务部门或IT 主管部门会对相关数据进行维护。
3.2 运行维护属性
这是与设备（系统）使用及运维相关的一组属性，主要包括手持终端信息（设备编号、数量）、运维责任信息（运维单位、运维责任人、使用人等），设备（系统）状态等。这一组信息较多地由运维部门进行维护。
3.3 配置属性
主要是设备自身的软硬件配置，包括设备的硬件配置（如手持终端的CPU、内存、蓝牙）、网络地址（IP 地址等），更新会比较频繁。这一组信息可以由相关的管理人员手工维护，也可以通过自动化的监控手段自动获取这些信息。
这样的分类主要是从业务的角度出发，以属性信息可能的来源作为分类条件，以便于考虑把CMDB 的维护工作分散到业已存在的业务工作当中去，使CMDB 的维护不再是CMDB 自己的事，这样才能使CMDB 得到最有效的更新。还可以在条件许可的情况下，通过数据的整合，实现部分或全部的联邦特性。
四、CMDB 构建的可行方法
构建CMDB 时工作量巨大是往往是因为要从头进行配置对象的输入，特别是对配置对象属性并采集，但即使是从头进行数据采集，也可以通过一定的策略对过程进行优化。
4.1 从第一个数据来源建立配置项列表
根据实际情况出发，从前述的三个分类中挑选一类作为CMDB 构建的起点：
如果能够获得手持终端设备台帐，则可以从设备台帐建立配置列表，并具有全部或者部分的终端设备属性。运行维护属性及配置属性需要在后续的工作中完善。
如果运维部门能够提供设备运行的信息，如终端设备列表，运维人员管理的设备（系统）列表，则可以根据该列表建立配置项列表。
设备和配置属性后续完善。
如果已经有了在线的监控系统（包括桌面管理系统），而该系统有足够的覆盖面，则可以从被监控设备列表建立配置项列表，设备和运维属性后续完善。
4.2 在后续工作中完善属性数据和关系
很多情况下，建立一个属性尚不完善的配置列表已经可以满足部分工作的需要，缺失的属性和关系可以在后续工作中进行完善。
这里最重要的因素是让CMDB 中数据能够有效地被不同的用户所使用，不同部门、不同用户的需要往往是CMDB 属性和关系的一个子集，当这个子集被用户关注时，往往能得到及时的更新与维护，一定要避免CMDB 建设出现闭门造车的情况。
五、CMDB 维护
一般来讲，CMDB 的变更入口主要是ITIL 规范的变更流程和发布流程等，然后进入配置管理流程，这种标准的处理流程实际上有一个严重的问题：真实对象的实际变更在相关流程成功结束时已经发生了，其过程得到了领导或主管人员的批准，变更的结果也在流程结束时得到了确认，而配置管理流程在这之后才能开始，这是一种严重的滞后，作为配置管理流程涉及的主要角色－配置经理，实际上并不一定具备对真实变更情况进行验证的能力，实际情况往往是，变更、发布等流程和配置数据的修改是脱节的，配置经理和配置管理员承担的是CMDB 数据录入员的角色。
其实，根据国内多数机关企事业单位的实际情况，只要管理规范，变更、执行等流程往往能够得到严格的把控，相关配置数据的变更完全可以由这两个流程自动完成，这样不仅简化了流程，减少了操作，更重要的是避免了配置管理流程滞后带来的问题，配置管理流程只有在需要时才会被应用，配置管理的相关角色也只需用在需要时才对配置管理进行维护。
六、结论
CMDB 以及ITIL 标准的实践需要充分考虑实际的需求，它们的引入是为信息化系统服务的，在建设中一方面要考虑遵循标准，而更重要的是结合业务让优秀的理念来服务于用户，这个问题需要在实践过程中的经验积累，还需要我们IT工作者进行不懈的研究和努力。
因篇幅问题不能全部显示，请点此查看更多更全内容