企业自动化运维巡检管理方案

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

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

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

如何解决？

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

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

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

初始数据收集工作量大：

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

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

如何解决？

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

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

17

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

如何解决？

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

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

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

如何解决？

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

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

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

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

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

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

18

如何解决？

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

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

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

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

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

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

如何解决？

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

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

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

如何解决？

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

19