《ITSS认证IT服务工程师培训教材》_试用版_2011_0311--IT服务技术（2）
本帖最后由 tom615 于 2014-10-22 11:50 编辑干货推荐：
ITSS题库
中国ITSS白皮书2.0【第二版】PDF
ITSS服务项目经理培训
ITSS服务项目经理培训——2-基本概念及方法
ITSS服务项目经理培训——3-IT服务设计
ITSS服务项目经理培训——4-IT服务转换
ITSS服务项目经理培训——5-IT服务运营(3)
ITSS服务项目经理培训——6-IT服务改进
ITSS服务项目经理培训——7-IT服务项目类别
ITSS服务项目经理培训——9-IT服务项目管理知识体系(1)
ITSS服务项目经理培训——10-IT服务项目群管理
2.2 常用IT 服务管理流程
2.2.1 概 述
流程（引用的定义）
流程（Process）1是按照一个既定的目标组织起来的一组逻辑上相关的活动。需要针对每个流程的输出制定一个标准，从而使得当每个流程服务其标准时，这个流程就可以实现组织的目标。
流程管理的目标就是通过规划和控制从而确保流程是有效和有效率的。组织通过管理可以对流程的质量加以控制，流程的质量基础可以通过每个流程的结果所提供的数据看出来。在缺乏明确指标的情况下，要确定一个流程是否处于控制之下以及计划的改进活动是否得以实施，是一件困难的事情。
流程通常通过规程（Procedure）和工作说明（Work Instruction）加以描述。
规程是对一组逻辑上相关的活动以及实施这些活动的人的描述。一项规程可以包括来自不同流程的多个阶段。规程中定义了由谁做什么事情，并且依据组织类型的不同而有所不同。
一套工作说明定义了一个规程中一项或多项活动应当怎样加以实施。
流程规范、规程、工作规范之间的关系如下图所示：
常用 IT 服务管理流程
IT 服务工程师常用的IT 服务管理流程一般为事件管理、问题管理、变更管理、发布管理、配置管理等。分别介绍如下：
2.2.2 事件管理
事件管理是尽快解决IT 环境中出现的事件，尽快恢复向业务提供协定的服务或响应的服务请求，保持IT 服务的稳定性。
概念定义
重大事件：重大事件是指对业务产生重大影响的事件，这类事件的发生需要迅速处理。
影响度：由事件对业务的影响程度决定，即事件可能或已经引起对所约定或期望的服务水平造成的偏离程度。
紧急度：紧急度的级别可以根据组织的业务需求来定义，一般可分为五个级别，每个级别定义解决事件的目标期限、对事件的第一响应时间和对用户的沟通频度等服务级别协议。
优先级：指的是IT 业务用户根据事件涉及的业务影响度和紧急度，确定的对该事件的处理要求。IT 服务工程师根据优先级来对处理的事件进行排序，优先处理高优先级的事件。
目标和范围
事件管理流程的目标是尽快解决 IT 环境中出现的事件，尽快恢复向业务提供的协议服务或响应服务请求，尽量减少事件对业务运营的不利影响，确保最好的服务质量和可用性级别，保持IT 服务的稳定性。
具体目标：
[*]在成本允许的范围内尽快恢复服务；
[*]进行事件控制；
[*]提供IT 管理信息。
事件管理范围包括运营维护的各运行环境中产生的故障和服务请求及服务咨询，举例如下：
[*]故障（如应用系统服务不可用、应用系统磁盘占用量超限、硬件停机）；
[*]服务请求（如申请新的IT 资源、密码重置、帐号资源申请、与IT 服务相关的服务请求）；
[*]咨询（如服务咨询）。
主要活动
下图主要显示了事件管理流程的基本步骤和事故管理活动：
资料来源：OGC．
事件接收和记录
服务台负责接收和记录事件。它将基本信息输入事件数据库并报告给事件管理小组。一般来说，服务支持小组是不允许直接记录事件的，所有事件必须先报告给服务台，然后由事件管理人员根据服务台提供的信息及事件数据库信息判断此事件是否与已有事件相同或相似，如果有，就更新事件信息或建立原事件的从属记录，并在必要时修改原事件的影响度和优先级，如果没有，则创建新的事件记录。
事件管理需要给每个事件分配一个唯一编号，记录一些基本的事件分析信息（时间、症状、位置、受影响的服务和用户以及硬件等）并补充其他事件信息（来自于与用户的交互和配置管理数据库等）。
归类与初步支持
归类是根据事件发生的原因和所需支持的类别对事件进行划分的过程。如果发生的事件是重复出现的，则只需根据已有的经验和措施采取行动即可。如果事件是新出现的，就需要将其与问题和知名错误进行匹配。如匹配成功，就可直接用已有方案解决事件。如果不能将事件与问题或知名错误进行匹配，下一步就是确定事件的优先级，以确保支持小组对事件给予必要的关注。优先级应综合事件的影响度和紧迫性来确定。
在确定事件优先级后，服务台应对事件提供初步支持。服务台如果没有成功解决事件，就将事件转交给二线或三线支持处理，然后负责记录事件并协调各支持小组、采取必要的措施以确保用户满意事件的解决过程。
启动服务请求程序
如果该事件属于一项服务请求，则启动服务请求程序，由其他服务管理流程如变更流程、配置管理流程、能力管理流程等流程对服务请求进行适当的处理。
事件匹配
当服务台接收并记录有关事件的信息后，需要将发生的事件与问题管理中的问题、知名错误进行匹配。如果匹配成功，则可以根据问题管理中现成的解决方案解决事件。如果匹配不成功，则服务台应将事件转交给事件管理人员，由事件管理人员对事件进行调查和诊断。
调查和分析
如果没有现成的解决方案，事件管理人员应对事件进行分析和诊断，并提出快速解决事件的方案或应急措施。
解决与恢复事件
在确定了事件的解决方案或应急措施后，事件管理人员应当立即对事件进行解决以快速恢复 IT服务的运作。
跟踪与监控
在事件解决的全过程中，服务台需要跟踪和监控事件解决的进度及用户的反馈情况，必要时应增加事件解决人员或对事件进行升级。
终止事件
在事件解决后，服务台应向客户确认事件解决的效果是否达到服务级别协议的要求，如果达到要求或使客户满意则应终止事件，否则应扩展事件处理流程。
事件记录
典型事件记录如下表所示：
与其他流程关系
事件管理流程的运作与问题管理、配置管理、变更管理和发布管理等流程具有密切的关系。这种关系如下图所示：
资料来源：OGC．
下面具体说明事件管理与这些流程的关系：
[*]配置管理：事件管理在记录和诊断事件的过程中将从配置管理数据库（CMDB）获取有关资源、服务、用户、服务级别及其相互关系的信息；
[*]问题管理：问题管理需要根据事件管理所记录的事件信息查找事件发生的潜在原因。而事件管理则需要利用问题管理提供的问题、知名错误、应急措施等方面的信息快速地解决事件；
[*]变更管理：事件管理可以为变更管理制定变更方案提供事件信息，而变更管理所制定的解决方案需要反馈给事件管理。在变更实施的过程中如果控制不当，则可能产生新的事件，因此应该详细记录变更过程和变更轨迹，并将它们与事件记录、问题、知名错误和变更请求等信息保存。
角色划分和职责
关键成功因素
[*]要保证事件管理流程的成功运行，需要从以下几个重点关注：
[*]所有事件应该被记录；
[*]所有事件要进行编号；
[*]事件应该进行分类；
[*]每个事件在建立后，在生命周期中的每一个阶段都应有事件负责人负责；
[*]IT 服务工程师要关注事件的处理条件和时间要求；
[*]关注事件是否违反服务协议和规则；
[*]对于自己不能处理的事件，IT 服务工程师应该及时升级；
[*]首要负责制，确保事件流程处理是进行的闭环流转；
[*]应该定期对事件处理进行回顾；
[*]能够与问题管理、变更管理、配置管理进行关联。
常见场景及优化
衡量指标
[*]事件总数；
[*]解决事件所需的平均时间；
[*]事件在约定响应时间内得到的处理比例；
[*]事件分类统计数；
[*]解决事件占总体事件的比例；
[*]各类事件平均解决时间；
[*]重新开启的事件数。
2.2.3 问题管理
问题管理负责预测、监控、发现并及时解决IT 服务和IT 基础设施中存在的问题和错误，将这些问题和错误对客户和业务的负面影响降至最低，并防止由其引发的事件再次发生。
概念定义
问 题
问题指未查明根源的一次或多次事件的原因。问题定义有两个途径。一类是由一系列显示共同特征的事件导致的；二是由某个原因不明的重要事件导致的。
问题管理
指负责解决IT 服务运营过程中遇到的所有问题的流程。问题管理包括问题处理和问题控制，其目标在于将由于IT 基础架构的错误而导致的问题和事件对业务产生的负面影响减小到最低，以及防止与这些错误有关的事件再次发生。为了实现这个目标，问题管理调查分析事件的根本原因，然后采取有关行动改进或纠正这种情形。
问题管理与事件管理的区别
问题管理的主要目标是要查明事件发生的潜在原因并找到解决此事件的方法或防止其再次发生的措施，而事件管理的主要目标是在事件发生后尽可能快地恢复客户服务，即使采取的是一些应急措施而不是永久性的解决方案。事件管理强调速度，而问题管理强调质量，把速度放在第二位。为了发现事件原因和防止事件再次发生，问题管理可能需要花费更多时间解决事件且可能推迟恢复服务。
被动问题管理
通过对当前事件情况进行分析，查找引起该事件的根源，找出针对该根源的解决方案，从根本上解决事件。
主动问题管理
在事件尚未发生（复发）时，通过对历史事件记录的回顾以及趋势分析，主动识别潜在的问题，查找出导致问题的根源，设计针对根源的解决方案或预防措施，从根本上解决问题，并防止该问题导致的同性质的事件再次发生。
已知错误
指问题经过诊断分析后找到事件产生的根本原因并制定出可能的解决方案时所处的状态。在这种状态下，一种临时性的权宜措施或永久性的解决方案已经得到确认。如果一个问题转化成了一个知名错误，则应当提出一个变更请求。但是，在通过一项变更将此知名错误永久性地修复之前，它仍将作为一个知名错误。
问题控制
对发现的问题进行归类、调查和分析从而提出解决方案或应急措施的流程。问题控制的根本目的是要查明事件产生的根本原因，一旦查明事件产生的根本原因，问题就升级为知名错误。知名错误将由错误控制流程解决。
错误控制
是对知名错误进行处理和控制的流程。在问题控制将知名错误转交给错误控制之后，错误控制需要向变更管理提交变更请求，再由变更管理实施变更后最终消除知名错误。
目标和范围
目 标
问题管理流程负责预测、监控、发现并及时解决IT 服务和IT 基础设施中存在的问题和错误，将这些问题和错误对客户和业务的负面影响降至最低，并防止由其引发的事件再次发生。具体的目标细化为：
[*]将由IT 基础架构中的错误引起的事故和问题对业务的影响减少到最低程度；
[*]查明事故或问题产生的根本原因，制定解决方案和防止事故再次发生的预防措施；
[*]实施主动问题管理，在事故发生之前发现和解决可能导致事故产生的问题。
范 围
问题管理的范围包括问题控制、错误控制和主动问题管理。
主要活动
问题管理识别并管理引发服务事件的根本原因，最小化甚至阻止一切客户损失发生。问题管理与解决流程中的被动部分—事件管理紧密联系，它更为主动：主动阻止事件以及已知错误的重复发生。
问题管理的主要活动分为主动管理和被动管理两大方面。被动方面是指问题管理流程对某一个或某一些事件进行分析后确定问题根源并加以解决；主动方面是指问题管理流程分析事件和问题的发展趋势，在问题 之前采取相应的对策。因此，问题管理流程的管理范围包括问题控制、已知错误控制和主动问题管理。
（1）问题控制
问题控制是对发现的问题进行归类、调查和分析从而提出解决方案或应急措施的流程。问题控制的根本目的是要查明事件产生的根本原因，一旦查明事件产生的根本原因，问题就升级为知名错误。知名错误将由错误控制流程解决。
问题控制的基本流程如图所示：
资料来源：IT Service Management, an Introduction．
图2.6 问题控制流程
下面对问题控制流程中涉及的主要活动进行简单介绍：
发现和记录问题
问题控制的第一步是要发现和记录问题。理论上，所有导致事件产生的未知原因都可以称为问题，但我们通常只将那些重复发生的或非常严重的事件归类为问题。问题记录与事件记录类似，但不完全相同。事件记录强调是受影响的用户数量、影响程度等信息，而问题记录则更侧重于事件的症状、与事件相关的基础架构的运行情况等方面的信息。问题记录应该关联到所有与其相关的事件，事件的解决方案和应急措施也要记录在相应的问题记录中。
问题归类
在查明和记录问题后，为了评估问题可能对服务级别产生的影响，应首先对问题进行归类。问题归类应当根据问题涉及的领域、影响度和紧迫性以及优先级等因素综合确定。问题归类不是静态的，它在问题生命周期的不同阶段可能会发生调整，如应急措施可以降低问题的紧迫性，而新出现的事件却可能会提高问题的影响度。
调查和分析问题
问题调查与事件调查的目标不同。事件调查的目标在于找出快速恢复事件的应急措施，而问题调查是要找出问题存在的根源。因此，问题调查比事件调查要更加全面深入，甚至包括对事件管理所制定的解决方案和应急措施的调查。在对导致事件的未知原因展开调查后，需要对这些原因进行分析和测试，以确认其是否是问题产生的最主要和最根本的原因。
在确认产生问题的根本原因后，问题就转化成为知名错误，问题管理也就进入错误控制阶段。如果未最终确认问题产生的根本原因，则应向事件管理人员建议实施应急措施，同时扩大调查和分析的范围，直到找到问题的根源为止。
（2）错误控制
错误控制是对知名错误进行处理和控制的流程。在问题控制将知名错误转交给错误控制之后，错误控制需要向变更管理提交变更请求再由变更管理实施变更后最终消除知名错误。错误控制流程如图所示：
资料来源：OGC．
图 2.7 错误控制流程
下面对错误控制流程所涉及的活动加以简单介绍：
发现和记录错误
在问题控制流程查明了问题产生的根本原因，问题就转化为一项错误，如果同时针对这些错误提出了相关的应急措施，则错误又进一步升级为知名错误。发现和记录错误或知名错误是错误控制流程的开始。问题管理人员需要将有关知名错误的信息存放在问题数据库中。
评价错误
在发现和记录错误后，问题管理人员应与其他支持人员一道对解决错误的可能方法进行初步评估，并根据对错误评价的结果制定相应的解决方案。
记录错误解决过程
在问题管理人员提出解决错误的方案后，错误控制流程应详细记录每个知名错误的解决过程，特别是与知名错误有关的配置项、症状和解决方案（或替代方案），记录的信息可保存在知名错误数据库中。这些信息可以为以后发生类似事件时进行事件匹配提供信息。
提出变更请求
如果问题管理人员发现制定的解决方案无法从根本上消除知名错误时，应向变更管理流程提出变更请求，变更管理应根据错误的影响度和紧迫性确定变更请求的优先级。
问题解决评估
在问题管理人员实施解决错误方案或者变更管理人员根据问题管理人员的变更请求实施变更后，问题管理人员需要继续跟踪和监督错误解决过程，必要时应进行实施后评审（PIR， PostImplementation Review）来确认问题或知名错误的解决效果。然后，问题管理人员需要根据服务级别目标和解决问题所需的成本确定是否需要进一步对问题展开调查和研究。
问题终止
在确认问题和知名错误得到较好的解决后，问题管理可以终止错误控制流程。同时，需要将有关问题的更新信息存入问题数据库中。
（3）主动性问题管理（Proactive Problem Management）
问题控制和错误控制都是在问题出现后才作出的响应，因而是一种被动的问题管理。事实上，根据对IT 基础架构进行的分析，问题管理可以找到可能出现问题的薄弱环节，在事件发生前发现和解决有关问题和知名错误，以尽量减少问题和知名错误对业务的影响。这就是下面要介绍的主动性问题管理。
主动问题管理主要包括两项活动：趋势分析和制定预防措施。
趋势分析
趋势分析需要根据事件和问题分析报告提供的信息预测IT 服务运作的趋势，找出IT 基础架构中的薄弱环节，并估计薄弱环节和可能产生的组件故障对业务运作的影响。通过趋势分析，问题管理人员可以制定积极的预防措施，从而维持IT 服务的持续运作，改进服务质量。一般来说，趋势分析可以从以下几个方面进行：
[*]找出IT 基础架构中不稳定的组件，分析其原因，以便采取措施降低配置项故障对业务的影响；
[*]分析已发生的事件和问题，研究其变化趋势。
通过其他方式和途径分析，比如：
[*]系统管理工具；
[*]用户反馈；
[*]与客户和用户的座谈会；
[*]客户和用户调查。
制定预防措施
通过趋势分析，问题管理人员一般可以确定IT 基础架构中存在的薄弱环节，从而可以帮助服务支持人员明确哪些问题是应当重点关注的。在确定服务支持人员应重点关注的问题之后，问题管理人员就应针对这些薄弱环节制定积极的预防措施以避免事件的发生。这些预防措施通常包括：
[*]提交变更请求（RFC）；
[*]提交有关测试、规程、培训和文档方面的反馈信息；
[*]进行客户教育和培训；
[*]对服务支持人员进行教育和培训；
[*]确保遵守问题管理和事件管理的规程；
[*]改进相关的流程和程序。
问题记录
典型问题记录列表如下：
与其他流程关系
问题管理流程在运作过程中需要与其他多个流程进行信息上的沟通。它需要根据事件管理、能力管理、配置管理等流程提供的信息制定解决方案和应急措施；同时它所产生的解决方案和变更请求等信息又需要输入事件管理和变更管理流程的运作过程。问题管理与这些流程的关系如下图所示：
图2.8：问题管理与其他流程之间的关系
资料来源：IT Service Management， an Introduction．
下面具体说明问题管理与其他流程之间的关系：
[*]事件管理：事件管理是和问题管理关系最为紧密的流程。事件管理所提供的事件记录将作为问题管理的主要信息来源。问题管理则对事件管理提供全面的支持，包括：为事件管理提供解决方案、应急措施，如果问题为知名错误则为事件管理提供快速修复方案以防止类似的事件再次发生；
[*]变更管理：必要时问题管理应根据问题调查的结果会向变更管理发出变更请求，变更管理通过实施变更来消除问题；
[*]配置管理：配置管理所提供的关于基础构架、软硬件配置、服务及其相互关系方面的信息是问题管理进行问题研究的重要信息来源。
角色划分和职责
关键成功因素
要保证问题管理流程的成功运行，需要从以下几个重点关注：
[*]所有问题都应该记录；
[*]所有问题要进行编号；
[*]问题应该进行分类；
[*]每个问题在建立后，在生命周期中的每一个阶段都应有问题负责人负责；
[*]IT 服务工程师要关注问题的处理条件和时间要求；
[*]对于自己不能处理的问题，IT 服务工程师应该及时升级；
[*]要对问题的根本原因进行详细分析；
[*]对于问题引发的变更，要关注变更的处理情况；
[*]应该定期对事件进行回顾，如果有重复发生的事件和重大事件要建立问题；
[*]能够与事件管理、变更管理、配置管理进行关联。
衡量指标
[*]最近一个周期内识别的问题数；
[*]各类问题关闭的平均时间（天）；
[*]已确定根源的问题数及占问题总数的比例；
[*]已解决的问题数及占问题总数的比例；
[*]升级通知领导的问题数及占问题总数的比例；
[*]未关闭的问题数及占问题总数的比例。
2.2.4 变更管理
变更管理是对变更从提出、审议、批准到实施、完成的整个过程的管理。
概念定义
紧急变更
指系统出现的重大突发事件，为解决这些突发事件而提出的变更，如果不立即采取措施而按照正常变更管理流程，将会严重影响正常业务运作，此时应遵循紧急变更管理流程。
标准变更
指风险很小或者没有风险的变更，并且执行这些变更的步骤和方法已经很成熟，这些变更事先已经得到审批并记录在案，遵循简化的标准变更管理流程。单个标准变更发生时，无须送至变更经理处进行审批，直接进行变更执行。
常规变更
其他不在标准变更、紧急变更范围内的变更，定义为常规变更，遵循常规变更管理流程。
目标和范围
目 标
确保在变更实施的过程中使用标准的方法与步骤，从而以最快的速度实施变更，将由变更所导致的业务中断影响减少到最低。确保所有的变更都有明确的记录可追踪，维持变更需要和实施变更后的可能产生的后果之间的适当平衡。
范 围
变更管理的对象是对于计算机、网络设备和软件、系统软件、应用软件、相关文档的修改都应该遵循变更管理规范并被记录。
主要活动
变更管理流程的实施以变更请求（RFC）、配置管理数据库（CMDB）和变更实施进度表（FSC)为基础，经过登记变更请求、筛选和接受变更请求、确定优先级和归类变更请求、制定变更实施计划、实施变更评价和终止变更、处理紧急变更等变更管理活动之后，产生变更管理报告、变更顾问委员会行动备忘录等管理信息。变更管理流程的过程如下图所示：
资料来源：Jan van Bon, etc．《IT Service Management, an Introduction》．Van Haren
Publishing, May 2002．
图2.9：变更管理活动过程
下面对变更管理运作过程中的主要活动进行介绍。
记录变更请求
所有的变更请求都应该被记录并分配编号。最好的记录方法是使用集成服务管理系统。这种系统可以自动分配变更请求编号和记录有关变更请求的活动。此外，集成服务管理系统还可进行分级授权，比如任何经授权的人员可以创建、增加变更请求处理报告，但是只有变更管理员或配置管理员有权限终止某个变更请求。
评审和筛选变更请求
在记录变更请求后，变更管理人员进行初步评价，以确定是否有不清楚的、不合法的、不切实际的或不必要的变更请求。然后，变更管理人员应根据变更的必要性及其对业务的影响来决定接收或拒绝变更请求。如果拒绝某个变更请求，应说明原因并给变更请求提交者解释的机会。
对变更请求进行分类和确定优先级
一旦决定接受某个变更请求，变更管理小组必须确定该变更请求的类别和优先级。
变更管理小组需要根据服务台、事件管理和问题管理等对变更的初步分类，进一步考虑变更的影响和可用资源等方面的情况，最终确定变更的类别。变更类别表明了变更的影响和它对组织所提出的要求，其结构和复杂性很大程度上是由业务需要决定的。
优先级是根据问题的影响度和解决问题的紧迫性确定的，它表明了某个变更请求相对于其他变更请求的重要程度。变更请求的优先级可分为四种：低优先级、中等优先级、高优先级和最高优先。
制定变更实施计划
在明确了变更请求的类别和优先级之后，变更管理小组需要根据变更进度安排表（FSC）对变更实施进行计划。重大变更需要先由IT 管理部门批准，然后再提交变更咨询委员会讨论批准。
实施变更
在完成前面几项工作之后，变更管理可以开始具体实施变更计划。这个过程主要由构建、测试和实施三个步骤组成。下面对这三项具体的实施活动作简单介绍。
[*]构建
[*] 在实施变更前需要构建相应的IT 组件。构建活动的内容包括：
[*] 构建新的产品模块；
[*] 创建一个或多个新的软件版本；
[*] 外购设备或服务；
[*] 做好准备修复某个硬件；
[*] 制作新文档或修改补充原有文档；
[*] 完成撤销（Back-out）计划；
[*] 准备用户培训修正方案。
[*]测试。为了防止变更后的IT 组件对服务质量造成不良影响，所有变更在实施前应该接受全面测试。测试的目的主要在于确定IT 组件的安全性、可维护性、可支持性、可靠性、可用性等方面的性能；
[*]实施。变更的实施不一定由变更管理人员亲自进行，任何部门中的负责基础架构管理的任何人员都有可能被要求对基础架构实施变更。在这一过程中，变更管理的任务是确保这些变更的实施按照变更进度计划表的安排进行，并保证变更对IT 服务的影响被降到最低限度。
评价和终止变更
变更实施完成后，变更管理小组或变更咨询委员会应对变更实施的情况进行评价。评价主要从以下几个方面进行考虑：
[*]变更达到预期目标了吗？
[*]客户和用户对变更结果满意吗？
[*]变更产生了什么不良影响？
[*]变更符合成本效益原则吗？
在针对上述几个问题对变更实施进行评价后，如果认为变更实施成功，变更管理或变更咨询委员会就可以终止变更请求。反之，则要进一步采取行动进行补救，或者干脆撤销（Back-out）现有行动然后提交另一个修改后的变更请求。
与其他流程关系
变更管理流程的运作与事件管理、问题管理、配置管理和发布管理等流程具有密切的关系。这种关系如下图所示：
图2.10：变更管理与其他流程之间的关系
下面具体说明变更管理与这些流程的关系：
[*]事件管理：事件管理与变更管理的关系是通过问题管理间接联系起来的。变更管理通过实施变更降低了事件发生的频率和事件产生的影响；
[*]问题管理：问题管理在对事件产生的原因进行调查和分析后，可能向变更管理提交变更请求。变更管理负责对这些变更请求进行评审、批准、实施和监控，以确保实施的变更能够从根本上解决问题，并保证变更对业务的影响被减小到最低程度；
[*]配置管理：变更管理需要根据配置管理提供的配置数据分析某项变更对IT 服务运作的影响，而配置管理则负责对变更的结果作出详细的记录；
[*]发布管理：在变更管理将某项变更导入实际的运作环境之前，需要发布管理对这些变更项目进行发布和分发，以加强业务方和IT 部门的信息沟通，尽量减少变更对业务运作的影响。
角色划分和职责
关键成功因素
[*] 要保证变更管理流程的成功运行，需要从以下几个重点关注：
[*] 所有变更应该记录；
[*] 所有变更要进行编号；
[*] 变更应该进行分类；
[*] 每个变更在建立后，在生命周期中的每一个阶段都应有变更负责人负责；
[*] 变更流程经理要关注变更的处理情况；
[*] 要有详细、全面的测试计划和回退计划；
[*] 要关注变更是否引发事件和问题的发生；
[*] 如果变更需要进行发布流程，需要关注该发布的进展情况；
[*] 应该定期对变更进行回顾；
[*] 能够与事件管理、问题管理、发布管理、配置管理进行关联。
衡量指标
[*] 单位时间内完成的变更数量；
[*] 变更中紧急变更的百分比；
[*] 标准变更的百分比；
[*] 被否决的变更数量；
[*] 由变更导致的事件数量；
[*] 被撤销的变更数量；
[*] 根据优先级、变更分类表分类的变更的百分比；
[*] 需要回退的变更百分比。
2.2.5 发布管理
发布管理通过实施正规的工作程序和严格的监控，保护现有的IT 运营环境和IT 服务不受冲击。它负责对软硬件发布进行计划、设计、生成、配置和检测，影响范围可能涉及现有的IT 环境、客户和组织各分支机构。
发布管理应对待发布的变更有全面的理解，包括变更的动因、影响、范围等，以确保发布的所有技术和非技术方面都能得到整体性的考虑。发布管理负责变更实施的规划、构建、测试以及最终的上线，并保证配置管理数据库得到实时的同步更新。
概念定义
项目发布
由项目类变更引发的发布称为项目发布。具体包括，新的或更新的服务和系统的发布，尤其是新功能的引入，通常涉及软件和硬件的采购、测试、上线等活动。
标准发布
在变更管理中定义为标准变更的那些变更的执行称为标准发布，并把具体的发布动作在标准变更管理流程中进行规范。典型的标准发布如路由器的安装。
常规发布
在变更管理中定义为常规变更的那些变更的执行称为常规发布，并把具体的发布动作在常规变更管理流程中进行规范。典型的常规发布包括在首次发布之后的软件的再发布，如Windows 补丁和Symantec 病毒库之类的发布。
紧急发布
在变更管理中定义为紧急变更的那些变更的执行称为紧急发布，并把具体的发布动作在紧急变更管理流程中进行规范。典型的紧急发布包括为解决事件而提出的变更，如核心路由器故障。
目标和范围
目 标
具体目标如下：
[*] 设计和监督以确保软件及其相关硬件的首次运行（Rollout）能够成功进行；
[*] 设计和实施有效的过程来发布和安装IT 系统的变更；
[*] 确保硬件和软件的变更是可追踪的、安全的，并且只有正确的、被授权的和经过测试的版本才能安装；
[*] 在新版本的规划和首次运行过程中，沟通并管理客户的期望值；
[*] 联合变更管理，确定发布的确切内容和首次发布计划；
[*] 利用配置管理和变更管理中的控制流程，在实际运营环境中实施软件和硬件的新发布；
[*] 确认所有最终软件库中软件正本的拷贝是安全可靠的，并且在配置管理数据库中得到了更新；
[*] 通过配置管理，确保所有的硬件均已得到发布，所有的变更是安全的和可追踪的。
范 围
发布管理负责对软件和硬件进行规划、设计、构建、配置和测试，以便为实际运行环境提供一系列的发布组件。需要发布管理进行控制的组件包括：
[*] 自行开发的应用程序；
[*] 外购软件；
[*] 工具软件；
[*] 供应商提供的系统软件；
[*] 硬件和软件的规格说明；
[*] 装配指南和文档，包括用户手册。
所有的组件，从开发或购买，到定制和配置、测试和实施，一直到最后的现场环境的实际运营，都需要发布管理进行有效的管理。而这整个过程，离不开发布管理的参与。特别地，发布管理应当应用于以下三种情况：
[*] 重大或关键硬件的首次运行，特别是当业务系统对某个相关的软件变更具有较大依赖的情形；
[*] 主要软件的首次运行，特别是新的应用程序与其协同软件同时发布的情形；
[*] 将一组相关的变更打包成一个个适当规模的单元的情形。
主要活动
发布管理是为变更管理提供支持的，发布管理贯穿了变更的整个生命周期，并且发布管理流程的实施应当在变更管理流程的控制下进行。发布管理可应用于设计开发环境、受控测试环境和实际运作三种环境之中。发布管理包含的主要活动如下图所示：
资料来源： Michiel Berhout, etc．《Service Support》．OGC, 2000．
图2.11：发布管理流程的主要活动
下面对发布管理活动进行介绍。
制定发布策略
制定发布政策的目的在于明确发布管理中的角色分配和责任划分。发布政策通常是作为总体变更计划的一部分来制定的。发布政策的主要内容通常包括：
[*] 发布的命名和编号规则；
[*] 有关重大发布（Major Release）和小型发布（Minor Release）的具体定义，以及有关签发紧急修复的政策；
[*] 确定重大发布和小型发布频率的指导性原则；
[*] 每种发布类型的预期成果，如安装指南和发布记录等；
[*] 从应用构架和设计的技术角度看，集中式发布管理的职责；
[*] 有关发布管理控制流程（如评审会、进度评估、升级、影响分析等）的描述；
[*] 最终软件库（DSL）中配置的文档记录，以及新增软件的验收标准。
制定发布计划
发布计划需要根据变更进度计划表制定。在发布计划中，需要明确发布日程、角色和职责分配、资源级别、发布撤销计划、发布质量计划等方面的问题。
制定发布计划所需的信息输入包括项目的生命周期、经批准的变更请求、发布政策、业务需求概要、约束和先决条件、变更咨询委员会的审批结论等。
通过制定发布计划，可以得到如下信息：针对某个特定发布的计划、高级测试计划和发布的验收标准等。
发布的设计、构建和配置
发布的设计应当根据发布政策和组织的总体变更计划作出。发布设计的主要目的是要明确发布的类型（全发布、德尔塔发布和包发布）、发布的频率、发布的方式等问题。构建发布需要对流程进行规划和文档记录，并尽可能地重复使用标准化流程。有关发布构建的完整记录也要求保存到配置管理数据库（CMDB）中，这是为了确保在必要时能按照该配置记录重复构建。
发布测试和验收
在一项发布最终引入实际运作环境之前，必须进行严格的测试和用户验收。缺乏充分的测试是导致所有变更和发布失败的最主要的原因。发布测试主要负责对将要引入实际运作环境的发布及其安装流程进行测试，以确保发布和变更成功。发布验收应当在一个可控的测试环境中执行，这个可控的测试环境还要求能够恢复到已知的软件和硬件配置。
制定首次运行计划
首次运行计划（Rollout Planning）拓展了当前的发布计划，它在发布计划的基础上增加了有关安装过程的详细信息和达成一致意见的实施计划。一般来说，首次运行计划中应当明确首次运行的时间安排、需要安装和卸载的配置项、沟通计划、采购计划等方面的内容。
沟通和培训
为了使管理人员、客户和支持人员了解发布管理流程中所作计划的具体内容，发布管理人员通常需要与他们进行适当的沟通并对他们进行必要的培训。在首次运行过程中产生的问题和变更也需要充分传达给上述各方，以使他们能够了解整个过程并随时调整自己的期望。
分发及安装
在完成上述各项活动后，发布管理需要将拟变更的新版本的软硬件分发至目的地。对于软件的分发，发布管理需要进行适当的设计以确保在整个处理、打包和移交过程中能够保持软件的完整性。
软件完成以后，整个变更生命周期的最后一步就是要将发布的应用软件或硬件引入实际运作环境，对引入的软件或硬件进行安装。
在完成软硬件的安装之后，发布管理和变更管理需要将有关信息反馈给配置管理流程，以便配置管理人员对配置管理数据库（CMDB）进行更新。
与其他流程关系
发布管理主要与配置管理、变更管理、问题管理具有较大的关联。下面对发布管理与这些流程的关系进行介绍。
[*]配置管理：当一个新版本的软件或硬件被导入最终软件库或最终硬件库中，配置管理应当将这些信息同步添加到配置管理数据库中。同样，当新的或者变更过的软硬件转出时，配置管理数据库中的信息也要相应地进行更新。发布管理在发布过程中需要用到配置管理提供的各种配置信息。
[*]变更管理：变更管理需要发布管理的配合以尽量降低变更对服务质量的影响。发布管理负责将变更导入或转出实际运作环境，保持IT 部门和客户之间的信息沟通。发布管理是在变更管理的控制和授权之下运作的。
[*]问题管理：问题管理根据发布的新版本的信息更新知名错误数据。
角色划分和职责
关键成功因素
要保证发布管理流程的成功运行，需要从以下几个重点关注：
[*]所有发布应该记录；
[*]所有发布要进行编号；
[*]发布应该进行分类；
[*]每个发布在建立后，在生命周期的每一个阶段都应有发布负责人负责；
[*]发布流程经理要关注发布的处理情况；
[*]应该定期对发布流程处理进行回顾；
[*]要有详细、全面的测试计划和回退计划；
[*]要关注发布是否引发事件和问题的发生；
[*]发布后，将发布结果返回引发发布的事件、问题、变更流程；
[*]能够与事件管理、问题管理、变更管理、配置管理进行关联。
衡量指标
[*] 发布过程中没有出现不可接受的错误从而需要撤销发布数量；
[*]引起事件的发布百分比；
[*]未经测试的发布百分比；
[*]需要回退的发布百分比。
2.2.6 配置管理
配置管理是描述，跟踪，控制和汇报所有IT 基础架构中所有设备或系统的管理流程。这些设备和系统被称为配置项。通过该管理流程实现对所有配置项的有效管理，跟踪和控制以支持IT 服务和基础设施成功运行。
概念定义
配置项
配置项（Configuration Item）指基础架构组件或与基础架构有关的项目，包括软件、硬件和各种文档，比如变更请求、服务、服务器、环境、设备、网络设施、台式机、移动设备、应用系统、协议、电信服务等。这些组件或项目已经或将要受到配置管理的控制。
配置基准线
配置基准线（Configuration Baseline）指一个产品或系统在某一特定时刻的配置状况。这种配置不仅体现了其产品或系统的结构，还反映了其具体内容，从而使得以后可以按照上述配置重建该产品或系统。尽管被作为基准线的这个配置状态以后可能会发生改变，但这个基准线本身却保持不变。这个基准线可以作为初始状态的一个参考或当前状态的一个对照。配置基准线可用于：
[*]IT 基础架构中的授权产品；
[*]标准配置项；
[*]开发和测试新配置的起点；
[*]作为提供给用户的配置的标准，比如“标准工作站”；
[*]作为提供新软件的起点。
配置管理数据库（CMDB）
配置管理数据库（Configuration Management Database）指包含每个配置项及配置项之间重要关系的详细资料的数据库。配置管理数据库包括以下内容：
[*]发布内容，包括每个配置项及其版本号；
[*]经批准的变更可能会影响到的配置项；
[*]与某个配置项有关的所有RFC；
[*]配置项变更轨迹；
[*]特定的设备和软件；
[*]计划升级、替换或弃用的配置项；
[*]与配置项有关的变更和问题；
[*]来自于特定时期特定供应商的配置项；
[*]受问题影响的所有配置项。
配置管理数据库（CMDB）管理所有配置项及其关系，以及与这些配置项有关的事件、问题、知名错误、变更和发布及相关的员工、供应商和业务部门信息，此外，配置管理数据库保存多种服务的详细信息以及这些服务与IT 组件之间的关系，最后，配置管理数据库保存配置项的财务信息如供应商、购买费用、购买日期等。
配置管理数据库不是库存管理系统。后者只是提供有限的有关软件、硬件和网络设施方面的信息，而前者除此之外，还保存了这些与基础架构之间的关系，以及与它们有关的各种文档。
最终软件库（DSL）
最终软件库（Definitive Software Library）是一个存放和保管所有已批准的最终版本的软件配置的地方，它是软件正本存放的物理性仓库或逻辑性的存储空间。这个逻辑性存储空间在实际中一般由一个或多个物理性软件库或软件存储器组成，它们应当与待开发或待测试的文件存储空间分隔开来。最终软件库也可能包括一个用来保管外购软件正本（比如防火墙软件）的物理性软件仓库。由于受到变更管理和发布管理的严格控制，只有那些已经过批准认可的软件才会被纳入最终软件库中。
最终软件库并不只是为了满足配置管理的需要，它也是发布管理和配置管理的共同基础。
目标和范围
目 标
[*]所有配置项（配置项） 能够被识别和记录；
[*]配置项当前和历史状态得到汇报；
[*]维护配置项记录的完整性；
[*]提高IT 环境的稳定性；
[*]确保IT 资产的有效控制和管理。
范 围
配置管理的范围是IT 生产环境的所有配置项（配置项） ，包括生产环境的服务器，存储设备，机房环境，应用软件，网络设备，板卡，重要的客户端，合同，文档等；具体内容包括识别，控制，汇报和审核等行为。
配置管理涉及IT 基础架构中所有IT 组件及其相应的版本，以及各IT 组件之间的关系，配置管理需要对它们进行识别、记录、报告和审核等行为。
主要活动
配置管理流程的基本活动主要包括配置管理计划、配置识别、配置项控制、配置状态报告、配置审验、配置管理数据库（CMDB）备份、存档和保管等。下面对这些活动进行介绍：
配置管理计划
配置管理是整个组织IT 基础架构的控制中心和信息中心，它的运作成功与否对其他流程的运作具有相当的影响。特别是配置管理数据库，它是变更管理和发布管理的基础。因此，在正式实施和运作前应当对配置管理进行充分的计划和安排。一份合理的配置管理计划应当包括以下内容：
[*]配置管理的目标和范围；
[*]与特定的支持小组相关的政策、标准和程序；
[*]配置管理角色和责任安排；
[*]配置项命名规则；
[*]实施配置管理活动的日程安排和程序；
[*]与第三方（如变更管理、供应商等）的接口控制；
[*]配置管理系统的设计。包括CMDB、配置管理数据的存放地点、配置项运行的受控环境、与其他服务管理系统的联系和接口、构建和安装等支持工具；
[*]配置管理的内务工作，包括许可证控制、配置项的存档等；
[*]计划的配置基准线、重大发布、里程碑以及针对以后每个期间的工作量计划和资源计划。
配置标识
配置标识是配置管理的一项基础性工作，它要确定配置项的范围、属性、标识符、基准线以及配置结构和命名规范。下面对这些活动进行介绍：
确定配置管理范围
配置管理流程对IT 基础架构的有效管理是通过将IT 架构分解为单个的配置项并对其分配唯一的标识和编号来实现的。在确认配置项之前，首先必须确定配置管理的范围。
一般来说，配置管理的范围包括用于构建、发布、验证、安装、分发、维护、恢复和移除配置项的硬件和软件及相关文档。这里的硬件包括大型机、工作站、打印设备和网络设备等，软件包括客户自行开发的系统，购买的商业应用系统，以及系统软件如操作系统等；文档可包括服务级别协议、规程、操作手册、技术规范、组织结构图和许可证等。文档可以存放于不同地点，但它们的版本号、发布日期、作者、存放地点其他相关信息应保存于配置管理数据库中以便配置管理和变更管理对其进行控制。
确认和记录配置项属性
为了便于对配置项进行管理，配置管理需要预先确认和记录各配置项，特别是高风险或关键的配置项的属性。配置项属性一般包括配置项的名称、编号、类别、版本号、责任人、来源、提供日期、许可证号、目前状态、计划状态、父配置项关联、子配置项关联、事件号、问题号、变更请求号、变更号、备注等内容。
为配置项定义标识符
为便于识别，配置管理应该赋予每个配置项一个唯一的标识符并维护这些标识的准确性。对于硬件配置项，可以通过在硬件配置项上贴上或刻上物理标记或通过条形码来定义配置项的标识符；对于软件配置项，可以在将其软件拷贝存入最终软件库（DSL）中时制作一个包含配置项名称和版本号的标签；而对于文档配置项，可以通过在文档命名中加入有效日期和更新日期加以标识。
确定配置基准线
配置基准线（Configuration Baseline）是对某个特定时点上一组配置项的描述。一项完整的配置基准线应该包括以下内容：
[*]过去的、当前的和计划中的发布信息；
[*]过去的、当前的和计划中的变更信息；
[*]批准和实施变更时系统的状态和有关文档；
[*]实施发布时系统的状态和有关文档；
[*]按标准规范配置的硬件和软件。
确定配置结构
为了完整地识别和记录各配置项之间的关系，确定IT 基础架构的配置结构。配置结构说明了配置项的层次结构以及各配置项之间的关系。这里的结构可以是基础架构的配置结构，也可以是服务配置结构。与配置结构有关的一个关键问题是配置项的选择。一个配置项可以是一个独立的硬件单元或软件模块，也可以是由多个不同的配置项组合成的一个较大的配置项。
确定配置项命名规则
命名规则（Naming Conventions）可应用于配置项标识、配置文档、变更和基准线等。合理的命名规则有助于管理配置结构中各配置项的层次关系、每个配置项的层次或从属关系、配置项与其相关的文档之间的关系、文档与变更之间的关系、事件和变更之间的关系。配置管理应该建立所有的配置项和控制形式（如RFC）的命名规则。命名规则的制定应尽量考虑配置项名称的延续性、易记性可扩展性。
配置项控制
配置项控制是指在正式建立配置文档后对配置项变更进行控制的各种活动，包括对变更的评价、协调、批准或否决等活动。进行配置项控制的目的在于确保配置管理数据库中只记录那些得到批准和可识别的配置项，同时配置项的增加、修改、替换或删除是根据适当的控制文档（如批准后的变更请求、更新后的命名规则）进行的。为此，配置管理需进行以下配置项控制活动：
[*]注册新配置项及其版本；
[*]更新配置项记录；
[*]许可证管理；
[*]撤销或删除配置项时将相关记录存档；
[*]保护各种配置项的完整性；
[*]定期检查配置项以确保它的存在性和合规性并相应更新配置管理数据库。
配置状态报告
配置管理流程应当针对所有受控配置项的当前版本和变更记录定期制作配置状态报告。通过配置状态报告，配置管理人员可以了解配置项以前、当前及计划的状态，可以跟踪基准线和发布版本之间的变动情况。配置状态报告内容包括：
[*]基准线和发布标识符；
[*]为构建系统或应用所使用软件的最新版本；
[*]对系统所进行的变更次数；
[*]基准线和发布版本的数量；
[*]配置项的使用和变动情况；
[*]对基准线和发布版本的比较结果。
配置审验
为了确保配置管理数据库中包含的配置信息能够完全真实地反映IT 基础架构中配置项的存在及变更情况，配置管理人员需要对配置项和CMDB 进行审验。配置管理人员可以采取自动审验工具对基础架构中的配置情况进行审验，并针对报告基础架构的当前的状态。
一般来说，配置审验应当定期进行。但在以下几种情形下应当进行配置审验：
[*]实施新的配置管理数据库之后；
[*]对IT 基础架构实施重大变更前后；
[*]在一项软件发布和安装被导入实际运作环境之前；
[*]灾难恢复之后或事件恢复正常之后；
[*]发现未经授权的配置项后；
[*]任何其他必要的时候。
部分常规配置审验工作可由审计软件完成，比如比较两台电脑的配置情况和分析工作站并报告当前的状况。但要注意的是，审计软件即使发现不一致的情况，也不允许自动更新配置管理数据库，而必须由有关小组调查后再进行更新。
配置管理数据库备份、存档和保管
配置管理数据库（CMDB）中的数据信息应当定期进行备份并保存在安全的地方。为了应付灾难的发生，一般建议将CMDB 的一份拷贝保存在一个较偏远的地方。备份的频率和保管政策需要根据IT 基础架构的规模和变动情况来确定。
配置项记录示例
配置项分类
配置项状态
配置项之间的关联关系
配置项属性
与其他流程关系
配置管理流程在运作过程中需要其他流程为其提供信息，如变更管理流程提供的有关IT 组件变更的信息以及采购流程提供的有关IT 组件采购的信息。配置管理同时也为其他流程提供配置管理报告和配置管理数据库中的信息。配置管理数据库与其他相关流程的关系如图：
资料来源： IT Service Management, an Introduction．
图2.12：配置管理与其他流程的关系
[*]事件管理：事件管理需要配置项等方面的信息以确定配置项的具体位置和责任人，了解是否存在与配置项有关的问题和知名错误；
[*]问题管理：问题管理需要根据配置管理所提供的基础架构配置方面的信息分析问题或知名错误与配置项之间的关系，并根据配置管理数据库中的信息对事件和问题进行调查和分析，如通过比较基础架构的实际配置与配置管理数据库中的被批准的配置来发现基础架构的缺陷；
[*]变更管理：变更管理根据配置管理数据库中提供的配置项之间相互关系的信息来估计某个特定的IT 组件的变更对其他组件可能产生的影响，同时变更管理也为配置管理提供有关IT基础架构变更方面的信息，以更新配置管理数据库；
[*]发布管理：发布管理为配置管理提供有关IT 基础架构配置变更的发布计划和版本信息（如发布日期）以及已实施变更的配置项的信息。另一方面，在实施变更和发布前，发布管理需要根据配置管理提供的配置项信息（如配置项的状态、位置等）确定发布的类型和范围。
角色划分和职责
关键成功因素
要保证配置管理流程的成功运行，需要从以下几个重点关注：
[*]所有配置项应该被记录；
[*]配置项应该进行分类；
[*]所有配置项要进行编号；
[*]应该定期对配置数据库中的配置项与实际生产环境的配置项信息进行审计；
[*]每个配置项在建立后，应有配置负责人负责；
[*]要关注配置项的变化情况；
[*]应该定期对配置管理进行回顾；
[*]能够与事件问题、问题管理、变更管理进行关联。
常见场景及优化
衡量指标
[*]IT 资产管理方面
[*] 在配置管理数据库中发现的配置项属性出现错误的比例；
[*] 成功通过审查和验证的配置项的比例；
[*] 审查和验证配置项的速度和准确性。
[*]提高IT服务质量方面
[*] 因配置项信息不准确而导致的IT 服务运营故障比例；
[*] 组件修复速度；
[*] 客户对服务和终端设备的满意度；
[*] 没有变更单且配置管理数据库没有更新的次数；
[*] 有变更单但配置管理数据库没有更新的次数；
[*] 配置项实体配置错误的次数；
[*] 审计过程中配置项状态差异百分比及其趋势；
[*] 增加的新配置项的数量及其趋势；
[*] 报废的配置项的数量及其趋势；
[*] 修改的配置项的数量及其趋势；
[*] 上一次的改进行动计划的落实情况。
返回到首页 《ITSS认证IT服务工程师培训教材》_试用版_2011_0311连载 http://ITIL-foundation.cn/thread-36464-1-1.htmlITSS、培训、服务、资格、评估、ITSS培训师、ITSS评估师、实施ITSS、ITSS符合性、ITSS服务工程师、ITSS服务项目经理、ITSS标准、ITSS咨询、ITSS工具、IT服务监理、ITSS体系、ITSS服务质量、评价、指标、运维、治理、咨询、ITSS出版物、ITSS产品、服务监理工具、服务质量评价工具、标准符合性评估工具、服务管理工具、服务治理工具、系统监控工具、辅助决策分析、服务支持管理、基础设施监控、ITSS基础教材、ITSS标准、ITSS服务人员培训教材、标准化、专业化、人员（People）、流程（Process）、技术（Technology）和资源（Resource），简称PPTR、规划设计（Planning&Design）、部署实施（Implementing）、服务运营（Operation）、持续改进（Improvement）和监督管理（Supervision），简称PIOIS、服务交付规范、资源要求、外包管理、服务交付、分类、代码、服务指南、通用要求、指标体系、ITSS落地实践交流-QQ群：21542747
页:
[1]