[转贴征文]CMDB的生命模型
学习资料：IT运维管理社区专家讲堂直播300期视频回放
有这样一个业务场景：
服务商AAA为客户提供IT服务，现在已经一款软件版本已经在生产环境运行了（由AAA开发），CMDB中对应的CI是CI001，当前的软件版本是1.0，由于此软件存在BUG，已经完成开发与测试，正在做发布流程作业，对应的软件版本是1.001（CI002），另一方面此软件一直在做一个功能增强，目前正在开发过程中，对应的版本号是1.100（CI003）。这是一家号称ITIL导入成熟的服务商，现在的问题是，这三个CI现在如何在CMDB中记录与其管理，还有后续的业务过程该如何作业？
假设我们把CI001、CI002、CI003都记录在CMDB中，那么这时CMDB中记录的范围需要从由外部的生产环境扩散到内部的生产环境，这是一个很大的概念转折，这预示着我们从运维对象的创始之初就需要开始管理，而不是投入运营后才开始管理，这里就形成一个悖论了，ITIL中有清楚明示过需要从设计之时就介入么，一直以来我们的理解是投入运营后，ITIL关注的是这一个生命周期的管理，如果软件的开发与测试环节是外包给另外一个公司做，那么AAA的作业肯定是从新的软件版本发布时才进入CMDB，或者如果是一个全新的软件项目，那么AAA的作业肯定也是当软件发布到客户的生产环境中后，才会进入CMDB记录，这时我们看到存在一个灰色的地带，到底ITIL或ISO20000中的配置管理是从什么阶段开始，从方法论与标准的角度而言，似乎不应该有如此的灵活性与变通，因为这会很大程度上失去了方法论与标准的作用了，这是第一个问题，到底是从什么阶段进入CMDB。
如果三个版本三个不同生命阶段的软件版本全部记录在CMDB中，这预示着有三个CI，这时又会带来另一个问题，如果CI001已关联5个事件2个变更，本来版本1.001发布成功时有一种做法，可以直接更改CI001的属性，这样历史的数据关系与记录都一直继承着，但由于现在是独立的CI了，这样版本1.001（CI002）发布成功后，必须先将CI001的状态做更改（严格来说，CI001都应该被删除，因为它已不存在任何物理世界了），再将CI002置入生产环境中，这时会造成两个问题，一个是历史的数据关联会随着以前的软件版本迁移，二是从服务的角度而言，更多是关于这个软件的情况，但现在这种CMDB的管理模式造成难以知道这个软件的整体情况了，现在的主要概念是针对各个版本了，反而最重要的主体概念没有了，这会带来一系列的问题，这里面首先是一个理论问题，其次也是一个CMDB技术问题。
现在把问题集中一下：
1、配置管理的范围是基于整个服务的生命周期，即从设计、开发、测试、一直到实施与运营，还是仅仅是从运营阶段开始？
2、如本案例的情况，到底是只需要建立一个CI即可，还是每一个版本的软件都需要建立CI？
3、不管理建立一个CI还是建立多个CI，配置维护的方式如何进行？如果解决数据关联的问题，比如想知道一个CI关联的事件、变更等等。
有一些ITIL的书籍中有粗略的介绍过，用主体+变体的处理方式，但这样的详细实现方法没有明示，而且这主体与变体与DSL及流程单据的关联的复杂度会成指数增长。本来思考这个问题时，是好久之前，但一直没有成形的记录下来，在考虑这个问题时，我当时联想到，ERP中的一个核心的要素即BOM（Billofmaterial），ERP中的BOM与ITIL的CMDB有一些类似，但又不尽相同。在ERP中，BOM是分几个阶段的，在设计阶段有E-BOM、在生产制造阶段有M-BOM，所以CMDB如果想管理对象的整个生命周期，在逻辑上也有两种做法，一是针对不同的生命阶段建立不同的CMDB，即设计阶段的CMDB、开发阶段的CMDB以及实施阶段的CMDB以及运营阶段的CMDB，二是同一个CMDB将每个CI按不同的生命周期管理。在直觉上，我一直没有放弃对建立不同阶段的CMDB的想法，因为这是一个有力把运维从设计开始的作业模式落实的一个有力手段，而且这时才真正把规划到运营的整个信息关联起来，然后还可以追溯每一个阶段的配置变化。
当一个IT工程的规划师在做方案时，就可以建立一个粗浅的配置信息，把他头脑中的规划信息置入Design-CMDB中，然后随着规划的深入，会不断细化深入相关的信息，此时CMDB的CI数量与属性逐渐丰富起来，当最后成形时，评审过后，则进行发布，此时这个规划案就在CMDB形成快照，然后进入开发阶段，这样每个生命周期均记录下本身需要关注的配置信息，最终各个环节的信息组装在一起时就是一个全面的配置信息了，同时也可以满足任何阶段的信息需求，初级的模型如下：
当从逻辑与概念上切分了CMDB的不同生命阶段后，ITIL们关注的仍是O-CMDB，O-CMDB只是对生产环境的最终描述，依赖于CMDB本身的检索技术可以把握所有的变化过程与数据关联。而将CMDB的概念与CMMI等方法论进行融合，这样既可以满足任何一个独立环节的作业与管理需求，同时不会冲击生产环境的配置信息，而且在问题根源追溯会起到很大的作用，另外由于各个生命周期的发布控制，对最终O-CMDB的数据精度会有促进作用，而且就维护而言，我们不再恐惧于庞大的CMDB数据构建了，因为它被切分在不同的阶段不同的人员作业。而最终上述的问题的解决也是显而易见了。
除了死亡，一切只是概率
转发自“破子博客”
支持，支持！！ CMDB的设计是个大问题，要不用不了，要不不好用 支持楼主，用户楼主，楼主英明呀！！！ 是爷们的娘们的都帮顶！大力支持
页:
[1]