最近的一些 CMDB 项目和测试中都用到和测到了自动发现工具，很多用户对此的理解和看法还不是很到位。 **首先：“自动化配置和关系发现工具是什么？” **它是 CMS 工具集当中的数据采集工具。 从产品名称上看，往外都带 DDM，它是 Discovery Dependency Mapping 的缩写。意思就是帮你发现 CI 和 CI 之间关系的工具。很多用户的各种 IT 管理工具都可以自动发现网络、服务器和应用的配置项以及之间的关系，那么为什么还需要在购买一个新的发现工具呢？其实发现工具解决的真实发现工具不统一和发现数据不统一的问题，更重要的是它可以发现配置项之间的依赖和影响关系。对于一个数据中心来说，变更会经常发生，那么一套应用运行了一段时间之后，你很难准确的说出它都连接了那些其他相关的设备，很难理解它当前的部署状态。我们希望发现工具能帮我们更好的洞察当前 IT 基础架构的构成，应用对设备的依赖，底层 IT 服务对业务的影响。**其次：“它是如何工作的？” **它的工作原理和其他所有的管理软件也没什么太大的差异。基本上讲有两种技术：无代理发现和有代理发现；三种产品形式：纯粹无代理扫描方式、纯有代理方式和混合方式。无代理采集必须依赖被采集设备的开放协议，常用的采集协议有：snmp,wmi,telnet,ssh,jmx,http 等。往往需要在被采集设备上配合一定的账号和权限。采集动作往往是定时、周期性或者触发式执行。扫描结果返回一个数据库中，准备向 CMDB 同步。再次：“它是 CMDB 必须的工具么？”对于下面几种情况我个人认为它是一个必的工具：1）数据中心用户，服务器和应用成百上千套，变更每周都会进行，新业务系统增长快。CMDB 需要使用它来自动更新配置项信息。2）应用多是多层的复杂应用，CI 之间依赖关系复杂，物理连接图已经不足够用来做影响分析，CMDB 需要它来自动化维护配置自己的关联关系，通过它可以减少进 70%的手工工作量。从国外的一些项目经验上来看，50%的 CMDB 用户并没有使用配置自动发现工具，他们使用的配置数据多是监控管理系统中已有的，CI 间的关系靠手工维护。最后：“它是如何与 CMDB 同步的？”有些厂商的 CMDB 是从发现工具上起家的，所以他们本来就使用的一个库，没有同步问题。有些厂商的发现工具是整合的其他产品工具或者收购的，他们自己的同步就需要一定得数据模型了。通过数据模型来解决数据字段映射的关系，一般来讲 CMDB 中会有数据模型 CDM，发现工具同步的时候就以该模型为准，把 CI 和关系经过一定的过滤条件同步到 CMDB 中。不同厂商的发现工具和 CMDB 如果需要同步的话，需要满足起码这样几点需要：CMDB 必须有标准的数据模型来做数据映射；需要有某种数据集成和同步的工具来连接两个数据库；CMDB 中需要具有强大的数据调和功能来处理发现工具带来的数据。