4、从哪里下手建立CMDB

如果一个组织是“从无到有”的状态下建立CMDB，建议采用“从上而下，逐步扩充”的方式，因为这个方式是比较经济适用，见效最快的。另外常用的“从下而上，从资产数据整理，逐步精炼CI”的做法不但时间成本投入巨大，而且很容易陷入“只见树叶不见森林”的情况，同时见效也慢。

所谓“从上而下，逐步扩充”就是从“服务目录”开始着手，从目录清单中找出核心业务（基于核心业务分析的结果），然后从这个服务出发，挖掘出支持业务的相关支持资源，并梳理出与支持服务相关的属性和关系，改造出一个“服务CI金字塔”。在这个过程中，服务目录是出发点，SLA是参考。

在提炼CI的时候，一定要注意投入和价值。管理都是有成本的，而且在配置管理中，不但牵扯到成本问题，还牵扯到真实性的问题。一个全面但失真的CMDB还不如一个简单但真实有效。

除了以上方式来提炼出CI建立CMDB外，还要注意一下活动是要提炼CI记录到CMDB中的：

——资产出库

——正式版本发布到DML

——相关文档的发布（重要的文档是要被纳入到CI进行管理的）

——监控工具发现新的设备

——审计发现

——建立CI基线

——IT人员入职

——发展一个新的供应商

那什么时候CI从CMDB中删除呢？——建议是不删除，只改变其状态

微信扫一扫，阅读更方便^_^

5、 配置基线的理解 理解配置基线的概念前要先理解“快照”的含义，所谓“快照”就是发现工具抓拍的配置的当天状态。这里的“工具”是的广义概念，不是特指某个东西，可以理解为一个可以产生结果的行为。 所以，配置基线就是产品或者系统在某一个时刻的配置状态。这个状态在实际工作中用来做什么呢？主要用在两个方面：1、用来做影响分析。当计划变更时，需要利用当前的基线信息来做变更的风险，影响度分析以确定是否执行和如何应对。2、是回退标准。上一个状态的基线是每次变更回退计划的依据和参考，同时，也可能根据情况要回退到更早的基线状态下，因此，不同时期的基线是要保留的。 作为基线的内容，不仅仅是要体现产品或者系统的结构，还要放映其具体的内容。
6、 配置项之间的关系 在CMDB中有一个重要的信息集合，它用来描述配置项之间关系。按照经验来说，关于CI之间的关系一定不能过细过多，而是要抽象出来，彼此之间具有明显的区别，这样才能方便现实中的使用。多细的关系分类不能很明显的区别出之间的不同，很容易导致同一个关系在不同人标准下的认知歧义。 具体来说，CI之间的关系分为两种：物理关系，是配置项之间的物理关系，一般可以归纳为“构成”、“连接”和“需要”三种。有一点需要特别强调，这个关系是带有“方向”属性的，即在描述关系时要使用“构成××”，“连接××”和“需要××”。CI间还有一种关系称之为逻辑关系，包括“拷贝”、“涉及”和“被使用”三种。
7、 配置管理告诫 个人认为，配置管理是一个渐进的过程，不要从开始就贪大贪全，从实用角度出发，先解决主要问题，记录有业务意义的关系，记录有效益的关系；关键业务关键服务的恢复需要哪些配置项，就把范围划在哪里；开始的切入点要正确。从服务的识别开始梳理起，服务-应用-设备-OS/中间件/系统…；切记20-80理论，切记“完美主义害死人”这句话。

学习了。

{:soso_e179:}

很不错啊！