传统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年开始，业内引入了自动发现工具用以解决配置数据的初始化问题，但由于这类工具往往由某个厂商提供，导致了配置发现的局限性，企业往往也要付出较大成本。
投产后由于变更频繁，数据无法保证及时准确
以往企业一般采用变更操作驱动配置修改（人工修改或自动化发现修改）的方式以确保配置数据的准确性，这种方式往往会出现配置信息的不一致。
如何让人人“乐于”参与
这里的参与主要体现在两个方面：
1.需要使用与自己相关的配置数据时，CMDB可以立即提供；
2.遇到CMDB无法提供的数据时，IT部门可自行在一定标准和约束下扩展满足本部门运维CMDB模型，支撑部门级的运维场景。
配置数据的价值无法呈现
缺乏清晰的场景定义，包括流程价值、监控价值、BSM价值、云价值等
单一流程驱动CMDB的场景，无法让CMDB中的数据流动起来，随着时间的推移CMDB中的数据就逐渐腐败——不及时也不准确。
同时，CMDB在技术上作为一个“数据库”，要让其中的数据能够流动起来，必须明确与之匹配的运维场景。
场景是用来描述与CMDB中某些配置项交互的一组活动，满足IT部门某一方面的运维管理目标，这一目标可以被度量、跟踪、改进、可视化，与此同时，CMDB的价值也随之呈现。
缺乏有效、明确的配置数据集成策略
如前所述，CMDB是一个逻辑上的数据库，其中的数据需要和企业现有IT环境中的多类数据源进行整合，一套行之有效的数据集成策略和ETL（数据抽取、转换、转载）工具也必不可少。
通过以上分析，我们回顾了CMDB的历史发展过程，以及建设过程中遇到的挑战。下面来看云化环境下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项之间的关系）也类似，应用系统依赖于数据库节点和中间件节点，而数据库节点和中间件节点都依赖于操作系统，操作系统运行在虚拟机上，虚拟机又依赖于物理服务器，物理服务器又与存储相连……那么，应用系统与存储其实也是有关联的。这样的连接关系，如果用关系数据库来表示，应该怎么设计？实际上是无法表达出来的。
在图2中，我们可以根据CI之间的关系定义不同的关系，例如CI和CI之间是依赖关系、包含关系、运行于关系、安装在关系，以及连接关系等。而且关系的属性种类可以根据实际的需求无限制扩展。
图2 一个图数据库中CI关系图示例
CMDB领域中的图数据模型
图数据库一般都有自己独特的对数据进行描述的方式，即以图节点和图边为特征的数据表征形式。在不同领域的数据结构中图模型的表现是完全不一样的。我们将通过一个实际案例来详细了解一下，在CMDB领域的图模型是如何建模的。
传统CMDB原始数据分析
传统CMDB都是把数据存储在关系型数据库中，并且分多张表存储。接下来我们就把数据从关系型数据库中导出为.csv格式的表格，用Excel打开。如图3所示，这是一个包含了UPS、STS、配电柜、机柜、物理主机、VM、应用系统等超过20种数据类型的原始数据表格。
图4是原始数据表中配电柜子表的数据演示，出于数据隐私的需要，我们隐藏了部分字段的真实信息。其他CI的数据我们就不一一示例，基本上都大同小异。
图4 配电柜原始数据示例
原始数据关联关系分析
关于什么是图数据库的“节点”和“边”我们不再详述，大家可以参考我们上一篇介绍图数据库的文章，到这一步，我们就直接分析如何根据原始数据建立节点和边的关系数据模型。
第一步是要根据业务需求，确认不同CI之间的关系分类，如我们在表1中所描述的那样，一般情况下，CI之间的关系就只有表中呈现的那么多。
表1 CMDB中CI与CI之间的关系列表示例
第二步，我们把所有的CI和关系的种类都列出来，当然，只需要和业务部门充分沟通。图5是一个示例。
图5 CI与CI之间的关系分析
根据分析结果整理出节点类型和边类型
根据步骤一和步骤二的整理结果，列出所有的节点类型，如图6、图7所示。
图6 图数据库节点类型
图7 图数据库边类型
根据节点类型和边类型画出CMDB系统的图模型
根据已经整理好的节点类型和边类型，我们就可以很轻松地把基于图数据库框架的数据模型画出来，将来原始关系型数据库中的结构化数据也会以这种数据模型的架构转换成图数据库中的节点和边的数据类型，从此不再和关系型数据库有任何关系。
在图8中我们可以看到所有CI之间的关系图谱。图数据库的一个最大优点就是数据建模非常方便直观。传统关系型数据库的DBA可以无需做任何修改就把原始的E-R图直接转换成图数据库的图数据模型，这一点对业务部门的使用者而言非常方便。
我们在上文谈及传统CMDB的弊端时，曾经说过传统CMDB的建模非常难以把握CI深度的这个度的关系，而在图数据库中这都不会存在问题。管理员可以根据业务需求，随时修改图8的图模型，例如在不同的CI之间建立起边的联系，或者新增加一种节点类型（CI类型），而这一切甚至不需要停机，在线状态就可以直接修改生效。
图8 CMDB系统的图数据库系统建模示例
CMDB查询展示
数据模型建好之后，接下去只需要把数据导入图数据库即可，对于ITIL管理人员来说，还是要看一下图数据库是如何解决传统CMDB系统弊端的。
查某一个／多个CI向上支撑／向下影响的其他CI，并支持结果按类别筛选
我们首先来看看在CMDB中遇到的最常见问题：查找任意一个CI的影响关系，即如果该CI出现问题，无论是出现故障还是需要做变更，看看这个CI的影响范围，以及可能的影响职能部门，甚至指定的个人。
在图9中，我们查找从指定UPS出发，在“结果类型”中填0，表示查询所有受影响或支撑的CI，在“查询深度”输入框中指定步数，输入10，则表示查询10步及10步以内受影响或支持的CI。如，UPS到开关是一步影响关系，UPS到开关再到配电柜就是2步影响关系，以此类推。
图9 CI影响范围的查询
在上面的图展示中，可以对图进行放大缩小，或者对某一块区域的图节点进行放大查看，甚至可以对某一个节点进行查看。
查询关联路径：选择2个CI，看其间的影响／关联路径
查找两个CI之间的关联关系也是我们在CMDB系统中经常遇到的问题，传统的关系型数据库需要做不同表之间的Join操作，数据量一大就会出现计算时间呈指数级别上升，往往查询时间会让管理人员无法忍受。而图数据库的查询时间基本上是在几毫秒到十几毫秒之间，较之传统的关系型数据库查找时间，可以减少几个数量级。
我们在“源节点ID”输入框中输入第一个CI的ID，如UPSG；在“源节点类型”输入框中输入第一个CI的类型，如ups；在“宿节点ID”输入框中输入第二个CI的ID，如rs-06D51ER；在“宿节点类型”输入框中输入第二个CI的类型，如ps。则表示需要查询ups为
UPSG和物理主机rs-06D51ER之间的关联路径；在“查询深度”输入框中输入步数，如10，表示查询到的路径最长不超过10步。查询结果见图10。
图10 不同CI之间的影响路径查询
查询某个人管理着哪些CI
查询某个人管理着哪些CI，在图数据库上就是查找和这个人有关联关系的节点和边的类型的计算。
我们在CMDB系统中，在“节点ID”输入框中输入某个人的姓名，在“节点类型”输入框中输入类型，如person，表示查找某个管理员管理着哪些CI；在“最多查出多少个节点”中指定一个数，如100，表示最多查出100个（见图11）。
图11 查询某个人管理着哪些CI
类似的查询场景还有查询某个机房有哪些CI，如图12所示。
图12 查询某个机房有哪些CI
查询某个IP被哪个CI使用了
查询某个IP被哪个CI使用了这是最为频繁使用的查询，传统关系型数据库的查询速度应该也不会慢太多，但是关键是我要从查询到的结果出发去进一步查找该CI的信息，此时图数据库就可以展现出更直观的方式。在图数据库上只需要点击查询到的CI，就可以从该CI出发，进一步展现和该CI有关系的其他CI，这种查询可以无限制地做下去，直到找到管理员需要的信息（如图13所示）。
图13 查询某个IP正在被哪个CI使用
查询结果可以以多种直观的方式展现
图数据库对查询结果的输出可以非常灵活，可以导出为.csv格式的表格性数据，但更擅长的还是图形化界面的展示。
图形化界面的展示可以是多种形式，例如通过力学排列、树形排列、层叠排列、环形排列等不同形式展现，方便查看（例图见图14、图15）。
图14 力学排列CI查询结果
图15 层叠排列CI查询结果
存在的问题
CMDB已经是IT领域一个并不算新颖的话题，甚至有点老生常谈，但是通过图数据库来重新构建CMDB系统，却给这个似乎已经步入中年的IT技术重新带来了青春。在问题管理、资产管理，以及变更管理上，都大大提高了既有的工作效率。
虽然如此，通过图数据库来重新构建CMDB系统也存在一些待决的问题，需要各个CMDB的软件厂商和项目落地的合作伙伴共同去面对和解决。
首先，使用图数据库并没有解决原始数据自动化配置发现的问题。图数据库的出现，大大拓展了CI的范围广度和深度，将之前运维体系所不能，甚至不敢涉足到的CI数据也纳入到管理系统中来，同时查询性能反而得到了提高，这是一个优点，但是原始数据的自动化配置也是图数据库无法绕开的步骤。巧妇难为无米之炊，如果没有数据，再强大的平台也无能为力，所以图数据库还需要配合数据自动化配置发现才能实现最佳效果；
第二，目前市面上基于图数据库的CMDB系统基本上都是在既有的ITSM系统上再次改造而来，并没有厂商开发出原生的基于图数据库的CMDB系统。主要原因是图数据库技术还比较新，传统CMDB厂商对其了解还不够深入，所以现在更多的实践还是在现有CMDB基础之上的改进和补充。目前已经有一些CMDB的开发厂商正在研究如何把图数据库整合到ITSM平台中，甚至完全替换掉传统的CMDB技术，让我们拭目以待。
关于系统选型和配置建议
从2014年开始到现在，图数据库已经在目前所有数据库模型的发展趋势中名列第一，如图16所示。目前业界基于图数据库开发出来的开源软件和闭源软件都不少，其中开源界最有名的是Neo4j，而在闭源的商业软件则有GraphSQL——一个来自美国硅谷的品牌。
图16 db-engines.com网站对全球所有数据库模型发展趋势的评分
无论是Neo4j还是GraphSQL，他们都是基于原生图存储和图引擎计算的数据库产品，在原理上完全一致。在产品知名度、软件易用性上，Neo4j经过多年发展已经更加深入人心，但是在大型企业部署上，例如高可用、高并发、可扩展性等企业级管理功能上却是GraphSQL明显胜出。
CMDB领域本身的数据量并不大，关键是复杂关系的关联分析和管理。一个1000人大型企业的CI项目总计在一起一般不会超过50万个，转换成图数据库中的节点和边的数据类型后一般在100万个节点左右甚至以下，边的数量在1000万左右。这个数据量对图数据库而言都是小儿科，一台普通的X86服务器就可以满足要求。如果出于企业级管理的需要，例如高可用、热备等，就要考虑部署3台左右的主机，甚至异地数据中心的双集群架构。
最后，关于本文中提到的技术框架问题、数据模型，以及如何做到数据同步、如何实现自动化数据配置发现等问题，因篇幅所限无法一一展现，欢迎有兴趣的朋友和我们联系。 |
