CMDB在企业中是如何实现的，有什么缺点？

CMDB业内做的最好的应该是HP和BMC了，不少传统企业都实现过了，现在说说缺点：

1. 老问题，不够灵活

2. 成本高，特别是现在大量的“屌丝”系统（X86+Linux)

3. 实施周期长，客户现在都想构建“小而精”的系统

4. 以前的CMDB更多面向“管理团队”，而不是“运维团队”

5. 信息不实实。

目前我的想法是，企业要构建的CMDB，实际上把它叫成CMDB有些太大了，我平时称为“主机信息管理系统”， 和自动化运维平台进行整合，系统安装完成后，就已经纳入到主机信息管理系统中，可以从各个维度搜索查看相对应的主机信息并进行统计。

总体来说，是一个面向“运维”团队的CMDB。

举例：除了openssl的漏洞，官方给的数据是在6.4一下版本中都有该Bug，那么，以前的CMDB要通过什么样的手段才能Run出来6.4版本以下的系统信息呢，Run出来之后，如何进行统一变更呢？

所以，CMDB也是要和自动化运维平台进行整合，这样，信息才能帮到操作。

我在之前的项目中，通过puppet的fact机制，收集主机信息到数据库中，1. 为了运维的方便，所有系统一定纳入到了puppet管理中，所以，不会存在着“不在管理”的系统。2. 按照一定条件，搜索出来的主机可以直接进行自动化运维操作，一站式！