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

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

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。