ITSM平台和CMDB集成的主要场景

本文主要谈CMDB和ITSM的集成的一些应用场景，以及非常关键的一个话企业，就是CMDB的自动化发现问题。最近在越来越多的上市企业的运维组织看到这样的需求，没有CMDB，很多工作甚至无从下手，比如如何有效的控制变更的风险。包括越来越多的专业厂家，已经将CMDB作为一个单独的产品来做。
企业随着业务的发展，应用系统越来越多，以及新信息技术的不断引入，基础架构越来越庞杂，IT资源规模是越来越大，IT架构的复杂性也与日俱增导致信息科技管理与运维服务工作面临相当大的挑战，因此很多企业引入科技服务管理平台来确保科技运营管理、服务体系落地及日常工作的风险管控，ITSM与CMDB平台的对接帮助客户解决了很多方面的问题。

在具体项目实施中往往会与企业内已有的平台做对接（如：监控系统、SSO平台、协同办公/OA、运维自动化平台、云管、安全审计系统、CMDB平台等），形成数据和流程的联动，便于数据资源更好的“消费“与”被消费“。

众所周知CMDB平台的作用是管理一切IT硬软件资源、状态及关系映射，为上层平台提供数据消费。主要的场景如下图所示：

针对其中一些场景，我来举几个例子，并展开来谈一下：

1）读取CMDB平台中的数据为各大管理流程用于资源定位、故障根因分析、变更影响分析等，比如说一个应用系统、CI的变更会有哪些联动的上、下游系统受到影响，进而帮助评估变更的风险等级和需要哪些CAB参与会签；
2）读取配置数据为服务级别(SLA)提供数据因子，在流程执行过程中自动匹配对应的SLA；传统来讲，一般的SLA主要是和服务目录、优先级（优先级=影响度*紧急度）来定义，所以更多是还是依靠人工的选择和判断，进而人工决定了SLA的级别。实际上有CMDB的模型，可以更客观和智能一些。
3）读取配置数据为健康检查提供支撑；巡检可以按照业务系统的维度去上下游支撑关系的维度去巡检，而不是依靠依靠经验固化的巡检模板或固定的、粗颗粒的系统或者资源维度。
4）读取配置数据为容量管理及分析提供支撑；
5）读取配置数据与流程记录关联形成全生命周期管理；也就是可以从流程的维度去看CI，也可以从单独的一个CI或者一个业务的维度去看有哪些生命周期流程，比如事件、问题、变更、发布等等。
6）读取配置数据与供应商、合同管理及任务进行关联，便于数据的一致性及完整性；很多传统的CMDB是有资产属性和资产管理的应用场景的，那么自然就会涉及到类似于维保厂商、维保的起止日期、过保提醒之类的诉求。
7）对于不能通过自动发现且需要依靠人工或变更流程来更新的配置项需要返写到CMDB平台。
8）事件的处理，自然就不用多说了。关键时，不知道它是谁？有啥影响？有哪些上下游的关系，就很麻烦。

以上几点只是列举了部分场景，从集成的广度和深度可结合企业实际情况做具体分析,截至目前国内市场已有很多不错的对接CMDB平台厂家，并且在企业实际应用中取得了非常好的成效。

对于CMDB，除了尽可能有更多的有价值的应用场景来驱动之外，当然尽可能去做自动化发现，这些目前主流的观点。手工维护，领导有要求，下定决定一时是可以做好的，但是热情一过，95%就准确率也是等于0，因为在最终发现不知道哪些是那5%。

目前市场上主流的CMDB，比如BMC的CMDB、优维CMDB、神州信息的CMDB其实都是有自动化发现能力的，尤其是有些CMDB厂家借助于自身的自动化能力，可以把CMDB的自动化发现能力很强，脚本扩展性也很强，还可以支持有代理和无代理两种方式。

本文地址：https://blog.csdn.net/linhong99/article/details/108781230