ITIL理念与实操

前言

业务部门与IT部门的矛盾似乎永远存在……

面对企业领导的疑问：
IT部门不断伸手要钱，IT投资不断增加，难道IT投资真实个“无底洞”？怎么样才能让我看到IT投资的实效？花巨大资金“养”这个部门是否值得？
面对业务部门的责难：
信息系统总是出现问题，信息部门的人都是干什么吃的？公司为信息部门投入了那么多，怎么一点改善都没有？我们怎么没有感觉到IT带来的收益？
IT部门的委屈：
一天到晚忙忙碌碌，通宵达旦加班，工作得不到认可，郁闷！IT初期需要高投入，回报确实长期的，怎么才能算清楚？信息中心难道永远是“有苦劳没功劳”，总是受气的“童养媳”？

IT部门如何消除与其它部门的矛盾 ？

明确IT部门的定位
建立整体的信息化管理体系
建立高效的运维管理机制
打造一支能打硬仗的IT团队

本文将会带领大家：

熟悉ITIL的基本概念，了解ITIL体系中核心流程
架起业务和IT的桥梁，理顺业务部门和IT部门的关系
促使IT部门成为以服务为导向的组织，提高服务级别及客户满意度
更合理地使用IT资源，使IT投资达到效益最大化，更有效地控制IT成本

三个方面来阐述ITIL带给大家的帮助：

如何改变IT部门救火队员的角色？

信息化建设时期如何同步进行信息化建设和信息化运维管理？

ITIL如何实施？

一、IT服务产生的背景

1、根据Gartner Group的调研，信息化管治的发展有以下趋势：

企业/单位的IT服务在进一步的集中。这种集中不仅仅是单纯地集中IT人员，而是形成更模块化和专业化的结构。Gartner Group 预期，为了在企业/单位内部充分利用稀缺资源，以各种管理和投资方式出现的能力中心和共享服务中心将会增长。

多数企业/单位注意到其IT流程的重要性，并努力改善IT流程。企业/单位根据其IT流程模式建立了相应的IT 服务组织。流程模式指综合的流程集合，用于提供IT 服务。大多数流程建模工作是在集中型企业/单位而不是分散型企业/单位中实现的。
IT服务组织，面临渐增的外部服务商的竞争压力和组织复杂性，正在寻求和流程相配合的方法，以有效的管理来改善服务水平。流程模式和框架将被广泛地作为确定工作流、管理协议和变革协调的工具来使用。

对很多企业/单位来说，找到合适的外部服务提供商是一个挑战。预计外部服务提供商将覆盖所有IT 服务，特别在应用开发、维护和网络服务方面。这个趋势对IT服务组织传统的角色和结构有显著的影响。IT服务团队将变得更注重于战略规划、项目管理、IT体系结构管理、合同管理、关系管理（在业务和IT 服务组织间）和知识管理（管理业务流程知识，支持信息系统，以保证知识是保留在企业/单位内部）。

在现代企业/单位中，提供某种服务的部门或组织，根据其服务的性质与被服务对象之间签订服务水平协议已经成为一种趋势。这种做法有利于规范服务提供者和服务收益者之间的关系，加强对服务工作的衡量和管理。IT管理部门作为信息服务的提供者，也应该从这种管理方式中得到借鉴。服务水平管理涉及的内容包括建立在服务预算基础上的：SLA 领导、SLA 协调、SLA 激励机制以及与SLA 相关的培训、汇报和衡量机制。

2、信息化管理要素框架

IT服务管理中信息化部门的两层含义：
一、为其它部门提供支持和服务，
二、创造价值。
首先，信息部门本身并不直接创造价值，是依托其它部门的管理及业务需要而存在的。因此，为其它部门提供信息化相关支持和服务是信息部门的职责所在；同时，虽然信息部门并不产生直接利润或者收益，但通过信息化的手段提高其它部门的效益，降低运行成本，同样为组织创造了价值，从而也就体现了自身的价值所在。

3、在信息化过程中，信息化部门的三种组织类型

信息部门在IT服务中有三种不同的类型：支撑型、使能型和内在驱动型。

1、支撑型模式下，信息化只能通过减少成本带来利益。
2、使能型模式下，信息化带来内部流程创新潜力，但并不向外扩张这些利益。
3、内在驱动模式下，信息化为业务创造更大的发展空间。

4、在信息化过程中构建高绩效IT部门的步骤

为什么要构建高绩效的IT部门？
需要理解“IT治理”和“IT管理”的区别！

5、在不同业务阶段，信息部门应发挥不同作用

6、IT服务管理的产生背景

IT服务的提供是指对IT基础设施的全面管理(维护和运营)。
在服务提供过程中，客户的体验是非常重要的。客户通常会通过下列问题去评估服务的质量：
服务满足期望了吗？
我在下一次得到同样的服务吗？
服务是以合理的成本提供的吗？
满足客户期望的关键点：提供的服务是否与客户的需求一致，而不仅仅是对提供了多少服务的考核。
与客户期望达成一致的重要手段：沟通！
服务成本是服务与质量相关的一项派生关注点。

两个需要重点注意的问题：
1、一个组织确定其成熟度后，可以为改进活动制定一个战略，根据这个战略可以进一步制定具体的计划。
2、针对组织内部的局部改进活动对最终结果只会产生有限的影响。如果没有针对客户关系、员工满意度和领导力进行改进，或组织的战略或政策不是很明确，则其他局部的改进活动都不会取得很好的效果。

IT服务管理：匹配服务提供者的能力与客户的需求

IT服务管理：在服务过程中需要重点关注客户关系

在IT服务管理中，最大的难题就是要确保IT部门和客户在各个层次上都维持良好而有效的关系。

IT服务管理：服务流程不因组织架构而变异

为什么（WHY）：流程结构可以确保获得有关服务供应的全面的数据，从而可以改进服务的规划和控制。
做什么（WHAT）：横跨几个部门的流程通过监控质量的某些方面，如可用性、能力、成本和稳定性等，可以监控一项服务的质量。
为谁做（WHO）：服务组织需要尽可能地将这些质量特征与客户的需求进行匹配。。

二、ITIL简介

ITIL，全称Information Technology Infrastructure Library，统一译为“信息技术基础架构库”或“IT基础架构库”。它是英国国家计算机和电信局CCTA（现在已并入英国商务部）于80年代中期开始开发的一套针对IT行业的服务管理标准库。
ITIL产生的背景是，当时英国政府为了提高政府部门IT服务的质量，启动一个项目来邀请国内外知名IT厂商和专家共同开发一套规范化的、可进行财务计量的IT资源使用方法。这种方法应该是独立于厂商的并且可适用于不同规模、不同技术和业务需求的组织。这个项目的最终成果就是现在被广泛认可的ITIL。
ITIL虽然最初是为英国政府部门开发的，但它很快在英国企业中得到广泛的应用。在20世纪90年代初期，ITIL被介绍到欧洲的许多其它国家并这些国家得到应用。到90年代中期ITIL已经成为欧洲IT管理领域事实上的标准。90年代后期ITIL又被引入美国、南非和澳大利亚等国。90年代末，ITIL也被有关公司引入中国。

ITIL基于这样的背景产生：

组织正日益依赖于IT来实现其业务目标
在整个IT产品的生命周期中，运营阶段占了整个时间和成本的约70％至80％
在任何情况下，服务必须具有可靠性、一致性和高质量，并且其成本也应当是可接受的。

IT服务管理主要涉及对为满足组织需求而定制的IT服务的交付和支持。ITIL 被开发出来也是为了系统和一贯地推广得到实践证明的IT服务管理最佳实践。

ITIL核心关注：服务质量，为满足统一的服务质量，使用相对统一的服务框架/流程，部门或岗位间的职责分配主要取决于已有的组织架构。

ITIL的价值：对客户的价值分析

IT服务的提供变得更加以客户为中心，同时在服务质量上的协商一致会改进双方的关系。

服务内容可以以客户的语言和更为恰当的详细程度得到更好的描述。

可以对服务质量、可用性、可靠性和服务成本进行更好的管理。

通过对联系点的协商一致改进与IT部门的沟通。

ITIL的价值：对IT部门的价值分析

IT部门会形成一个更为明晰的架构，从而变得更有效率和更为关注公司目标。

更加有利于IT部门对其负责的基础设施和服务实施控制，同时变更也变得更易于管理。

一个有效的流程架构为有效地外包某些IT服务提供一个框架。

遵循ITIL最佳实践可以促进文化变革从而有助于服务质量的改进，还可以对采纳基于ISO 9000系列标准或BS 15000的质量管理体系提供支持。

ITIL为内部沟通和外部供应商沟通，以及程序的标准化和识别提供一个一致的参考框架。

应用ITIL可能产生的问题和错误

ITIL的引进需要花费很长的时间和很大的努力，并且需要组织进行文化变革。
如果将完善流程结构变成一个孤立的目标，服务质量也可能会受到负面的影响。
由于对相关流程应当产生的结果、恰当的绩效指标和怎样对流程进行控制缺乏基本的了解，无法对IT服务实施改进。
由于没有可作为比较参照的基线数据和(或)确立了错误的目标，在服务质量和成本降低方面的改进不是很明显。
一项成功的实施需要组织内各层次人员的参与和承诺。
如果在适当的培训和支持工具方面缺乏足够的投资，流程可能不会产生应有的作用，从而服务无法得到改进。如果组织实施了过多的IT服务管理活动而又不是使用“最佳实践”，则可能在短期内需要更多额外的资源和人力。

ITIL的基本框架

ITIL的基本框架：服务管理

ITIL的基本框架：服务管理- 服务台

服务台提供每天对IT使用者的服务窗口。使用者反馈对IT服务不满、疑问和建议等。基于这个原因，服务台应该是一个很容易让使用者可以反馈的界面窗口。

服务台，也是使用者在使用IT服务的登录点，他们的表现代表IT服务给客户的服务品质。

服务台，也要负责尽快地协助顾客恢复服务的运作，比如提供使用指引，修正，或针对某一意外事件做补救。服务台不负责意外事件的分析，这类的深入分析是属于问题管理的范畴。

ITIL的基本框架：服务管理- 服务支持 - 事件管理

目标：尽快恢复正常服务运营，并将对业务造成的影响降到最低限度，以确保服务可以达到最佳水平。

ITIL的基本框架：服务管理- 服务支持 - 问题管理

目标：将问题导致的负面影响降至最低，并积极找出、去除IT服务中的错误，以维持一个稳定的IT服务。
活动：
问题控制
错误控制
主要事故支持
管理信息
主要问题评估
主动预防问题

ITIL的基本框架：服务管理- 服务支持 - 变更管理

目标：确保在IT服务变更的过程中能够有标准化的方法以有效地监控这些变更，降低或消除因为变更所造成的问题。所谓“变更”是指一些在IT基础建设项目上的动作所造成一个新的状态。所有在配置项目上的变更都必需纳入变更管理的控制。

ITIL的基本框架：服务管理- 服务支持 - 配置管理

目标：
1、在维持配置管理数据库(CMDB)中每个IT基础建设的配置记录。
2、提供配置项目(CI)的报表。这包含以下的管理信息，
问题记录
变动记录
版本信息
状态信息
关系信息

ITIL的基本框架：服务管理- 服务支持 - 发布管理

目标：保障所有软件模块的安全性，以确保只有经过完整测试的正确版本得到授权进入正式运作环境。为了控制软件的版本，需要建立一个“最终软件库”(Definitive Software Library；DSL) 。

ITIL的基本框架：服务管理- 服务提供 - 服务级别管理(SLM)

目标:维护并逐渐提高面向业务的IT服务质量,通过以下的循环实现

定义
统一
监控
报告
评估
清除

ITIL的基本框架：服务管理- 服务提供 - 财务管理

目标:平衡IT服务的成本与效率

ITIL的基本框架：服务管理- 服务提供 – 能力管理

目标:支持IT服务的最佳效率，主要是在调整营运需求和IT资源的平衡。能力管理是要确保在合适的时间，地点和适当的成本下提供合适的资源。对IT部门来说，有效地利用可用资源很重要，并且要对系统营运的未来需求制定计划。

要求我们理解:
未来业务需求
组织运作
IT构架

ITIL的基本框架：服务管理- 服务提供 - 持续性管理

目标：确保处理IT系统危机并在规定时间内恢复的能力，以支持整体业务连续性。例如有一段时间无法提供服务，这需要将工作转移到另一套系统，而这并不应是平常会遇到的。我们必需发展一套在面临IT危机时能够恢复正常运转的计划以备不时之需。

业务持续性生命周期
阶段 1 – 启动持续性管理
阶段 2 – 需求和战略
阶段 3 – 实施
阶段 4 – 运营管理

ITIL的基本框架：服务管理- 服务提供 - 可用性管理

目标：在正确使用资源，方法及技术的前提下，保障IT服务的可用性。当企业营运越来越依赖IT，为了维持竞争力，IT必需避免或减小预期外的当机时间。可用性管理在深入探讨那些资源和测量是维持最佳营运状态所必要的，希望能让资源的使用最有效。

ITIL的基本框架：安全管理、IT基础设施管理、应用管理

安全管理(Security Management)的目标是按照保密性、完整性和可用性的要求保护信息的价值。这个目标的确立是基于服务级别协议中所确定的安全性需求的，这些安全性需求通常与合同的要求、法律法规以及组织的政策相关。安全管理致力于在独立于外部条件的情况下提供一个基本的安全性级别。

IT基础设施管理主要论述了为提供一个稳定的IT和通信基础设施所需的流程、组织和工具，这个IT和通信基础设施需要以合理的成本满足业务需求，以技术为中心构建。

应用管理(Application Management)提供对应用管理生命周期的一个概要性介绍，并可为企业用户、开发人员以及服务经理了解如何从服务管理的角度对应用系统进行管理提供指导。

传统IT管理与ITIL的比较

ITIL对业务有哪些好处？

三、ITIL的核心岗位：服务台

1、服务台概述：

服务台(Service Desk)在用户支持方面扮演了重要的角色。
一个成熟的服务台可作为其他IT部门的前台，能够在无需联系专家的情况下处理一些客户询问。

对于用户来说，服务台为他们提供了联系IT部门的单一联系点(SPOC，Single Point Of Contact)，从而可以确保他们能找到合适的支持人员来帮助解决其问题或请求。

服务台可以理解为一个岗位、一项职能、一个部门或者一个组织单元，不是一个流程。

注意服务台与帮助台的区别，后者往往只在“事件管理”流程中出现。

ITIL的核心岗位：服务台-与相关流程的关系

ITIL的核心岗位：服务台-基本结构类型

服务台结构有多种选择。常见的方式包括：

集中式服务台(Centralised Service Desk)作为所有用户的单一联系点，可能还单独设立了一个服务台来处理用户在业务应用系统方面的问题(职能分离的集中式服务台，Split Function Centralised Service Desk)。

本地式(分布式)服务台(Local／Distributed Service Desks)分布在多个地方。通常，将服务台划分为多个本地服务台将会导致更加难以管理。

虚拟式服务台(Virtual Service Desk)并没有实质性的位置，这是由于使用了通信技术。

ITIL的核心岗位：服务台-基本结构类型

1、集中式服务台

如果IT部门需要同时负责提供服务(信息系统)以及为信息系统的使用提供支持，那么最好是将服务台作为用户的一个单一联系点。这种方式可以与运营桥结合使用以方便服务台和运营管理(生产、运营)之间的直接沟通，这里所指的生产包括网络管理、计算机运营等。这种直接沟通可以保证在出现服务台不能立即解决错误的情况下仍然能够作出快速响应。

2、分布式服务台

分布式服务台一般被分成多个服务台分布在多个地点，如在不同的大楼里甚至在不同的国家。

3、虚拟式服务台

分布式服务台的现代化和专业化版本就是虚拟式服务台。它由一些本地服务台组成，由于现代通信技术和网络使得地理位置变得无关紧要，因此，虚拟式服务台看起来是一个统一的实体。

服务台和支持人员现在可以分布在任何地方。通过在世界各个时区的不同位置设立本地服务台，可以向用户提供全天候的支持服务(“日不落式”)。
虚拟服务台的缺点在于提供现场支持变得更加困难。

ITIL的核心岗位：服务台-人员类型

呼叫中心：这种类型的支持单元只负责记录呼叫请求而不提供解决方案。呼叫请求被转发到相应的专业部门。

非技能型或呼叫记录型服务台： 呼叫请求被记录下来，并用通用的术语进行描述，这些呼叫请求大多数被立即转发至相应的支持人员。这种服务台在很大程度上只是一个调度部门。这种方式的优点在于事件记录被标准化了。其缺点是响应时间比较长，首次呼叫解决率要远低于技能型服务台。

技能性服务台： 这种类型的服务台比前面几种服务台具有更多的技能和经验。通过使用文档化的解决方案，它可以解决许多事件，虽然有些事件还是要转发给相关的支持小组。首次呼叫解决率通常都要远远高于非技能型服务台。

专家型服务台：这种类型的服务台具有关于全部IT基础设施的专家知识以及独立解决大部分事件的专门技术。

ITIL的核心岗位：服务台-主要活动分析

ITIL的核心岗位：服务台-关键绩效指标

服务台应当定期(最少每月一次)核实其运作是否达到了预定的标准。评价这一点的指标包括：

在没有求助其他支持层次如二线支持、三线支持或供应商的情况下事件被解决的百分比；

每个工作站/用户被处理的呼叫数目，以及整个服务台该项指标的总数；

平均事件解决时间，实现一项服务请求之前已经造成的影响和经历的时间。总共耗费的时间和实际耗费在呼叫请求上的时间应该进一步明确；

关于平均答复时间、被用户放弃的呼叫请求的数目、平均呼叫持续时间以及每个服务台分部的相对指标等方面信息的PABX（程控交换机、集团电话）报告。

可以针对这些指标设定标准，从而可用来监控服务的改进或变化。服务台的运作效果也可以通过定期在客户中进行调查来进行评价。

四、部分 ITIL的核心流程：服务支持

事件管理
问题管理
配置管理
变更管理
发布管理

1、事件管理-概述

事件管理(Incident Management)是一个被动性的任务，也就是减少或消除存在或可能存在于IT服务中的干扰因素给IT服务带来的影响，以确保用户可以尽快恢复自己的正常工作。
关键点：事件分类、主动服务、与客户沟通

ITIL的核心流程：事件管理-基本术语

事件(Incidents)，即在某一服务中不属于标准操作(standard operation)的并能导致、或可能导致这个服务的中断或服务质量下降的任何事件(event)。

事件包括：
软件错误/故障；
硬件错误/故障；
服务请求；

事件管理流程涉及服务的整个生命周期。

服务请求(Service Requests)也可作为“标准服务(standard services)”：它是根据服务级别协议(SLA，Service Level Agreement)提供的；其提供是根据既定程序进行，而这些程序是经过协商的且具有适当的检查和控制功能；它也应该保存在维护记录的地方，如配置管理数据库(CMDB，Configuration Management DataBase)。

服务请求：用户想要获得支持、递送、信息、建议或文档的请求，它并不属于IT基础设施方面的故障。

服务请求的例子：
● 功能方面的问题或请求
● 状态查询
● 口令重置
● 对批处理活动、恢复以及口令认证的请求
● 数据库的提取
● 要求提供具有一定IT技能或服务的新雇员的请求

当同时处理若干事件时，必须设定优先级。优先级是根据错误对用户和正常业务带来的影响的严重程度来确定的。优先级决定了事件得到处理的先后顺序。

优先级=影响度×紧急度

影响度(Impact)： 影响度指就所影响的用户或业务数量而言，事件偏离正常服务级别的程度。重要事件是指那些对用户团体带来非常严重影响的事件。而有些在时间上极度紧迫的需要解决的事件也应当作重要事件来处理。
紧急度(urgency)：紧急度指解决故障时，对用户或业务来说可接受的耽搁时间。


升级：

如果某一事件不能在规定的时间内由一线支持小组解决，那么更多有经验的人员和有更高权限的人员将不得不参与进来。它可能发生在事件解决过程的任何时间和任何支持级别。 升级分为职能性升级和结构性升级。

多线支持：
1线支持(也称为第1层次支持)通常由服务台来提供；
2线支持则通常由管理部门提供；
3线支持则多由软件开发人员和系统结构人员提供；
4线支持由供应商提供。
公司(组织)越小，则可供升级的级别数就越少。

价值：

对于整个业务来说：

更及时地解决事件可减少事件对业务的影响；
提高用户的工作效率；
独立的、面向用户的事件监控；
基于SLA的业务管理信息的可用性。

对IT部门来说：

改善监控，对SLA的执行情况可进行更为准确的评测；
有用的关于服务质量的管理报告和服务级别协议(SLA)报告；
更好地和更有效地使用人力；
避免事件和服务请求的丢失或被不正确地记录；
更准确的配置管理数据库(CMDB)。因为当根据配置项对事件进行注册时对配置管理数据库(CMDB)的检查是必不可少的；
提高用户和顾客的满意度。

由于执行失败，可能会导致的负面影响

由于无人负责监控和升级事件，事件可能会无谓地加剧并降低服务的等级，事件得不到解决，用户不断地被迫求助于其他部门；
专业人员经常会受到用户打来电话的干扰，这意味着他们将不能正常地完成工作。结果是，几个人可能会同时参与到对同一事件的处理工作上，既浪费时间，又可能会得出相互冲突的解决方案；
与用户和服务相关的管理信息的缺乏。
由于以上问题，由业务部门和IT部门耗费的成本会比正常的高出许多。

事件管理-基本流程

事件管理-与其他流程的关系

事件管理-相关成本分析

与事件管理相关的成本包括：
初始执行成本：如对流程和过程的定义以及相互间的沟通；
培训和指导人员成本；
选择和购买支持流程的工具的成本；
……
另外，还有与人事和工具使用相关的成本。

这些成本在很大程度上取决于事件管理的结构、活动范围和责任，以及与该流程有关的场所的数量等。

事件管理-常见问题分析

2、问题管理

如果发生事件则启动事件管理流程对其进行处理；当服务恢复正常，受影响用户恢复工作时，就停止对该事件的处理活动。但是这样做意味着导致事件发生的根源并不一定都解决了，因而事件还有可能再次发生。

问题管理(Problem Management)调查基础设施和所有可用信息，包括事件数据库，来确定引起事件发生的真正的潜在原因以及提供的服务中可能存在的故障。

一旦找到了永久解决这些根本原因的方法，我们就可以发出一个变更请求(RFC)来消除这些已知错误。而在此之后，问题管理会继续跟踪和监控这些基础设施中的已知错误。

ITIL的核心流程：问题管理-与事件管理、变更管理的关系

问题管理的基本流程

ITIL的核心流程：问题管理-与其它流程的关系

3、配置管理

配置管理(Configuration Management)流程负责核实IT基础设施中实施的变更以及配置项之间的关系是否已被正确地记录下来了；监控IT组件的运行状态，以确保配置管理数据库能够准确地反映现存配置项的实际版本状况。

配置管理流程的目标就是要提供有关IT基础设施的可靠和最新的信息。值得一提的是，这些信息不仅包括基础设施中某个特定的项目(配置项，或CI’s，Configuration Items)的详细资料，还包括这些配置项与其他配置项之间的相互关系方面的信息。

配置管理流程得到了有效的实施，可以提供以下几方面的信息：

产品政策
我们正在使用的是哪些IT组件？
每一个模块(版本)中有多少这样的组件？
这些组件我们使用了多长时间？ • 不同产品线中各存在怎样的趋势？
哪些IT组件可以停止使用、哪些需要进行升级？
我们拥有哪些许可证(licenses)以及这些许可证是否够用？
哪些维护合同需要进行审查？
我们的IT基础设施的标准化程度如何？
故障检修信息和影响度评估
灾难恢复程序需要哪些IT组件？
如果配置修改了，灾难恢复计划是否仍然有效？
受试运行(Rollout)影响的IT组件有哪些？
设备连接到了哪个网络？
包括在每个套件中的软件模块有哪些？
受某项变更影响的IT组件有哪些？
哪些针对特定IT组件的变更请求(RFC)正在评估中？
已经发生了哪些事件和问题？这些事件和问题中与当前相关的有哪些？
哪些IT组件导致了已知错误
服务提供和计费
对某个服务项目而言，哪些IT组件配置是至关重要的？
哪些IT组件正在被使用以及谁在使用它们？
哪些是用户可以订购并得到支持的标准IT组件？

配置项可以包括由IT部门控制的所有PC硬件、软件、有源和无源网络、服务器、中央处理器、文件、规程、服务以及由IT部门所控制的所有其他IT组件。

流程

4、变更管理

变更管理(Change Management)旨在管理变更的过程，以及相应地减少错误和与变更有关的事件。

变更概述：

流程范围：变更管理流程的范围由配置管理和发布管理决定。决定范围是一项动态的工作，因为范围可以改变，所以从配置管理数据库(CMDB)中的信息需求也随之改变。故而，必须定期评审范围，而且配置管理数据库(CMDB)中的数据模型也必须相应地更新。

标准变更：那些被生产商明确定义并由他们完成的常规管理任务，不需要由变更管理来控制。
标准变更中的常规任务包括：新建用户账号，改变网络连接和安装PC等等。
在标准变更的情况下，活动在完整变更管理流程中不是作为变更来执行，但是可以划分为事件管理下的服务请求。

基本流程：

5、发布管理

概述

发布管理(Release Management)采用一种项目规划的方法来实施IT服务中的变更，它负责处理变更项目所有技术和非技术方面的问题。

发布管理的目标是要通过正式的程序来确保生产环境的质量以及在实施新的版本时对其进行检查。

与变更管理不同，发布管理主要关注的是变更的实施，而变更管理则涉及整个变更流程，并且主要关注与变更有关的风险。

总体而言，发布管理主要涉及的还是软件方面。

发布是由一项或多项经过批准的变更所组成。根据层次的不同，它可分为以下三类。

重大发布： 新的硬件和软件的大型试运行(Rollout)，通常是伴随着重大的功能增强。这种发布通常可以消除多个已知错误，包括临时性的应急措施和临时性修复。
小型软件发布和硬件升级：这种发布通常是指对已知错误进行的一些小的改进和修复。
紧急修复： 通常用来对某个问题或已知错误进行临时性修复。

由于可能同时存在多个发布，因此通常给每个发布分配惟一的识别符。发布识别应该指出相关的配置项并包括一个含有两位或更多数字的版本号，例如：

重大发布：管理系统V.1，V.2，V.3等；
小型发布：管理系统V.1.1，V.1.2，V.1.3等；
紧急修复发布：管理系统V.1.1.1，V.1.1.2，V.1.1.3等。

发布类型：

发布类型
德尔塔发布(Delta Release)：是一种局部发布，它只包括那些发生变更的硬件和软件组件。德尔塔发布通常在紧急修复或临时修复时使用。
优点：只需要花很少的工作来构建测试环境。
缺点：这种发布类型的缺点在于不能对发布所包括的组件以外的环境进行测试以及那些不再被软件调用的模块也被删除了。
全发布(Full Release)： 全发布指同时对发布单元内的所有组件进行构建、测试和分发，包括那些无需变更的组件。
优点：多项变更可以同时得到实施
缺点：需要更多的准备工作和资源
包发布(Package Release)：包发布是指由一组相关的应用系统和基础设施的全发布和(或)德尔塔发布组成。它一般在更长的时间间隔内进行。
优点：通过修复小的软件错误以及将多项新的功能有效地组合到一起为用户提供了更长时间的稳定期。
缺点：需要更多的准备工作和资源

基本流程

五、ITIL的核心流程：服务提供

1、服务级别管理

服务级别管理(SLM，Service Level Management)是对IT服务的供应进行谈判、定义、评价、管理以及以可接受的成本改进IT服务的质量流程。

服务级别管理试图在服务质量的供应与需求、客户关系和IT服务成本之间找到某个合适的平衡点。

服务级别管理包括对下列文档的设计、协商和维护：
服务级别协议(SLA，Service Level Agreements)
运营级别协议(OLA，Operational Level Agreements)
支持合同(UC，Underpinning Contracts)
服务质量计划(Service Quality Plans)


常见问题：

服务级别管理可以导致IT部门和客户之间形成一种类商业性的(公事公办的)关系，并要求所有的IT人员都遵守相关的协议。这需要在组织内进行一定的文化变革。
客户在确定服务级别需求方面可能需要帮助。
按照可量化的标准和相关的成本表述客户的期望是非常困难的。
服务级别经理应当提防在有关的规划、测量和监控工具，程序、服务质量计划和支持合同还没有开发和制定的情况下签订不切实际的协议。
与监控和评价服务级别相关的成本很容易被低估。
许多IT部门直接从草拟服务级别协议开始，而跳过客户需求分析、设计阶段以及服务质量计划的开发。这可能导致一个难以管理的流程，该流程不能提供清晰可量化的标准。
服务级别管理的文档和流程应该终止于它们本来应该终止的地方，而不应该成为改善IT服务提供者和客户之间关系的一种手段。

2、IT服务财务管理

IT服务财务管理的目的就是要构建对IT基础设施的管理，从而促进高效和经济的使用IT资源。其中一个目标是要激起客户的成本意识，从而促进其根据组织的业务目标合理的使用IT资源。

以合理的成本向用户提供IT服务取决于下面三个因素：
质量：能力、可用性、绩效、灾难恢复、支持……
成本：支出、投资……
客户需求：成本和质量必须符合客户的业务需求

3、能力管理

能力管理(Capacity Management)致力于在恰当的时间以一种经济节约的方式为数据处理和存储提供所需的能力。 良好的能力管理可以帮助消除某些“最后时刻”的临时应急式的盲目采购，或者超量采购。

能力管理主要论及下列几个方面：

处理能力的购买成本相对于业务需求来说，是否合理以及处理能力是否以最有效率的方式(成本Vs能力)被加以利用？
当前的处理能力是否足够满足客户当前以及未来的需求(供给Vs需求)？
现有的处理能力是否发挥了最大的效率(性能调整)？
额外的处理能力准确地讲应该在什么时候形成？
我们是否知道未来需要什么样的IT能力以及何时需要这种能力？

能力管理中包括的重要概念包括：
性能管理(Performance Management)： 为优化整体运营绩效而评价、监控和调整IT基础设施组件的性能的活动。
应用选型(Application Sizing：需要用来支持新的或改进后的服务以及预计的未来负载量的硬件或网络能力的过程。
模拟(Modelling)：使用分析、模拟和趋势预测模型来确定服务的能力需求以及确定最佳的能力方案的过程。模拟需要分析各种不同的情形，并分析各种“如果……怎么办”式的问题。
负载管理(Workload management)：主要是了解不同的业务驱动会产生怎样的结果，需要哪些资源(它既可以作为模拟的一个基本组成部分，也可以是单独的一种活动)。
能力规划(Capacity Planning)： 根据能力管理数据库分析当前的情况、预测IT基础设施未来的使用情况以及为满足预计的IT服务需求而需要的资源，从而制定能力计划的过程。

4、IT服务持续性管理

误区：许多信息部门经理认为进行IT服务的持续性管理是一种奢侈，为此他们不愿意花费任何资源。

在持续性管理流程中需要重点关注对“灾难”的预防。所谓灾难可以理解为对一项服务或一个系统造成影响从而需要付出很大的努力来恢复初始绩效水平的时间。
灾难比“事件”严重很多，它是一次业务中断，这意味着在一次灾难发生后，全部或部分业务不能正常运作。常见的灾难包括：火灾、雷击、水灾、失窃以及暴力破坏等。此外，恐怖袭击也变得常见。

与传统的意外事件规划只是反应性的流程不同（在灾难发生之后该做什么），新的IT服务持续性管理流程侧重于预防，即避免灾难的发生。

常见问题：

资源：组织没有为项目团队配备额外的资源来制定和测试恢复计划；
管理层承诺：一些和投资有关的事宜，往往更需要获得管理层的批准；
难以估计损害：IT设施因灾难导致的对业务的损害往往很难以量化；
得不到业务经理的支持；
无限期推迟：由于IT服务持续性管理的全部或大部分流程还没有就绪，从而导致进度被频繁的延期；
失盲：IT服务提供者放弃了责任，以及放弃了对IT服务持续性管理是否准备就绪的控制；
意识的缺乏：没有全体人员的意识到位和支持，IT服务持续性管理流程注定是要失败的。

5、可用性管理

可用性管理是有关设计、实施、监控、评价和报告IT服务的可用性以确保持续地满足业务的可用性需求的服务管理流程。

可用性：高可用性意味着宕机时间很少和服务恢复迅速，因而IT服务对客户是持续可用的。服务的可用性取决于：
IT基础设施的复杂程度；
组件的可靠性；
快速有效地对故障作出反应的能力；
由支持部门和供应商提供的维护的质量；
运营级管理流程的质量和范围。
可靠性：足够的可靠性意味着在约定的服务时段内服务没有发生中断。服务的可靠性由下列因素决定：
用于提供服务的组件的可靠性；
一项服务或组件在一个或多个子系统发生故障时仍能有效运作的能力(弹性)；
防止宕机的预防性维护。

**可维护性和可恢复性与维持服务的运作以及在出现服务中断时尽快恢复等活动相关。
**

主要包括预防性维护和计划性审查。这两个概念所包括的具体活动有：
采取措施防止故障的发生；
检测故障；
进行诊断，包括由组件自己进行的自动诊断；
解决故障；
在故障发生后尽快恢复；
恢复服务。
可服务性与外部服务提供商的合同契约有关(承包商、第三方供应商)。该合同定义了需要为外包服务提供的支持。有效的可用性管理要求对业务和IT环境都有充分的了解。认识到可用性并不仅仅靠“买来的”这一点很重要。

六、如何成功实施ITIL

好的方法论可以事半功倍：

1、做好现状评估

2、远景规划

3、需求设计

4、项目实施

七、附录

ITIL实施方法论 – 评估体系