|
CI关系是CMDB的重要价值体现之一，也是配置管理建设与IT资产管理建设的区别之一。没有了关系，CMDB就是一个CI孤岛，将沦为资产库。在进行配置模型设计时，需要定义CI关系，从而决定关系信息是否可用于分析CI之间的影响或依赖关系。CI的关系可以是一对一、一对多或者多对多。识别出CMDB中需要使用的CI关系以及对其维护比较困难，但是关系数据对于IT流程而言有着重大的意义。关系一旦明确，运维人员就可以借助通过关系顺藤摸瓜，准确定位相关资源，一旦事件发生也能快速定位故障源以及影响范围，从而迅速解决事件或者找到问题根源。
CI的关系可以从逻辑和物理的角度来区分：
l逻辑关系：如一个OA系统使用了一个数据库；一个邮件系统安装于一个操作系统上；一个操作系统使用了一个IP地址； l物理关系：如一个ERP系统安装在一台PC服务器上；一台PC服务器通过一台交换机的一个端口与外网连接；一个ERP系统的数据存储于一台存储设备上；一台存储设备安装于一个机房的一个机柜上；
关系的分类可包含：依赖于、应用于、使用、支持、复制、付费、父子等。目前有一种分类思路是，所有这些关系都是“依赖”关系。并且这种依赖关系往往是带有方向性。
关系举例列表【来自bmc资料，做了小幅度修改】： | | | | | | 依赖于 | A依赖于B | B是A的被依赖者 | A依赖于B | 逻辑/物理 | 大部分关系均可应用此关系解读。请看下表。 | 应用于 | A应用于B | B是A的被应用对象 | B依赖于A 理由：B被A所应用的内容影响 | 逻辑 | 信息安全策略应用到事件管理流程。对信息安全策略的修改可能影响到对事件的处理。 | 使用 | A被B使用 | B提供A的用途 | B依赖于A 理由：A的改变将可能导致B无法使用或用途改变 | 逻辑/物理 | RFID读卡器用于仓库管理流程。一个损毁的RFID读卡器可能令仓库管理流程无法进行。 | 支持 | A支持B | B被A支持 | B依赖于A 理由：当A提供支持时，B才可能提供承诺的服务水平 | 逻辑 | 服务器支持组对服务器提供支持。 | 复制 | A是B的复制版 | B是A的原创 | A依赖于B 理由：任何对B的改变都可能影响作为复制品的A | 逻辑 | 应用系统备份。 | 付费 | A为B付费 | B被A支付 | B依赖于A 理由：缺少A的付费，B可能无法正常工作 | 逻辑 | 信息中心为某个存储设备付费。 | 父子 | A是B之父 | B是A之子 | B依赖于A。 理由：B将代表A的某些特性，也可理解为具体描述了A的某方面特性。 | 逻辑/物理 | 主板是内存的父亲。同一条内存不可能同时安装于两块主板上。与之类似的关系还有属于、安装于、存放于、部署于、在……之内，在……只上，等等。 |
实际工作中，一般可以采取两种方法进行CI关系的梳理工作，即“自上而下”和“自下而上”的方法。“
l“自上而下”通常要求企业先明确对外所提供的服务，编制服务目录，然后基于服务目录按照“业务服务——IT服务——IT系统——IT组件”的顺序进行梳理，从逻辑关系向物理关系或其他逻辑关系延伸； l“自下而上”则是逆流而上，先从对内部IT组件关系的梳理开始，然后逐步将IT组件映射到IT服务，从逻辑或物理关系向更高层次的逻辑关系提炼。
万事开头难，确定了梳理工作的方向后，从千头万绪的CI和关系中应该如何找准第一个起点？我们建议可以先选择一个“依赖于”的关系。然后根据实际配置管理的需要逐步添加更多的关系
CMDB配置项关系设计样例(以某个业务系统为例)【来源网上，需要对其中关系文字作进一步修改】：
以后资料可以参考：
| | | | | | | | | CI可独立存在运行，CI之间有物理连接，A和B之间存在连接关系 | | | | | | | | | | | | | A与B属于不同的CI层次，通常情况下是软件A部署在硬件B上 | | | | | | | | | A是B的一部分，在没有B的情况下，A没有独立存在的意义 | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A与B是可独立存在，之间存在逻辑依赖关系，在没有B的情况下，A无法实现其业务目标 | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A和B属于同类CI，A与B之间存在主备关系，其中，A是主，B是备 | | | | |
| 
转播
分享
淘帖
()
