OneCMDB中文

IT服务管理论坛（itSMF）香港分会制作了ITIL V3词汇对照表，该指南对在大中华地区工作的ITIL研究员很有帮助。

下载地址：

ITIL® V3 英/繁/简 词汇对照〔精装版〕 http://www.itsmf.org.hk/eng/dl/ITILV3GCRG-P2%20v1_0-200905.pdf

在IT管理向ITSM（IT服务管理）体系演进的征途中，CMDB（配置管理数据库）从传统的电子报表中走来，蜕变为基于ITIL最佳实践的IT服务管理核心。对于所有的ITSM体系的建设者而言，CMDB都是一部庞大机器上必须精心打磨与调试的一个关键部件。

“水域，这是俄罗斯的必需！”彼得大帝的慨叹表达了一个民族对海洋的渴望。而在获得了出海口之后，封闭的俄罗斯终于打开了通往文明欧洲的窗口，走上富强之路。CMDB之于ITSM，或许远不如十六世纪海洋对于俄罗斯如此那般的迫切。但是在今天的IT管理领域，CMDB在完整ITSM系统中的核心地位绝对无可替代。今天，CMDB不仅是管理软件厂商和ITIL倡导者常挂嘴边的时髦词汇，也早已成为企业用户在IT管理项目推进中关注的焦点。

“通过更先进的资产管理和自动化流程，帮助用户建立跨系统的数据管理关联，从而最终推动跨功能的流程整合”是CMDB对用户的最新承诺。而在阐述CMDB现阶段的定义之前，必须说明的是，CMDB并不是IT管理领域的新生事物或名词。从诞生至今，CMDB经历了三次脱胎换骨的技术蜕变。实际上，早期的许多管理软件中都包含了现代CMDB的雏形，它们以电子报表的形式出现，简单记录IT资产信息；后来，CMDB演变为依附于帮助台的资产库，与帮助台捆绑并向用户销售；如今，CMDB摆脱了管理软件附属品的角色，成为独立的系统管理模块，是企业级集中式的配置数据库。

英国商务部出版的《ITIL服务支持》一书这样定义CMDB：“它是一种包含每一个配置项（Configuration Item，CI）全部关联细节以及配置项之间重要关联细节的数据库”。可以说，是ITIL最佳实践孕育了现代CMDB，目前CMDB中配置项信息覆盖了企业网络中的应用、操作系统、补丁、硬件设备、生命周期成本以及用户链接。针对目前大多数企业中IT配置数据以不同格式保存在桌面机、服务器、补丁包、操作系统和网络设备中的局面，CMDB把不同格式的数据统一采集到一个信息库中，打破了IT域之间的固有壁垒，有效管理IT资产。同时，通过对配置项信息的分析，快速定位系统故障来源。

而伴随着ITIL版本的刷新，CMDB在整个ITIL框架中的作用也悄然发生着变化。有专家指出，ITIL v2奠定了CMDB在ITSM中的重要地位，而ITIL v3则进一步释放了CMDB的效能，将其与知识管理和报告展现紧密地联系在一起。

模型设计：专注数据完整

有人将当下全球盛行的ITIL实践形容为一场“奥林匹克”盛会，一方面在“重在参与”精神的感召下，ITIL在企业用户中迅速普及；另一方面，“更高、更快、更强”的目标激发了参与者的潜能，用户和IT服务供应商开始追逐更有效率、更有效果的卓越IT运营能力。在这一轮激烈的竞技之中，CMDB因其对企业ITIL实施效果的决定性作用，被比喻为ITIL的“发动机”。

而在许多基于ITIL的ITSM项目中，实践者虽深知CMDB对于企业IT服务管理能力的重要性，但在部署过程中却往往被CMDB构建所涉及的庞大工作量所困扰，感觉困难重重，不得要领。同时，由于CMDB数据库工业标准尚处在讨论和修订阶段，并未形成通用标准，也让许多实践者感到无法从成熟规范中寻求支持。因此，有分析人士指出，IT管理者需要从CMDB概念的混乱中找到一条通向管理数据集成和最佳实践的路径。

要实现CMDB的成功构建，CMDB的设计和运作是必须攻克的两大难点。如果设计不当或无法有效运作，将极大地制约ITSM系统的管理能力，让IT运营的效率和效果大打折扣。同时，也只有实现了合理的模型设计和配置管理流程的有效运作，我们才能深入地探讨CMDB工具的选型，以及软件开发、数据挖掘和知识管理应用等更高层次的话题。在CMDB设计层面，对CMDB模型完整性的保证是设计过程的重中之重。

由于CMDB是ITIL流程支持的核心，它需要为ITIL其他流程提供IT服务及基础架构层面的配置信息，所以只有CMDB记录的数据完整，才能准确地反映IT服务的真实状态。而所谓CMDB的完整，包含了配置管理范围的识别、CI属性的选取和CI关系的构建。

第一步，确定配置管理的范围。这主要涉及CI的宽度和深度，以及CI的生命周期。需要说明的是，ITIL规范认为，CI的生命周期是从CI的接收到最终报废退出的全过程，但在具体实施过程中，由于流程管理主体的差异化，不同项目对CI生命周期的划分和定义会有所不同。

在确定CI的宽度和深度时，设计者应当从企业IT服务的需求、企业IT服务管理水平和CMDB运营管理成本三个方面进行合理规划。具体来说，CMDB构建应该主要从IT服务角度考虑，IT服务本身也可以作为CI记录到CMDB中，同时IT服务涉及的IT基础架构及其相关的重要信息都应记录到CMDB中；必须认识到CMDB与企业IT服务管理水平之间紧密的联动。企业IT服务管理水平越高，其对CMDB的依赖程度也随之上升，对CMDB数据的准确性和完整性也越高。同时，企业变更管理的成熟度，包括变更管理范围和流程执行力度也将在很大程度上影响CMDB数据的准确性和完整性；成本方面，CI的颗粒度决定CMDB中信息的详细程度，而这些信息的有效维护取决于IT部门投入的管理成本。如果无法投入相应资源进行CMDB的维护，其数据准确性便无法保证，也无法发挥其应有价值。

CI生命周期的确定主要包含对两个问题的确定。一是什么时候识别CI并记录到CMDB。在标准的配置管理流程中，CI全生命周期的理想状态应该覆盖从采购申请到报废退出的过程。但在实际实施时，流程执行主体的管理范围和职责将决定CI被识别的时间点；二是什么时候删除CI记录。这一时间点同样由流程执行主体的管理范围和职责所决定。例如，对于租赁的CI，IT部门并不关心它的报废过程，只关心其在生产环境中的运营状况，因此CI被租赁公司更换，则该记录就有可能被标记为删除。而CI记录的删除并不是数据的真正删除，而是将其标记为删除，这样做的目的是为IT审计提供数据支持。

第二步，定义配置项的属性。对于同一类型CI属性的定义，不同企业的定义方法可能截然不同。通常情况下，设计者需要遵循一个原则和一套结构。一个原则就是“精而不多”。如果我们将大量属性纳入CMDB，那么无疑将加大信息维护的成本。反之，如果属性过少，CMDB对流程支持的有效性就降低了。所以，所谓“精而不多”就是找到适合自身需求的平衡点。ITIL专家指出，CI属性的定义要注重选择的属性是否具备“面向服务的特性”。例如，一台商用服务器可能会包含上百个属性，但实际上经过筛选，对企业有实际意义往往是CPU个数、CPU主频、内存、硬盘、网卡等信息。

一套结构指的是，我们通常可以把一个CI的属性分为五大来源。具体的划分方法如附表所示。

第三步，构建CI之间的关系。CI关系的定义也是配置管理建设与IT资产管理建设的区别之一。一般可以采取两种方法进行CI关系的梳理工作，即“自上而下”和“自下而上”的方法。“自上而下”通常要求企业先明确对外提供的服务目录，然后基于服务目录按照“业务服务→IT服务→IT系统→IT组件”的顺序进行梳理；“自下而上”则是逆流而上，先从对内部IT组件关系的梳理开始，然后逐步将IT组件映射到IT服务。

流程运作：确保数据正确

上线后的CMDB需要向ITSM系统提供准确的配置管理数据，尤其是要做到所记录信息与生产环境的数据保持一致，这就需要建立一套良好的配置管理运作机制。这套机制包含了制定配置管理策略、确定变更/发布与配置之间的流程关系、制定CMDB审计流程，以及配置管理的角色安排等工作。

1．配置管理政策的制定 该政策是企业配置管理的行动指南和共同纲领。它能够帮助企业统一认识，减少不必要的沟通成本，实现流程的高效执行。配置管理政策主要包含宏观政策和运营政策。其中，宏观政策涉及企业或IT部门层面指导性、方向性的政策，目标是在企业内部形成统一认识。例如，IT部门应该使用统一的配置管理流程，并且使用标准的文档记录和汇报机制。

运营政策主要涉及到流程目标、人员、输入、输出、活动以及KPI（关键绩效指标）等要素，以及流程之间相互协调、信息交互方面的指导原则，其目标是使流程能够在政策的指引下稳健、有效地执行。一般而言，包括CI的命名规范政策、CMDB数据保留政策，以及数据备份和恢复政策等。

2．确定流程间的接口关系 要实现CMDB的有效运作，成熟的变更/发布管理流程必不可少。其原因是，这一流程掌握着CMDB中数据变更的通行证。变更/发布管理流程与CMDB更新之间的关系如图2所示。

在图2中，CMDB数据的任何变更都应该对应已批准的变更请求单。同时，由变更管理流程将变更信息提供给负责配置管理的相关人员进行CMDB数据的更新。其中，CMDB数据的更新主要包括以下三种情况。

一是CMDB数据结构的变更。通常发生在因管理需要而重构CMDB模型的情况下，例如新增需进行变更控制而未识别的CI，因服务调整而重新梳理CI间的关系等；二是新增或删除CI。即指对已有CI的操作，例如更换或报废设备，新采购标准的配置等。从方便管理的角度出发，IT服务供应商往往会制定标准配置清单，用户应根据实际关系需求，确定配置清单颗粒细节的符合度；三是，修改CI的属性。此类变更是针对某CI具体属性的操作，例如增加了某服务器CI的硬盘容量，就需要对其相应属性进行调整。需要注意的是，CI属性的变更通常会关联到其他CI属性的调整。例如，硬盘CI信息变更时，管理员还需要调整服务器CI的属性，将无疑会增加数据维护的成本。针对这一问题，建议企业在确定CI属性数据时，尽可能地从其他可靠数据源中获取。例如，可以将服务器需要的硬盘容量属性数据通过数据继承关系，从硬盘CI本身的属性中获取。

3．CMDB审计流程的制定 在确保CMDB变更准确性的前提下，变更管理流程的构建需要经历一个持续改进的过程。用户往往会遇到CMDB数据仍与实际环境不符的问题，这就需要通过审计流程来进行检查、分析和修订。

CMDB审计过程中需要注意的是，首次审计一般发生在CMDB初始化准备上线之前，此后CMDB的全面审计应该定期展开，企业应根据需要设置周期，一般一年至少展开一次。另外，CMDB还需要进行一些专项审计，从而小范围、细致地核查某类CI或某项关键服务所涉及的CI“账实相符”的状况。当CMDB审计发现数据不符时应尽快查明原因，并通过变更工单提请变更，最终修改CMDB数据。CMDB审计流程应该独立展开，审计员应由监管单位或部分的相关人员担任。

4．配置管理的角色安排 在政策和流程确立之后，具体的执行还是需要人来推动。因此，就进入了配置管理角色设置的环节。配置管理活动所涉及的角色主要分为四类，他们各司其职，共同协助完成CMDB的运作任务。其中，配置管理流程责任人需要对整个流程执行的结果负责，并拥有一定的流程管理权力；配置经理主要担当流程开发和管理的角色，重点确保配置信息的准确性和可用性；配置管理员负责维护配置数据，保证提供给IT部门的CMDB信息总是准确的；配置审计员则主要负责通过审计操作确认配置数据。各个配置管理角色之间的关系如图3所示。

部署CMDB：丰俭由人

CMDB构建的重点在于对数据变更的把握，管理者需要用最合理的资源保证CMDB信息的“新鲜度”。这无疑是一项艰苦的任务，好在在这一领域，一些先行者积累了宝贵的经验供后来者分享。同时CMDB已经在金融、电信、政府、教育等行业拥有了一定的部署规模，这些具有鲜明行业特色的案例将在同行业的CMDB构建过程中发挥示范效应。

中国工商银行在ITSM领域的实践一直处于行业领先地位，并且项目执行到位。在CMDB构建的问题上，工商银行并没有购买CMDB商业软件，而是采取了自建的方法。在解释选择自建策略的原因是，工商银行信息科技部的技术负责人表示，市场上商业化CMDB工具还不够成熟。目前，大部分的CMDB软件可以自动发现基于服务器的软件应用，并构建映射关系图，但是对于一些主机应用或企业自行开发的应用却检测不到。对于应用种类繁多，同时存在大量自有和遗留应用的金融企业，商业化CMDB工具对整个IT环境的覆盖能力有限。

自建CMDB虽然需要企业投入更多的资金，但CMDB的独立性和新鲜度却能够在企业内部就得到有效保障。目前，工商银行总行的资源管理库已经运行多年，实现了CMDB与帮助台、相关管理工具的有机结合，管理范围覆盖全行各分支机构，管理功能囊括主要的配置管理操作。而在电信行业，也有很多用户倾向于自建方式，主要也是考虑到商业CMDB软件对生产系统中管理对象的发现和管理能力欠缺的问题。

无论是购买商业产品，还是自行构建，CMDB的建设似乎都意味着企业需要投入巨资才能完成。这实际上是对CMDB的一种误解。作为IT服务管理实践的起点，同时也是ITIL的基础部件，CMDB的构建可以有很多途径。

美国杨百翰大学基于MySQL开源数据库构建校园CMDB便是一个经典案例。新数据中心的落成和学校与上级机构的合并驱动了杨百翰大学踏上ITIL实践之路，并着手进行IT资产配置数据的集成与分享。但是CMDB项目并没有足够的资金支持，因此他们着眼于开源软件。通过MySQL和廉价学生开发劳动力，杨百翰大学构建了具备常规配置管理特性的CMDB，并计划围绕这一数据库设计一个Web前端系统，并由此建立系统内的数据分级体系。在CMDB构建的过程中，杨百翰大学对CI的类和子类进行了仔细的筛选，有效规避了CI颗粒度过细而容易导致的部署成本上升和构建难度加大等问题。而在未来，他们计划将这一系统升级到甲骨文数据库平台。

联邦性：CMDB成熟的印记

Gartner 2006年发布的CMDB研究报告指出，并不是所有的配置数据库都是CMDB，它必须具备联邦性、协调行、同步性、映射和可视化四大特性。这份报告给出了CMDB软件成熟度评估的具体依据。目前，很多软件厂商都宣称可以向用户提供CMDB工具，在其ITSM解决方案中，也会包含CMDB组件。但如果站在专业ITSM实施的角度，它们中的一些更像是帮助台资产库尚未蜕变完全的产物。我们看到，很多所谓的CMDB得不到完整变更流程的支撑，数据的实时性无法保证；而一些产品介于IT资产库和配置数据库的中间，模型设计和配置策略不符合ITIL流程规范。联邦性、协调行、同步性、映射和可视化给出了区分不成熟和成熟CMDB的刚性标准。而现在，CMDB市场的发展仍然处在向这一标准逐渐靠近的过程之中。

联邦性是软件供应商难于攻克的部分，同时也是近期技术进展最大的CMDB特性。从2006年开始，许多厂商将CMDB的联邦能力作为产品研发的重点，并相继推出了具有联邦特性的CMDB产品。IBM在2006年6月所发布的CCMDB（变更和配置管理数据库）便强化基于开放标准的对IT资产信息的自动发现和整合能力，能够满足客户对联邦属性的需求；Managed Objects所推出CMDB 360°解决方案能够从多个厂商数据库中捕获配置信息，并自动协调相关CI和消除重复的CI，在联邦性方面取得可喜突破；另外，HP、BMC、CA、Symantec等公司都陆续推出联邦式CMDB。而围绕对Peregrine和美科利的收购，HP对三个品牌CMDB的整合工作也于今年宣告完成。

联邦式CMDB符合技术和应用的发展方向。这一点已经能够通过现阶段的客户实践加以验证。在高度异构化的IT环境中，企业将所有IT资产的配置信息保存在一个通用数据库的想法并不现实。如果能够将多个数据库连接在一起，通过一个逻辑配置数据库构筑一个联邦式的CMDB，对于企业而言是一种切实可行的方案。这样一来，客户不必把所有配置数据都存储在一个大数据库中也可以实时获取多来源的配置数据。联邦式CMDB通过记录不同数据库中配置信息的关联关系，在接到客户的访问请求时，快速追溯配置数据的保存位置。以前，很多厂商把CMDB的开发局限在自己的专有架构中，这种传统的技术方式限制了CMDB对多数据源配置信息的发现与集成能力，同时不合理的数据复制方式还会造成集成后CMDB中CI的高度冗余。联邦式CMDB则通过逻辑上对配置数据的灵活调用和统一管理，弥补了传统CMDB的缺憾。

推进方式：由点及面

CMDB的实施自然是“条条大路通罗马”，但在现阶段，从小处入手精心设计，逐步扩大CMDB的覆盖范围还是技术专家和企业客户所青睐的项目推进方式。传统的构建方法是自下而上地推进，也就是先做一个大的CMDB，在逐步精炼CI。但这种方式的缺点是投入巨大且浪费时间，很多企业耗时数年才能完成CMDB的部署，而后期的测试和上线同样涉及面广，费时费力；已经拥有简单配置数据库的用户往往会选择自中而上的推进方式，以现有数据库为基础，添加必要的CI和CI之间的关系后，用户可以用比较短的时间就组建一个功能相对丰富的CMDB。

而对于大多数从零起步的用户而言，“自上而下，渐进式扩充”是一种可行性更高的方法。专家建议，用户可以先从订单系统、邮件系统这样的垂直应用开始，尝试在单一环境中发现、收集、追踪和管理配置信息的技巧，逐渐积累配置管理经验。在构建了相对成熟的配置管理流程后，再构建更大范围的CMDB。

一些用户还会先期设计一个小型的试验项目，它会包含CMDB所必须的审计、控制、自动化等环节。启动这种试验项目可以帮助企业收获一些关键的CMDB部署体验，例如对IT资产配置的描述方法，如何通过准确的信息来支持IT服务管理，事件、故障、变更和发布管理流程的串联和磨合，以及如果更高效地对配置记录做出变更。

而有专家建议，在启动这样的试验时，最好选择一个能够得到广泛支持的IT服务，而不是对业务营收至关重要的IT服务。同时，这样的服务不应该需要进行频繁的更新，并且在IT系统框架中处在相对独立的环境之中。因为频繁的变更操作将增加管理的难度，也更容易导致管理错误的发生。

CMDB普及期待标准支持

CMDB在ITSM领域的重要性勿庸置疑，但是用户在相关产品选型上的疑虑在短期内仍然难以消除。长期以来，不同品牌CMDB之间的互操作能力一直无法让用户满意，这也是一部分用户不惜巨资自建CMDB的关键原因。由于CMDB本身的演进过程就非常漫长，并且在相当长的时间内是通过与帮助台捆绑的方式进入企业的IT环境的，那么配置数据库的重叠在信息化起步早的企业中便成了非常普遍的现象。如何将分散在不同应用中的配置信息收集起来，并进行有效的集成，目前的商业CMDB工具并不能提供成熟的解决方案。而这一问题的解决，有赖于CMDB标准化进程的快速推进。

目前这一领域的软件公司已经意识到，标准是激发CMDB市场潜力的催化剂。2006年4月，一个旨在建立配置数据共享通用规范的协作性组织CMDB联盟工作组（CMDBf）成立，成员包括IBM、BMC、CA、HP、微软等。今年2月，该组织推出了一份阐述配置信息共享机制的白皮书，8月该组织发布了公共过渡性草案0.95版本，定义了联邦式CMDB与其他管理数据库数据共享的形式。虽然CMDB规范框架初现，但与用户的部署需求及项目实施的步伐相比，其进展仍显滞后。这样的规范缺失虽不致于让用户的实践陷于无序，但这种状态的持续将制约CMDB的普及。因此，无论是出于市场拓展的需要，还是向用户提供规范化的部署指导，开放和遵循统一标准都应该是CMDB软件供应商的共同选择。

本文转自：cnw.com.cn，原文地址：CMDB配置管理数据库构建过程拆解

在ITIL的书籍中很容易就找到这张表，说明紧急度，影响度以及优先级之间的关系。

按照ITIL的说法，优先级=影响度X紧急度

我在这里要谈的是在实际应用中如何去应用优先级的计算方法。

举个例子，公司老总打电话过来，说他马上要开会了，但他的电脑无法连接投影仪。这个例子的优先级如何计算呢？

影响中X紧急度高=8小时内解决？估计IT经理第二天就被老总炒鱿鱼了。我认为优先级需要在这个公式内加入员工级别参数。例如，老总的级别是8，部门经理的是4，普通员工是1等。公式应该调整为优先级=影响度X紧急度/员工级别=影响中X紧急度高/人员级别8=1小时内解决。满足了实际的需要。

还有一种情况，如果邮件服务器罢工了，全公司都受到影响的话，那员工级别应该设置为多少才合理呢？定义为8？还是1？我以为，假设员工级别定义为8的话，那么优先级=影响高X紧急度高/员工级别8=8分钟内，这是不可能完成的服务；所以员工级别应该定义为1，例如，，那么优先级=影响高X紧急度高/员工级别1=1小时内解决。符合实际情况。

那么当上面两个支持需求同时出现时怎么办呢？

这就需要再增加二次优先级来解决，二次优先级可以通过加入影响人数的参数去获得，数值越高，越需优先处理。如上面的两个例子，分别的内部优先度为

第一个例子，二次优先度=影响人数1X影响中X紧急度高/员工级别8=1

第二个例子，二次优先度=影响人数100X影响度高X紧急度高/员工级别1=100

100>1，所以两个支持需求同时过来时，第二个支持会优先安排，符合实际需要。

注：本文转自：思瑶雅居 – CSDN博客，原文地址：再谈ITIL服务台中的服务优先级。

如果在IT服务管理过程中，我们的长期目标是建立一套有效率且有用的运营体系，那么，在开始就规划好短期成果是很重要的，当这些成果产生时，就会得到大家的认可和祝贺。

巨大的变革和持续的改进，比如ITIL最佳实践的实施，是需要时间的—有时候需要几年的时间。然而，大多数的人，包括高级管理层，都不能忍受这样的“长征”，除非在较短的时间之内有一些显着的迹象让他们看到，这个长征可以获得预期的成果，是值得付出的代价。

下面这个案例可以说明这一点。

某公司的IT经理戴尔是一个有着“大主意”的人，是一个有眼光的思想者。在另外两个IT经理的协助之下，他开发出了一套配置管理数据库（CMDB）方法，可以帮助企业加强对IT资产的认知和控制。

实际上，这三个人越琢磨这个机会，他们就越是意识到CMDB可以给企业的业务和IT运营带来很多利益。他们的提议最后获得了通过，后来，他们埋头实施方案，花费了一年多的时间。

按照他们自己的标准而言，他们获得了很大的成功：新的发现、开发出了新的审计工具和方法、定义了新的流程和行为，而且，还定义并实施了一个先进的CMDB系统。

然而，按照怀疑主义者的标准，尤其是CIO，以及要看到更多有形的财务上的利益以弥补支出的各部门负责人来看，他们三个人所做的事没有任何意义。

当被询问时，他们三人解释，大的变革是需要时间的。CIO和其他负责人暂时接受了这一说法，然而，在一年多之后，这个项目被中止。

变革的最佳实践

根据哈佛商学院领导力学教授John Kotter的理论，巨大的变革有8个关键的成功要素（如表1所示）。这一组织变革模式被广泛认为是引导转型的最佳实践框架。这8个关键要素中的第6个是“产生短期效果”。

在戴尔的这个案例中，如果他和他的同事精心地制定了一些产生短期成果的计划，他们的这个项目很有可能会继续下去，并最终为IT和企业业务带来助益。

如果在IT服务管理过程中，我们的长期目标是建立一套有效率且有用的运营体系，那么，在开始就规划好短期成果是很重要的，当这些成果产生时，就会得到大家的认可和祝贺。

这种方法可以证实我们所做的事情的有效性，并帮助赢得IT服务管理中一些关键人物的心，当然还有客户和我们的外部合作伙伴。

速效10法

下面是10种普遍的、可以快速产生成果的方法，在你制定规划时可以参考。

合并成一个事件数据库

即便企业有多个服务台，一个单一的事件数据库也会增强流程的连贯性和报告数据的完整性，并且有助于对事件和问题趋势进行更好的分析。这最终会帮助你对变革和改善做出更快更精准的决策。

建立单一联系点

所谓单一联系点不能混同于一个单一的服务台。对于不同的地区、语言和业务单元等，你可以相应使用多个服务台。

只是要确保每个客户在所有的事情上都只需要知道一个联系点。这是一个得到证实的效果良好的最佳实践，它将会使你在客户中获得声誉。

建立事件管理政策

在如何处理特殊的或预期发生的情况方面，要给服务台工作人员以确切的指导。如果在普通的客户服务技能上对他们进行了培训，却没能教会他们如何处理典型事件的特殊程序，那么，这所带来的风险就是，他们第一次会做得很好，也许第二次和第三次也做得不错，但是，每一次他们都可能会采取不同的方法处理事情。

在为固定的客户服务时，这是一个不会有错的方法。始终如一地与他们打交道，他们将会由衷地喜欢你。

考虑问题管理

这是ITSM的最薄弱环节。还有很多人认为，如果他们他们善于争吵，他们就会擅长问题管理。错！

要想有效地从事问题管理，你需要走出第一线，开始分析突发事件的数据。将这个任务写进工作描述，并分配时间来主动地完成这个任务。（注意：不只是被动地对高影响的事件作出反应。）

快速生效的办法就是，积极主动地应对问题，在未来事件发生之前采取行动，这样就会提高服务质量。

创建变更文档

建立完好的变更管理流程，是一个物有所值且意义重大的项目。即使只是记录下变更发生的事实，而没能阻止和控制它，也会带来好处。

创建一个变更日志，它们什么时候发生的、什么东西发生了变化、谁对这些变更负责、变更是否成功，以及是否触发了什么事件？这是值得做的第一步，它们有助于分析趋势，定义问题的范围。

让应用开发参与进来

都是与运营有关的，在ITIL框架之内，应用开发人员没有多少机会涉入其中（变更管理是显而易见的一个）。让他们参与进来，至少会很快提高他们的意识。

告诉我们，当计划和决策公布时，如果人们被排除在外没有机会参与，他们就会成为阻碍力量。你等待的时间越长，工作难度就会越大，这包括任何员工，不仅仅是应用开发人员。

谈“服务”而不是“系统”

在IT部门还有很多人认为他们的工作是“让系统运转起来”而不是“帮助销售保险政策”（或你的企业所做的无论什么业务）。确实，我们需要系统工作，只有这样我们才能提供服务，但是服务是第一位的。

如果系统是好的，而服务却不行，客户就会不高兴。如果系统有了问题而服务却正常，客户仍然会高兴。

这就是所谓“谈服务而不是系统”的意思。在这方面快速产生效果的方法是，IT人员开始关注正确的事件，这样就可以迅速带来服务质量的提高。

“从下到上”而不是“从上到下”

没人会不同意，就和任何企业的变更项目一样，执行层的参与是一个成功的流程变更的关键要素。但是，真正的变更是嵌入进去的，它每次向企业提出一个问题：一个变更、一次事件、一个问题，一个发布。

逐渐地，草根阶层就会产生一种简单的信念，“新”的方法并不是像最初想的那样差，更正确的方法是，“新”方法看起来好象是有几条“腿”。

你还能记起你的业务名片上没有传真号或者是电子邮件地址的时候吗？你能想像现在没有电子邮件如何工作吗？这就是格拉德威尔（Malcolm Gladwell）所说的“引爆点”，当关键的大众走向而不是远离流程时，这正是我们在这个流程改进的世界所寻找的东西。

开放报告

在指标、控制和测试绩效方面已经谈了很多。假设这已经发生了，什么才是真正重要的工作呢？所有这些数据在哪里结束呢？谁收集、处理、分析、安排和分发这些数据呢？谁在这之上采取行动？这些数据是“机密”的吗？

一般的IT人员是否能理解，所有这些正在改变他们的生活的流程，会给企业带来真正积极的影响？

从本质上来讲，检测是为了提高，但是，一旦事情开始向正确的方向发展，为了保持动力，将这些结果与所有涉及到的人进行交流是很重要的。

让老板兴奋并参与

老板可以是你最好的朋友，或者是你最坏的敌人。要让老板成为你的朋友，而且要尽快做到这一点。

要记住，对CIO、IT主管，项目经理、流程所有者和变更代理来说，一个关键的挑战是，早期成功是全面规划流程的一个重要部分。要通过审慎的规划和行动获得快速成功，而且还要：

◆ 所有人都可以看见；

◆ 有意义，并且在短时期内可以达到。

注：本文转自http://bbs.ileader.com.cn，原文地址：ITIL的实施速效10个法则。

注：本文转自TechTarget中国,原文地址，http://www.searchdatacenter.com.cn/showcontent_23581.htm。版权归TechTarget中国所有。

当IT组织努力提高效率和效果之时，他们必需在提高商业IT服务质量的同时减少无计划的反馈性工作。来自管理方面的压力如此之大，IT前辈面对这种局面也很无奈，关于管理有无数的陈词滥调，听起来不错，但投资收益却毫无改善。而变更管理却是一个能真正起作用的关键IT服务管理（ITSM）过程。

有一点很清楚，变更管理并不是一个能解决所有问题的神奇药剂。然而它在提高可用性、安全性和灵活性的同时的确可以大大减少无计划的工作，这样能使更多的员工从事有计划的项目。有可靠的证据证实，这绝不是一个仅仅听起来不错而不能被实现的的陈词滥调。

• 人为误差在设计、编码和操作中蔓延。任何对系统的变更都会造成某种程度的风险，并将产生一个消极的结果。
• 据IDC的最新研究表明，近80%的网络可用性事故来源于人为误差。一些组织甚至超过了这个数字。不管怎样，当事件发生时，项目被搁置、资源被调换，直到危机得以缓解。这会导致项目积压和管理失败。
• 所有的事情都是一样的，一个系统事故很可能起源于一个变化。是的，环境问题和硬件故障可能是一种原因，但是其概率要低一些。人们往往将百分之八十的维修时间花在试图寻找究竟发生了什么变化。如果能够尽快解决，你数据中心的可用性会变得更高，IT职员将会有更多的时间去关注计划性工作。
• 尽管证据表明变更管理和规范的流程是有效的，但在IT行业里有一个很普遍的“牛仔”心态，即员工不喜欢被告知他们必须遵循一个过程。要执行变更管理，或关于它的任何过程，必须有意识地去改变这种文化。

执行变更管理需要考虑的内容

在这里我就不重复《ITIL服务转变》中提到的有关变更管理的内容了，我想回顾一下我们真正遇到的一些问题，并对那些在设计和执行变更操作过程中经常出现的问题进行解释。

• 促进文化变革。文化变革的需求并没有得到太多的重视。事实上，正种心态往往也导致了失败。在一个进程的设计和执行期间，要注意寻找合适的人选。对其进行培训，提供交流和预警机制。要及时对工作描述和补偿计划进行更新，使其适合整个进程。最后但同样重要的是，IT管理、ITSM管理和变更管理过程中用户和经理必须努力学习，不断增强对变更管理的需求。
• 为什么要有一位变更经理？必须有一个人来为平衡风险或规避风险负责。这个人必须具有大局观，确保在局部层面看起来不错但更高层面可能出问题的变更不被执行。例如，某个网络管理人员可能认为升级一台交换机是低风险的，因为他没有意识到这个改变发生在周末的账户统计期间，这也就暗藏了一份风险。
• 要有重点！最好是设计一个过程并在一个特定的IT层面执行，在这一层面业务和IT部门都愿意以该过程为原型并对它进行调试。在一个小范围内变更一个过程比追求一个全有或全无的方法更容易且政治风险更小。
• 从点滴做起。随着复杂性的增加，文化转换的难度和长期持续的变更管理风险也增加了。此时，需要对持续过程改进进行规划，同时要制定发展蓝图以确定过程将随着新版本进行演变。但是，一定要确保从简单做起逐步改进。有时侯变更管理的开始可能是最艰难的。
• 多模式。ITIL的变更管理过程可识别多模式的用途：标准的、紧急的、次要的、正规的和主要的。这些仅仅是适当平衡风险、成本和时间的工作流程。事实上，一个组织可以有多种模式，只要这些模式有实际意义且它们清楚何时遵循何种模式。实施变更管理的组织要适应他们的各种模式，从而具备适当的灵活性和风险管理能力。
• 标准的变更模式是至关重要的。谈到模式，标准的模式使低风险、可预测的变更得以被记录和实施。这些变更不需要提交变更顾问委员会（CAB），这样IT部门就有了更高的灵活性。它们仍然需要仅在授权变更窗口被执行，同时必须被记录以便人们能轻易地回答这个问题“有什么改变吗？” 随着时间的推移，符合必要标准的变更应该经过正式审核并遵循这个模式。组织中的大多数变更应该遵循这个模式。备注：如果变更因为任何原因出现明显的问题，那么必须有一种方式来正式撤销变更的标准等级。
• 注意紧急变更。对组织而言，紧急变更所承担的风险是最大的。特别注意不要让IT人员认为紧急变更是一个为了弥补计划缺乏而对生产做匆促变更的好方法。紧急变更应该是一个为紧急事件，随后会被CAB、相关副主席或CIO所检测和调查，从而确定为什么企业会陷入危险当中。
• 判定变更失败的标准。许多人经常争论是什么导致了一次失败的变更，他们经常将个人、团队行为目标和报酬联系在一起。如果发生偶然事件或变更无法按计划完成，就将一个变更应被视为失败。注意这两个因素——如果一个IT服务产生负面的影响,这种变更是失败的。当变更发生，但不能严格地按计划去执行，它被标记为一个失败的变更，同时会执行相反的计划。失败一定不能被糖衣所包裹。变更的能力必须随着时间的流逝不断提高。如果变更结果是不可预知的，就说明有些事情是常错误的，必须立即改正。
• 变更探测。自动化工具可以帮助检测并与一项配置中核准配置的变更进行通信。利用这些工具，一个团体可以从字面上保证系统未被以任何方式修改，且变更管理过程正在被跟踪。这是非常重要的，因为业务运营和信息安全需要及时了解是否有变更发生。
• 责任。IT人员必须遵循变更管理过程，如果他们没有遵循，则必须有明确的处理办法。质量专家W. Edwards Deming说在一个过程中你只能做两件事——或者遵循它或者正式变更它，没有其他的选项。并且人们不能自发地偏离过程，管理上对过程的确认是很有必要的，这可以降低风险。

变更管理对IT行业而言是一个关键的控制过程。它绝不是一个用于满足监管机构官僚控制的程序，事实证明对所有组织而言它都是有好处的，包括提高可用性、降低成本、服从管理、减少安全漏洞等。

英文原文地址：http://searchdatacenter.techtarget.com/tip/0,289483,sid80_gci1361542,00.html

注：本文转自TechTarget中国,原文地址，http://www.searchdatacenter.com.cn/showcontent_28271.htm。版权归TechTarget中国所有。

数据显示，大多数数据中心灾难都人为原因导致的。在与许多数据中心经理交谈过程中，我发现这些人为因素主要分为两种情况：一是缺乏精确的变更管理流程；二是在进行简单变更操作时忽略了对现有的管理流程。

这里我讲的并不全是那些飓风和暴风雪之类的大型灾难。我谈论的是打断数据中心正常业务运营、影响公司收入的所有事故。与IT员工或其它员工的认为因素相比，数据中心发生自然灾难的概率要小的多。数据中心灾难恢复规划需求具有一定的季节性，对美国企业来讲，8月份开始需求会上升，到11月份会有所减少，那时候大多数公司都已开始制定自己下一年度的预算规划了。从某种程度上讲，这与美国的飓风多发季节是保持一致的。

而如今，在各家公司即将开始准备制定下一年度预算规划的前夕，我们来讨论一下数据中心如何减少自己的宕机时间。

成熟的IT进程模式：CMM和ITIL

能力成熟度模型（CMM）将IT软件的成熟度分为5个等级，第5级是最高的。要达到每一级都需要付出大量的努力，但由此获得的回报也是很可观的。而ITIL则为IT机构提供了一种定制需求、实现更高组织成熟度等级的框架模型。

但是，让我们来看一下评估组织机构成熟度模型的现实情况。首先，这不是一个短暂的进程。多数机构升一个等级要花一年左右的时间。他们需要对员工进行相关培训，由于许多员工对于基础设施的变更都有抵制情绪，在这个过程中会有许多问题产生。不到他们自己亲身经历这些变更的时候他们是不会相信这些流程的价值的，更不用说去尽力支持了。此外，还有一些员工往往不愿意采用这些新的进程。这很不幸，这样的结果就是你将他们调整到其它位置或是将其解雇。大约一年前，我与一家致力于从CMM2级向3级晋升的公司有过接触，其副总裁拒绝部署变更流程，他认为这是一种额外的工作，没有什么价值所在。几个月后，我得知消息说公司解雇了这位副总裁并找人来代替了他的位置。

通过部署进程和管理方案可以提高组织的成熟度，并减少IT变更管理中的错误，这就最终减少了数据中心灾难的发生。但是，永远没有一个方案可以完全解除人为的错误。有时候即使是一个很小的失误也会导致灾难的发生。

即便是很小的变更也可能导致数据中心灾难发生

Burton Group的研究发现，即使是一些很小的事情也可能导致IT机构陷入麻烦。具体情况如下：

• 有的IT机构总是想寻找更高效的方式——最常见的做法是为了提高效率而对某些流程进行删减；
• 某些小的配置变更进程似乎是可以被跳过的。通常企业会将一些看起来似乎不是很重要的变更流程省去，为的是提高业务速度；
• 将一些可以跳过的进程提前完成；
• 有些进程第一次这样做没有引起故障，但并不代表它永远不会发生故障；
• 有的进程一旦第一次被跳过，那第二次也很可能被跳过；
• 所有这些非正规操作的步骤都是IT系统故障发生的隐患，这些隐患随时可能导致数据中心灾难发生。

要想提升IT进程成熟度，最基本的是要严格遵守各种既定的进程和流程，即使这些流程看似并不是很重要。这对于减少数据中心故障的发生是很有用的。

是时候该提高IT进程的成熟度了

金融危机为机构提供了一个改进IT进程成熟度的时机。在经济繁荣时期，IT机构将业务重点都放在尽可能快地构建IT基础设施和服务以支持业务增长上了。所有的CIO都明白IT进程应该为促进业务增长而服务，而不应该成为业务增长的绊脚石。就像我的一位同事所说的：“在经济繁荣时期，IT组织一直在以最快的速度为自己的‘业务机车’铺设轨道，而在经济危机时期，他们就有机会重新审视一下自己的基础架构和进程，来为提高效率而对其进行一些改进了。”

如今，IT机构是时候该将他们的注意力更多地放在改进组织成熟度和效率上了，这对于降低数据中心灾难发生的人为原因来讲也是很关键的。

译者：Richard Jones

英文原文地址：http://searchdatacenter.techtarget.com/tip/0,289483,sid80_gci1349537,00.html

ITIL v3以后，配置管理进化为“服务资产和配置管理SACM”，换句话说，资产和配置管理不分家。两个流程应该是融合的。从微观上看资产管理设计到CI的所有生命周期状态，而这个服务资产在CMDB中出现的状态为整个生命周期中的一部分。

最好能通过资产管理为统一入口，来完成对CMDB中资产的生命周期管理。例如：一台服务器在到货以后，完成资产入库后，就应该在CMDB中自动创建CI，在上架部署了软件后，有配置资产自动采集工具，采集回详细配置信息后，资产状态就自动变为“部署”，当在运行维护中服务器宕机或者维护时，在资产管理中也能看到更新的信息。下面是建议的服务资产的生命周期状态:

配置项管理和资产管理的联系和区别。

Service Asset and Configuration Management (SACM) = Configuration Management + Asset Management

Configuration Management
@The Process responsible for maintaining information about Configuration Items required to deliver an IT Service, including their Relationships
@This information is managed throughout the Lifecycle of the CI

Asset Management
@Asset Management is the Process responsible for tracking and reporting the value and ownership of financial Assets throughout their Lifecycle.

本文转自Martin Liu’s Blog，原文地址：http://martinliu.cn/2009/12/13/service-asset-ci-life-cycle/

最近工作都是围绕ITIL和ITSM展开的，需要做一些记录。CMDB（配置管理数据库）实施过程相当复杂，为此参考了别人的实施过程对实施任务进行了分解：

• 第1步：识别CMDB实施组成员，定义角色和职责；
• 第2步：进行实施组CMDB知识培训；
• 第3步：Review，并就CMDB实施目标、任务达成一致；
• 第4步：Review，定义并沟通CMDB实施后预期收益；
• 第5步：制定实施计划，并进行项目SWOT分析、ROI分析、财务分析；
• 第6步：Review，并识别管理上的需求；
• 第7步：Review，并选择可实现的CMDB最佳实践方法；
• 第8步：识别潜在的问题，并提出解决办法；
• 第9步：识别资产和存货管理要求；
• 第10步：定义CMDB支撑的服务目录要求；
• 第11步：定义其他ITIL流程对CMDB的要求；
• 第12步：定义CI层次，建立IT设施模型
• 第13步：定义CI之间的关系
• 第14步：定义CI的属性
• 第15步：设计IT模型蓝图
• 第16步：选择实现CMDB的技术（产品选型）
• 第17步：计算并提出ROI
• 第18步：确定项目范围并制定扩充计划
• 第19步：构建CMDB
• 第20步：选择自动化CMDB工具或定义数据来源
• 第21步：填充CMDB数据
• 第22步：创建CI生命周期管理流程
• 第23步：建立配套的配置管理流程
• 第24步：对CMDB用户和配置管理角色进行使用、管理培训
• 第25步：识别指标并保持指标计算
• 第26步：建立可持续性服务改进程序

当然，实际步骤需要由项目经理根据实施单位的情况制定。

原文参见：http://web2world.cn/article/2009/10/a133.html