本人从事自动化运维相关工作，由于工作关系，自身与厂商、集成商、同业、运维同行交流过程中，CMDB话题是一个解不开、绕不过的话题。通常双方都会开门见山地问“你们的CMDB是用了哪家产品”“CMDB有几层模型”等等，这些问题不能说问的不对，只是不算是打开cmdb的优选方式。借这个机会和大家交流一下我们正在开发使用的CMDB。

一、CMDB的前世今生

CMDB官方称呼是配置管理数据库，当看到这个概念时，就能体会到概念出自ITIL此等运维管理体系，咱们先做第一步翻译，CMDB就是存取管理对象相关信息的仓库，那什么是管理对象？管理对象的信息又包括哪些？ITIL体系是方法论，不可能直接给出一个具象化的数据类型表结构，体系作为放之四海而皆准的道理，所以定义的门槛就要足够底，因此每个客户现场对于管理对象的广度、深度的定义是差异化的，管理对象是给管理层使用的概念化的名词，如果用基层技术人员的白话来翻译一下，就是应用、系统、网络类技术人员所维护的具体实例，以我个人经验，管理对象的范围至少应该包括应用系统、服务器、操作系统、数据库、中间件、网络设备，管理对象的深度至少包括应用系统名称、统一编码，应用系统所属主机（操作系统）IP，该操作系统对应的物理机机型、序列号，对应物理机所在机房、机柜，应用系统对应负责人员姓名、联系电话，至于为什么收纳这些管理对象，是因消费场景而设计，此处先卖个关子按下不表，后文分解。

二、CMDB的误区

因为CMDB的提法是随着ITIL体系的推广而在客户之间广泛传播的，按ITIL的说法CMDB用于存取信息，可是前十多年间的实践来看，客户随ITIL体系电子化过程建立CMDB，做了大量存信息的工程实践，我接触过的商业CMDB软件，在支持数据录入、数据采集方面可谓煞费苦心，从人工录入，snmp采集到脚本采集，实在不满足，还可以“脚本+二次格转入库+多方调和”的形式，可以说存数据方式已经发挥到了极致。取可以理解为消费CMDB库中数据，这个环境要结合每个企业的自身情况，其中消费实践相对单薄，商业软件厂家、集成商也只是结合自身实施项目经验而定，所以要想把CMDB功能发挥得好，关键是靠客户自身的运维经验。以前CMDB功能重点在存，所以做出来的CMDB大多是台账功能，有点类似资产系统或者有些客户直接把资产系统包装成CMDB，在我看来，CMDB的基础属性是台账功能，供人工去查信息，我们要用发展眼光去思考问题，以前把CMDB做成台账受限于技术，由于十年前云平台并未如今日之大行其道，自动化工具开源产品相对较少，如今技术突破，客户环境也逐渐从物理机转向了云环境，直接影响就是管理的主机多了，管理主机也多使用自动化批量脚本命令了，传统与ITIL结合CMDB逐渐转为和自动化或云平台融合，做一套具备自动化能力的CMDB更符合时代需要。我们的工程实践也是通过CMDB建设推动CMDB数据消费，打通ITIL、CMDB、自动化平台、云平台、资产平台之间的连接。

三、此CMDB非彼CMDB

在软件开发项目管理中也有CMDB的概念，而且是项目管理的重要过程，其实很少有人把这两个概念搞混，因为开发、运维自成体系，双方人员也各玩各的，我的理论基础不深，朴素的感觉来看，软件开发过程中的项目管理，运维体系的ITIL体系，对于过程的把控原则有种同根同源的意思，通俗的比喻有点像降龙十八掌和九阴真经，一个是外功至尊，一个是内功修炼，两方各自将武功练到最高境界，都是独步江湖的武林高手。双方的宗旨都是建一套公共库来管理信息（存），库中信息能够被更多人、系统使用（取）。

四、双模IT

Devops发酵的速度非常快，越来越多的用户在尝试使用这种模式，技术层面少不了各种自动化工具、CICD工具，这是一个专业课题，在工作流程层面同样带来了挑战。双模的说法也是人为总结的概念，发展成熟的互联网企业必要也会随企业发展而固化沉淀出适合自身的工作流程，在互联网环境成长的企业，IT自动化运维、测试程度更高、代码从开发到发布周期更短频度更快，如果速度不快就失去了市场，被残酷竞争淘汰。传统企业也面临着迫切敏捷要求，在某些应用系统开发运维过程中，采用快速迭代，减少工作审批环节，自动化打包、编译、上版等过程，传统企业与互联网企业相互借鉴，最终达到共识，国内企业大部分是基于ITIL或ISO20000体系构建了自身的管理流程，长时间来遵从ITIL思想成为稳态运维的代表，以互联网企业为主的模式则被定义为敏捷，这里面并不是说ITIL就不敏捷，互联网就不稳定，相信ITIL、ISO体系也在进行理论升级，到时会有关于稳态、敏态下能够指导用户落地的知识体系。在稳态环境下，因为开发、运维周期相对较长，所以对是否自动化要求并不高，ITIL上走了变更，线下由各自技术团队去执行方案，实际上流程审批与操作执行是两条线进行，在这个背景下用户有CMDB需求，但CMDB是否准确并不是真正影响到操作执行。在敏态环境下，开发、运维周期都缩短到周为单位，自动化工具是敏捷的必要手段，工具化时代，CMDB作为一个系统模块其中存储的数据就能够为各类工具服务，此刻就突现了CMDB的重要性，敏态是工具化的天下，也为建设CMDB提供了方向，CMDB如果能够和自动化工具结合更紧，CMDB的使用效果就更明显。我眼中敏捷的一个诱人的场景就是通过看板类项目管理工具，用户在前端界面化处理一个个描述性需求点，把需求状态改变成受理、开发、测试、待上线、上版等各个阶段，后台工具能够根据前端需求状态变化而改变现实生产环境、测试环境中应用系统代码的状态，实现了持续集成与持续部署。

五、实践经验

在企业做CMDB，可以拆分为产品开发和产品运营两个阶段，第一阶段是CMDB库搭建，第二阶段CMDB数据采集、数据调和；第三阶段是CMDB数据供给，当中数据获取、数据供给又是循环往复优化升级的过程。康威定律告诉我们，企业沟通方式会通过系统设计表达出来，这点在我们实施CMDB中体会颇深：建设CMDB是个偏技术活，而使用CMDB则是个侧重管理的事情。企业建设CMDB必然面临对原有专业条线工作模式的调整，因为原来是每个条线、每个小团队、每个人一本账，当有了CMDB后，理论上每个人的台账应该不需要了，大家的信息能公共汇聚到CMDB库中，按照事先设定好的规则进行调和成一份实时更新最权威的数据。

在现实中，技术能解决的事情往往是比较直接而简单的，建数据库，数据库表可以前台图形化定义，库里的数据支持搜索，有多个数据集的概念，不同数据集可以设置调和规则，数据修改能够留痕可以查到以往版本，高级点的能够采用非关系型数据库、图数据库、内存数据库，可以对拓扑关系进行快速存储展示，市面上的现成产品或是企业自主研发的产品能够具备这些功能。可以说后台技术并不需要特别领先时代的东西，我们在现实中的难度在于，CMDB的数据力求准确，为了提升准确率，我们采用“倒逼”机制，首先为CMDB中每类数据找到消费场景，通过用户使用数据来检验数据；其次为每类数据找到产生源头，源头是数据产生者，数据相对准确的提供方；另外重要的是，要将更新数据过程渗透到用户的日常工作中，用户的任何工作都有流程，日常已经有了N个工作流程待处理，但不要让用户为了维护数据而单独走第N+1个流程，对于一个按ITIL体系运转的企业，日常工作离不开电子化流程，过程中涉及到现有流程的优化改造。我们通过几个消费场景来直观感受一下，如果构建CMDB。

1、基于自动化工具的采集项

我们企业部署了自动化工具，基于操作系统上安装自动化代理工具，对于任何系统级操作，包括不限于操作系统巡检、数据库巡检、中间件巡检、应用程序发布，理论上都通过下发定制化脚本完成；自动化平台也包含了网络管理，交换机、路由器、防火墙等各种网络设备，网络维度的设备巡检、配置、变更也都通过自动化完成。所以自动化平台能够管理的目标对象，就构成了CMDB基础的配置类，基于自动化脚本，我们能够采集到自动化平台可以管理的任何信息。推行ITIL、ISO体系的企业，对于基层技术人员来说，走流程是比较头疼的，因为流程太多，日常的工作往往还做不完，还要应对合规管理的流程，鱼和熊掌不能兼顾，从简化工作出发CMDB的数据采集入库，在各专业条线技术用户在使用自动化平台的过程中就完成了。

（1）A系统应用系统管理员，利用自动化平台进行应用程序发布，该应用管理员必须要完成的先前工作就是应用系统建模，脚本编写，选择目标服务器，这些模型数据就是CMDB中记录的数据，因此应用管理员建模的过程就是初始化、更新CMDB的过程。当主机操作系统管理员要对服务器进行巡检，操作系统管理员在自动化平台配置了巡检项、巡检策略，这些项目就是CMDB中记录的数据，随着自动化平台的巡检任务的执行，数据就更新了CMDB库，完成了操作系统管理员的巡检任务，也完成了CMDB相应信息采集工作。

（2）当有新建应用系统或应用系统扩容了服务器时，自动化平台需要纳管新增服务器时，用户通过电子化流程发起申请，申请单中携带必要信息，待流程审批通过后，后台数据有企业内部流程系统推送自动入CMDB库，完成了自动化平台的服务器纳管，纳管后的服务器按照自动化平台设定好的巡检任务，进行相应配置项采集。尽量减少人工干预的环节。

（3）对于存储、光纤交换机设备、esxi虚拟机没装自动化代理的设备，我们采用“分布式”模式，虽然自动化不能直接与某个具体存储设备交换信息，但存储整体有管理控制台，光纤交换机可以通过cmd方式登录，虚拟机由vcenter可以集中管理，自动化平台纳管这些专业领域的控制台，各类控制台对下属存储、光纤交换机、虚拟机可以采集信息，前期CMDB人员对此类信息进行格式化拆解并设定规则定时入库。因此曲线地完成了信息自动方式入CMDB库。

我们划定CMDB管理对象是自动化能覆盖的范围，对于那些不能部署自动化代理，仍采用手工维护的对象，CMDB提供的功能仅是台账，CMDB提供信息记录、查询功能。

2、非自动化类配置项

CMDB中的配置项不可能全部由自动化平台获取，对于非自动化类配置项，就需要根据具体配置项产生的过程，让用户通过电子化流程的方式进行数据更新。

（1）应用系统名称、编码。应用系统名称是人为定义的概念，比如企业中会有A系统、B系统，应用系统名称产生、修改流程依靠相应负责架构管理处室组织有关开发、需求处室人员线下开会讨论确定，最后通知给各方人员是通过公司内部OA系统发文完成的，频度一年四次，周期较长过程并不透明，鉴于应用系统名称是从需求提出时就可能需求，后续系统开发、投产上线、运行发布变更等开发、运维环节都需要的一个重要配置类，需要从源头就能落实。我们是通过新建一个电子化流程，在线下讨论环节完成后，流程起点由申请人提出应用系统名称申请，经需求、开发、架构管理处室相关人员审批后，新增应用系统名称、编码按规则产生，同时将产生的数据-应用系统名称、编码入库CMDB。后续应用系统上线电子化流程、应用系统名称更新电子化流程中需要应用系统名称字段时，通过电子流程后台向CMDB库取对应数据，流程审批完成后，将数据更新结果，同步到CMDB库中。

（2）应用系统负责人员。人员信息包括基础信息：姓名、公司oa账户、所属组织机构、联系电话、在职状态，关联关系信息：与人员对应的应用系统。人员基础信息来自公司电子化流程平台，由于早期流程平台与公司oa系统做了数据同步，可以将姓名、公司oa账户、所属组织机构字段信息同步过来，加之我们公司重视ITIL流程，科技人员包括分行人员都使用电子化流程平台完成工作审批，各审批节点都配有短信通知，所以我们判断科技人员的联系电话目前阶段在流程平台存储的相对准确，因为是正在使用的数据。所以CMDB与流程平台直接定时同步人员基础信息。应用系统与负责人之间的关系，通过在电子化流程平台制作了一个简便流程，通过自服务模式，让原应用系统负责人提交申请将负责人岗位移交到新负责人，通过流程审批后，更新的数据同步至CMDB库。实际使用中，配合着定期检查手段，保证了自服务流程的正常流转。

3、数据调和与消费

（1）CMDB的基础功能就是数据调和，每个管理维度是对CMDB数据的切片。比如主机所在机房、机柜信息，初始需要系统管理员在自动化平台服务器纳管阶段手工更新，入库之后，CMDB基于自动化脚本能力可以采集到物理机aix、linux、windows操作系统所属主机硬件机型、序列号、设备厂商，面对虚拟化的linux、windows操作系统，CMDB采用调用vcenter api方式，获取虚拟机所在esxi信息、对于硬件设备机型、序列号、设备厂商信息。CMDB与公司资产管理系统通过数据接口进行交互，资产管理系统通过RFID电子标签标示物理设备机房机柜位置，双方根据设备序列号作为关键字，CMDB可以获取实时更新的物理设备位置信息，此时资产系统关于设备位置数据集在数据调和优先级高于初始通过人工录入的数据集中的位置信息。

（2）基于多维度数据调和汇总成一张全面立体的数据网，这样就构建了多种消费场景，CMDB能够提供主机操作系统ip到所属主机硬件机房、机柜的信息，当出现监控告警时，能够发现告警的应用系统部署的故障操作系统对应的设备所在位置，故障设备至上运行的主机操作系统、其上运行的应用系统，便于精准定位故障。基于CMDB的自动化能力，能够采集到主机ip、mac地址，通过与网络交换机采集到的ip、mac地址进行关联，能够构建出应用系统、主机、网络交换机之间的关联关系。通过采集主机光纤卡wwn，光纤交换机上wwn，能够构建出应用系统、主机、光纤交换机、存储之间的关联关系。通过服务器纳管、应用系统自动化发布的模型构建，能够构建应用系统在同城双中心运行状态拓扑结构。

（3）CMDB通过数据接口供多个系统工具使用。公司内部监控系统引用应用系统名称、应用系统所属主机ip、应用系统维护人员与联系方式，与监控自身告警项匹配后，可以将告警项精准推送至相关人员。公司内部安全审计系统调用CMDB数据接口，获取应用系统名称、应用系统所属主机ip，供安全审计进行应用系统风险评估。专业人员通过CMDB可以查询应用系统、应用系统所属主机ip，主机操作系统、数据库、中间件版本、位置等各类配置项信息。

4、需求驱动

最后重申一下实施CMDB的原则，有数据消费的需求就想办法通过自动化手段进行数据采集，这样能节约成本。因为一路走来，虽然CMDB自身有产品但在用户现场落地，都需要进行定制化开发，一方面模型的初始化建立、后续更新，另一方面与公司已有工具系统融合对接，我们自身也只是说在逐步摸索，并不好说是独步江湖。个人感悟，CMDB是靠用起来的，技术只是一部分，关键是如何将CMDB融于自身企业的工作流程当中，这里面用户自身是主要决定因素，外部的实施方、咨询方给出的建议都是放之四海而皆准的框架，没有错，指导落地场景时，还是看最终用户、消费场景的需要什么数据，CMDB去反推此类数据如何获取，获取后又通过什么样的工作流程保证数据及时被更新，这些过程只是用户自己去体会。当工具选择上，如果是企业内部只有一套云平台、自动化或者什么类型的工具当然最好，这样做便于技术上统一，但现实中往往不太可能，除非是刚刚起步的企业，否则一样会有各种历史包袱，老的系统还在运行，新的工具加入，新的技术背后带来的是新的组织沟通模式，这里面是一种企业模式的重新调整，要从技术、管理、组织架构上进行适应，否则如果只是技术上去适应，往往效果会打个折扣。啰啰嗦嗦写了很多，很可能我们面临的痛点在大家面前根本不痛，我觉得是企业性质、企业文化使然，康威定律在指挥着大家的工作，这次是抛砖引玉，希望能为各位提供一个思路。