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

作为资产管理就默认不准确是一种常态，无论通过itsm流程来保证，还是通过自动化运维来保证数据的有效和联动，都一定会存在不准确，不及时的问题；关键原因还是传统的CMDB是IBM，BMC，HP，CA从主机、小机年代传递下来的思维，尤其是金融机构和大型企业，业务，开发，运维完全是不同部门，所以cmdb必然就是一种资产管理，靠打补丁是无法实现完整的快速业务需求和配置消费准确联动的； 另外就是cmdb本身的技术结构，传统试用关系数据库，带来的更新难度非常大；增减都很困难，不仅是数据一致性的问题，关系都很难在变更中保持完整描述。 新一代的cmdb已经从资产转向了业务/应用资源，从应用和业务的视角看到所设计的资源对象，要求资源对象本身默认就要保证是真实、及时、一致的，而不一致的情况属于特例，同时新一代cmdb/it资源对象管理的技术从传统关系型数据库转向了图数据，从而实现了复杂和变更都不影响关系描述的记录和修改。 更近一部，把资产配置 转变为 业务/应用资源对象，更是从管理功能，转向了业务支持能力，也就是管理成为了业务的支撑，这也是it管理的真正目标。

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. 按照一定条件，搜索出来的主机可以直接进行自动化运维操作，一站式！

转一个吧，剖析的很透彻：

1. 缺乏合理化、整体化的规划

需求不清晰，定义了不合理的配置广度和深度。

在大而全? 还是小而深? 方面犹豫不决：

这种决策机制在项目初期往往耗费了大量时间，但随着新技术的不断涌现，这种方式已经无法适应越来越敏捷的IT环境，我们发现一种相对静态的CMDB模型已经不能满足纳管新IT组件的要求。

如何解决？

用一种更为灵活的CMDB模型扩展机制。

采用了不正确的管控策略：

按照经典ITIL的管控和项目实施机制，配置管理规划，尤其是CMDB模型的规划往往由项目组承担，一旦规划完成后整个模型也就变得很难再进行扩展，应该说这里采用的是一种集中管控的策略。

但在实际IT运维工作中，我们发现对于CMDB使用最多的是各个二线团队，不同团队之间对于CMDB 深度和广度的要求，以及管控方式都有较大差别。

如何解决？

基于集中分布式的理念建立CMDB管控体系

2. 配置管理人员职责定义不清晰

配置经理、配置管理员、配置Owner之间职责不清晰：

按照ITIL或ISO20000中对于这三类角色的定义往往过于宽泛，没有进一步考虑实际运维人员的运维场景，以及使用的运维工具，导致职责定义和实际做事方式脱节。

如何解决？

结合运维场景、运维工具、流程角色职责，对于各角色的职责进行重定义。

角色职责和岗位的对应不明晰：

在没有ITIL以前，在企业IT部门或数据中心往往找到不到一个现成岗位对于IT配置信息进行集中管理，而是每个人各管一摊。

实施ITIL后，究竟由哪个部门的哪个岗位承担配置经理这一职责往往是最让人伤脑筋的，最后往往是赶鸭子上架。这种角色定义方式最终导致体系无法运转。

如何解决？

基于集中分布式的理念设定角色和岗位的对应关系

3. 配置管理成了IT运维的负担

这其实是CMDB在企业落地所面临的最大挑战，无法充分调动运维人员的积极性，主要体现在：

初始数据收集工作量大：

存量的配置数据往往基数很大，一般配置的量级在5000以上，考虑到云化环境的海量运维场景，这个基数还会更大。

随着分布式应用架构以及微服务架构的兴起，未来一套新应用系统上线引入新的配置项数量也无法简单通过手工输入的方式来完成。

如何解决？

借助自动化手段进行数据采集

单一的自动化配置发现工具只是一种幻想：

如前所说，约从2007年开始，业内引入了自动发现工具用以解决配置数据的初始化问题，但由于这类工具往往由某个厂商提供，导致了配置发现的局限性，企业往往也要付出较大成本。

如何解决？

建立适配多类自动化工具的CMDB架构，将企业现有的脚本、监控工具、自动化工具、云平台都转化为配置数据的提供方。

投产后由于变更频繁，数据无法保证及时准确：

以往企业一般采用变更操作驱动配置修改（人工修改、或自动化发现修改）的方式以确保配置数据的准确性，这种方式往往出现了配置信息的不一致。

如何解决？

建立基于配置基线驱动的IT环境变更（操作）架构，即建立通过配置修改事件触发变更操作的事件响应模型。

对于未来软件定义环境，这种架构是一种必然选择。

如何让人人“乐于”参与：

这里的参与主要体现在二个方面：

1）需要使用与自己相关的配置数据时，CMDB可以立即提供；

2）遇到CMDB无法提供的数据时，IT部门可自行在一定标准和约束下扩展满足本部门运维CMDB模型，支撑部门级的运维场景。

如何解决？

建立小、快、灵的CMDB架构，支撑快速扩展、快速纳管、快速交付数据。

4. 配置数据的价值无法呈现

缺乏清晰的场景定义，包括流程价值、监控价值、BSM价值、云价值等：

单一流程驱动CMDB的场景，无法让CMDB中的数据流动起来，随着时间的推移CMDB中的数据就逐渐腐败—不及时也不准确。

同时，CMDB在技术上作为一个“数据库”，要让其中的数据能够流动起来，必须明确与之匹配的运维场景。

场景是用来描述与CMDB中某些配置项交互的一组活动，满足IT部门某一方面的运维管理目标，这一目标可以被度量、跟踪、改进、可视化，与此同时，CMDB的价值也随之呈现。

如何解决？

建立基于场景驱动的CMDB解决方案集合;

缺乏有效、明确的配置数据集成策略：

如前所述，CMDB是一个逻辑上的数据库，其中的数据需要和企业现有IT环境中的多类数据源进行整合，一套行之有效的数据集成策略和ETL（数据抽取、转换、转载）工具也必不可少。

如何解决？

建立数据集成策略，引入ETL。