虽然配置管理本身不是一件复杂的事情，但建设一个有生命力的CMDB仍然需要一些方式方法，如何让运维工程师平滑地将传统配置管理的方式迁移到CMDB上，如何收集、管理配置信息，如何消费配置信息从而最大程度地发挥出CMDB的价值等，都是值得思考的。
1、关于配置项
明确了CMDB的定义之后，一个比较难的内容来了，那就是配置项。配置管理的本质是对配置项进行管理，那么首先我们需要梳理应该管理哪些资源的哪些配置项，这是一个关键点，很多人容易在这个地方迷失自我而无从下手。可以将上述问题拆解成两个问题：第一个问题是哪些资源应该纳入CMDB进行管理，第二个问题是哪些配置项应该纳入CMDB进行管理。
对于第一个问题，普遍认为所有的IT设施都应该纳入管理，但这只是一个目标，并不意味着一开始就能达到，在实践中，我们要按需接入，持续迭代。由于不同类型的资源往往接入方式和配置属性差别较大，一般情况下会先对资源进行分类，然后根据需求逐步接入对应的资源，例如为了对应用发布提供支持，应用服务器是我们需要优先考虑并进行管理的对象。
对于配置项的管理，通常情况下我们也会对其进行分类，例如针对应用服务器，我们可以将属性信息分为3类，包括基本配置信息、静态属性信息、运行时属性信息。基本配置信息包括资产编号、设备型号、品牌、资产上架时间、维保到期时间等；静态属性则包括CPU核心数、内存大小、磁盘大小、数量等；运行时属性信息包括CPU负载、CPU使用率、内存使用率等。其中，CMDB需要管理的是基本配置信息和静态属性信息，而运行时属性信息则不需要纳入CMDB进行管理，因为CMDB建成之后，我们只需要对接监控系统，就能获取到运行时属性信息。
2、兼容使用习惯
在运维工程师的日常工作中，即便没有CMDB，配置管理的运用也无处不在，例如Excel表就是其中一种形式。大多数情况下，运维工程师会维护多种信息的Excel表：关于服务器的Excel表记录了服务器的配置信息，机房的Excel表记录了服务器的布局信息，SA的Excel表记录了应用配置信息和部署信息，DBA的Excel表记录了数据库资源的分配信息，网络工程师的Excel表记录了策略开通的信息等。这些都是配置管理的体现，只是通过Excel表来进行承载。CMDB首先要做的便是对配置管理系统化，相应需要考虑到的便是兼容运维工程师的使用习惯，即如何将Excel表中的配置信息抽象到CMDB系统中，这样不仅能提高配置管理的可维护性和便捷性，也能为配置属性的抽象和归纳提供参照，对后期CMDB系统推广也提供了潜在的帮助。
3、配置信息收集
配置信息的收集，实际上是将资源管理落地，首先我们要做的是对资源进行分类，一般情况下，可以通过资源面向的服务类型来进行分类，例如基础设施层、中间件层、应用层，也可以根据资源的特性来进行分类，例如硬件资源、软件资源。
通常情况下，底层的资源配置信息以自动收集为主，人工录入为辅，例如对应用服务器来讲，操作系统的版本号、CPU核数、内存大小等配置就可以自动收集，而资产编号、上架时间、合同编号等配置就需要人工录入。
对于应用层和中间件层，则主要以人工录入为主，自动收集为辅，例如应用的日志路径、部署路径以及类型等就需要人工录入，如果科技团队内部的标准化做得比较到位，那么这其中的部分工作也可以自动化实现。总地来说，配置信息收集的基本原则是基础配置信息自动收集，逻辑配置信息人工录入，不过即便对于自动收集的配置来讲，仍然不能缺少手工复核的过程，以保证数据的准确性。
4、有价值的功能
有了配置数据之后，就要分析如何应用配置数据打造一个面向消费的CMDB，即从中能挖掘出哪些有价值的功能。经过分析，我们总结了以下几个要点。
- 统一的配置查询。CMDB存储管理了各种维度的配置数据，能快速有效地进行资源检索是一个关键能力。通常情况下，我们在查询的时候往往希望能够关联出任何和查询条件相匹配的数据，例如通过IP能查询出关联的虚拟机、物理机以及运行在上面的应用等。这种查询方式使得易用性和查询的效率变得更高，同时查询结果也更加立体。然而传统的关系型数据库并不能达到上面的要求，在实践中，可以考虑将配置数据同步到ElasticSearch，然后利用ElasticSearch灵活强大的查询能力进行查询。
- 报表中心。运维的对象是资源，那么难免会涉及对资源状态的查询，对资源容量的监控等。在传统模式下，运维工程师们通过定期输出报表来达到类似的目的，而CMDB存储管理了各种类型的配置数据，对于报表的制作有天然优势。例如：通过获取监控数据，我们可以定期输出监控报告；通过查询资源使用情况，我们可定期输出容量报告；通过定期巡检，我们可输出巡检报告等。CMDB通过报表中心对相关报表进行统一配置和管理，数据中蕴含着无穷的价值。
- 资源状态关联查询。在实践中，CMDB往往并不局限于自身的数据收集，其强大之处在于通过关联系统来获取关联数据，从而实现过去无法满足的应用场景，例如：我们想找出没有被监控的服务器，通常情况下，只有当事件发生后，才发现没有被监控，告警没有发送出来。CMDB可以解决类似的问题，因为CMDB管理着所有配置数据，关联监控系统后，就能获取所有设备的监控信息，从而能很快定位出哪些设备没有被监控，哪些监控项没有正确配置。另外，前面提到资源有一部分运行时属性，关联监控系统后，就能够很容易地获取到，这使得在CMDB上不仅能查询到资源的静态配置信息，也能动态获取到资源的监控信息。