OneCMDB中文

去年做的省公司IT服务流程中设计了了一个“不可用CI”报告的功能，同时配置管理流程里面针对配置变更有“配置变更申请”功能，同事对这两个功能不能理解。因为在实际开发过程中，开发人员将“不可用CI”报告的功能最后操作定义成了直接更新CMDB，不需要走流程，而将“配置变更申请”功能需要走“CMDB控制和维护”流程。同事的疑问不可用CI是否会破坏流程性及用户误操作。我的意见是这两个功能都不可缺失。

配置管理员是配置管理流程中主要工作承担者，其职责为：通过手工或自动化操作增加及更改配置项，保证所负责的关键CI的关键属性、关键CI间的关键关系完整、准确。实际工作中由各专业技术人员分别担任配置管理员，维护各自所管的设备或应用。配置管理员可以按照基础架构的分类划分，也可以按照所属业务的类别进行划分。也就是说实际过程中配置管理员数量会是1+个。

配置管理和其他流程关联原则

• 配置管理和变更管理的关联
  • 变更主管在变更计划阶段必须制定配置项更新计划，对计划修改的配置项进行说明
  • 变更实施完后，由变更主管汇总相应的配置项修改的情况，并通知相应的配置管理员，配置管理员接收到配置项修改请求后，与CI实体进行核对，核对无误后方可修改CI属性以及关系
  • 对于风险等级为高和重大的变更，CAB中应该包括配置经理，以确保对CMDB的适当控制
  • CI应与变更记录建立关联，从而对CI的变化情况进行记录
• 和事件管理、问题管理的关联
  • CI应与事件记录、问题记录建立关联，从而确保对CI维护工作的统计和分析

从配置管理和其他流程关联关系来看，配置变更主要由变更管理流程发起，也就是需要提供“配置变更申请”功能给变更流程作为流程接入点，但是在实际中配置管理员需要对CMDB中数据准确性负责，然而在事件流程、问题流程或者其他流程过程中发现CMDB中记录的CI实例值更实际情况不符合（例如：CMDB中记录Sever1连接Switch1的23端口，但实际却是连接Switch2的3端口），这种情况怎么办呢？发起变更流程？工程师没有变更任何东西呀。这种情况下应该做出CI例外报告（HP这样的翻译实在不好），就设计了一个功能专门用于报告CI不可用的情况。

两个功能设计如下：

• 不可用CI报告：用于其他流程运维人员提交CMDB中记录有误的情况，用于辅助配置管理员收集错误的CI。配置管理员在收到不可用CI报告时需进一步核实CI情况，以便修改CMDB数据或者发起配置变更申请。
• 配置变更申请：为“CMDB控制和维护”子流程正常入口，用于变更流程或者配置管理员发起CI修改流程

在查看BMC Remedy IT Service Management功能之后，发现BMC中有一个“创建CI不可用性”的功能，名称好近似呀。不过BMC定义：CI 不可用性是指 CI 的实际宕机时间。您可以记录因某事件导致的意外情况引起的 CI 不可用性。看来在引入ITILV3后续流程后需要重新对不可用CI报告重新命名，以免误会。

注：转自Dominic.Xu’s 博客，原文地址：http://web2world.cn/article/2010/07/a146.html

建立、实施CMDB应该注意什么？

本人负责并参与过ITIL相关评估与研讨，配置管理与CMDB的建立一直是ITIL建设的核心与难点，在这里谈谈我个人的看法，供大家参考，并希望共同探讨！

首先强调一下配置管理的核心地位：

事件管理、问题管理、变更管理、发布管理都是与配置管理紧密相关的，试想如果CMDB对故障设备的hostname与location提供了错误描述，事件能够得到及时解决吗？如果没有配置管理的同类故障统计分析支持，如何实现主动的问题管理？如果没有配置管理提供CI之间的关系作为依据，如何针对将要进行变更的CI做风险评估？ITIL实施的难点之一就是因为这些管理，并不是相互孤立的，而是相互关联并且相互制约的，而配置管理恰恰就是这些关联的枢纽与核心。

要建立与实施配置管理，要清晰配置管理的相关概念，并避免几个误区

这些概念包括什么是配置管理、什么是CI、什么是CMDB、CMDB与DSL/DHS (V3用的是DML)的关系等，建议准备真正实施ITIL的人一定要熟练掌握（个人感觉V3的SACM（服务资产与配置管理）的相关定义比V2描述的更加清晰），在这里我不会具体赘述概念本身，但强调一些大家可能会有的误区。
误区一CMDB= Asset DB，准确说CMDB> Asset DB, 这个大于有两层含义，一 CMDB中的CI包含所有服务资产与IT组建，如设备、服务、系统、人、知识、文档等，远远大于asset db中的设备; 二CMDB是一个更大的逻辑库，更侧重CI组建的逻辑映射与关联，这些关联必定会很立体并远远复杂于Asset DB。
误区二 配置管理=CMDB，这也是很多实施ITIL的人容易有的误区，务须置疑CMDB是配置管理的核心， CMDB的范围与深度，理论上说其实是可以无限扩展和细化的。但是评估配置管理，不是要评估其CMDB有多么多么准确与详尽，而是要看，根据其当前现状（IT资源与运行状况）与管理（范围与深度）的要求，是否去规划、识别、控制、监控、验证各配置项的版本以及相互之间的关系，从而确定基础架构或服务的逻辑模型。所以配置管理≠CMDB，而是围绕CMDB开展的一系列动作。

那么，建立、实施CMDB应该注意些什么？常用工具有哪些？

第一 不要急于求成

要认识到，“罗马不是一天建成的”，实施ITIL、建立“完善”的CMDB永远是一个需要永不停息的追求过程，要充分认识到其艰难性，要做好打持久战的准备。

第二 管理范围要合理、粒度要适度

粒度要适度，是指CI的定义不能过粗，也不宜过细，如何界定过粗、过细的原则和标准呢？说到底是要应该基于管理要求出发（当然管理要求如果越高，投入CMDB初期建设的精力与成本也一定会水涨船高），例如本人在做一家知名网络公司的评估时，发现其管理要求是要细化到硬盘部件级，那CI就一定要细化到部件级，而不能是系统级（整机级）。

第三 CMDB界面要友好

何为友好，就是要可视化、易检索；

第四 要可调和、可联邦

这个有点术语话了，简单解释一下，大家如果看过V3的书会发现V3用CMDB1、CMDB2….替代了V2的CMDB，这也是实际实施ITIL中的现实情况，这就要求不同的CMDB要有集成能力（向下调和），同时要有共享能力（向上联邦）

第五 可维护、可扩展、可更新

没有绝对“完善”的CMDB，但不完善的CMDB要能够通过不断扩展、更新、验证等步骤实现相对的逐步完善。

第六 注意安全保障

无论如何针对记录了完全核心内容的CMDB，一定要注意安全保障，如设定严格的权限访问控制等。

关于CMDB模型与工具，给大家推荐BMC 的 Atrium CMDB模型，是业界普遍认可的理想CMDB模型。

本文转自：智朴人生 – 畅享博客，原文地址： [原创]关于配置管理—建立、实施CMDB应该注意什么？