当前位置:首页 >> IT/计算机 >>

ITIL Foundation-下


服务级别管理(Service Level Management)

下(185)

Why SLA?

IT

Service Desk

Business Units

下(186)

议程
概述 ?基本概念 ?主要活动 ?与其它流程之间的关系 ?关键角色 ?成本、效益和问题 ?关键成功因素和绩效指标 ?总结
?

下(187)

概述
?

定义:
- 服务级别管理是有关定义、协商、签订和测试提供给客户,服务的 质量水平的流程。

?

目标:
- - - - 整合提供IT服务所需的各种要素; 生成清晰地描述服务项目中各种要素的文档; 以一种客户能够理解并涉及到的术语对所要提供的服务进行描述; 以一种可控的方式改进IT服务提供。

?

范围:
- 一般只包括在服务提供过程中发生的IT服务提供方与其他相关主体 之间就服务质量所进行的协调活动; - 主要包括三个协议所调整和规范的各方主体的行为及活动; - 三个协议是:服务级别协议(SLA)、运营级别协议(OLA)、 支撑合同(UC)。 下(188)

基本概念(1):客户/用户/IT服务提供商
?

定义:
- 客户:一个组织的代表,它被授权代表组织与供应商就获取IT服务 签订协议。因此,它不同于IT服务的最终用户。客户是服务费用的 承担者。 - 用户:经授权可以使用某个系统或某项服务的人。 - IT服务提供商:一个组织的代表,它被授权代表组织就IT服务的供 应与客户签订协议。

?

说明:
- 从理论上讲,任何获得IT服务的人都是客户; - 在大部分情况下,IT部门是作为IT服务提供商; - 由于IT部门自身常常也获得了某些IT服务,所以IT部门在这里同 时也是IT服务提供商的客户。 下(189)

基本概念(2):SLA/OLA/UC
服务级别协议 (SLAs) ? 服务级别协议(SLA) - 由IT部门和客户之间签订的描述将要提 供的一项或多项服务的一份协议; - 用非技术语言进行描述;

服务B 服务A 基本架构
运营级别协议 (OLA) 支撑合同 (UCs)

服务C

- 在协议期间它可作为评价和调整IT服务 的标准。 ? 运营级别协议(OLA) - ITSP与IT部门内部某个具体的职能或岗 位就某项IT服务所签订的协议; - 支持IT部门提供各种服务; - 是对SLA的细化。

内部供应商

外部供应商

? 支撑合同(UC) - 与外部提供商就某项服务的供应所签订 的合同; - 通常是正式的合同,而SLA和OLAs通 常不是法律文本。

SLA: Service Level Agreement OLA: Operation Level Agreement UC: Underpinning Contract

下(190)

基本概念(3):服务级别需求/服务说明书
?

服务级别需求(SLR)
- SLR 包括客户需求的详细定义,它可被用来开发、修改和启动服 务; - SLR可作为设计一项服务及其相关的SLA的一个蓝本。

?

服务说明书(Service Specification Sheets)
- 服务说明书描述了功能(与客户约定的,因而是以客户为中心的) 和技术(在IT部门内实施的,因而是以IT为中心的)之间的关系, 并为服务提供了一个详细的说明; - 服务说明书将服务级别需求(外部说明书)转化为提供服务所需的 技术细节(内部说明书); - 说明书还描述了SLA与任一份UC和任一份OLA 之间的联系; - 说明书是监控内部和外部说明书之间一致性的重要工具。
下(191)

基本概念(4):服务目录
?

定义:
- 有关可用的服务及这些服务的服务级别的详细说明。

?

说明:
- 可以帮助IT部门全面反映其自身的情况,并将其自身呈现为一个IT服务提供商,而不仅 仅是一个技术的实施者和维护者; - 以客户的语言对运营服务的描述,同时对IT部门能够提供给客户的相关的服务级别作出 了概要说明。 - 它也是一个重要的沟通工具。服务目录可以帮助调整客户的期望,从而有助于客户和服 务提供商之间的流程整合。 - 该文档是根据服务说明书中所描述的外部说明制定的,因而应该采用客户的语言进行撰 写,而不是采用技术说明的形式。

Customers

SLR

下(192)

基本概念(5):服务改进方案/服务质量计划
? 服务改进方案(SLP)
- 服务改进方案通常作为一个项目来实施,它定义了与改进一项IT服务相关 的活动、阶段和相应的里程碑。 ? 服务质量计划(SQP) - 服务质量计划是一个重要的文档,由于它包含了所有用于管理IT部门的管

理信息。
- 服务质量计划定义了服务管理流程和运营管理的流程参数。 - SLA是关于我们应该提供什么服务的,而SQP则是关于我们应该怎样提供 这些服务的。 - 服务质量计划还为所有流程定义了报告内容和报告间隔期。 - 绩效指标是根据服务级别需求确定的并记录在说明书中。如果有外部提供 商参与服务的供应,如当服务台或PC机维护被外包出去时,相关的绩效指 标也同时在支撑合同中进行了定义。

下(193)

Service Improvement Matrix
Improvement Title What is the Improvement? How will the Improvement be achieved?

Value Questions –Does the Improvement.. Reduce the cost for TSD and the business? Provides an opportunity for revenue growth? Improves the perception or Service Delivery? Provides a better foundation for growth (scalability)? Improve the VM and customer experience? Reduce business risk? Improve the speed of response to internal customers? Improve the effectiveness of internal customers? (Total score of a possible 40)
Ease/Cost of Implementation Questions –Score E/COI on the following.. Level of resource required (mandays) Level of specialist skills required Amount of organisation change required Level of Complexity regarding 3rd parties Extend of change in working practices Level of Capital Expenditure required Speed of Implementation Level of ongoing support requires (Total score of a possible 40)

0 Increases Costs No Opportunity No Improvement No Change No Improvement Increases Risk No Improvement No Improvement

Score

0

5 Major Reduction Major Opportunity Major Improvement Major Improvement Major Improvement Major Reduce Major Improvement Major Improvement

Notes

0 Over 200 days Significant Major Change Several/Complex Major Change Significant Months/Years Significant

Score

0

5 Under 20 days None No Change One Internal Dept No Change None Weeks/Months Minimal

Notes

下(194)

主要活动
客户需求 识别:需求 定义:内部的&外部的
订约: -协商 -草拟 -修订 -终止

Service Level Requirements

Service Catalogue Service Level Agreement Underpinning Contract(s) Operational Level Requiremnets

监控:服务级别 报告 Service Level Report Service Improvement Program

评审

下(195)

主要活动:
?

识别 定义 订约 监控 报告 评审

背景:

一项服务被体验到的质量取决于客户的期望、对客户体验的日常管 理、服务的稳定性以及成本的可接受性。

?

客户:

客户自己一般都不是很清楚他们的期望; - 有时候,他们只是简单地假定应该提供具备某种质量特征的服务, 而没有任何明确的意见; - 对于IT服务的这些假定的(含糊的)质量特征往往是造成许多纠纷 的主要原因。

?

客户需求

以一种可量化指标进行表述,以便对IT服务进行设计和监控; - 如果没有与客户就评价指标达成一致意见,则很难验证IT服务是否 满足了协议中的某些要求; — 服务级别管理在理解和定义客户的需求方面扮演了关键的角色。

下(196)

主要活动:

识别 定义 订约 监控 报告 评审

?定义外部标准(设计阶段) - 概括性地定义或重新定义客户对服务的期望;
- 这些期望在服务级别需求(SLR)中进行描述并形成文档; - 这种描述应该针对整个客户组织。这一步骤通常被认是服务级别管理中最困难的部分; - 在开始这一步骤之前,服务级别经理必须为与客户进行会议沟通做好准备; - 在会议沟通时,应该将用户分成几个小组。服务级别经理负责制定一个关于用户小组及 需求和权限的清单; - 设计阶段将产生一份服务级别需求文档,它需要由服务级别经理和客户签字确认; - 在定义服务级别需求时需要用到以下信息:
?从客户角度对服务所要提供的功能进行的描述 ?服务必须处于可用状态的时间和天数 ?服务持续性需求 ?提供服务所需要的IT职能部门 ?在定义服务时需要考虑的当前运营方法或质量标准的参考基准 ?需要修改或替换的SLA的参考模板

下(197)

主要活动:

识别 定义 订约 监控 报告 评审

?转化为内部标准(说明阶段) - 在说明阶段,服务级别需求需要制定得详细而具体。而这一阶段试图提供如下
信 息:
?对IT服务及其需要的组件的清楚和详细的描述 ?关于服务被实施和提供的方式的说明 ?关于必要的质量控制程序的说明

- 在说明阶段,建议对内部使用的文档资料和外部使用的区分开来。外部使用的说

明书主要是 关于与客户约定的目标以及由这些目标所控制的设计过程。内部使用 的说明书是指IT部门 的内部目标,这些目标需要实现以满足客户的要求。

- 说明书(服务说明书)详细地描述了客户想要的服务(外部要素)以及这种需求
可能会对IT 部门产生的影响(内部因素)。说明书无需双方签字认可,但需要进 行文档控制。

下(198)

主要活动:
?制定服务质量计划

识别 定义 订约 监控 报告 评审

- 在完成服务级别需求和服务说明书后,建议所有的管理信息(关
键绩效指标)以及为内部和外部供应商准备的说明书融合在一个 单一文档中, 以提供有关每个管理流程对IT服务所作的贡献方面

综合信息。

下(199)

主要活动:
? 制定和修改SLA

识别 定义 订约 监控 报告 评审

- 在确定服务级别协议结构时,建议在谈判开始前先就整个公司的一般服务项 目(如网络服务)进行定义并制定一个总体的以服务为基础的SLA模型。 - SLA应该具有一定的层次结构,就像客户的组织结构,即表现为多个层次上 构架协议。 - 每个层次都有其自身的详细程度。最高层的协议是关于提供给整个组织的一 般服务。而较低层次的协议则是与具体客户相关的信息。

? 制定和修改OLA和UC ? 制定服务目录

- 根据SLA来制定相应的OLA和UC; - 任何现有的UC或OLA都必须在设计过程中得到修改。
- 尽量避免技术术语,而使用一些符合相关业务的术语。 - 尽量从客户的角度看待问题,并使用这种方法来识别相关的信息。 - 提供一个有吸引办的规划,因为IT部门需要使用该文档来向其客户全面地展示 自己。 - 确保该文档可以到达大部分潜在的利益相关者,例如在企业内部网站上进行发布或分发 装载该文档的CD盘片。

下(200)

下(201)

ITIL-Based Service Level Agreement

下(202)

ITIL-Based Service Level Agreement

下(203)

下(204)

下(205)

Service Catalogue

下(206)

主要活动:

识别 定义 订约 监控 报告 评审

?服务级别监控 -服务级别必须从客户角度加以测度和评价。
- 监控也不仅限于技术方面,而应该包括流程方面的问题。例如,直 到用户得到服务已经恢复的通知,他们可以假定服务仍然是不可用 的。 - 可用性管理和能力管理通常可以提供与服务级别相关的技术目标的 实施情况方面的信息。 - 有些情况下,还应当由服务支持流程特别是事件管理提供一些信息。 - 然而,仅仅评价内部参数是不够的,因为这些信息与用户的体验是 无关的。诸如响应时间、升级时间和支持等方面也应当是可量化的。 只有在结合来自系 统和服务管理两方面的管理信息的情况下才能获 得一个全面的考察。

下(207)

主要活动:
?报告时间:

识别 定义 订约 监控 报告 评审

-按照SLA中约定的时间间隔提交; ? 报告内容: -在指定的时间内的可用性和宕机时间; -在高峰期间的平均响应时间;

-高峰期间的交易速度;
-在IT服务中再现的功能性错误的数目; -服务降级的频率和持续时间; -高峰期间的平均用户数;

-成功或不成功的安全侵害企图的数目;
-服务能力被利用的比例; -完成和未完结变更的数目; -提供服务所耗费的成本。

下(208)

主要活动:
?评审的内容

识别 定义 订约 监控 报告 评审

-自从上次评审以来签订的服务级别协议、与服务有关的问题; -服务趋势的确认、在约定的服务级别围内对服务所作的变更; -对程序所作的变更以及对所需的额外源所作的估计; -未能提供约定的服务级别的原因。
?

如何改进?
-制定一份服务改进方案,分配额外的人员和资源; -对SLA中定义的服务级别进行修改;

-修改有关的程序;
-修改运营级别协议和支撑合同。

下(209)

与其它流程之间的关系

下(210)

与其它流程之间的关系(续1)

SLM与服务台
服务台致力于在错误发生时尽可能快地恢 复约定的服务级别。 服务台通常提供有关用户对服务级别管理 流程质量的体验(用户满意度)方面的有 价值的信息。 用户满意度VS.客户满意度;

SLM与可能性管理
服务级别管理为可用性管理提供需 要的IT服务可用性级别方面的信息 输入 可用性管理向服务级别提供实际的 服务可用性水平方面的信息。

服务台协助降低服务中断所造成的影响的 响应时间和解决时间。

下(211)

与其它流程之间的关系(续2)
SLM与能力管理
能力管理通过提供有关一项新的服务或 现有服务的拓展对总体能力的影响方面 的信息来支持服务级别管理。 服务级别管理为能力管理提供有关预期 的当前和未来对IT基础架构的使用情况 方面的信息。

SLM与事件/问题管理
事件管理和问题管理是服务级别协议行到 有效实施的良好的指示器。 问题管理通过采取永久性的措施来确保错 误不再重复发生以优化服务的稳定性。 在向客户报告时,服务级别管理概述使用 由这两个流程提供的报告信息。

下(212)

与其它流程之间的关系(续3)

SLM与变更管理
SLA中定义了用户组织可以请求作出的 变更以及在应对这些变更方面的协商意 见(由谁来处理变更、周期时间、成本、 向组织通报等)。一项变更可能会对已 经约定的服务级别产生影响。任何对服 务实施的变更和相关的SLA都应该由变 更管理进行控制。

SLM与配置管理
配置管理负责将与一项服务有关的组件和文档的 详细资料输入配置管理数据库(CMDB),并从 该数据库中为其它流程提供相关信息。因此,一 项服务或SLA的创建或修改都可以影响到配置管 理数据库(CDMB),配置管理数据库(CDMB) 还可以用来报告配置项的质量,从而有助于服务 级别管理报告已提供的服务的质量。

下(213)

与其它流程之间的关系(续4)
SLM与IT服务财务管理
如果客户需要向IT部门就可使用的服务收费, 则也应当就应当在SLA中明确定义。财务管理 为服务级别管理提供有关提供一项服务所需要 的成本方面的信息。它还可以提供有关计费方 法以及弥补一项服务的成本而向客户收取的费 用方面的信息。

SLM与发布管理
发布管理在硬件和软件的供应方面监控由服 务级别管理制定的协议的履行情况。而服务 级别管理则根据发布管理报告所提供的信息 来报告IT的质量。

下(214)

关键角色:服务级别管理
?角色
-服务级别管理需要由一个流程经理来进行控制。该经理应该确保该流程有效动作 并提供预定的效益。 -这并不必要意味着是由一个人来担任这个角色,许多组织都有多个服务级别经理, 每一个服务级别经理各负责一项或多项服务或多个客户群。

? 职责
- 制作和更新服务目录;
- 为IT部门定义和维持一个有效的服务级别管理流程,包括:
?确定SLA结构 ?与内部提供商签订UC ?与外部提供商签订UC

- 更新现有的服务改进方案; - 与有关方面协商谈判,并负责签订和维护SLA\OLA和UC; - 评审IT部门的运作绩效,并在必要的时候采取改进措施。

下(215)

成本、效益和问题
? 成本: — 人力成本(服务级别经理和项目小组),培训成本 — 文档目录成本,场地、硬件和软件成本 — 与更新服务质量计划、服务级别协议和服务目录相关的运营活动 成本 ? 效益: — IT服务可以被恰当地设计以满足定义在服务级别需求中的期望 — 服务绩效可以被测度,意味着可以对服务绩效进行管理和报告 — 如果IT部门针对IT服务的使用而向客户计费,客户可以自行在要 求的服务质量和响应的成本之间选择一个恰当的平衡点 — 更好的客户关系和客户满意度 — 客户和IT部门都清楚其职责和角色,因而产生的误会和疏忽也更 少了。 下(216)

成本、效益和问题(续1)
? 可能产生的问题 — 服务级别管理可以导致IT部门和客户之间形成一种类商 业性的(公事公办的)关系; — 客户在确定服务级别需求方面可能需要帮助; — 按照可量化的标准和相关的成本表述客户的期望是非常 困难的; — 容易低估监控和评价服务级别相关的成本; — 服务级别经理应当提防在有关的规划、测量和监控工具,程序、服 务质量计划和支撑合同还没有开发和制定的情况下签订不切实际的 协议; — 直接从草拟服务级别协议开始,而跳过客户需求分析、设计阶段以 及服务质量计划的开发。

下(217)

关键成功因素和绩效指标
? 关键成功因素:
— 具备IT和业务双方面经验的能力很强的服务级别经理,必要时还需 要一个支持部门; — 清晰的流程使命和目标; — 开展意识宣传,向相关人员提供有关流程的信息,获得员工们的理 解和支持; — 清楚地定义流程内的任务、权限和职责,并将流程控制和运营任务 (客户联系)区分开来。
?

关键绩效指标:
— — — — — SLA中包括的服务项目; SLA中由OLA和UC支持的服务项目; SLA中得到监控的服务项目,并且有关的缺点被报告出来; SLA中定期得到评审的服务项目; SLA中约定的服务级别得到实现的服务项目。 下(218)

IT服务财务管理(Financial Management for IT Service)

下(219)

议程
? ? ? ? ? ? ? ?

概述 基本概念 主要活动 与其它流程之间的关系 关键角色 成本、绩效和可能产生的问题 关键成功因素和关键绩效指标 总结

下(220)

概述
?

背景:
- 在许多人看来,IT服务是支持组织日常业务活动的一个具有重要贡献的因 素,然而却很少有人意识到这些服务是需要花钱。 - 开发ITIL的一个目的就是构建对IT基础架构的管理从而促进高效和经济地 适用IT资源。其中一个目标是要激起客户的成本意识从而促进其根据组织 的业务目标合理地适用IT资源。

?

定义:
- 是负责对IT服务运营过程中所涉及的所有资源进行货币化管理的流程; - IT服务财务管理包括预算、会计核算和计费三个子流程。

?

目标:
- - - - - 对支持IT服务运营的IT资产和资源进行成本效益管理; 便于企业内部采取商业化的形式进行IT服务动作; 全面核算IT服务运作的成本,为IT投资决策提供财务信息; 促进IT资源的高效和经济的使用; 激起IT服务用户的成本意识;促使用户根据其业务目标合理使用IT资源;

下(221)

基本概念(1):预算/会计核算/服务计费
?

?

?

预算(Budgeting) - 是用于预测和控制费用开支的一个子流程; - 由设定预算目标(通常一年设定一次)和对当前预算执行情况进行 日常监督两部分组成。 会计核算(Accounting) - 是指对IT服务动作过程中产生的各种效益和成本进行确认、计量和 报告的过程; - 会计核算意味着监控IT部门如何花钱。能够确定某个客户、每项服 务和每项活动等的成本是尤为重要的。 服务计费(Charging) - 是指为客户所使用的服务开出账单并计算费用的所有活动; - 包括计费对象的确定和计费方法的选择; - 计费流程的顺利动作有赖于有效的IT服务会计核算系统。 下(222)

基本概念(2):成本分类
?

?

分类1: - 直接成本:与某项IT服务具有特定和专属关系的成本。例如,与某 项特定的服务直接并唯一相关的活动和材料耗费(如为上网所租用 的电话线路); - 间接成本:与某项IT服务不具有特定和唯一相关关系的成本。典型 的例子包括设施(如一张桌子)、支持服务(如网络管理)以及管 理费用(包括时间)。 分类2: - 固定成本:独立于产品数量的成本。它们包括投资于硬件、软件和 建筑物方面的成本。在大多数情况下,月折旧或年折旧以及利息也 被包括在内,而不仅仅包括购买成本;即便是在产品(服务)数量 下降或中断的情况下,固定成本依然存在。 - 变动成本:随着产品数量的变化而发生变化的成本。典型的例子包 括人力成本、墨盒、纸张、热力以及电力成本等。
下(223)

基本概念(3):成本分类
?

分类3:
- 资本性成本:组织中用于购买用于长期使用的资产的 成本。这些成本将在若干年内进行折旧。这样一来, 其实际成本就应当等于折旧总额,而不是购买成本。

- 运营性成本:与有形的生产资料无关的日常成本。这 方面的典型例子包括硬件和软件维护费用、特许费以 及保险费等。

下(224)

基本概念(4):成本类型
成本类型共有六种,有些是直接成本,有些是间接成本。 ? 设备成本单元:所有的IT硬件,如:服务器、打印机等。 ? 软件成本单元:用于维持系统动作的直接和间接成本。 ? 组织成本单元:直接和间接的人力成本。 ? 场地成本单元:所有与住房有关的直接和间接成本。 ? 转移成本单元:与其它部门所提供的货物或服务相关的成本。 ? 成本核算单元:与财务管理活动自身相关的成本。
设备成本单元,ECU 软件成本单元,SCU 组织成本单元,OCU 场地成本单元,ACU 转移成本单元,TCU 成本预算,CA

下(225)

主要活动
业务行为 的IT需求 IT计划 (包括预算) 会计 计费

确定 财务目标

成本控制 方法
有关计划收费的反馈

计费方法

服务级别 管理

财务管理

在一个IT组织内部,财务管理流程通过以下三个主要的子流程来得以实施的:
?
? ?

预算 会计核算 计费

下(226)

主要活动:
?工作量预测

预算 会计核算 服务计费

报告

- 在编制预算之前,先要对未来的IT服务工作量(负载)进行预测,并结 合以前年度的成本数据预测IT服务的成本。 - 在对所有的IT服务项目进行了合理的预测之后,可以着手编制IT服务预 算。
?

选择预算方法
- 增量预算-头一年的数据作为制定新的预算的基础,即根据头一年的预 算进行调整以反映预期的变化就得到新的预算。 - 零基预算-这种方法从一张空白纸(零基)开始,即忽略过去的经验。 这需要经理们根据他们预算中的成本调整他们的资源需求。这意味着对 每一项支出都要进行评估,并要决定该项支出是否应该发生以及该项支 出应该是多少。显然,这种预算方法更费时间,因而通常只是隔几年使 用一次,而在这些年度内使用增量预算。

下(227)

主要活动:
?确立责任中心

预算 会计核算 服务计费

报告

- 在进行会计核算之前必须明确IT部门属于何种性质的责任中心; - 一般来说,可以将IT部门确立为如下3种性质的责任中心:核算中心 ( Accounting Center ) , 成 本 中 心 ( Recovery Center ) 和 利 润 中 心 (Profit Center)。
?

确定服务要素
- 服务要素之间形成了一种层级结构,这些服务要素是IT部门在提供服务 时所产生的。 - 在一个服务要素结构中,低层次的服务要素对高级别的服务要素提供支 持。一项服务要素在该结构中的位置越高,则其功能与业务的相关度越 大。 - 服务结构定义得越详细,则越易于理解相关的成本。

下(228)

主要活动:
? 定义成本要素

预算

会计核算 服务计费

报告

- 在确定服务要素之后,需要进一步定义成本要素。 - 成本要素可以被细分为人力、硬件、软件和间接费用等成本单元。 - 按照服务要素来构建成本要素的优点在于发生在硬件、软件和支持方 面的支出变得更加清楚。

下(229)

主要活动:
硬件 软件

预算

会计核算 服务计费

报告

? 在定义了成本要素之后,可以按照下图所示的流程IT服务成本的归集和分配。
人力资源 场所 外部服务 转换成本

成本要素 直接服务成本
硬件 软件 人力资源 外部服务 场所

可分摊间接服务成本
硬件 软件

不可分摊间接 服务成本
硬件 软件 人力资源 外部服务

IT服务总体成本

IT成本的归集与分配

下(230)

主要活动:
? 总体拥有成本
— 如何定义IT成本的范围? — 如何进行TCO的核算?

预算

会计核算 服务计费 报告

? 投资评价
— 用于IT项目投资评价的指标主要有投资回报率(Return on Investrnent,Rol)和资本报 酬率(Return Capital Employed,ROCE). — 这两个指标的计算方法分别如下:

?ROI平均利润增加额/阿项目投资额 ?ROCE=税前净利润/(总资产—流动负责)

? 差异分析
— 在取得了实际IT服务的成本数据后,IT会计人员应将实际的成本数据与相应的预算数据、计划数据 相比较,确定其差额,调查差异产生的具体原因并差异产生的责任落实到人,同时采取适当的措施 处理这些差异。

下(231)

主要活动:
? 明确计费政策

预算

会计核算 服务计费

报告

— 信息沟通-客户经理被告知应付费用是为了使他们清楚他们部门使用的IT
服务所产生的成本。 — 名义计费-针对服务成本开出发票,但无需实际支付,这种方法可以帮助 IT部门获得实施该流程的经验以及纠正计费系统中存在的错误,也使客户 有机会来适应计费流程。但是,这种方法只有在服务成本最终仍需回收的 情况下才会有用,否则树立和强化成本意识的目的将会落空。 — 实际收费

下(232)

主要活动:
?

预算

会计核算 服务计费

报告

设定收费标准
- 确定计费的目标; - 确定直接和间接成本; - 确定市场价格; - 分析服务需求、客户的数量以及竞争的情况。

?

确定定价策略
-成本加成定价法-存在的形式有多种,但都是基于实际发生的成本加上一定比 例的利润附加(成本+%)作为服务的价格。 -现存价格法-适用于那些已经达成价格协议的服务项目。 -目标和利润定价法-适用于价格事先已确定的那些服务项目。 -市场价格法-收取与外部供应商差不多的价格。 -合同协定价格法:这些价格是在与客户讨论后确定的,如果客户请求一项新的 服务,则需要就客户是否需要承担全部投资成本还是仅仅承担一部分成本进行 协商。

下(233)

主要活动:
? 报告

预算

会计核算 服务计费

报告

— 根据计费政策的不同,对于实际使用的IT服务,要么开出发票(账单), 要么仅仅与客户就其成本进行沟通; — 这些成本通过服务级别管理流程在定期与客户进行的会谈中得以处理; — 因此,需要向服务经别管理流程提供以下信息: ?每位客户的IT服务开支; ?实际收费与预计收费之间的差距; ?使用的计费与核算方法

?任何关于收费的争议,及其原因和解决方案

下(234)

与其它流程之间的关系(续1)

IT服务管理与服务级别管理
SLA定义了客户的期望和IT管理部门的义务,在满足客户需求过 程中产生的成本会对与客户的服务形式和范围带来较大的影响。
IT部门的账务经理需要与服务级别经理就以下问题进行协商,满 足当前和未来业务需求所需的成本,计费政策和其对客户的影响 以及该政策将如何影响客户的行为。 下(235)

与其它流程之间的关系(续2)

IT服务账务管理与能力管理
对于能力和可用性的提供,同样会受到相关成本的信息的影响。 从整体上讨论由于为某位客户或某项服务提供更高的能力和可 用性而导致增加的成本是非常必要的。 成本与业务收益比的信息会影响客户决定是否是购买的能力还 是提高可用性。

下(236)

与其它流程之间的关系(续3)
IT服务管理与配置管理

配置管理指明、识别和记录了所 有针对基础架构组件的变更。配 置管理数据库(CMDB)中信息, 包括成本信息的运用有助于收集 有关成本的历史信息。 配置管理还可以用于将有关的资 产数据与来自账务系统的数据进 行核对保持一致。

下(237)

关键角色:IT财务经理
? 角色 — IT账务经理是IT服务账务管理的关键角色;
— 有些IT部门有其自己的财务经理,而有些IT部门则是与 账务部门达成协议,在IT管理方面进行密切的合作。

? 职能 — 和来自管理层的代表以及账务部门的人员一起制定预
— — — — — — — —

算、IT核算和计费的政策; 实施和维护IT账务管理流程,包括预算、IT核算和计费; 协助IT部门及其客户制定投资计划计划; 就预算的遵循情况定期向IT经理和客户报告; 选择合适的工具和流程来收集成本信息; 开发合适的成本模型; 为高层管理人员建议成本全理的IT解决方案 在组织计费政策的范围内确定计费方法; 定期为客户开出账单。

下(238)

成本、效益和可能产生的问题
?成本
- 与规划、引进和实施该流程相关的组织成本; - 购买必要的工具所需的成本,例如应用相关的硬件和数据库。

?效益
- 基于成本效益性为每项作出决策; - 采取一种类商业化的方法来对IT服务和相关的投资问题作出决策; - 为支持某项开支提供更多的信息,如显示了避免战略性开支发生的成

本;
- 根据更可靠的信息制定预算和计划计划; - 通过将成本与被使用的服务挂钩来回收IT成本; - 影响客户行为,如在需求高峰时期通过收取更高的费用来平抑客户需 求,或为管理采取相关行动提供有关服务成本和利用情况方面的信息。

下(239)

成本、效益和可能产生的问题
?问题
- IT人员对记录和监控成本的活动通常不是很成熟; -对成本进行监控、计算和计费通常需要有关非IT服务规划方面的信息,

比如建筑物,但通常不可能获得建筑物方面的详细规划信息;
-难找到既熟悉IT又熟悉会计核算的人员; -如果信息系统部门的战略和目标还没有形成清晰的描述并进行文档化,

就很难考虑进行必要的投资;
-流程中产生的(降低成本的)机会通常不能行到充分的了解,从而导致 不充分的合作; -缺乏管理层的承诺意味着该流程还没有被组织所完成认真地采纳。

下(240)

关键成功因素
?
? ?

关键成功因素:
用户必须知道他们使用的哪些服务项目是需要收费的; 用户必须了解计费方法(如通过可量化的绩效单位确定的协议报告) 从而可以控制他们的成本; 成本监控系统必须能够提供有关开支以及为什么 发生这些开支的详细 信息; IT服务管理必须提花平稳的系统从而可以通过合理的成本提供有效的 IT服务; IT管理人员必须充分了解引进账务管理流程的影响以及产生的成本, 并对这个管理过程作出承诺; 配置管理必须为建立一个适当的会计核算系统服务结构的相关信息。

?

?

?

?

下(241)

关键绩效指标
关键绩效指标 -针对提供的服务进行的准确的成本-效益分析; -客户认为计费方法是合理的; -IT部门实现的其财务目标; -客户使用的服务量发生了变化; -及时向服务级别管理报告。
?

下(242)

可用性管理(Availability Management)

下(243)

议程
概述 ?基本概念 ?主要活动 ?关键角色 ?与其它流程之间的关系 ?成本、绩效和问题 ?关键成功因素和绩效指标 ?总结
?

下(244)

概述
?

定义:
- 建立和维持信息系统可用性的流程及为达到此目的而根据特定需求 所提供的服务;

?

目标:
- 提供符合预定可用性级别能够得以评价和计量,以及在必要时时行 持续改进;

?

范围:
- 所有新增IT服务以及当前民经签订服务级别需求(SLR)和服务级别 协议(SLA)的IT服务; - 那些不一定签订正式的服务级别协议但对组织业务却极为关键的IT服 务; - 作为IT支持部门的内部和外部供应商; - 可能影响可用性的IT基础设施和IT支持部门的所有方面,包括培训、 政策、流程的有效性、程序和工具等。 下(245)

可用性管理的概念框架
用户 用户 用户 用户 客户 可用性(服务级别协议) IT服务

IT系统

IT系统
可靠性+可维护性(运营级别协议)

IT服务提 供商

内部供应商

软件开发人员

软件维护人员

其它维护人员

可服务性(支撑合同)

硬件

软件
供应商

环境

通信

外部供应商和 维护人员

下(246)

基本概念(2):可用性/可靠性
?

可用性(Availability)
- 定义:可用性是指一个组件或一种服务在设定的某个时候或某段时间内发挥其应有功 能的能力。表示方法: ? 用绝对数来表示,如可用时段为8:00到18:00; ? 用相对数来表示,如平均可用性级别最低为99%; ? 两者的结合,如在开放时间内平均可用性级别99%。 - 决定因素: ? (A)IT基础架构的复杂程度;(B)快速有效地对故障作出反应的能力; ? (C)组件的可靠性;(D)运营级管理流程的质量和范围; ? (E)由支持部门和供应商提供的维护的质量;(F)IT基础架构的弹性。

?

可靠性(Fioliability)
- 定义:可靠性是指IT基础架构可以无间断运作的能力,它主要取决于单个IT组件的可靠 性和IT基础架构的弹性。 - 根据服务组件出现故障的概率来决定的。 - 决定因素: ? 用于提供服务的组件的可靠性; ? 服务或组件在一个或多个系统发生故障时仍能有效运作的能力 弹性; ? 防 机的预防性维护。

下(247)

基本概念(3):可维护性/可服务性
?

可维护性(Maintainability):
- 定义:可维护性是指IT基础设施组件在出现故障后可被修复并恢复正常运作的特性。 - 包括预防性维护和计划性审查,这两个概念所包括的具体活动有: ? 采取措施防止故障的发生; ? 检测故障; ? 进行诊断,包括由组件自己进行的自动诊断; ? 解决故障; ? 在故障发生后尽快恢复; ? 恢复服务。

?

可服务性(Serviceability):
- 定义:可服务性是描述组织内部IT服务提供与外部第三方供应商之间合同履行情况的 一个指标。 - 可服务性本身并不是一个可测度的指标,它需要通过对IT服务及组件的可用性、可靠 性和可维护性进行测度和评价后体现出来。 - 与外部服务提供商(承包商,第三方)的合同义务有关; - 这种合同只涉及IT服务的一部分,因而可服务性并不是指整个服务的可用性; - 当承包商整体上负责某项服务(如签订设施管理合同)的时候,可服务性和可用性是 同义的。

下(248)

基本概念(4):关键业务功能/IT支持部门
?

关键业务功能(VBF)
- 关键业务功能主要是指由IT服务所支持的业务流程中的 关键环节。 - 一项IT服务可能同时支持了多项业务功能,而其中只有 某些业务功能才是关键性的。例如,对于ATM(自动取 款机)服务而言,提供现金是其关键业务功能,而打印 交易凭条则被视为非关键性功能。

?

IT支持部门
- IT支持部门是指对IT基础设施进行支持、维护和管理的 部门及其相关人员; - IT支持部门主要由内部和(或)外部的供应商组成。
下(249)

基本概念(5)
系统事件间隔时间

宕机时间,修复时间 响应时间 修复时间 恢复时间

正常运行时间,故障间隔时间

事件
检测时间 解决时间 恢复

事件

时间

下(250)

基本概念(6):MTTR/MTBF/MTBSI
?

平均修复时间(MTTR)

- 平均修复时间(Mean Time to Repair)是指事件发生到服务恢复之 间的平均间隔时间,又称为停机时间(Downtime)。它由检测时间 和解决时间两部门组成。这项指标与服务的维护性和适用性有关。 ? 平均无故障时间(MTBF) - 平均无故障时间(Mean Time Between Failures)是指从某次事件修复 到下次事件发生之间的平均间隔时间,又称为正常运作时间 (Uptime)。这项指标与服务的可靠性有关。 ? 平均系统事件间隔时间(MTBSI) - 平均系统事件间隔时间(Mean Time Between System Incidents)是 指连续两次事件发生之间的平均间隔时间。平均系统事件间隔等于平 均修复时间(MTTR)和平均无故障时间(MTBF)之和。 -平均无故障时间(MTBF)和平均系统事件间隔时间(MTBSI)之比可 以表明,服务运作中是存在许多小的故障,或者仅仅是比较少的大故 障。 下(251)

基本概念(7):组件故障影响分析
?

组件故障影响分析(CFIA)

- 在进行可用性设计活动时,需要预测和评价由于IT基础架构中组件失灵对IT服务可用 性造成的影响。 - 组件故障影响分析(Component Failure Impact Analysis,简称CFIA)就是可以提供这 方面信息的一种相对简单的技巧。CFIA最初是由IBM公司出于硬件设计和配置需要而 在20世纪70年代首创的。 - 运用组件故障影响分析法可以提供如下信息:

?能够对IT可用性产生影响的单点故障;

?组件故障对业务动作和用户的影响;
?组件和人员依赖关系; ?组件恢复时间安排; ?需要确认和记录恢复方案的环节; ?需要确认和实施风险降低措施的环节。

下(252)

基本概念(8):故障树分析
?

故障树分析(FTA)
- 故障树分析(Fault Tree Analysis)是一种可用于确定引起某项IT服

务中断的一系列事件的可用性管理技巧。
- 结合有关的计算方法,故障树分析法可以提供有关可用性的更为详细的信 息。 - 故障树分析的主要优点在于: ?FTA可用于可用性计算 ?可以按照故障树分析的结论调整服务动作,可以保证服务动作与设计 方案相符;

?可以方便的选择想要分析的具体层次;

下(253)

基本概念(9):可用性管理的指导原则
Guiding Principle#1:’Availability is at the core of vusiness and User satisfaction’(可用性是业务和用户满意 度的核心) ?Guiding Principle#2:’Recognizing that when things go wrong,it is still possible to achieve business and User satisfaction’(即使出现了故障,仍然可以达致业务及 用户满意的目标) ?Guiding Principle#3:’Improving Availability can only begin after understanding how the IT Services support the business’(只有在理解IT服务是怎样为业务提 供支撑后,可用性才可能得到改善)
?

下(254)

主要活动
规则 -确定可用性需求 -可用性设计 -恢复能力设计 -恢复管理 -制定可用性计划 ?监控 -评价和报告
?

下(255)

主要活动:
?

可用性需求 可用性设计

恢复 安全 维护 可用性计划 监控

什么时候? - 在签订服务级别协议之前进行; - 需考虑新的IT服务和需要对现有服务作出的变更两个方面; - 应当在尽早的阶段确定IT部门是否能够满足这些需求以及怎样满足这 些需求。 ?确定什么? - 关键业务功能 - 约定的IT服务中断时间 - 可量化的可用性需求 - 非计划的IT服务中断对业务功能所产生的可量化的影响 - 客户的业务动作时段 - 有关维护窗口期的约定 下(256)

主要活动:

可用性需求 可用性设计

恢复 安全 维护 可用性计划 监控

确定业务可用性需求 IT基础架构分析和能力评价 协商可用性需求 确定可服务性需求 写入支撑合同(UC) 确定可靠性、弹性和可维护性需求 可用性模型

写入运营级别协议()

可用性需求满足程度测试 可用性需求符合性监控 下(257)

主要活动:
? 可用性设计

可用性需求 可用性设计

恢复 安全 维护 可用性计划 监控

- 那些影响可用性标准的薄弱环节应当尽早得到确认。这将有助于防止 额外的开发成本、计划外的后期支出、单点故障(SPOF)、供应商收 取的额外成本以及延迟的发布等情况发生。 - 基于适当的可用性标准的一个良好的可用性设计可以使得有可能性与 供应商签订有效的维护合同。设计过程 中采用了一些技巧,如确认单 点故障的组件故障影响度分析 (CFIA)。 - 如果可用性标准不能够 实现,最好的选择是确认设计是否可以进一步 改进。 - 如果可用性需求特别难以达到 ,则应当考虑使用其它的容错技术、其 它的服务管理流程(事件管理、问题管理员和变更 管理)或额外的服 务管理资源。

下(258)

主要活动:
? 恢复方案设计

可用性需求 可用性设计

恢复 安全 维护 可用性计划 监控

- 确保IT服务故障发生后,IT服务能在最短的时间内得以恢复以使正常 的业务运营继续进行; - 构建一个对故障具有高度弹性的IT基础设施即使不是不太可能,也可 能会造成成本过于高昂; - 因此 ,在给定的成本约束 下,IT基础设施满足可用性需求的能力常 常取决于可以对IT服务故障进行及时有效恢复的能力 。

下(259)

主要活动:
?

可用性需求 可用性设计

恢复 安全 维护 可用性计划 监控

关键的安全性问题

- 安全性和可靠性是密切相关的,一个较差的信息安全设计会直接影响 到服务的可用性。 - 高可用性要靠有效的信息安全来支撑 。在规划 阶段,应该考虑相关的安 全问题,对安全问题可能给服务供应带来的影响也应当加以分析 。 - 与安全问题相关的活动主要有:
?
?

确定谁将有权访问安全区域; 确定需要作出哪项关键授权。

下(260)

主要活动:
? 维护管理

可用性需求 可用性设计

恢复 安全 维护 可用性计划 监控

- 所有IT组件都必须按照计划进行有关维护活动。有计划的维护活动可 以使IT支持部门能够: ? 实施预防性维护以避免故障的发生 ;
? 及时进行软件和硬件升级以提供新的功能和额外的服务能力 ; ? 根据地业务需要对IT基础设施实施必要的变更; ?激活IT基础设施中新增的功能。

- 计划性维护活动涉及的首要问题是计划停机时间。 - 在确定新增或改进后的IT服务的可用性需求时,需要明确计划性维护 的所需的停机时间以及由此导致的收入方面的损失 。如果在可用性设 计和恢复设计阶段就虑这个问题并将持续 运作作为设计的核心特征, 就可以在不全面影响 IT服务的前提下进行维护活动。 - 在IT服务1天24小时或一周7天都必须正常运作的情况 下,可用性管理 就必须在权衡计划停机时间需求和相应的业务损失之后确定最优的维 护方案。除非有措施可以保证IT服务器的持续运作, 否则在要求高可 用性的情况下对停机维护时间进行计划和安排就显得非常重要了。

下(261)

主要活动:

可用性需求 可用性设计

恢复 安全 维护 可用性计划 监控

? 制定可用性计划
- 为有效地实施有关可用性管理活动以改进 IT组件及服务的可用 性, 必须制定明确的可用性计划。 - 可用性计划不仅需要关注技术方面的问题,还应对 用性管理的人员、 流程、工具和技巧等式方面进行考虑。在可用性管理的初始阶段 ,可 用性计划与实施通常是紧密结合进行的,但这两者却又是不同的,不 能将它们混淆。 - 可用性计划的计划周期性应当覆盖率1至2年,并且对于前6个月的计 划应当提供更为详细的信息。 - 值得注意的是,可用性计划和能力计划互相补充,因此 ,可用性的发 布应当和能力计划和业务预算的周期保持一致 。

下(262)

主要活动:

可用性需求 可用性设计

恢复 安全 维护 可用性计划 监控

? 评价 - 评价和报告是重要的可用性管理活动,它们为核实服务协议、解决
问题和制定改进建议提供了基础 。 - 可用性报告可以包括下列指标 :

? 以MTTR、MTBF和MTBSI表示的可用率(或不可用率);
? 总体正常运作时间差和宕机时间; ? 故障的次数; ? 有关故障可能实际或潜在地导致比约定数更高的不可用率的额外信息。

如果你不能评价它,你就不能管理它。 如果 你不能评价它,你就不能改进它。 如果 你不能评价它,你可能性也就不在乎它。 如果 你不能影响 它,那么你就不用评价它。

下(263)

与其它流程之间的关系

下(264)

与其它流程之间的关系 (续1)

可用性管理与SLM
服务级别管理负责与客户就握权提供 的IT服务进行谈判协商 并管理员服务 级别协议; 可用性是服务级别协议中需要考虑的 一个最重要 的因素。

可用性管理与配置管理
可用性管理需要根据配置管理数据库 提供的信息对IT基础架构的可用性进 行监控和评价。配置管理则负责存储 有关IT基础架构可用性的信息并进行 更新。

下(265)

与其它流程之间的关系 (续2)
可用性管理与连续性管理
可用性管理不需要负责在一次灾难发生后恢复业务流程。这是IT服务连续性管 理的职责。 IT服务连续性管理为可用性管理有关关键业务流程的信息。 在实践中,许多用于提高可用性措施同时也提高了IT服务的持续性,反之亦然。

下(266)

与其它流程之间的关系 (续3)

可用性管理与能力管理
能力方面的变更通常会影响一项服务 的可用性,而可用性方面的变更则又 会影响能力。 能力管理可以提供大量的信息,包括 有关IT基础架构方面的信息。 这两个流程通常可以就IT组件的升级 或终止使用以及迫使能力需求随之变 更的可用性需求等方面进行信息交换。

可用性管理与变更管理
可用性管理为变更管理提供与新服务 项目以及相关的要素相关的维护问题 方面的信息,并触发变更管理流程实 施可用性措施所需要的一些变更。 变更管理可以为可用性管理提供有关 计划中变更方面的信息。

下(267)

与其它流程之间的关系 (续4)
可用性管理与事件管理
事件管理说明了事件应当如何得到解决。 该流程提供了有关恢复时间、修复时间 等信息的报告。这些信息可用来确定已 实现的可用性级别。

可用性管理与问题管理
问题管理可以为可用性管理设计和监控 IT基础架构和IT服务的可用性提供有益 的建议。 问题管理提出的应急措施或解决方案也 会直接或间接影响IT服务的可用性。

下(268)

关键角色:可用性经理
?

角色
- 可用性经理是可用性管理的关键角色。 职能 - 定义和开发可用性管理流程; - 确保IT服务在经过设计后,实际的服务级别(以可用性、 可靠性、可服务性、可维护性和可恢复性等指标表示)能 够符合约定的服务级别; - 撰写可用性报告; - 优化IT基础架构的可用性,从而为提供给企业的服务实施 成本合理的改进。

?

下(269)

成本、效益和问题
?

成本
- - - - 实施成本。 人力成本。 设施成本。 测度和报告工具。 有一个单一的联系人负责产品和服务的可用性。 新的产品和服务可以满足与客户约定的需求和可用性标准。 相关的成本是可接受的。 可用性标准在恰当的时候得到持续的监控和改进。 在服务不可用时实施恰当的改进行动。 服务不可用的发生次数及持续时间都降低了。 关注的重点从修理故障转移到了改进服务。 IT部门更容易证明其增加值。 下(270)

?

效益
- - - - - - - -

成本、效益和问题(续1)
?

问题:
- 很难为业务和IT支持部门确定一个易测度、可实现、易理解且符合成 本效益原则的IT服务可用性级别; - 对内部或外部供应商及其所提供服务的品质的管理会由于缺乏一致的 和可测度的可用性目标而难以进行; - 对于新增IT服务,可能未充分考虑其IT可用性问题,这种未考虑可用 性和恢复方案的IT服务设计可能会导致成本高昂的回复性变更; - 新增IT服务的不稳定性可能会使组织的丧失有关商业机会和影响组织 的声誉; - 由于缺乏明确的责任划分,有关IT可用性问题在IT支持部门内不能够 及时发现和追究责任; - 不难一贯地提供商定地可用性级别不可避免会导致客户的不满意、信 任缺少信任以及业务方和IT支持部门之间的冲突。

下(271)

关键成功因素和绩效指标
关键成功因素: - 进行充分的可用性需求分析; - 制定明确的可用性目标; - 保持可用性管理与能力管理、配置管理之间紧密协调; - 制定充分的可用性计划; - 可用性目标应当在服务级别协议中予以明确定义; - 客户和IT部门必须使用一致的有关可用性和停机时间的定义。 ? 关键绩效指标: - 每项服务或每组用户的可用性百分比(正常运作时间的比例)。 - 服务中断的持续时间。 - 服务发生中断的频率。 - 一定时间内IT组件的停机时间。 - 实施可用性改进所耗费的成本。 - 因可用性改进而减少的事件的数量。
?

下(272)

能力管理(Capacity Management)

下(273)

议程
概述 ?基本概念 ?主要活动 ?关键角色 ?与其它流程之间的关系 ?成本、绩效和问题 ?关键成功因素和绩效指标 ?总结
?

下(274)

概述
定义 - 在成本和业务需求的双重约束下,通过配置合理的服务能力使组织 的IT资源发挥最大效能的服务管理流程。 ?目标: -分析当前的业务需要和预测将来的业务需求,并确保这些需求在制定 能力计划时得到充分的考虑; -确保当前的IT资源发挥最大的效能、提供最佳的服务品质: -确保组织的IT投资按计划进行,避免不必要的资源浪费。 ?范围: -处理能力的购买成本是否相对于业务需求来说是否合理以及处理能力 是否以最有效率的方式(成本Vs能力)被加以利用? -当前的处理能力是否足以满足客户当前以及未来的需求?(供给Vs需求)? -现有的处理能力是否发挥了最大的效率(绩效调整)? -额外的处理能力准确讲应该在什么时候形成? -我们是否知道未来需要什么样的IT能力以及何时需要这种能力?
?

下(275)

基本概念(1):BCM/SCM/RCM
业务能力管理(BCM) - 根据组织的业务计划和发展计划预测和规划组织未来业务对IT服务的需求,并使其在制 定能力计划时得到充分考虑; - 主要关注当前未来的业务需求,确保IT服务提供方在进行能力规划时能够充分考虑组 织业务需求的现状及发展趋势,该子流程主要地是一个主动性的流程。 ?服务能务管理(SCM) -对服务级别协议中确定的服务项目的品质进行监控、评价、记录、分析和报告; - 该子流程的目标是确定和了解IT服务(提供给客户的产品或服务)的使用情况,为了 确保能够拟定和签订恰当的服务协议,需要充分了解服务动作的绩效和高峰时期的负 载量。该子流程在服务协议条款的谈判和制定方面与服务级别管理具有很密切的关系。 - 确保组织的IT投资按计划进行,避免不必要的资源浪费。 ?资源能力管理(RCM) - 对IT基础设施中的所有组件进行监控、评价、记录、分析和报告,以及在必要时采取 适当的行动对现有的IT资源进行调整,以确保其支持的IT服务能够满足组织的业务需 求; - 该子流程的目标是确定和了解基础架构及其组件的利用情况。为了有效地管理这些资 源,需要提早发现潜在的问题。组织也需要了解技术的最新发展,密切地监控IT资源 基础架构动作的趋势也是该子流程的一项重要的活动。
?

下(276)

基本概念(2):模拟/应用选型/弹性
?

模拟(Modeling) - 使用分析、模拟和趋势预测模型来确定服务的能力需求以及确定最佳 的能力方案的过程。 - 模拟需要分析各种不同的情形,并分析各种“如果……怎么办?”式的

问题。 ?应用选型 - 应用选型(Application Sizing)是指对动作新增或改进的应用系统所 需的硬件和网络资源进行估计和分析从而确保资源的配置能够支持 正常的服务运作及相应的服务级别需求。 ?弹性 - 弹性(Resilience)是IT基础设施质量特征的一个方面,具体是指在 一个或多个组件出现故障后IT基础设施仍能支持系统的充分运行而不 影响其主要功能的特性。 - 并行配置和串行配置对可用性的影响。

下(277)

基本概念(3):绩效管理/负载管理
?

绩效管理

- 绩效管理(Performance Management)是指对IT基础设 施组件进行测度、监控和调整等一系列旨在提高IT基础设 施服务品质的管理活动。
?

负载管理 -负载管理(Workload Management)主要是了解不同的业 务驱动会产生怎样的结果,需要哪些资源。它既可以作为 模拟的一个基本组成部分,也可以是单独的一种活动。

下(278)

基本概念(4):CDB/能力规划
能力数据库( CDB ) - 能力数据库( Capacity Database)是指用于存储能力 管理流程中所采用集的业务数据、服务数据、技术数据、 财务数据以及资源得用数据等数据信息的数据库。 -CBD中的数据由能力管理的所有子流程保存和使用 -CBD不一定是一个单一的数据库,它可能存放在不同的物 理位置 ?能力规划 - 根据能力管理数据库分析当前的情况、预测IT基础架构未 来的使用情况以及为满足预计的IT服务需求而需要的资 源,从而制定能力计划的过程。
?

下(279)

主要活动
业务能力管理(BCM) 服务能力管理(SCM) 资源能力管理(RCM)

复 性 活 动 需 求 管 理 模 拟 测 试 应 用 选 型 能 力 管 理 数 据 存 储

制作能力计划 CDB
有关BCM、SCM、和RCM的计划

下(280)

主要活动:
?作用:

能力计划 模拟 应用选型 监控 分析 调整

实施 需求管理 CDB



描述了当前及未来对IT基础架构能力的需求、IT服务需求方面的预期变化、 过时缓缓的替换以及技术方面的最新发展;

- 说明了在考虑未来服务级别需求的情况下,以可接受的成本提供服务级别协 议(SLA)中约定的服务级别而需要作出的变更。

?要求:
- 能力计划不仅需要描述预计的变更,而且还要指出相关的成本;
- 应当每年进行一次修订;

- 为保证其正确性,应当每季度进行一次审查。

?内容: - 一份能力计划应当包含绩效预测、升级点、基础架构升级(资本、招募、运
营、人事)的预计成本等方面的信息;
- 上述信息应当根据动态的环境定期地更新。

下(281)

主要活动: 能力计划
?

模拟 应用选型 监控 分析 调整

实施 需求管理 CDB

作用: 技术&手段:

-模拟是一个非常有力的能力管理工具,主要用于基础架构的运行情况。
?

-拇指规则; -线性预测(趋势分析):获取有关负载量方面的信息,也可用来预测大 致的响应时间; -分析性模拟:通常耗时较少,但结果的可靠性不高; -仿真模拟:可用于准确地预测一台主机的运行绩效,也可能作为应用选 型的一项要素。但却是一种非常耗时间和资源的方法; -基线评价(最准确); -系统实际运行考察。 下(282)

主要活动:
?

能力计划 模拟 应用选型 监控 分析 调整

实施 需求管理 CDB

目标:
- 考察运行新的或改进的服务(如处于开发或维护状态中的服务,或需要按照客户要求购

买的服务)所需要的资源;
- 有关的预测信息包括预期的绩效水平、必要的资源以及成本等;
?

作用:
-在首次产品开发阶段显得尤为重要; -该方法还有助于草拟新的或改进的SLR’s或SLA’s;

?

重点考虑:
- 应用选型需要考虑的第一个问题是在初始的系统分析和设计阶段就必须确定所需的服务 级别。在应用系统设计开发周期的开始而不是后来的某个时候考虑所需的服务级别可以 降低整个开发过程的成本和难度。

- 应用选型需要考虑的另一个问题是新建应用系统的弹性。有时候,单个组件的故障可能
导致整个IT基础设施的瘫痪,但如果在资源能力管理中充分考虑到IT基础设施中脆弱但 关键的那些组件并采取适当的预防措施,就可以单个组件的故障对整个系统的影响,从 而提高IT基础设施的弹性。资源能力管理子流程应当结合可用性管理流程分析现有的配置 对单个组件的敏感程度,并提出符合成本效益原则的配置方案。

下(283)

主要活动:

能力计划 模拟 应用选型 监控 分析 调整

实施 需求管理 CDB

?

目标:

- 确保约定的服务级别能够实现。
?

监控对象(举例)

- CPU利用率 - 磁盘利用率 - 网格利用率

- 软件许可证的数量

下(284)

主要活动:
?

能力计划 模拟 应用选型 监控 分析 调整

实施 需求管理 CDB

目的:

- 确定正常的使用情况服务级别,或都为它们制定基准性。
?

作用:

- 趋势分析可以用于预测未来的增长并确认潜在的“瓶颈” - 通过定期的监控并将监控结果与这些基准线进行比较,可以确定单

个组件的使用情况或服务运营的异常情况,从而据以报告对SLA的履
行情况; - 根据分析的结果预测未来资源的使用量以及比照预期增长率来监控实 际的业务增长率;
?

要求:
力管理三个子流程各要素之间的关系具有完全的了解。 下(285)

- 活动分析需要对总体基础架构、业务流程以及业务、服务、和资源能

主要活动:
?

能力计划 模拟 应用选型 监控 分析 调整

实施 需求管理 CDB

目标 哪些配置项进行调整以提高系统资源的利用效率和改进相 关IT服务的品质。 要求 - 在实施调整方案之前,最好对调整方案进行测试以验证其 可行性和必要性;

- 在对监控活动采集的数据进行分析后,应当确认可以对

?

- 例如,通过中以了解是否可以通过需求管理来避免实施有 关调整,或者在实施前通过模拟测试表明计划的某项变更 的有效性。

下(286)

主要活动: 目的:

能力计划 模拟 应用选型 监控 分析 调整

实施 需求管理 CDB

?

- 引进一项必进的或新的能力; - 将监控、分析和调整活动所确定的变更引进实际的服务运营之中。
?

要求:

- 任何变更的实施都必须通过一个严格而正式的变更管理流程来进行,
这样可以将变更的影响及相应的风险控制在可接受水平内; - 在实施有关变更后,仍然需要进一步的监控以便合理评估变更的影

响;
- 根据评估结果,管理人员可以决定是否需要进一步实施其它变更或 回滚已经实施的变更。 下(287)

主要活动:
?

能力计划 模拟 应用选型 监控 分析 调整

实施 需求管理 CDB

目标和作用:

- 首要目标是影响和调节客户对IT资源(能力)的需求; - 需求管理为制定、监控和在可能的发问下调整能力计划和服务级别协议提供了 信息来源。
?

方式:
的一种短期的需求调节活动,也可能是组织为限制长期的能力需求而采取的 一种IT管理政策;

- 需求管理既可能是由于当前的服务能力不足以支持正在动作的服务项目而进行

- 短期需求管理一般在IT基础设施内某个关键组件发生局部性故障时进行,而长期

需求管理一般发生在进行上组件的升级显得很必要但却又似乎不划算的情形;
- 可能采取差别计费(如在高峰时段和非高峰时段采取不同的计费标准)的方法, 通过控制高峰使用期间的需求来影响客户和用户的行为。
?

要求:
服务必须动作的时间安排。

- 需求管理需要掌握有哪些服务项目在多大程度上需要依赖某项IT资源,以及各项

下(288)

主要活动:

能力计划 模拟 应用选型 监控 分析 调整

实施 需求管理 CDB

?创建CBD -创建能力数据库意味着收集和更新技
术类、业务类以及其它与能力管理相关 的信息。

?能力管理数据的存储 -在动作能力管理各子流程时,必须及
时将流程中采集的各种数据存入CDB;

-这些数据主要包括业务数据、服务数 据、技术数据、财务数据以及资源利用 情况数据等六种;
-CDB中的数据信息有以下两个用途: 第一,为制作提交给管理层和技术人员 的服务品质报告和能力管理报告提供基 础;第二,用于预测未来的能力需求。

下(289)

与其它流程之间的关系

下(290)

与其它流程之间的关系 (续1)

能力管理与事件管理
事件管理为能力管理提供有关由于能 力或绩效问题所导致的事件方面的信 息。 能力管理可以为事件管理诊断和解决 有关能力方面的问题提供蓝本。

能力管理与问题管理
能力管理不论在其被动性流程还是在 主动性流程中都为问题管理提供了支 持。 能力管理中的工具、信息、知识以及 专家经验都可以被用来协助问题管理 的各种活动。

下(291)

与其它流程之间的关系 (续2)
能力管理与变更管理
能力管理应是变更顾问委员会(CAB)的一 部分,提供了有关能力需求以及某项变更对 服务供应可能产生的影响方面的信息。 有关变更方面的信息也为制定能力计划提供 了有价值的信息来源。能力管理在计划实施 期间也同样可以提交变更请求(RFC’s)。

能力管理与发布管理
在网络和发布服务器被用于自动或手动发布 的情况下,能力管理可以为制定发布计划提 供支持,从而可以确保在所有需要的方面都 保有足够的IT能力。

下(292)

与其它流程之间的关系 (续3)

能力管理与配置管理
能力管理数据库(CDB)和配置管理数据 库(CMDB)之间具有密切的联系;

能力管理与SLM
能力管理为服务级别管理确定可行的 服务级别(如响应时间以及服务级别 需求等)提供建议。能力管理对绩效 水平进行评价和监控,并为核对约定 的服务级别及相关的报告是否实现以 及在必要时进行变更提供了信息。

能力数据库可能形成了配置管理数据库的 一部分。
配置管理所提供的信息对于开发一个有效 的能力数据库非常关键。

下(293)

与其它流程之间的关系 (续4)
能力管理与IT财务管理
能力管理可以为投资预算、成本-效益 分析以及投资决策提供支持,它还可以 为与能力相关的服务项目(如网络能力 的利用)的计费提供重要的信息。此外, 非常重要的一点是,能力计划应当与财 务规划和计划的各方面保持一致。

能力管理与IT服务连续性管理
能力管理说明了在灾难发生时用于继续 和恢复服务供应所需的最低的能力水平。 IT服务连续性管理的能力需求应该经常 加以审查,确保它们能够反映实际运作 环境中的日常变化。

下(294)

与其它流程之间的关系 (续5)

能力管理与可用性管理
有关绩效和能力方面的问题可以导致很 差的IT服务质量。
事实上,在客户看来,很差的服务绩效 与服务不可用没什么分别。 由于相互之间存在许多的依赖关系,需 对这两个流程需要进行有效的协调。它 们都使用了一些同样的工具和技巧,如 组件故障影响分析(CFIA)和故障树分析 (FTA)。

下(295)

关键角色
?

能力经理 - 能力经理这一角色的职责是管理流程,以确保能力计划的 定期制定和维护以及能力数据库的随时更新。 - 系统、网络和应用经理们都对能力管理流程具有重要的支 持职责,他们不仅要负责协助其管理范围内的资源,同时 还要求运用他们的专门知识对他们管理范围内的技术问题 提供建议和协助。

下(296)

成本、效益和问题
?

成本
- 购买硬件和监控工具、能力管理数据库、用于仿真模拟和统计分析的 趋势分析和模拟工具以及报告工具等软件工具的成本; - 与该实施该流程相关的项目管理成本; - 人力、培训和支持成本; - 设施和服务。

?

效益
- 由于资源被有效地加以管理以及设备运作绩效被持续地监控,与现有 服务相关的风险也被降低了; - 通过应用选型可以了解新的或改进的服务对现有系统的影响,从而降 低了与新的或改进的服务项目相关的风险; - 在恰当的时候(既不太早也不太晚)进行投资,这意味着采购流程再 也不需要应付临时应急式的采购或超前于需求而购买过度的能力,从 而使得总体成本降低了。 下(297)

成本、效益和问题(续1)
?

可能产生的问题:
- - - - - - 不切实际的预期; 缺乏恰当的信息; 供应商提供的信息来源; 在复杂环境下的实施; 确定适当的监控级别; 缺乏管理层的支持。

下(298)

关键成功因素和绩效指标
关键成功因素: - 准确的业务预期; - 对IT战略和规划的充分了解及其这种了解的准确度; - 对当前及未来技术的知识; - 与其他流程的协调; - 实现成本效益的能力。 ? 关键绩效指标: - 客户需求的可预见性-对工作量随时间发展和变化的趋势的确认,以
?

及能力计划的准确性。 - 技术-评价所有IT服务绩效的工具、实施新技术的速度以及在使用旧 技术的情况下仍然可以持续地实现服务级别协议中所确定的目标能力。 - 成本-临时性贸然采购次数的减少、采购不必要或昂贵的过度能力的 次数的减少以及在更早的阶段制定投资计划。 - 运营-由于绩效和能力方面的问题而导致的事件次数的减少、在任何 时候都能满足客户需求的能力、以及能力管理流程被严格采纳的程度。

下(299)

IT服务连续性管理(IT Service Continuity Management)

下(300)

议程
概述 ?基本概念 ?主要活动 ?关键角色 ?与其它流程之间的关系 ?成本、绩效和问题 ?关键成功因素和绩效指标 ?总结
?

下(301)

概述
?

定义
- 负责预防灾难、增强IT基础架构的弹性(Resilience)和容错能力 (Fault Tolerance) 的流程; - 它需要确保组织在发生灾难后有足够的技术、财务和管理资源来确 保IT服务的持续性运作。

?

目标:
- 确保业务运作所需的IT基础架构和IT服务在灾难发生后的限定时间 内能够得到恢复,从而对组织的总体业务连续性管理(BCM)提供 支持。

?

范围:
- 重点关注那些支持关键业务流程的IT服务项目; - 对具体的IT技术和服务需求提供支持。

下(302)

基本概念(1):灾难
?

定义:
- 灾难(Disaster)是指可以对一项服务或一个系统造成影响从而需要 付出很大的努力来恢复初始绩效水平的事件。

?

灾难VS.事件:
- “灾难”比“事件”要严重得多; - 在一次灾难发生后,全部或部分业务不能正常运作; - 常见的灾难包括火灾、雷击、水灾、失窃以及暴力破坏等。

?

意外事件规划VS.IT服务连续性管理:
- 传统的意外事件规划是反应式的,通常是被IT部门作为用来免除其 责任的一种形式; - IT服务连续性管理流程侧重于预防,即避免灾难的发生。 下(303)

基本概念(2):BCM/ITSCM
?

业务连续性管理(BCM)

- 包括(1)将风险降低至合理水平以及(2)在业务中断发生以后进 行业务流程恢复两个方面; - 包括启动、需求分析和战略定义、实施和运营管理四个阶段。 - BCM通过风险分析和管理确保组织在任何时候都具备最低要求的生 产能力和服务供应。业务连续性管理的目标在于将风险降低至可接 受水平并为恢复被灾难中断的业务活动制定恢复计划。
?

IT服务连续性管理(ITSCM)
- 指确保发生灾难后有足够的技术、财务和管理资源来确保IT服务持 续性的流程; -包括灾难恢复设施的需求分析、灾难恢复计划的制定、计划的更新、 测试的执行以及必要时进行实际的灾难恢复等方面; -IT服务连续性管理(ITSCM)是应对影响IT服务运作的灾难并维护IT 服务以支持业务的持续运作的流程。 -IT服务连续性管理是总体业务持续性业务计划的一部分,并依赖于业 务连续性管理流程所提供的信息。 下(304)

基本概念(3):逐渐恢复/中期恢复/紧急恢复
?

逐渐恢复(Gradual Recovery)

- 即冷支持(Cold stand-by); - 可以不用立即恢复业务流程和重建所有IT设施,能在72小时或更长 的时间丙继续保持运行; - 要求提供装备了以下设施的未使用的场所:电力、环境控制措施、 局域网集线器、通信连接。 - 即暖支持(Warn stand-by); - 通常是指在24小时到72小时内重建关键系统和服务的方法; - 用于在预定时间内恢复IT设施,避免其对业务流程造成影响。 - 发生不可挽回的事件后产即恢复有关服务; - 紧急恢复不同于热支持(Hot stand-by),热支持通常是指在较短 的时间内(如2-4小时内)恢复服务的可能性,而紧急恢复指发生 事件后立即恢复服务的可用性。 下(305)

?

中期恢复(Intermediate Recovery)

?

紧急恢复(Immediate Recovery)

基本概念(4):业务影响分析
?

定义

- 业务影响分析(Business Impact Analysis, BIA)是指对关键业务流程以及由于这些流程 中断而可能对组织造成的损失或损失进行确认的管理活动;
?

说明
- 决定ITSCM需求的关键因素是当灾难发生或其它服务中断时组织能承受的灾难损失的程 度和损失扩散的速度。 - 业务影响分析有助于实施风险评估,从而可以明确哪些地方需要重点IT服务连续性管 理。具体而言,通过业务影响分析可以明确以下多方面的信息:

? ? ?
? ? ? ?

关键业务流程; 关键业务流程发生中断可能对组织产生的潜在损害或损失; 损害或损失可能出现的具体形式,如收入减少、成本增加、声誉损失或竞争 优势丧失等; 服务中断发生后危害或损失程度的变化趋势; 灾难发生后为保持关键和必要的业务持流程在最低可接受水平运作所必需的 人员、技能、设施和服务(包括IT服务)等; 恢复到最低级别的人员,设施和服务所需的时间; 所有必要的业务流程以及支持人员、设施和服务全面回复所需的时间。

下(306)

主要活动
阶段1:启动 阶段2:需求分析
和战略规划

定义ITSCM的范围
业务影响分析 风险评估 IT服务持续性策略
? ?

启动 需求分析和战 略规划

阶段3:实施

组织和实施规划 实施备用方案和降低风险措施

? ?

实施 动作管理

开发恢复计划和程序
执行初始测试
阶段4:动作管理
教育和培训

评价和 审计

测 试 变更管理

保证

下(307)

主要活动:
?确定政策 -

启动 需求分析和战略规划 实施 动作管理

有关IT服务连续管理的政策应当尽可能早地制定并充分传达给组织内所有 的相关的人员,从而使他们意识到IT服务连续性管理的需求;

- 同时管理层也需要明确表达他们的承诺。
?

确定范围和相关的领域
- 保险需求,如ISO9000质量标准和BS7799安全管理标准,以及总体的业务政 策原则都需要被用来选择风险评估和业务影响分析(BIA)的方法;

- 此外,还需要确定适当的管理架构(清晰划分职责)和应对灾难的流程。 ?

分配资源

- 建立一个IT服务连续性管理环境需要投入大量的人力和物力。

?建立项目小组
- 最好使用一种由管理软件支持的正式的项目管理方法,如PRINCE2.

下(308)

主要活动:

启动 需求分析和战略规划 实施 动作管理

?业务影响分析 - 在有些情况下,服务在灾难发生后仍可以继续动作一段时间,因而其重点
是恢复服务;而在其它情况下,没有IT服务的支持业务将完不能动作,因 而其重点将是预防。大部分企业都需要在这两个极端之间选择某种平衡。 - 服务分析:对某些不重要的服务而言,可以规定在灾难发生时使用能力和 可用性有限的应急服务。但需要注意的是,即使是在灾难恢复期间,服务 级别也只有在客户达成协议之后才能进行修改。对于是关键性服务来说, 必须在进行预防和制定恢复方案之间选择某种平衡。 - 基础架构分析:在完成服务分析之后,需要评估服务和IT资源之间的依赖 关系。可用性管理流程提供的信息可用来分析IT资源在支持前面所讨论的

IT服务时可在多大程度上发挥关键性的作用。能力管理提供有关所需的能
力方面的信息。进而,确定从最初服务失败到全面恢复期间,这些服务在 多大程度上可能被中断是非常必要的。之后,这些信息可用来为每项服务 制定恢复方案。

下(309)

主要活动:
?风险评估

启动 需求分析和战略规划 实施 动作管理

-风险分析可能帮助识别一个企业所面临的风险。这样的分析通过确认业务
中存在的威胁和薄弱环节以及相关的预防措施可以为管理层提供有价值的 信息。 -实施一个灾难恢复计划是比较昂贵的,因此应当优先考虑使用各种预防措 施。如果所有这类预防措施全部用上了,则有必要进一步确定是否还存在需要制定应 急计划的残余风险。 - 风险分析
?必要确认相关的IT组件(资产)包括建筑物、系统和数据等; ?分析这引动资产所面临的威胁以及这些威胁之间的相关程度,并估计灾难发生的可能性(高、中、低); ?要确认这些资产的薄弱环节,并进行分类(高、中、低);

?根据各IT组件的具体情况评估威胁和薄弱环节,从而评估风险的级别

资产(Asset)

威胁

漏洞 分析

风险 对策

管理

下(310)

主要活动:
?IT服务持续性策略

启动 需求分析和战略规划 实施 动作管理

-预防措施
?在充分考虑了预防措施的成本和风险的级别后,可以根据风险分析的结果采取预防措施; ?要害关键控制法(Stronghold/Fortress Approach)是用得最多的预防形式,它可以消除大 部分的薄弱环节;

-恢复方法
?不作任何反应—在这种方法下,很少有业务能够有效地动作。运用这种方法的目的更可能是表明尚未查明情况; ?回复至手工(基于纸质的)系统—这种方案对于那些对业务有关键性影响的服务来说是不可接受的,但对于那 些不甚重要的,小的服务仍然是可行的。大部分的恢复计划都包括一些基于纸质的备份程度; ?逐渐恢复(冷支持)--这种方案适用于那些在一段时间内(如72小时)没有IT服务也能动作的企业。 ?中期恢复(暖支持)-这种方案可以使服务在接入一个类似的动作环境后经历一段短暂的过渡期(24-72小时) 使可以继续正常动作。 ?内部式恢复(相互支撑)-如果企业有多个办公场所或可用于生产的专用的测试环境,可以采用这种内部式恢 复方案。

?外部式恢复-由第三方恢复组织提供商业服务,这些组织通常是为多个客户服务的。
?移动式恢复-这种方案所需的基础设施一般都是用一辆拖装载着。 ?立即恢复(热启动、热支持)-这种方案提供了即时的或非常快速的恢复服务,如在不超过24小时之内。

下(311)

主要活动:
?组织和实施规划

启动 需求分析和战略规划 实施 动作管理

-在确定了业务战略和选定了恢复方案之后,就可以开始ITSCM,并为每个IT设
施制定详细的恢复计划; -最高管理层应当针对下列问题制定一个总体性计划:
?紧急反应计划; ?损害评估计划; ?恢复计划; ?关键记录计划(怎样管理数据,包括纸质的记录); ?危机管理和公共关系计划。

-预防措施和恢复方案
-为减小事件影响而制定的预防措施必须结合可用性管理而实施,主要包括: ?使用UPS或其它备用电力供应; ?容错系统; ?异地存储和RAID系统等; -在这一阶段还应当开始考虑制定支持协议,协议应该涵盖的内容人员,建筑和电 信服务等。即便是在紧急事件期间,也可以就恢复正常动作和订购新的IT组件签 订有关的支持协议。

下(312)

主要活动:
?制定恢复计划和程序

启动 需求分析和战略规划 实施 动作管理

-恢复计划
?恢复计划应当详细制定并处于正式的变更控制之下; ?恢复计划应当明确所有需要支持该计划的具体程序; ?这些问题需要通过计划传达至所有的参与人员和受影响的人员; - 风险分析 ?制定有效的恢复程序是非常关键的,有了集体的程序,任何人都可以按照程序的 指示实施恢复;

?需要制定的程序包括:
-安装和测试硬件和网络组件; -恢复应用系统、数据库和数据。 ?这些以及其它相关的程序应当附在恢复计划后面。

下(313)

主要活动:
?执行初始测试

启动 需求分析和战略规划 实施 动作管理

-对恢复计划、程序和相关的技术组件进行初始测试是ITSCM 非常关键的一个方面;

-测试应当针对特定的情形实施并具有明确的目标和成功标准;
- 在发生重大变更后还需要实施进一步测试,这类测试至少每 年要进行一次;

-IT部门负责测试恢复计划和程序中IT部门的有效性能;
-这类测试可能是公开的也可能是非公开的,但邀请适当的业 务经理参加将有助于促进相互了解因而更有可能获得业务层 的支持和承诺。

下(314)

主要活动:
?培训和意识培养

启动 需求分析和战略规划 实施 动作管理

- 对IT和其它人员进行培训,以及对所有人员和进行意识培养对于
成功地IT服务连续性管理是非常关键的;

- IT人员需要对业务恢复团队中的非IT人员进行培训,以确保他们熟
悉所有的问题并在实施恢复期间能够提供支持。
?

评价和审查

- 计划应当定期评审和查验以确保它们总能反映最新的情况;

- 每当IT基础架构中发生了一次重大变更(如引入了新的系统、网络 或服务提供商)后就应当进行一次这样的审查; -当业务战略或IT战略发生任何形式的变更时也应实施这样的审查。

下(315)

主要活动:
?测试

启动 需求分析和战略规划 实施 动作管理

- 恢复计划应当定期进行测试; - 通过测试,也可以识别计划中的弱点以及被我们忽略的变更;

- 如果在灾难发生时所有人都需要重新学习恢复计划,这就存在很多
问题。
?

变更管理
要的角色,因为它确保了任何对恢复计划所作的变更的影响都得到 明确的分析。

- 变更管理在保持所有的IT服务连续性管理计划的更新方面扮演了重

? 保证 - 保证意味着验证流程(程序和文档)及其输出成果的质量是否是以 满足公司的业务需求。

下(316)

与其它流程之间的关系

下(317)

与其它流程之间的关系(续1)
?服务级别管理

- -

服务级别管理为IT服务连续性管理提供有关IT服务责任方面的信息; 而IT服务连续性管理通过制定预防性措施紧急恢复计划可以提高实际的服务级别。

?可用性管理

- 通过制定和实施预防措施支持IT服务连续性管理; - IT服务连续性管理通过增强IT基础架构的恢复能力和容错能力提高
了IT服务的可用性级别。

?配置管理



配置管理在灾难发生时为IT服务连续性管理提供有关基准配置和IT

基础架构方面的信息,从而支持IT服务连续性管理实施灾难恢复方
案。

- 定义基线配置配置和IT基础架构,为IT服务连续性管理提供灾难发
生后哪些组件需要进行恢复到什么状态方面的信息。

下(318)

与其它流程之间的关系(续2)
?能力管理
-能力管理通过为业务需求配备足够的资源能力从而改进了IT服务的持
续动作;

?变更管理
-通过在所有影响预防措施和恢复计划的变更项目中引进IT服务连续性
管理,从而确保所有的IT服务持续性计划是正确的和保持更新的; -变更管理通过定期评审确保持续性计划的通用性和准确性。

下(319)

关键角色
?IT服务持续性经理
- IT服务持续性经理的职责是实施和维护ITSCM流程,从而保证
该流程任何时候 都能满足业务连续性管理的要求。 - IT服务持续性经理还需要在业务连续性管理中代表IT服务部门。

下(320)

成本、效益和问题
?

成本:
— 发起、开发和ITSCM的时间和成本; — 与引入风险管理有关的投资,如配备额外硬件的需求; — 恢复安排的后续成本,如签订外部热支撑合同的费用,测试安排的成本,以 及恢复设施处于备用状态期间的费用等; - IT服务连续性管理的日常动作成本,如测试、审查以及更新计划的成本。

?

效益:
— 较低的保险费:IT部门帮助组织向保险公司证实他们采取了积极的措施降低 了业务风险,从而可以降低保险费用,或在某些内进行自我保险从而节省了 保险费用。 — 改善业务方和IT人员的关系:维持业务的持续性可以促进的人员和业务方之 间的关系更紧密,有助IT人员更好地理解业务需求从而更好地支持这些需求。 — 增强组织的应急能力:实施IT服务连续性管理员可以增强组织应对意外事件的能力从 而能够为客户提供更级别的服务,进而取得客户的信任。 — 提高组织的信誉:组织的持续服务能力增强了客户、合作伙伴和股东对组织的信任, 提高了组织的声誉。 - 加强组织的竞争优势:维持业务持续动作的能力可以促使组织的后任伙伴及客户与组 织保持持续的业务关系,而成为组织赢得客户信任的竞争优势。

下(321)

成本、效益和问题(续1)
? 问题: — 资源:为项目团队配备额外的能力来制定和测试恢复计划; — 管理层承诺:组织的预算中应当包括用于ITSCM的年度成本,这需 要获得高层管理的承诺; — 获得恢复设施:前面讨论的所有方案都需要对恢复设施进行定期测 试。因而,任何恢复服务全同都应当让IT部门可以定期地获得这些 恢复设施; — 无限期推迟:由于IT服务连续性管理的全部或大部分流程还没有就 绪,从而导致进度被频繁地延期; — 意识的缺乏:没有全体人员的意识到位和支持,IT服务连续性管理 流程是注定要失败的。

下(322)

关键成功因素和绩效指标
? 关键成功因素: — 有效的配置管理流程; — 整个组织的支持承诺; — 最新的和有效的工具; — 对流程中涉及的所有人员进行专门的培训; — 对恢复计划进行定期测试。 ? 关键绩效指标: — 确认的恢复计划中的缺点的数量; — 由于灾难所导致的收益减少; — 流程的成本。
下(323)

Service Delivery 总结

下(324)

Service Delivery流程

可用性管理

服务级别管理

请求和需求

业务 客户 和用户

能力管理

需求、目标
和绩效

沟通、更新和报告

警告和期望 调整

IT服务财务管理 IT服务连续性管理

管理工具和 IT基础架构

下(325)

特点
? 面向客户: — 服务提供流程主要涉及服务级别目标的协商和谈判、资源需求的确 定、服务成本的核算和服务收费等战术性问题; — 这些问题的确定必须由客户或其代表(而不是具体IT服务的用户) 与IT服务提供方共同协商完成;
?

战术性流程: — 主要涉及服务级别目标的设定、资源需求规划、服务收费标准的确 定等较为全局性的问题,而不是一些具体运营上的问题; — 如果将IT服务管理分为事前管理、事中管理和事后管理三个阶段 中,服务提供流程主要是一种事前管理; — 服务提供流程也涉及一些事后管理的内容,如可用性的评价和报告 等,但这些往往与进一步的设计与规划活动联系在一起。

下(326)


? ? ?



?

?

结合组织的业务需求,协商确定服务级别目标; 对服务进行收费和成本核算,便于确定IT服务的成本益; 对组织的业务能力、服务能力和资源能力进行规划,IT资 源和组织业务的有效整合; 通过有效的连续性管理员和风险管理确保组织业务的持续 运营; 优化IT基础设施的可用性,为组织提供持续的符合成本效 益原则的可用性级别,从而确保组织实现其业务目标

下(327)

安全管理(Security Management)

下(328)

议程
概述 ?基本概念 ?主要活动 ?关键角色 ?与其它流程之间的关系 ?成本、效益和问题 ?关键成功因素和绩效指标 ?总结
?

下(329)

概述
?

定义:
- 安全管理是顺应信息安全的需要而产生的,其主要目标是确保信息 的安全性。 - 安全管理致力于确保服务的安全性在任何时候都能达到与客户约定的 级别 - 安全性在ITIL中被视为可用性管理的一部分。安全管理已经成为现代 IT服务管理中一个重要的问题,并且在ITIL系列书店中成为一本单独 的出版物。

?

目标:
- 满足服务级别协议中的安全性需求以及合同、法律和外部政策等外 部要求; - 提供一个独立于外部需求的基本的安全性级别; - 确保有效的信息安全措施在战略层、战术层和运营层本个层面都得 到贯彻; 下(330)

基本概念:安全性/机密性/完整性/可用性
?

安全性 (Security)
- 安全性是指不易遭到已知风险的侵袭,并且可能地规避未知风险的 性能。提供这种性能的工具是安全措施 - 安全措施的目标是要保护信息的价值,这种价值取决于机密性、完 整性和可用性三个方面。

?

机密性 (Confidentiality)
- 保护信息免受未经授权的访问和使用。

?

完整性 (Integrity)
- 信息的准确性、完全性和及时性。

?

可用性 (Availability)
- 信息在任何约定的时间内都可以被访问。这取决于由信息处理系统 所提供的持续性。 下(331)

主要活动
?控制 ?计划 ?实施 ?评估 ?维护 ?报告

下(332)

主要活动:
?

控制

计划 实施 评估 维护

报告

控制

- 控制活动是安全管理的第一个子流程,它主要是关于该
流程的组织和管理; - 主要包括信息安全管理框架,该框架主要描述了如下子 流程:安全计划的制定、安全计划的实施、实施评估以 及将评估结果纳入软解压安全计划(改进计划)。

- 该项活动中定义了子流程,安全职能、角色、和责任,
还描述了组织结构、报告安排以及控制结构(谁指导 谁,谁做什么事情,如何报告实施状况)。
下(333)

主要活动: ? 计划

控制

计划 实施 评估 维护

报告

- 计划子流程包括与服务级别管理磋商后制定服务级别协议中的安全部分, 以及与安全相关的支撑合同中的活动。
- 计划子流程不仅接收来自服务级别协议的信息而且还有来自服务提供商 的政策原则(来自控制子流程),例如:“每个用户的身份必须可以唯一识别” 和“在任何时候必须为客户提供一个基本的安全级别”。 - 针对信息安全的运营级别协议(具体的安全计划)也是通过正常的程序 来起草和实施的。 - 为了定义,更新和尊循服务级别协议中的安全部分,必须就该计划子流 程与服务级别管理进行讨论。服务级别经理负责这中间的协调。 -服务级别协议中应该定义安全需求,在可能的情况下还应该以可测度的 术语进行定义.该协议的安全部分应当确保客户所有的安全需求和标准能 够实现,并且实现的结果能够进行明确的验证.

下(334)

主要活动:
? 实施

控制

计划 实施 评估 维护

报告

- 实施子流程负责实施计划中规定的所有安全措施;
- 人员安全:
?职位说明中的任务和职责:安全防护; ? 针对个人的保密协议;处理安全事件和观察到的安全隐患的员工指南; ?纪律措施:提高安全意思

-实施安全管理:
?责任划分的实施以及岗位分离的措施; ?书的操作指示:内部规章; ?安全问题涉及整个生命周期,应针对系统开发,测试,验收,运营,维护和终止制定安全指南; ?将开发和测试环境与实际的运营环境分离开来; ?处理事件的程序(由事件管理负责处理):恢复设施的实施; ?为变更管理提供信息输入,病毒防护措施的实施; ?针对计算机、应用系统、网络和网络服务的管理措施的实施; ?数据媒介的的处理和安全;

-访问控制
?访问和访问控制政策的实施; ?用来访问权利的维护以及网络、网络服务、计算机和应用系统的应用维护; ?访问安全屏障(防火墙、拨号服务、网桥和路由器)的维护; ?针对计算机系统、工作站和连接在网络上的计算机的身份识别和验证措施的实施。

下(335)

主要活动:
?

控制

计划 实施 评估 维护

报告

评估

- 对安全措施的实施结果进行独立的评估是非常重要的;
- 评估子流程的结果可用来更新与客户协商约定的安全措施,也可用于改进它

们的实施效果;
- 根据评估的结果还可以建议实施某些变更,在这种情况下可以制作一项变 更请求并提交给变更管理流程。

- 评估主要有以下三种形式:
? 自我评估-主要由流程的直线组织实施;
? ?

内部审计-由内部IT审计师进行; 外部审计-由外部IT审计师进行。

-评估子流程的主要活动包括:
?核实遵循安全政策的情况以及安全计划的实施情况; ?对IT系统实施安全审计; ?找出对IT资源的不正确的使用,并作出相应的处理; ?承担其它IT审计的安全方面。

下(336)

主要活动: ? 维护

控制

计划 实施 评估

维护

报告

- 由于IT基础架构、组织和业务流程方面的变化导致相关的风险也随着发 生变化,因此安全也需要进行维护。 - 安全维护包括服务级别协议中安全部分的维护以及详细的安全计划(运 营级别协议)的维护。 - 维护需要根据评估子流程的结果以及对风险变化的评估结果进行。这些 建议既可以直接被计划子流程所采纳,也可以纳入总体的服务级别 协议 的维护中。

下(337)

主要活动: ? 报告

控制

计划 实施 评估 维护

报告

- 报告不是一个子流程,但它是其它子流程输出的结果。
- 报告可以提供有关已实现安全绩效方面的信息,并可以让客户了解有 关 的安全问题。这些报告通常是在与客户签订的协议中所要求的。 - 不论对于客户还是服务提供商来说,报告都是很重要的。客户必须正 确 地了解有关努力(如安全措施的实施)所取得的效率以及实际被采 用的 安全措施。 - 客户还需要了解所有的安全事件。 - 为了报告服务级别协议中定义的安全事件,服务提供商必须通过服务级别 管理、事件经理或安全经理与客户代表(可能是公司信息安全官)建立直 接的沟通渠道。 - 除了在特殊情形下的例外事项,报告都是通过服务级别管理进行传达的。

下(338)

与其它流程之间的关系
相关流程: IT客户管理管理 相关流程: 服务级别管理

IT服务财务管理

安全管理

可用性管理 能力管理 IT服务持续性管理 相关流程: 服务级别管理 IT服务财务管理 可用性管理

图15-2 安全管理流程与其它流程之间的关系

能力管理 IT服务持续性管理

下(339)

与其它流程之间的关系(续1)

安全管理与配置管理
在信息安全中,配置管理最为相关的,因 为它对配置项进行分类。这种分类将配置 项与特定的安全措施或程序联系在一起。 对一个配置项所做的分类,表明了其所要 要求的机密性、完整性和可用性。这种分 类是基于服务级别协议中的安全需求。

安全管理与事件管理
事件管理认可所有的安全事件。这 可以确保恰当的程序被触发来处理 安全事件。 任何阻碍服务级别协议中安全性要 求实现的事件都可以归类为安全事 件。任何阻碍实现基本的内部安全 级别(基线)的事件也通常被认定 为安全事件。

下(340)

与其它流程之间的关系(续2)
安全管理与问题管理
一个问题可能引起一种安全风险。在这种 情况下,问题管理在解决该问题时必须联 系安全管理。 针对这个问题或已知错误所制定的解决方 案或应急措施必须经常得到审查,以确保 不会引起新的安全问题。

下(341)

与其它流程之间的关系(续3)
安全管理与变更管理
变更管理与安全管理是相互依赖的。 变更请求中也应当包括一个处理安全问 题的建议。同时该建议的提出应当基于 服务级别协议中所确定的需求以及IT部 门所要求的基本的内容安全级别。 安全经理(也可能是客户方的安全官) 同是也是变更顾问委员会(CAB)的成 员。 任何与一项变更相关的安全措施应该在 变更进行的时候同时实施,并应纳入测 试的范围。

下(342)

与其它流程之间的关系(续4)

安全管理与发布管理
所有新版的软件、硬件和数据通信设备都应该由发布管理进行控制和导入实 际运作环境。 发布管理流程使用正规的验收程序。该验收程序中同时也涉及信息安全方面。 在测试和验收过程中考虑安全问题是特别重要的。这意味着,在服务级别协 议中定义的安全需求和措施在任何时候都应该得到遵循。

下(343)

与其它流程之间的关系(续5)

安全管理与服务级别管理
在服务级别协议中,同样涉及安全措施,其目标是要优化所要提供的服务的 级别。 服务级别管理包括了一些相关的安全活动,在这些活动中,安全管理扮演了 重要的角色。 在制定服务级别协议时,通常假定已经存在一个总体的安全级别(基准), 而客户的额外的安全需求则应当在服务级别协议中进行明确地定义。

下(344)

与其它流程之间的关系(续6)
安全管理与可用性管理
由于安全措施一般对可用性以 及安全方面的机密性和完整性 都具有很好的效益,因此,在 可用性管理、IT服务连续性管 理和安全性管理之间就安全措 施进行有效的协调是非常重要 的。

安全管理与能力管理
能力管理负责按照与客户的约 定最大程度地利用IT资源。对 绩效的要求一般基于服务级别 协议中所定义的定性和定量的 标准。 几乎所有能力管理的活动都会 影响可用性,安全管理也是如 此。

下(345)

与其它流程之间的关系(续7)
安全管理与IT服务连续性管理
IT服务连续性管理负责确保任何意外事件所 造成的影响都被限制在与客户约定的水平 以内。意外事件没有必在演变成灾难。 IT服务连续性管理流程的主要活动是定义、 维护、实施和测试应急计划以及采取预防 措施。由于安全方面的问题,该流程与安 全管理也具有一些联系。从另外一个角度 来看,没有实现基本的安全要求本身就可 被除视为是一次意外事件。

下(346)

关键角色
?安全经理
- 在小型的IT部门内,一个人可能负责管理多个流程。而在大规模 的IT部门内,可能需要多个人一起服务于一个流程的动作,如安 全管理。 - 在这种情况下,通常需要制定一个人作为安全经理。

- 安全经理负责整个安全管理流程的有效动作。他们在客户组织中 的相对人是信息安全官或公司信息安全官。

下(347)

成本、效益和问题
?

成本:
— 确保IT基础架构的安全需要人员和资金来实施、维护和检验各种安全措施。 — 然而,不能确保IT基础架构的安全同样需要付出成本(产量降低的成本,替换有关组 件的成本,对数据、软件或硬件带来的损害,与未能履行合同义务相关的罚金或赔偿 等)。 — 因些,通常需要在这二种成本中找到一个合理的平衡。

?

效益:
— 基于以下二方面的原因,一个具备足够信息安全的有效的信息供应对组织是非常重要 的:
?内部原因---只有当正确和完整的信息在任何需要时都可获得时,组织才可以有 效的运营。信息安全级别必须符合这方面的要求; ?外部原因---组织中的流程通过向市场或社会提供所需的产品和服务来实现其预 定的目标。信息供应不足可能导致产生不合标准的产品和服务,从而不能实现组 织目标甚至威胁组织的生存。足够的信息安全是保证充足的信息供应的一个重要 条件。信息安全的外部意义因此部分地由其内部意义决定了。

- 安全性可以为一个信息系统提供重要的增加值。有效的安全性可以提高组织的持续性 并帮助其实现其目标。

下(348)

成本、效益和问题(续1)
? 问题:
— 承诺:安全措施一般很少被立即接受,抵制比接受更为常见。因此 需要帮出特别的努力来激励用户,并确保管理层也遵循这些安全措施。 — 态度:信息系统不安全不仅仅是因为技术上的弱点,也更是由于不能合理的 使用技术。这通常与员工的态度和行为有关。 — 意识:意识或者说沟通是一个非常关键的概念。实施安全措施需要运用所有 的沟通方式来确保用户遵循安全管理人员期望的行为。 — 检验:安全性应该可以进行检查和验证。 — 并更管理:在评估变更是经常检验对基本安全级别的持续符合是否随时间在 下降。 —缺乏检测系统:新的系统,如互联网,一般都没有安全和非法入侵检测方面 的设计。 —过度依赖于关键/要害控制法:越来越多的安全威胁来自预料之外的地方。

下(349)

关键成功因素和绩效指标
? 关键成功因素: — 来自管理层的完全的承诺和参与; — 在开发流程过程中邀请用户参与其中; — 清晰而又彼此分离的职责划分; ? 关键绩效指标: — 安全管理绩效指标需要与服务级别管理绩效指标保持一 致,从而使这些与安全问题有关的绩效指标能够纳入服 务级别协议中。

下(350)

ITIL认证考试介绍

下(351)

议程
认证主持机构 ?认证体系 ?考试内容 ?样题分析 ?如何报名
?

下(352)

认证机构
ITIL拥有者

itSMF

ITIL推广者

ITIL认证执行机构

下(353)

认证机构

经理认证
事 件 管 理 服 务 台 问


更 管 理

配 置 管

服 务 级 别 管 理

可 用 性 管 理

能 力 管 理

财 务 管 理

安 全 管 理


管 理



ITIL基础认证

下(354)

ITIL认证
认证 ITIL Foudation ITIL Practitioner 描述 基本理解10个服务支持与提供 流程,并理解服务台职能。 培训和考试 2-3天的培训,1小时的 单项选择题考试(目前 有中文版)。

深入理解一个ITIL流程;并已 2-3天的培训,2小时的 经获得基础认证;共分为9项认 基于案例分析的40道单 证。 项选择题(目前无中文 版)。 更加深入的理解所有10个流程 有服务台职能;并已经获得基 础认证;共分为2项认证。 2-3周的培训,3小时的 基于案例分析的论述题 考试(目前无中文版)。

ITIL Service Manager

下(355)

ITIL基础认证考试
? 考试对象: — 基础认证考试面向IT服务管理领域的从业者; — 要获得“IT服务管理从业者认证”和“IT服务管理经理认 证”必须首先通过该认证; ? 考试时间: —1小时 ? 考试要求: —由40道单选题组成 —要求1小时内完成 —及格需要答对26道题(65%)
下(356)

考试内容:考试大纲
? (1)IT服务管理和IT基础架构和重要性: — 考生能够向以下人员说明系统化的手段和方法对IT服务的重要性: · 对IT服务的用户和客户;
· 对IT服务的供应商;

(2)服务管理流程及这些流程之间的相互关系: —指出描述服务管理流程对一个组织的益处; —区分ITIL流程与组织单元; —指出描述ITIL流程所需要的涉及到的关键点; ? (3)ITIL流程及这些流程之间的关系: —流程包括:
?

· 事件管理、问题管理、变更管理、配置管理、发布管理 · 服务级别管理、可用性管理、能力管理、IT服务连续性管理 · IT服务财务管理、安全管理、服务台(职能)

—区分各种ITIL流程的目标、活动以及这些活动的结果; —举例说明各ITIL流程之间的衔接关系。 下(357)

考试内容:基本概念(部分)
会计,核算(Acccounting) 作业成本法(Activity Based Costing) 应用选型(Application Sizing) 资产管理(Asset Management) 资产(Assets) 审计(Audit) 授权(Authorization) 可用性(Availability) 可用性管理(Availability Management) 预算(Budgeting) 业务能力管理(Business Capacity Management) 业务影响分析(Business Impact Analysis) 业务流程(Business Process) 呼叫(Call) 能力数据库(Capacity Database,CDB) 能力管理(Capacity Management) 能力规划(Capacity Planning) 目录(Category) 风险分析与管理法(CRAMM) 集中式服务台(Centralized Service Desk) 变更(Change) 变更审批委员会(Change Advisory Board, CAB) 变更管理(Change Management) 计费(Charging) 配置项级别(CI Level) 分类(Classification) 组件故障影响分析(CFIA) 保密性(Confidentiality) 配置基线(configuration Baseline) 配置项(Configuration item, CI) 配置管理(Configuration Management) 配置管理数据库(Configuration Management Database, CMD) 成本加成(Cost Plus) 客户(Customer) 最终硬件库(Definitive Hardware Store, DHS) 最终软件库(Definitive Software Library, DSL) 需求管理(Demand Management) 。。。。。。

下(358)

考试内容:基本概念(部分)
Service Delvery(《服务提供》) ?Service Support(《服务支持》) ?IT Service Management,an introduction — 全球ITIL基础认证培训标准教材; — 全球销量超过70.000册; — itSMF批准其为国际标准; ?《中国IT服务管理指南》
?

适用于Practitioner和 Manager级

适用于 Foundation 级

你希望阅读原版ITSM图书吗? 不希望,英文图书读起来太累 不希望,看中文资料就够了 希望,国内ITSM方面的中文资料太少 希望,看英文的理解更准确 希望,但是买原版图书太麻烦
33.33% (5) 0.00% (0) 40.00% (6) 26.67% (4) 0.00% (0)

下(359)

样题(1)
―已知错误”(Known Error)与“问题”在ITIL中的不同之 处表 现在哪些方面?
?

—A.导致已知错误的潜在原因是已知的,而导致问题的潜 在原因是未知的 —B.已知错误的与IT基础架构中出现的错误有关,而问题则与其无关 —C.已知错误通常产生于某个事件,而问题则不完全是这样的。 —D.对问题而言,与其有关的配置项已经发现和确认,而与已知错误 有关的配置项通常仍未发现

下(360)

样题(1)答案
?

答案
—A.正确。对问题进行调查以确定导致其出现的潜在原因。一旦发现这 个(些)原因,问题就变成已知错误。 —B.不正确。导致已知错误和问题的原因都可能出现于IT基础架构中, 但这个原因对于已知错误是已经知道的。 —C.不正确。问题总是根据一个或多个已经登记的事件来确定的。 —D.不正确。对问题而言,与其有关的配置项仍未确定。需要对问题进 行进一步调查以找出导致其出现的潜在原因。一旦找到这个(些) 原因,问题就变成了已知错误。

下(361)

样题(2)
?

某个终端用户的个人电脑崩溃。这并不是他的电脑第一次出 现问题。这种情况三个月以前也出现过一次。为此,该用户 户将该问题报告给服务台。请问如何描述这种情况?
—A.一个事件 —B.一个已知错误(Known Error) —C.一个问题 —D.一项变更请求(RFC)

下(362)

样题(2)答案
?

答案
—A.正确。这是一个事件,但这个事件与上一个事件不能被视为有直接 联系,因为后者发生在很早以前。 —B.不正确。这里出现的是一个事件,而不是已知错误。而且,某个故 障重重发生并不一定就表明这是一个已知错误。 —C.不正确。这个报告并没有涉及任何问题。而且,某个故障重复发生 并不一定就表明这是一个问题。 —D.不正确。这里出现的是一个事件,不是变更请求(RFC)

下(363)


相关文章:
ITIL Foundation 考试报名方式
ITIL Foundation 考试报名方式_IT认证_资格考试/认证_教育专区。ITIL Foundation ...考生可以在同一份订单下注册多个考试。在选 中考试科目的时候, 考试的价格就...
ITILV3Foundation-Chinese
ITILV3Foundation-Chinese_IT认证_资格考试/认证_教育专区 暂无评价|0人阅读|0次下载|举报文档 ITILV3Foundation-Chinese_IT认证_资格考试/认证_教育专区。...
ITIL V3 Foundation 2011版中文考试模拟题
ITIL V3 Foundation 2011版中文考试模拟题_IT认证_资格考试/认证_教育专区。ITIL...确保服务可以在设计阶段明确的约束下得到管理的和运营 设计和开发服务管理能力 ...
ITIL+V3+Foundation+考题及答案
ITIL V3 Foundation 培训... 329页 4下载券 ITIL v3 foundation 复习... 26...B 22/40 哪个流程负责监视 IT 服务,并检测何时性能降到了可接受的界限之下?...
ITIL Foundation模拟题-中文分类版
ITIL Foundation模拟题-中文分类版_IT认证_资格考试/认证_教育专区。ITIL Foundation...( A. 确保组件的可靠性(reliability)在确定的时间段内和确定的条件下能满足要...
ITIL认证
凡已取得 ITILFoundation 资格,并具有 4 年以上相关从业经验者,经过培训可以报名...事故管理的目的是在尽可能最小地影响客户和用户业务的情况下使 IT 系统恢复到...
ITIL Foundation管理_其它_教学视频大全
ITIL服务管理被越来越多的企业所重视的时候,ITIL 的认证也是越来越受大家的追捧;在互联网+的浪潮下,我们借助艾威国际网校平台重磅推出了ITIL在线培训,ITIL在线学习...
ITIL Foundation Certificate
ITIL Foundation Certificate_IT/计算机_专业资料。itil v3 foundation introof...ITIL Foundation-下 179页 1下载券 ITIL+V3+Foundation+考题... 7页 免费 ITIL...
ITIL V3 Foundation 中文试卷(7月)
ITIL V3 Foundation 考题及答案(中文) 1/40ITIL 服务管理的实施需要准备和计划好以下方面使用的效率和效果:C a) 人员、流程、合作伙伴、供应商 b) 人员、流程、...
ITIL Version 3 Foundation Sample Examination - from...
ITIL Version 3 Foundation Sample Examination - from APMG ITIL V3 Sample QuestionsITIL V3 Sample Questions隐藏>> Question No: 1 A Service Owner is responsi...
更多相关标签: