分类：
2005-10-01 22:19:19
2.1 ITIL及其诞生的背景
借助IT技术的迅猛发展, 企业可以将其产品及服务快速投入市场. 传统的等级制的组织架构越来越难以应付不断快速变化的市场. 决策机制随着越来越多的决策权力逐渐下放给操作层人员而发生了变化. 在IT架构上, 异构和分布逐渐成为其主要特点. 一种新型的管理理论面向扁平的组织结构, 或者水平跨越等级制组织架构的流程(Process)势在必行. IT服务管理(IT Service Management - ITSM)的运行流程正是诞生于这个背景下.
ITIL(IT Infrastructure Library)诞生于1980年, 由英国政府发起, 委托CCTA(Central Computer and Telecommunications Agency)组织, 后成立OGC(Office of Government Commerce)专门负责英国政府和其它公共事业组织对IT资源的有效及低成本利用. 目前ITIL已经成为IT行业服务管理的理论基础. 在此基础上建立的非赢利性ITSM论坛(itSMF-IT Service Management Forumn)已成为公认的ITSM的权威性社区.
ITIL是基于流程的方法论. IT部门可用其检查是否用一种可控的和可训练有素的方法为最终用户交付所需的IT服务. ITIL合并了一套最佳的实践惯例, 可适用于几乎所有IT组织, 无论其规模大小, 或采取何种技术. ITIL被用来建立和交付服务管理流程; 这些管理任务可被某些服务及系统管理工具所简化, 例如IBM IRM管理模型及IBM的Tivoli系统管理软件等.
ITIL对IT服务管理实践中涉及的许多重要问题进行了系统的分析, 包括全面的检查清单(checklist), 任务, 程序, 责任等与任何IT服务组织密切相关的问题. 这些概念的定义也涵盖了大多数IT服务组织的主要行为. IT服务组织可以借助ITIL的指导建立和拓展自己的IT服务流程.
在ITIL的基础上, 各商业组织也建立了许多IT服务管理框架. IBM的ITPM(IT-流程模型)即为其中之一.
这些管理框架在市场上的不断普及, 是使ITIL成为事实上的行业标准的原因之一.
2.2 IT服务和质量
企事业组织常常依赖于其IT服务, 并且希望IT服务不仅能够支持本组织目前的业务, 还能够为本组织制定新的业务目标提供可能性. IT服务不仅仅局限于对技术和组织内部的支持, 还需要考虑所提供服务的质量以及和客户之间的关系.
IT服务供应涉及到对IT架构的完全管理 – 包括维护和运行.
与 “产品”不同, “服务”的提供贯穿于和客户的互动中. 只有当服务被提供时, 才能体现其存在和价值. 服务的质量取决于服务提供者与其客户间互动过程中某些协议的实现程度. 客户如何感知服务的优劣, 服务提供者如何考虑所提供的服务, 两者都很大程度上取决于他们的经验和期望.
提供服务的流程是生产和使用的一种组合方式, 通过流程使服务提供者和客户同时参与服务的过程.
客户对服务的感知主要来自于服务供应的过程. 客户通常用以下问题评价服务的质量:
所提供的服务是否达到期望? (质量可衡量性)
能否在多次服务中得到同样的质量? (质量稳定性)
服务所需成本是否合理? (质量与成本)
服务是否达到客户期望主要取决于客户在多大程度上赞同所交付的服务内容, 而不是服务提供者提供了多“好”的服务. 因此开展有效的和持续的客户对话机制极为重要.
服务质量取决于服务完成客户需求和期望的程度. 为了能够提供所需的质量, 服务提供者应该持续评估服务经验, 了解客户对未来的期望. 不同客户考虑的内容和方式都不尽相同. 因此优质服务都是为客“户量身定做”的 – 这也是服务区别于产品的主要特点.
ISO-8402对质量的定义是: “质量是一个产品或服务就其具有的能力满足确定的或暗示的需求的总体特性.” 质量 “高”往往意味着产品或服务在某种程度上超过了客户的期望.
在质量得以保证的同时, 成本也是客户同时考虑的因素. 或者说在就其对服务的期望达成协议之后, 紧接着的步骤就是对成本达成协议. 服务成本必须是合理的 --- 对于服务提供者来说体现其实施成本与合理利润, 对于客户来说是建立在对服务市场的合理理解与选择之上.
客户对服务质量评估的另一重要依据是服务的一贯性. 如果服务提供者偶然能够提供超出客户期望的服务, 但在其它时间却常常让客户失望, 则显然不能称之为质量合格者. “持续的质量”是最为重要的, 也常常是服务业最难以实现的目标.
服务(或产品)的提供是通过交付行为实现的. 而其质量很大程度上取决于组织这些行为的方式. Deming质量轮提供了一个简单有效的质量控制模型:
这一模型假设要实现有效的质量控制, 必须重复履行以下步骤:
有效和适时地推动此轮旋转, 意味着服务行为被按照各自的计划和检查机制分为各子流程. 必须清楚谁在组织中负有责任, 他们被授权修改哪些计划和程序, 不仅为某一个行为, 而且为每一个流程.
质量管理(Quality Management)是在提供服务的组织中工作的每一个人的责任. 每一个员工必须明白他对组织作出的成果如何影响工作质量, 影响其他同事作出的工作质量, 并且最终如何影响整个组织提供的服务质量. 质量管理同时意味着持续地寻找改进组织的机会, 实施能够改进质量的行为.
质量保证(Quality Assurance)是组织内部的重要政策，用来保证质量管理的实施. 它集中体现了一整套质量衡量标准和履行程序，保证组织能够提供持久满足客户期望及相关协议的服务。 质量保证确保质量管理所实施的成果处于可维护的状态.
服务系统(Quality System)是与质量管理实施中有关责任, 程序和资源的有组织的架构. ISO 9000系列标准经常被用来开发, 定义, 评定和改进质量系统.
围绕质量系统的服务流程是保证服务质量持久延续的有效方法. 服务质量实现也往往是组成服务的各子流程优质完成任务的总体体现. 这些子流程形成一个链状结构, 其连接对各环节及整体质量形成影响. 有效协调各子流程不仅需要维护其各自的质量, 还要保证其协同一致的性能.
一个定义清晰的流程可以回答以下问题:
如
上图所示，流程是为既定目标制定的一组相关行为。在制定流程时我们首先考虑流程的目标和流程与其他流程之间的关系。流程通过其行为将输入转化为输出。根据
服务策略定义出质量特性和标准，并与输入输出挂钩，对流程执行结果的信息进行衡量。在流程链中须设置相应的控制点来监控所提供的产品或服务的质量。
2.3 IT服务管理
通过上述讨论，我们明确了IT服务是面向客户需求的，并且我们已经把客户需求量化为IT服务所遵从的质量标准体系。那么接下来，我们就要运用IT服务的管理方法达到既定的质量目标，或者说是履行IT服务组织和客户之间达成的服务协议。
IT服务管理被认为是基于流程的和面向服务的管理. 流程总是具有一个既定的目标. IT服务管理流程的目标是为IT服务质量而服务.
质量管理和流程控制形成组织及其政策的一部分.
了解IT服务管理的价值对于IT服务组织最终具备一个清晰的服务管理功能定义是十分重要的. IT服务管理对于IT服务组织的主要贡献如下:
IT服务的组织架构如下图所示:
其中服务交付(Service Delivery)和服务支持(Service Support)是IT服务运行的核心内容。那么它们都包含什么内容呢？
服务交付讨论客户的服务需求, 以及提供这些服务所需要具备的因素. 服务交付包括:
服务支持讨论客户如何得到适当的服务, 以支持其业务需求. 包括:
ITSM中各流程相互贯穿和作用, 形成有机整体, 共同建立一个健全的服务管理体系. 如下图所示:
例如, 以下过程模拟了当一个突发事件发生后各相关流程的启动和运行:
1. 一个用户致电服务台(Service Desk), 报告在线服务系统的响应时间延迟至不可接受程度.
2. 启动突发事件管理流程处理此事件, 通过可行的方式尽快恢复系统的正常运行.
3. 启动问题管理流程调查问题根源, 并致电能力管理流程支援本流程. 服务级别管理提示此故障涉及服务级别协议(SLA)条款.
4. 启动变更管理流程, 协调一个变更请求(RFC).
5. IT财务管理流程审核由硬件升级引起的业务成本.
6. IT服务持续性流程在变更管理流程中被引入, 确保当前备份的数据可用于恢复.
7. 版本管理流程控制变更实施中涉及的软硬件替换. 版本管理将最新的详细版本信息更新到配置管理数据库中.
8. 启动可用性管理流程, 确保硬件升级过程和升级后可以满足可用性和可靠性级别的要求.
9. 配置管理流程确保CMDB中的信息在整个实施过程中被更新到最新状态.
10. 通过客户关系管理流程, 在整个过程中始终和客户保持联系, 确保客户同步了解流程的进展状况.
下面分别就服务交付与服务支持的内容作概括性的介绍.
2.5 服务交付 (Service Delivery)
服务交付阐述以下问题:
2.5.1 服务级别管理(Service Level Management - SLM)
服务级别管理的目标是缕清与客户之间有关IT服务的协议, 并付诸实施. 因此, 服务级别管理需要收集客户需求, IT服务组织可提供的设施, 以及可用的财务资源. 服务级别管理针对提供给客户的服务 (聚焦客户的). 因此是基于客户需求建立服务 (需求拉动), 而非单纯基于现有技术所及(供应驱动), 从而使IT服务组织提高客户满意度. 服务级别管理阐述的内容有:
服务级别管理(Service Level Management －SLM)流程是用来确保服务级别协议(Service Level Agreements (SLAs)), 并支持运行级别协议(Operational Level Agreements (OLAs))及其它合同, 保证所有对服务质量的影响减少到最小. 此流程在服务质量和SLA基础上评估各种变更造成的影响, 包含预期变更前的影响, 也包含评估实施变更后的影响. SLA中某些最重要的目标和服务可用性、以及在容许周期内对突发事件形成决策有关.
SLM是服务支持和服务交付的关键. 由于它依赖于其它流程的存在性, 有效性及运行效率, 它不可孤立存在. 一个缺乏基础支持流程的SLA是没有意义的, 缺乏支持的SLA就失去了承认其内容的基础.
2.5.2 IT服务的财务管理(Financial management for IT Service)
财务管理针对于IT服务的谨慎从事. 例如, 当所提供的IT服务在进行中时, 财务管理将提供其导致的成本信息.
这样使考虑IT架构或IT服务的改变时, 能够合理地考虑成本和利益(价格和性能)之间的关系. 财务管理中对成本的鉴别,
分配, 预测和监控使成本成为可知因素, 减少成本和预算的差距. 重点结合IT服务组织的赢利, IT服务的财务管理描述了多种支付方法,
包括设立支付和定价的目标, 以及预算计划.
财务管理负责对成本及IT服务投资回报的会计核算, 并管理任何来自于客户的成本. 财务管理需要与能力管理(Capacity
Management), 配置管理(Configuration Management, 包含资产数据),
以及SLM的良好接口, 来确定服务的真实成本. 在IT组织预算谈判阶段和客户的IT耗费核算阶段, 财务管理很可能与业务关系管理(Business
Relationship Management)及IT组织密切相关.
2.5.3 能力管理(Capacity Management)
能力管理是优化成本, 获得时间, 以及开发IT资源的流程, 来支持与客户签订的服务条款. 能力管理针对资源管理, 性能管理, 需求管理, 建模, 能力计划, 负载管理, 以及应用软件能力推测. 能力管理强调用计划来确保所签订的服务级别可以被履行和成长.
能力管理(Capacity Managemen)负责确保在所有时间具备足够的可用能力, 以满足业务需求. 能力管理不是简单地与系统部件的性能相关, 而是直接与业务需求相关. 在那些与能力问题相关的困难面前, 能力管理在突发事件决策和问题鉴别过程中被引入.
能力管理提交变更请求(Requests for Change – RFCs)以确保得到适当的可用能力. 这些RFC被提交给变更管理流程, 其实施可能影响若干CI, 包括硬件, 软件和文档, 并需要提供有效的版本管理(Release Management).
能力管理应该在评估所有变更时被引入, 用来确定变更导致的在能力和性能上的影响. 这种影响在变更实施前后都有可能出现. 能力管理应该特别关注变更在一定周期后引起的累积性变化. 容易被忽略的单个的变更往往在经过累积后, 引起响应时间衰减, 文件存储问题, 和对处理能力的过度需求.
2.5.4 IT服务持续性管理(IT Service Continuity Management)
此流程在业务中断时对IT服务进行灾难恢复措施的准备和计划. 业务持续性管理为客户组织遇到灾难时准备好紧急预案, 根据此预案采取与IT服务相关的预防灾难发生的措施. IT服务持续性管理流程对技术, 财务和管理资源需求做好计划和协调, 确保灾难发生后可持续提供服务, 并就其内容达成客户同意.
IT服务持续性管理与一个组织在业务中断后在某个可允许范围内继续运作的能力密切相关. 至少要保证最基本的业务运行所需要的IT服务, 预先对其服务级别作出规定, 并和客户达成一致. 有效的IT服务持续性需要一个平衡的风险缩减措施, 例如有弹性的系统和备份恢复设施. 配置管理流程中的数据被用来辅助其计划和预防措施. 需要对架构和业务变更对持续性计划造成的潜在影响进行评估. 有关IT和业务的计划应该提交变更管理程序. 在持续性管理流程中, 服务台承担着重要角色.
2.5.5 可用性管理(Availability Management)
可用性管理是确保资源, 方法和技术得以适当拓展的流程, 以支持与客户签订的IT服务条款. 可用性管理针对所遇到的问题, 如优化维护等, 并且设计测量指标, 最大程度减少意外突发事件的数量.
可用性管理与IT服务的设计, 实施, 测量和管理相关, 确保规定的业务需求中有关可用性的内容被贯彻. 可用性管理需要理解IT服务失效发生的原因和恢复服务所需的事件. 突发事件管理和问题管理提供了关键输入
SLA中描述的可用性的目标在可用性管理流程中被监控, 并包含在其报表中. 此外, 在支持服务核查制度所提供的测量和报表中,
可用性管理对服务级别管理(SLM)流程提供了支持.
2.6 服务支持 (Service Support)
服务支持的内容描述了一个客户如何访问适当的服务, 以支持其业务.
服务支持包含以下内容:
2.6.1 服务台(Service Desk)
服务台
服务台(Service Desk)是IT服务组织和用户相互联系的接入点. 服务台曾经被称为帮助台(Help
Desk). Help Desk 的主要任务是记录, 分解和监控提出的问题. 一个服务台可以具备更宽范的角色,
如接收变更请求(RFC), 并且可以支撑多种流程中的操作.
服务台是服务提供者和用户之间的日常工作的单一联系点. 它也是报告突发事件和提交服务请求的焦点. 正因为如此,
服务台的职责是保持将服务相关信息, 行为和契机通知用户, 并追踪了解用户每日的行为. 例如, 服务台可能扮演用户提交变更请求的联系点,
基于变更管理流程传达变更实施计划, 并保持将变更实施进程通知用户. 变更管理应该确保服务台随时保持对变更行为情况的掌握.
在任何对SLA产生影响的事件面前, 服务台处于第一线, 并维护高速的信息流通道.
围绕突发事件, 服务台有可能在其权限范围被授权实施变更. 此类变更的范围可能被预先定义. 当所有相关变更发生时,
变更管理流程将被告知. 基本上, 当对任何CI的规范做出修改之前, 变更流程都需要对其进行预先审批.
2.6.2 突发事件管理(Incident Management )
突发事件管理流程致力于解决突发事件, 并快速恢复服务供应. 突发事件被记录下来, 并且事件记录的质量决定了相关的其它流程的效力.
服务台接近于突发事件管理流程和问题管理流程, 并处于它们之间. 如果没有适当的控制, 变更有可能引入新的突发事件.
因此需要建立有效途径对变更进行跟踪. 这是为什么建议持续不断地将突发事件记录在同一个CMDB中, 并分类为
“问题”, “已知错误”, “变更记录”等信息, 以促进服务台界面的信息沟通能力, 简化事件调查和报告.
突发事件的优先权及其升级需要作为服务级别管理流程中的一部分进行协商, 并在SLA中备案.
突发事件管理的目标:
突发事件管理的目标是尽可能迅速地根据SLA中定义的普通服务级别作出反应, 使产生问题后对业务行为及组织和用户的影响最小.
突发事件管理也应该保留对事件的有效记录, 以便于衡量和改进流程, 并向其它流程汇报.
突发事件流程如下图所示:
2.6.3 问题管理(Problem Management)
对于突发事件有两种处理方法, 一种是对其做出服务快速响应, 尽快恢复其正常运行, 另一种是鉴别和解决问题根源. 这两种方法之间存在微妙的区别, 而且经常被互相混淆. 对其做好区分具有重要意义.
如果问题被怀疑存在于IT架构内部, 问题管理流程将会瞄准其潜在的根源. 一个问题可能是被突发事件暴露出来的, 但是显然, 问题管理的目标是解决问题根源, 预防其可能产生的干扰, 而不是迅速恢复系统运行.
当问题被识别后(被识别的问题通常称之为已知错误), 通常需要进行一个业务决策, 决定是否采取永久性措施改进系统架构,
以预防再次发生新的突发事件. 如果需要, 提交一个变更请求来实现改进.
为了有效和高效地识别突发事件背后的问题根源及其发展趋势, 问题管理流程需要准确全面的突发事件的记录.
问题管理流程同样需要和可用性管理流程密切联络, 以确定这些趋势并明确补救措施的重要性.
流程:
2.6.4 配置管理(Configuration Management)
配置管理致力于控制一个变化中的IT架构(标准化和状态监控), 鉴别配置项目(清册, 相互关联, 审核与注册),
收集和管理有关IT架构的文档, 为所有其它流程提供IT架构的相关信息.
配置管理是所有其它服务管理流程不可分割的一部分. 拥有当前架构中所有部件的最新的, 准确的, 全面的和详细的信息,
并管理其变更, 使这些信息有效而高效地支持其它流程运行. 变更管理可以与配置管理集成. 至少, 建议在配置管理系统中控制变更的登录和实施,
并自在配置管理系统的帮助下对变更影响做出评估. 因此所有变更请求应该被输入配置管理数据库(CMDB),
并随着变更请求的进展随时更新记录, 直至其实施.
配置管理系统识别一个变更项目和架构中其它部件的关系, 将这些部件的所有人召集到影响评估流程中来. 不管一个变更是否在架构中实施,
相互关联的配置管理记录应该在CMDB中得到更新. 最好在变更发生时, 使用集成工具自动地更新记录.
CMDB应该开放给整个服务支持组, 使所有人理解部件失效可能的原因, 从而使突发事件和问题可以被更容易地解决.
CMDB还应当被用来把突发事件及问题记录和其它记录联系起来, 比如失效的配置项目(Configuration
Item - CI)和用户之间的联系. 如果缺少了配置管理流程的集成, 发布管理将难以实现, 并可能错误连连.
服务交付流程同样依赖于CMDB中的数据. 例如:
下图显示了配置管理和其它服务管理流程之间的关系:
图: 能力管理, 变更管理, 配置管理和发布管理之间的关系
2.6.5 变更管理(Change Management)
变更管理专注于对IT架构实施可控的变更. 此流程的目标是确定所需的变更, 并决定这些变更如何在对IT服务产生最小的不利影响的范围内得以实施.
同时确保其变更是可追溯的, 而且是经过整个组织内部有效地磋商和协调的. 在客户组织提交变更请求后,
由配置管理流程监控其状态, 与问题管理和若干其它流程进行协调. 变更实施履行一特定的路径, 包括定义,
计划, 建立, 测试, 接受, 实施, 和评估.
变更管理流程依赖于配置数据的准确性, 以确保获知所有实行
变更造成的影响. 因此变更管理与配置管理之间有密切的联系.
变更流程的详细内容应在SLA中存档, 确保用户知道提交变更申请的程序, 项目目标及时间, 以及实施变更造成的影响.
变更的详细内容需要通知服务台. 即使变更经过了全面测试, 仍然很有可能存在实施变更的过程中发生各种困难,
这些困难可能缘于变更没有按需求或预期运行, 或者对变更对功能造成的影响产生质疑.
变更咨询会议(Change Advisory Board - CAB)由可向变更管理小组提供专家意见的人员组成.
这个会议很可能由来自于所有领域的IT及业务单位的人参与.
2.6.6 发布管理(Release Management)
发布是指一组配置项目(Configuration Items – CI)经过测试被引入处于活动状态的环境中. 发布管理的主要目标是确保发布信息被成功地公布, 包括归纳综合, 测试与存档.
发布管理确保只有经过测试和正确授权的软硬件版本才能提供给IT运行环境. 发布管理与配置管理和变更管理的行为密切相关.
真实的变更实施经常通过发布管理行为得以贯彻.
变更的结果可能经常来自于新硬件, 新版本软件, 以及新的文档(自行建立, 或购买而来)等. 对它们进行控制,
并打包和颁发. 有关存档安全和公布程序应该和变更管理和配置管理流程紧密集成. 发布的程序也可能作为突发事件管理和问题管理流程中不可分割的一部分,
同时还和CMDB密切相连, 以维护及时更新的记录.
小结
上 面讨论了IT服务管理的方法论――ITIL的理论及其流程管理的模式。ITIL方法论的实践工作已经收到各国政府和相关IT龙头企业的高度关注。多年来 IBM不仅为ITIL的成长贡献了大量宝贵的经验和资源，还不断将形成的理论反过来应用在自身的实践上，应用在咨询服务，外包服务，技术支持服务等诸多方 面，验证其理论的正确性。下面就简单阐述IBM对于IT服务管理规划实施上总结的经验。
