CMDB，英文名Configuration Management Database，即配置管理数据库，常常被认为是构建其他ITIL流程的基础而优先考虑，ITIL项目的成败与是否成功建立CMDB有非常大的关系。

 

    从2000年开始，CMDB开始在国内企业慢慢推广开来，分别经过了最初的资产信息电子化阶段、开始与ITSM流程协同配合阶段，一直到配置自动化发现引入阶段，目前随着云计算技术的发展，CMDB的场景已经从传统的资产台账管理逐步演化到流程协同管理、影响分析、配置比对、云化资源管理等方面，但在CMDB的技术架构上，无论是开源产品还是商业化产品都没有明显改进，发展比较缓慢。这在一定程度上也影响了CMDB场景的拓展。

 

    接下来我们将分析当前CMDB建设遇到的一些常见问题。

 

    缺乏合理化、整体化的规划

 

    需求不清晰，定义了不合理的配置广度和深度。

 

 

    这种决策机制在项目初期往往耗费了大量时间，但随着新技术的不断涌现，这种方式已经无法适应越来越敏捷的IT环境，这种相对静态的CMDB模型已经不能满足纳管新IT组件的要求。

 

 

    按照经典ITIL的管控和项目实施机制，配置管理规划，尤其是CMDB模型的规划往往由项目组承担，一旦规划完成后整个模型也就变得很难再进行扩展，应该说这里采用的是一种集中管控的策略。 

 

    但在实际IT运维工作中，我们发现对于CMDB使用最多的是各个二线团队，不同团队之间对于CMDB深度和广度的要求，以及管控方式都有较大差别。

 

    配置管理人员职责定义不清晰

 

 

    ITIL或ISO20000中对于这三类角色的定义往往过于宽泛，没有进一步考虑实际运维人员的运维场景，以及使用的运维工具，导致职责定义和实际做事方式脱节。

 

 

    在没有ITIL以前，在企业IT部门或数据中心往往找不到一个现成岗位对于IT配置信息进行集中管理，而是每个人各管一摊。

 

    实施ITIL后，究竟由哪个部门的哪个岗位承担配置经理这一职责往往是最让人伤脑筋的，最后往往是赶鸭子上架。这种角色定义方式最终导致体系无法运转。

 

    配置管理成了IT运维的负担

 

    这其实是CMDB在企业落地所面临的最大挑战，无法充分调动运维人员的积极性，主要体现在：

 

 

    存量的配置数据往往基数很大，一般配置的量级在5000以上，考虑到云化环境的海量运维场景，这个基数还会更大。

 

    随着分布式应用架构以及微服务架构的兴起，未来一套新应用系统上线引入新的配置项数量也无法简单通过手工输入的方式来完成。

 

 

    如前所说，约从2007年开始，业内引入了自动发现工具用以解决配置数据的初始化问题，但由于这类工具往往由某个厂商提供，导致了配置发现的局限性，企业往往也要付出较大成本。

 

 

    以往企业一般采用变更操作驱动配置修改（人工修改或自动化发现修改）的方式以确保配置数据的准确性，这种方式往往会出现配置信息的不一致。

 

 

    这里的参与主要体现在两个方面：

 

 

    配置数据的价值无法呈现

 

 

    单一流程驱动CMDB的场景，无法让CMDB中的数据流动起来，随着时间的推移CMDB中的数据就逐渐腐败——不及时也不准确。

 

    同时，CMDB在技术上作为一个“数据库”，要让其中的数据能够流动起来，必须明确与之匹配的运维场景。

 

    场景是用来描述与CMDB中某些配置项交互的一组活动，满足IT部门某一方面的运维管理目标，这一目标可以被度量、跟踪、改进、可视化，与此同时，CMDB的价值也随之呈现。

 

 

    如前所述，CMDB是一个逻辑上的数据库，其中的数据需要和企业现有IT环境中的多类数据源进行整合，一套行之有效的数据集成策略和ETL（数据抽取、转换、转载）工具也必不可少。

 

    通过以上分析，我们回顾了CMDB的历史发展过程，以及建设过程中遇到的挑战。下面来看云化环境下CMDB又将面临什么新问题。

 

 

    在我们上一篇关于图数据库的文章《图数据库——大数据时代的高铁》中，我们已经对图数据库有了一个初步的认识，那么最擅长做风控的图数据库为什么也能在CMDB领域大展拳脚呢？这就与图数据库天生的技术特性密不可分。

 

    CMDB领域中最基本的单位是CI，也就是配置项，CMDB最基础的功能就是记录配置项，以及它们的重要属性和之间的关系。简单而言，CMDB是用以记录IT系统中所有类别及其具体属性，以及其间关联关系的。如果你只有那么几台设备，手指就能数得过来；如果有几十台设备，几张表也够了；而如果是成百上千台，甚至种类就多达几十种呢？这就必须要有个资产管理系统，否则你怎么知道这台设备的前世今生，以及它出了问题应该找谁（哪家供应商）。

 

    而资产管理系统就够了吗？设备要用起来，就不能是孤立的，多种设备，以及设备上的系统、软件必须是连接起来才有意义，但资产系统显然管不了这种关联关系。

 

    而如果使用传统的关系数据库，很简单的想法是一张表对应一种设备类型，表的列就是这种设备的属性。那问题来了，我加了一种设备怎么办？我需要在数据库里新建一张表，这个我还能做，因为我是个系统管理员嘛，这么简单的DBA入门工作还是能做的，但程序怎么办？它能认出新加的这张表吗？我可不懂Java、JavaScript……于是只好付钱给我的软件供应商，让他再帮我加这一类设备。而作为软件提供商，就会面临各种各样稀奇古怪的设备类型，那软件开发人员能把这些类型都内置在里面吗？显然不可能。再一种情况，以前我的资产管理系统对于PC服务器，只需要记录它的型号、配置即可，突然老板跟我说今年要作固定资产登记，每台机器加个标签，上面是固定资产编号。我又得叫软件提供商提供新版本了……

 

    简而言之，传统的资产管理系统，设备类别不可增，设备属性也不能增。或者，都可增，但开发代价太大了，不是小公司的开发团队能镇得住的，其性能及可维护性也不好。用关系数据库（RDBMS)来做CMDB是死路一条。而图数据库为CMDB的未来发展指出了一条阳关大道。

 

    图数据库属于NoSQL的一种，其表征数据的核心称之为节点，节点采用Key-Value的方式保存数据，这一点创造性解决了设备类别（CMDB里叫CI类）的扩展性，可以随意加一种CI类，也可以随意在CI类里加一个属性，而且它不会影响原有数据，也无所谓空与非空。另外，图数据库原来主要用于社交网络，就是小明认识小红，而小红是她妈妈的女儿，她妈妈是她爸爸的妻子，同时也是老板的下属，那小红与老板有什么社交关系就可以查出来了（如图1所示）。

 

 

图1 图数据库中社交图谱的展现

 

    人与人之间的关系太复杂，而设备与设备之间的关系（CI项与CI项之间的关系）也类似，应用系统依赖于数据库节点和中间件节点，而数据库节点和中间件节点都依赖于操作系统，操作系统运行在虚拟机上，虚拟机又依赖于物理服务器，物理服务器又与存储相连……那么，应用系统与存储其实也是有关联的。这样的连接关系，如果用关系数据库来表示，应该怎么设计？实际上是无法表达出来的。