CMDB建设从调研到落地

近期着手参与了CMDB应用的相关工作，这里就CMDB整体的建设思路做个简单的小结。CMDB的建设整体过程，我大致根据自已参与的经验总结为几个阶段：前期技术架构调研—各CMDB使用方需求调研—形成目标功能—投入建设—形成能力—持续关注。

一、前期技术架构调研

在开始这部分之前，对于企业中的平台架构、资产数量、设备类型、需要纳入的关系和模型要先有一个大概的认知。接下来可以了解下业界的开源或商业CMDB常见的都有哪些，选取一到两个描述相对适配企业情况的，相对深入的了解下这些CMDB使用的技术和架构，和其他的产品相比较，这些产品的优缺点分别是什么。当前知名度相对较高的CMDB管理系统有蓝鲸、优维、乐维、itop、OneCMDB等。

这里面关注的点有：

• CMDB使用的传统关系型数据库（mysql、oracle），还是图数据库(neo4j、orientdb、rocksdb)，不同的数据库是对资产管理更方便，还是对关联关系的构建更高效。另外架构是不是还涉及存放其他数据的mongodb、ES，里面各存什么数据（开源的可以搭建后简单录些测试数据看下）；
• 对数据的录入是支持自动采集还是手动导入，在同时有想要自动更新的数据（如硬件配置）和手工录入的数据（如人员、机柜信息），是否处理比较方便；
• 对于企业有安全要求，不能安装agent的，是否有较好的API支持，支持的API方式是否是业界标准方式；
• 手动录入的方式是直接web界面修改、还是excel导入，还是同时支持；
• 录入的数据如何消费，是否支持API、web在线修改、excel导出，是否可以通过属性（IP、序列号）在线查询；
• 关联关系数据是怎么对应的，1对1、1对N、N对1、N对N；
• 查询的关联关系是以关系图的方式显示，还是同时支持原始数据的输出，是不是方便应用直接调用后，同其他应用平台结合。

有了前期这个调研总结，我们算是对CMDB有一定的了解了，先做个总结。接下来就可以找各使用方调研需要求了。这里以国内某CMDB的架构为例，如下：

二、CMDB消费方需求调研

在现代的运维建设中，提出了CMDB的建设是面向应用消费的，而不是仅仅只做资产管理作用。所认针对这个目标，我们的消费使用场景包含：工程上下线（资产和业务）、监控系统、根因智鉴、自动化平台、安全等。和这些消费场景的对应管理人员沟通前，我们需要先站在对方角度思路一些能和CMDB关联上的部分，先总结一些问题，带着问题去和应用方沟通。因为你直接去问，你对CMDB有什么需求，他多半是只笼统的给你说，我只要资产能录入能查，能形成关系这些模糊的概念。这不是我们要的，我们需要了解到：

• 应用方流程是什么样的（比如业务上下线走什么内部流程平台，是不是有相关附件输出，这些输出里是不是存一些资产信息，能不能和ＣＭＤB直接对接，在流程流转完后，直接通过流程平台解析过来的数据，完成更新）；
• 需要录入的资产数据是什么样子的（一般使用方都有把他自己关心的数据录成excel管理的习惯，这部分内容如果能CMDB动态管理、方便使用，估计没几个乐意一直excel吧），有可能的话，可以把这些表给他们要过来或者以ｄｅｍｏ数据的方式要过来，这个就是后面的CI项；
• 需要的关系数据是哪些，详细列出（虚拟机-物理机，物理机-EOR-TOR，某某系统-nginx-tomcat-mysql），这些就是后面应用关心的关联关系数据；
• 应用方希望调用的方式，是否有新增关注的功能点等。

这个对接过程不是一次就能完成后，要做好多次对应的准备。

三、形成目标功能需求

在前期的调研完成后，需要根据调研情况，形成需求功能总结、字典-配置项-属性-关系 CI模型表。功能需求表里需要涵盖这些内容：

• 功能需求：比如有视图管理（整体概况、3d机房视图）、工程管理、资产管理（录入、查询、修改）、API能力、分权分域、关联关系、自动采集、配置审计等；
• 功能点和规格描述：根据上面的功能需求，细化相应的功能点和功能点的描述信息。

CI模型表包含的内容：

• 字典（可以理解为库）：类型于目录的作用，罗列出了采集方式（自动、手动），配置项分类（比如硬件相关的、网络相关的、业务相关的），配置项（如，物理机、虚拟机、交换机、FW等）；
• 配置项（可以理解为表）：配置项里要列出属性（可以理解为列属性），列属性就要列出来需要涵盖的属性字段(开发介入，还会增加对应的数据类型-string、布尔之类的)、关联关系（和其他属性项之间如何关联）、备注信息（采集源、采集方式）。

这些CI属性项表后面还要再找使用方确认，是不是已经覆盖了需求。同时还要输出一个能力要求模板，能力要求里会明确调用频率、调用接口时延要求、需求方、关系数据的起始终结点、数据输出的类型等。这个是产品成型后进行功能稽核要用到的。

四、投入建设

投入建设阶段，从投入方式上有使用开源、全新开发、基于开源二次开发或者直接购买企业版四种情况，如果涉及开发的，还需要加入开发模型设计的过程。从建设过程方式上，也分有从上往下构建和从下往上构建两种情况，见下图：

大多数需向业务应的企业会选择从上到下的建设方式，偏iaas层的CMDB则会选择自下而上的建设方式。这两个建设方式的不同体现在配置上，我上面有配置项的描述很多就是自下而上的建设方式。自上而下的是先某某APP、下面对应的业务模块、业务模块所在的主机、主机所在物理机-存储-网络等。自上而向下的建设如关注点见下图：

在完成在服务器的搭建以后，CMDB最重要的数据录入的环节，建议先是以某个应用需求开始，先进行录入和满足，再逐步满足其他应用。

五、形成能力和持续关注

形成能力这个很多就是使用方的事，比如根因分析和监控常见的一个场景，就是把CMDB生成的关系图调处，结合监控数据在输出的图上进行颜色区分，一眼就可以看出整体的问题出在哪一块儿，再在对应的块上进行上下钻。比如共性分析功能，可以通过将一批问题设备的上下联关系调出，通过程序求交集，得出这些设备是不是共同连接了一个存储，或者共同连接了一个交换机，可以辅助问题判断。这种能办输出后，要让应用需求方尝到甜头，这样才会有越来越多的应用感兴趣。

持续关注，CMDB的数据随着企业发展和架构演进，里面的数据也需要是活的、准确的、可快速更新的。只有长期形成，需求-采集-调用-能力这样的循环中才会形成面向应用的CMDB能力。不能建设完成后，长期不更新或停止关注，这样最后CMDB的命运就是一个摆设，各团队各用自己的表格自己玩。

以上总结结合业内一些理念和自己在实施过程中的理念进行杂糅汇总，视角偏产品经理方向。