配置管理的颗粒度考量需要参照哪些要素
学习资料：IT运维管理社区专家讲堂直播300期视频回放{定义}配置管理的颗粒度通常是指某个配置项记录的详细程度，这种详细程度表明了该配置项的纵深关系，也就是如何从深度和广度两个层面来有效定义一个配置项。
{分析}有效定义配置项的纵深关系是配置管理所需要解决的重要问题之一，因为这关系着配置项的实用价值和后期维护成本。例如，我们可以设计服务器→OS→应用这样的纵深关系，也可以设计为服务器→应用这样简单一些的纵深关系，这里大家应该可以看出，第二种关系模型，由于取消了OS这一层CI，那么OS的属性将只能矮化到服务器的属性里，我们可以对服务器增加两个字段“操作系统类型”、“操作系统版本”，当然这也也有局限，因为操作系统的其他属性不可能全部增加到服务器CI上，这样配置信息管理的颗粒度就粗糙了，给IT服务带来了一定的影响。但是，从维护成本上来看，显然第二种情况减少了CMDB的维护工作量，这个功能上的损失是值得的。
{实践}在设计配置项颗粒度的时候，需要把握两个重要问题：使用价值和维护成本。下面有两个真实场景，可供参考：
[*]在CI纵深关系的设计中要考虑IT的发展趋势，例如虚拟化、云计算，我们原来服务器→应用的关系发展为服务器→虚拟化平台→虚拟机→应用，我们要在CMDB建模阶段就要能识别和设计出来，因为如果到了后期才进行改造，工作量是很大的；
[*]有些朋友会认为CMDB中应该忠实地反映出网络设备的连接拓扑，而我不建议大家这么做。原因有二，一是CMDB的任何信息都必须要有明确的消费场景，而一般来说，网络工程师更愿意根据自己的网络架构图或网络自动发现工具所呈现的拓扑图来分析和解决问题，二是网络链路有时非常长，一条链路牵涉的物理设备或逻辑设备也可能非常多，如交换机、路由器、网络、子网、路由、光端机、调制解调设备、配线架、跳线、信息节点等，变化也比较频繁，如果要及时、真实地维护起来，这个管理成本是比较高的。这个意见对于那些懂得CMDB原理而又没有深入体验CMDB实践的人来说可能不可接受。我可以告诉大家的是，国内某著名的银行，到目前为止，CMDB也并没有将整个网络联络全部管起来。根据20/80原则，我们在有限的投入下，必须聚焦核心的CMDB数据采集和维护。
综上所述，确定配置管理数据库的管理范围，需要遵循信息量与管理成本相互平衡的原则。如果管理范围过小，会造成不能充分提供IT服务管理所需信息的困难；如果管理范围过大，会造成管理成本上升，运行效率降低的困难。鉴于配置管理与IT资产管理的区别与相关性，CMDB的分类与属性的设计建议更多的侧重对与运行和维护相关以及技术方面的内容，而较少涉及财务方面的信息，此类信息应为IT资产管理的范畴。但是在具体实现配置管理数据库的过程中，应充分考虑到CMDB与IT资产管理之间的关联与联系，也可考虑在配置管理数据项属性中设置一些与财务、价值相关的属性，从而可以及时反映一些与资产管理相关的信息。
页:
[1]