图数据库在CMDB领域的应用

【导语】在上期的图数据库介绍中，我们对什么是图数据库，以及图数据库所擅长的领域做了一个初步的介绍，也收到了众多的反馈和咨询，特别要求我们对图数据库在一些具体行业的应用能做一些深入介绍。为此，从本期文档开始，笔者将用一系列文章对图数据库在一些专门领域的部署和应用做专题介绍。第一期，将讲述图数据库在CMDB领域的建模和应用场景。

传统CMDB的弊端

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

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

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

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

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

大而全还是小而深——选择犹豫不决

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

采用了不正确的管控策略

按照经典ITIL的管控和项目实施机制，配置管理规划，尤其是CMDB模型的规划往往由项目组承担，一旦规划完成后整个模型也就变得很难再进行扩展，应该说这里采用的是一种集中管控的策略。
但在实际IT运维工作中，我们发现对于CMDB使用最多的是各个二线团队，不同团队之间对于CMDB深度和广度的要求，以及管控方式都有较大差别。

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

配置经理、配置管理员、配置Owner之间职责不清晰

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

角色职责和岗位的对应不明晰

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

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

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

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

初始数据收集工作量大

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

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

单一的自动化配置发现工具只是一种幻想

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

投产后由于变更频繁，数据无法保证及时准确

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

如何让人人“乐于”参与

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

• 需要使用与自己相关的配置数据时，CMDB可以立即提供；
• 遇到CMDB无法提供的数据时，IT部门可自行在一定标准和约束下扩展满足本部门运维CMDB模型，支撑部门级的运维场景。

配置数据的价值无法呈现

缺乏清晰的场景定义，包括流程价值、监控价值、BSM价值、云价值等

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

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

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