准备ITIL考试过程.docx

《准备ITIL考试过程.docx》由会员分享，可在线阅读，更多相关《准备ITIL考试过程.docx（20页珍藏版）》请在三一办公上搜索。

1、准备ITIL考试过程（1）ITSM简单介绍：组织的IT管理应聚焦于业务需求、内部和外部的客户需求，以及以合理的成本对服务质量进行 持续不断的改善。ITSM -目标首要目标是确保IT服务与业务需求保持一致，通过以下几个方面得以实现：1、提供高质量、稳定可靠以及低成本高效益的服务。2、维持良好的IT客户-供应商关系。3、持续改善IT服务的质量。4、有效使用IT服务以满足当前和不断变化的业务需求。ITSM -收益1. 业务收益2. 财务收益3. 创新收益4. 员工收益实施IT服务管理的先决条件IT服务管理战略所定义的IT服务结构应能够动态调整，以适应不断变化的业务需求。组织应该 选择适当的方法以满足

2、客户明确的需求，同时应主动采取措施适应客户需求的变化。在组织中成功实施IT服务管理战略依赖于：1、优良的IT基础设施2、定义明确的组织使命、目标和政策3、胜任服务文化变革的合适人选4、有效的和高效的ITSM流程定义流程流程的目标是什么？愿景和业务目标流程所期望的结果是什么？评估度量流程是否达到期望结果的标志是什么？流程改进流程的输出对其它流程会产生什么影响？度量指标流程的组成部分每个流程都应有清晰的目标，同时包含一系列活动。流程定义了相关的角色来执行相应的职责。流程的角色为了实现目标，每个流程都定义了相关的角色，每个流程的基本角色有：1）流程管理者（OWNER）:流程所有者负责流程的结果和输出

3、，他定义流程中的活动。流 程所有者也负责最终确认流程的实际执行效果是否与期望的结果相符合。2）流程经理（Manager）:流程经理负责规划流程，他控制流程的日常活动和运营。流程经 理也撰写报告帮助流程所有者比较流程的实际执行效果与预期的结果。3）流程操作者（Operatives）:流程操作者负责执行定义好的活动。他们向流程经理汇报。ITIL考试过程（2 ）企业真正的竞争优势是可靠的流程。业务组织逐渐由“用户”过渡到了“客户”。IT服务管理：管理服务以达到客户要求（BSI）。80%的业务中断原因在于人员和流程。引入ITIL需要以下几个步骤：1。进行初始评估。2。选定关键管理和基础架构人员来形成实

4、施关键推动力量。3。对经理和普通员工进行ITIL意识培训。4。实施第一套流程，并辅以对关键管理和基础架构人员进行深度培训和认证。5。评估第一阶段成果。6。实施余下的流程并把充分的知识转移到组织。ITIl考试过程（3）-认识ITILITIL目标ITIL旨在定义各种不同的流程以帮助组织1、识别IT基础设施的不足和冗余。2、度量和确定系统性能的基线。3、使用高效和可控的方式满足组织的IT需求。4、调整组织的战略决策以满足关键业务目标。ITIL考试过程（4）-服务台服务台作为IT服务提供者与用户的单一联系点，接受和处理用户的请求。记录事件，跟踪事件的进展。服务台的构建模式有三种类型：1、集中式服务台：

5、在集中式服务台模式下，所有用户呼叫由一个物理上集中的服务台统一接收 和记录。用户呼叫被区分为技术或业务应用相关的呼叫。根据服务台处理这两类请求的方 式（物 理上单一的一个实体统一处理两类呼叫或集中的两个不同的实体分别对呼叫进行处理），集中式 服务台又进一步被区分为两类：功能集成一集中式服务台：在一个功能集成一集中式服务台环境下，业务运营支持台与集中服务 台合二为一，为用户提供单一的联系点。功能分离一集中式服务台：当IT组织只提供信息系统给用户，但不支持信息系统的运营，该组 织被认为构建了功能分离一集中式服务台。在这种服务台环境下，集中服务台和业务运营支持台 是两个独立的实体。用户对业务应用的服

6、务呼叫可以直接向业务运营支持台寻求迅速和有效的支 持反馈。为了迅速解决用户请求，服务台可以直接联系运营相关的部门，如生产或运营部。服务台和运营 相关部门的连接点被称为运营桥。2、分布式服务台：在分布式服务台结构中，多个服务台分布在不同的地点以支持具有不同文化 背景的本地用户使用。然而，由于多个服务台分布在不同的地点，要管理分布式服务台非常困难。若按与用户的联系点来区分，分布式服务台有三种不同的类型：中心联系点:中心联系点类型的分布式服务台由一个中心联系点接收所有用户的呼叫请求，然后 将这些请求分配给合适的本地服务台进行处理。中心联系点也记录用户报告的事件（任何不符合 标准操作且引起或可能引起服

7、务中断和服务质量下降的事件。）。本地联系点：本地联系点（LPC，Local Point of Contact）从特定的本地用户处接收请求和抱怨。不 同的LPC处理各自的用户呼叫请求。所有LPC与一个中心联系点进行交互，中心联系点负责汇 总事件信息。LPCs具有以下功能：用本地化的语言服务本地用户作为成本中心分摊IT支持成本呼叫中心：呼叫中心式的分布式服务台为用户提供一个中心电话号码（如I860）来响应用户的 呼叫请求。当用户向呼叫中心提交呼叫请求时，语音菜单启动，菜单让用户选择特定的服务。基 于用户的请求，呼叫自动流转到特定的支持团队。3、虚拟服务台：虚拟式服务台利用远程通讯技术整合分布各地的

8、服务台网络。如，整合遍布世 界不同时区的服务台能为用户提供24小时的服务。由于各地服务台相互交错，功能就像一个单 一实体，用户并不知道服务台的具体位置。但是，这种服务台模式不能为用户提供现场支持服务。服务台员工执行下列活动：1、响应用户呼叫2、通知用户信息3、与供应商沟通4、执行运营管理任务5、监控ICT基础设施服务台可以分为以下类别：A、呼叫中心服务台B、非技能型或呼叫记录型服务台C、技能型或问题解决型服务台D、专家型服务台运营服务台经常碰到的瓶颈A、IT组织缺乏对业务需求的全面理解（服务台人员应以组织业务需求为导向）B、对服务台的培训投资不足（服务台人员应该接收所需的培训，以便解决可能的用

9、户服务请 求）C、不现实的服务级别（为了最小化用户的抱怨，组织应该将可用的资源与客户的需求和服务 级别联系起来）D、没有充分理解服务台的重要性（用户和客户应该清楚服务台的重要性）关键绩效指标服务台的关键绩效指标（KPIs）是：-每一呼叫的平均应答时间。-解决事件所花费的平均时间。-服务台一线解决事件的百分比。-每个服务台员工处理的呼叫数。-服务台接听的所有呼叫数。关键成功因素以下关键成功因素（CSFs）有助于提高服务台的绩效：-用户应能方便访问服务台以解决他们的问题-应鼓励用户将服务台作为单一联系点记录和解决碰到的所有事件-不鼓励用户绕过服务台-结合服务级别协议（SLAs）和服务目录，让用户全

10、面了解服务台的职能ITIL考试过程（5）-事件管理事件管理（Incident Management）流程扮演尽快解决事件和恢复正常服务的重要角色。事件可以分为技术升级和管理升级。基础设施各组件被报告的事件作为事件管理流程的输入。事件管理流程的输出包括有关事件的信 息和与其他流程相关的解决方案的信息。事件经理的职责1）事件经理准备流程报告，详细阐述事件管理流程的绩效和趋势分析。2) 事件经理组织事件管理流程执行中需要的管理信息。例如，收集所需的资源信息，以及 事件管理与其他流程之间的联系等。3) 事件经理推荐改进事件管理流程的方法。4) 事件经理开发和维护事件管理系统。5) 事件经理负责监督事件

11、支持团队的工作效率。可能的瓶颈1) 用户绕过事件管理的程序：如果用户没接收该流程的培训，他们可能不遵循正确的程序， 而是自己试图去解决错误。结果，事件记录不能准确的更新。2) 事件超负荷：没有至事件进行清楚归类、没有正确分配和转送事件，这两种情况，事件 可能超负荷3) 事件升级的增加：如果支持团队不具备适当的技能和资源，事件可能迅谏升级至1|更高级 别的支持团队。这将给专家支持团队增加不必要的工作量。4) 服务级别协议没有清楚定义：如果事件管理流程支持的服务没有在服务级别协议中清楚 地定义，事件管理人员不知道哪些报告的错误和需求可以作为事件。5) 组织蛙化的变更组织中实施事件管理流程需要以流程

12、为导向。结果，更多的任务、 责任和更严格的纪律要求可能超出员工的预料，一些人就会产生抵触情绪。关键的成功因素事件管理流程关键的成功因素是：-时常更新配置管理数据库(CMDB)，这是评估事件影响度和紧迫性所必须的-一个知识库，它用于记录事件、事件解决方案或临时措施-一个自动化系统，它是记录、跟踪和监测事件所必须的-与服务级别管理紧密联系，确保事件具有恰当的优先级和解决周期关键绩效指标事件管理流程的关键绩效指标(KPIs )包括记录事件的数量解决优先和非优先事件的平均时间在SLAs规定的事件解决周期内，服务台解决事件的数量一线支持解决事件百分比解决每个事件平均花费的成本支持团队非现场解决事件的数量

13、ITIl考试过程(6)-问题管理1) 知名错误(Known errors)是那些被成功诊断并知道根本原因的问题。特别地，这些错误已被 确认了一个临时性或永久性的解决方案。2) 临时措施(Workarounds)是为解决事件的临时性的替代方法或技术。它被用来消除用户对某 种已知有问题的服务的依赖性。使用临时措施后，用户可以继续使用服务而不被中断。3) 被动问题管理(Reactive Problem Management)确认事件的根本原因。根据这些原因提出永久 性解决方案防止事件再次发生。4) 主动问题管理(Proactive Problem Management)活动目的是在事件发生之前阻止它

14、们发生。此 活动协助鉴别IT基础设施中的缺陷并提出消除这些缺陷的方法。问题控制的阶段可分为：1) 鉴别和记录问题，并分析历史趋势题鉴别阶段2) 根据对业务的影响将问题进行分类3) 调查和诊断问题 错误控制阶段包括：1) 错误鉴别和记录：错误控制的第一个阶段是确认问题的原因。一旦问题原因被确认，那么 相关的CI就可以被看作是一个知名错误。2) 错误评价:问题管理小组评估错误解决方法。小组比较各种不同的解决方案，在比较时需 要考虑多种因素，比如服务级别协议(SLA)、成本和利润等。如果小组认为某个变更请求可 以解决错误，那么他们会根据变更管理的流程提交变更请求(RFC)。3) 记录错误解决方案，提

15、交变更请求:此阶段包括记录每个知名错误的解决方案。在知名错 误数据库中记录关于所有知名错误的CIs、症状、解决方案或临时措施是非常重要的。这些 信息对以后的事件调查、事件匹配非常有用。4) 错误终止：记录错误解决方案之后，相关的知名错误记录就被终止。问题管理小组进行实 施后评审(PIR)以确认终止前的解决方案的效果。对于事件来说，这可能是给用户打个电话 询问客户对解决方案是否满意。对更为严重的问题则需要一个正式的评估。5) 监测问题/错误的解决方案(持续性的活动)：该活动协助问题管理小组监控问题的进展以 及在问题控制和错误控制的所有环节监控问题和知名错误的解决情况。角色为确保问题管理流程的有效

16、和顺利进行，清晰定义其中的角色是非常有必要的。问题管理流程中，下面的角色执行流程中的活动：-负责管理整个问题管理流程的问题经理：问题经理负责问题管理中的所有活动，如1、开发和维护问题控制和错误控制流程。2、评估问题控制和错误控制活动的效果。3、为管理层提供与问题相关的信息。4、管理问题支持人员。5、为各项支持活动分配资源。6、评估主动问题管理的效果。协助问题经理的支持组成员：有两个职责A、被动职责，包括1、通过分析事件的详细情况识别和记录问题。1、根据问题的优先级调查研究问题。2、提交变更请求消除错误。3、监控知名错误的解决方案。5、为事件管理小组提供临时措施和快速修复的建议B、主动职责。包括

17、1、确认问题的趋势和潜在根源。2、提交变更请求防止问题再次发生。3、防止问题在多个系统中复制。下面的瓶颈可能阻止有效执行问题管理流程1、事件管理和问题管理流程间缺乏联系：事件记录应该与问题记录紧密联系。如果事件管理小 组不能正确地记录事件和相关IT组件的详细信息，那么问题管理小组也就不能准确地对问题进 行分类。因此，有效的事件控制流程中形成的事件详细历史数据对正确地识别问题非常重要。2、开发环境与实际运行环境中的知名错误间缺乏联系：从开发环境到实际运行环境的软件应用 系统应伴有知名错误的详细记录信息。如果问题管理流程对这些知名错误信息了解不够，那么问 题管理流程需要重新定义这些错误，从而造成了

18、重复性劳动。3、缺乏管理层承诺：如果缺乏管理层的承诺，问题管理的支持人员可能会忽视问题管理流程中 潜在的主动解决问题方面的努力。如果IT基础设施中潜在的问题没有提前被检测和清除，那么 将来事件的发生率就会上升。关键绩效指标问题管理流程的效果可以通过关键绩效指标(KPIs)进行评估。一个有效的问题管理流程的 关键绩效指标包括以下几方面：-解决问题前后事件发生的数量-解决问题花费的时间-解决问题过程中发生的成本(人力、物力资源等)关键成功因素问题管理流程执行的效果依赖于：-自动化事件记录和分类：人工注册和分类事件记录的方法不仅速度慢而且容易出现错误。日 益复杂的技术环境要求一个有效的自动化事件注册

19、流程。这样不仅可以节省时间和资源，而 且加快了服务交付的处理过程和提高了服务质量。-制 定切实可行的目标并充分利用人员的专业技能：为问题管理制定一个可行的目标和最大 限度地利用人员的技能是成功执行问题管理流程的关键所在。一些组织采用“ 兼职人员”的 问题管理流程策略，这种策略下人员只能投入一半的精力。在问题管理流程中最大程度地激 发员工的积极性以减少IT服务的中断，对组织来说非常必要。-事件管理流程和问题管理流程之间有效协调：事件管理流程和问题管理流程之间存在潜在 的冲突。前者“被动”处理事件，并以尽快解决事件为目的；而后者以“主动 控制”为目标， 通过细致分析来消除问题的根本原因，避免事件的

20、再次发生。因此，两个流程需要很好的协 调以确保有效地解决事件和问题，预防问题和事件的发生。ITIL考试过程(7)-配置管理配置项的特征：配置是服务交付所需的、唯一可识别的、可变的、可管理的。包括，所属分类、 关系、属性、状态。配置基线：配置管理小组可以在某一时间点冻结一组CI，以记录某一 IT产品或系统的原始结构 和细节信息。这些信息对以后重新构建产品和信息非常有用。由于这组 CI是固定的，所以他们 的特征也是固定的，而这些冻结CI的信息副本被称为配置基线。配置管理流程的几个主要活动，包括：1) 设计配置管理流程2) 识别CI：3) 状态监测4) 控制5) 验证和审计6) 生成报告配置经理的职

21、责包括：1) 建议配置管理的范围2) 计划和实施配置数据库(CMDB)3) 评估现存的和执行中的配置管理系统4) 开发CI识别系统和确定配置项(CIs)的命名规范5) 开发和其他流程的接口6) 审计和生成报告7) 流程交流和指导培训。在实施过和中需要注意的瓶颈有 详细程度：维护层次较深的(数据详细)的配置管理数据库(CMDB)需要大量的工作。 在CMDB中可能需要记录大量的细节数据，如属性、CI之间的关系等。另一方面，若 CMDB中数据的层次较浅，则记录的信息太少，可能会不够用。为了能够达到有效的配 置管理，必须为相关的记录设计最优的信息深度。 手动系统：一些组织采用纸张的形式记录信息，以为这

22、样就可以不用购买昂贵的、自动 化的工具来维护CMDB 了。手工处理会导致延误和混乱，而且消耗组织的资源。理想 状况是，一开始就选用自动化的解决方案以保证组织的效率。 紧急变更：有时候，CI的紧急变更(Urgent Changes)没有遵照严格的标准变更流程执行。 如果紧急变更之后，CMDB没有进行相应的更新，将会导致一系列的问题。例如CMDB 中存储的数据不够准确。远大的计划：如果变更和发布计划没有为实施配置管理流程留 出时间，将会延误进度。过于雄心的计划可能使配置管理流程看起来像是瓶颈。 不现实的期忘：有时管理层不切实际地期望配置管理工具能够提供全面的解决方案。只 有当配置管理流程的目标可实

23、现的前提下，该流程才可能发挥作用。另外好的项目管理 和对所有CI进行全面的验收测试对配置管理流程来说非常重要。 缺乏管理层的承诺：对有效地进行配置管理流程来说，管理层的承诺是必需的。让配置 管理流程的执行者和使用者充分认识到如果流程的实施是不完全和无法控制的会带来 什么影响，这非常重要。 繁琐的流程：一些组织认为配置管理流程太过官僚和死板，因为每一个变动都需要在 CMDB中作记录。个别人和团队可能借此作为不执行流程全部活动的借口。然而，这套 流程的成功就取决于这种“死板”的机制。 孤立的实施：缺乏充分地分析和设计将导致配置管理流程孤立地实施，缺乏与其他ITIL 流程的接口。而这将对CMDB的更

24、新带来麻烦。如果配置管理流程被孤立地实施，我 们将很难从CMDB中获取准确的配置信息。 呆板的工具：支持配置管理流程的工具必须足够灵活，能够支持新的需求和所有的 CI 分类。这些工具还应该能对事件进行关联和记录问题。这些工具的有效性决定了配置管 理流程的有效性。关键绩效指标(KPIs)为了评估配置管理流程的有效性，你需要设定评估指标和测量目标，并定期对这些指标进行评估 以分析趋势。配置管理流程的关键绩效指标(KPIs)与以下因素相关：-CI (配置项)和CMDB (配置管理数据库)-服务台-其他ITIL流程与CI和CDMB相关的KPIs有：-发现未被授权的“配置”的次数-由于CMDB中信息的不

25、完整，被拒绝的RFCs的数量（RFCs：用于记录变更请求的书面或 电子表格。这种变更请求是针对基础设施的配置项及与基础设施相关的规程和项目的变更。）-对CMDB中发现的错误实施变更的次数-检测发现正在使用的未被授权的IT组件与服务台相关的KPI:-每个月接到电话的数量和立即解决问题的电话数量比率的变化-服务台诊断和解决问题的平均时间和成本的变化与其他ITIL流程相关的KPI有：-出现的事件和问题数量和严重程度的变化-能追溯事件和问题产生的原因是不正确的变更所导致的数量-接收和执行变更的周期-违背服务级别协议（SLA）时，事件发生的数量和严重程度的变化-被浪费和未被正确使用的许可证（Licens

26、es）的数量-在审计时发现记录和实际情况不符的数量关键成功因素 确定清晰的流程目标 确保流程各个阶段的顺利实施 在引入流程之前删除现有记录以防数据冗余和错误 确保配置管理团队拥有必需的技术和能力 与变更管理流程紧密配合，以保证CMDB中信息的精确性ITIL考试过程（8）-变更管理在实施变更之前，需要平衡变更对业务的影响和变更所带来的收益，变更对业务的负面冲击可能 影响业务的持续性。变更管理流程的范围仅仅包含IT基础设施的变更。应用系统开发、组件选 择以及已变更或新的组件版本的发布超出了变更管理流程的范围。变更管理流程的目的在于实施 IT基础设施的变更，同时最小化变更造成的业务中断。从各个流程接

27、受的变更请求（RFCs）作为 变更管理流程的输入。这些RFCs由变更管理的活动进行处理。最后，接受的变更请求作为变更 通过发布管理流程来实施。变更的步骤：记录-接受-分类-计划-协调实施（在实施变更前，应告知所有受影响的人员和部门）-评估变更经理-职责1）筛选、接受和分类所有的变更请求2）为变更获得所需的授权3）计划和协调变更的实施4）评审所有已实施的变更，确保达到预期目标5）为所有紧急变更请求和关闭变更请求如开CAB会议6）通过服务台发布变更实施进度表7）提交规范、准确的变更报告 变更顾问委员会成员组成（变更顾问委员会成员的构成与变更请求所要达到的目的相关。例如， 安装新软件的变更请求与构建

28、一个新的流程的变更请求，在组建变更顾问委员会成员时应有所区 别。） 受变更影响的客户 服务级别管理、服务台及问题管理流程的代表 应用开发团队 软件和系统用户CAB成员的职责 出席所有CAB会议 参与变更进度表的制订 评审所有的RFC请求，估计它们的影响、所需的资源和成本瓶颈当实施变更管理流程时，下面的瓶颈可能发生：-官僚主义：官僚主义将导致变更管理流程：A冗长的活动；B繁重的文档工作。变更管理流程若全部采用手工的方式进行，则非常耗时耗力。 为了解决这一问题，组织需要自动化该流程的执行。-频繁的紧急变更：紧急变更具有最高优先级，需要立即实施。与此同时，由于时间紧急，某些 活动被忽略，这可能导致错

29、误的发生。为了避免变更实施失败，应尽量避免频繁的紧急变更，同 时应引进相对简单和灵活的变更流程。-与配置管理缺乏协调：变更管理和配置管理流程缺乏协调会导致对变更的影响分析不准确。为 了评估这些影响，变更管理团队需要与配置管理流程协调检查配置管理数据库中配置项的状态。-角色定义不清楚：假如在变更实施中所涉及人员的职责定义不清，变更流程就不能正确实施。 定义明晰的角色和职责对实施任何变更非常重要。-变更范围太广：变更管理是用来控制IT基础设施中的所有变更，因此变更管理范围容易变得 很广泛，导致管理变更非常困难。为了缩减变更管理的范围，在变更管理中需要排除那些具有清 楚定义和具有常规执行程序的常规（

30、标准）变更。例如，用磁带驱动器进行备份是一个常规流程 不需要变更管理流程进行控制。关键绩效指示通过下面的关键绩效指标度量变更管理流程的效果1、在特定时期内，实施与某一 CI相关的变更的数量2、成功执行的变更数量3、不成功的变更数量4、变更回滚（back-out）的数量下面的关键绩效指标有助于你确定变更的影响1、通过变更实施所解决事件的数量2、变更成功实施后工作量的减少3、实施一个变更的平均时间4、实施变更的平均成本在评估关键绩效指标时，你需要考虑RFC相关的指标1、RFC的数量及其对配置项的影响2、被拒绝的RFC的数量3、因实施变更而发生的事件数量管理报告在绩效指标中可以创建报告分析趋势，报告

31、详细程度依赖于阅读报告的管理者级别。级别高的管 理者可能需要月报和季报，中等级别的管理者需要详细的周报。下面的关键成功因素促进变更管理管理流程的功能高效发挥：1、变更管理流程系统化2、对变更进行全面的评估和测试3、IT员工和供应商良好的沟通4、与配置管理紧密配合ITIL考试过程(9)-发布管理发布可分为：A、紧急修复：(emergency fix)通常包括少量对已知错误的更正和快速实施的解决方案。B、小规模的软件发布和硬件升级：包括一定数量的改进和对已知错误的更正。C、大规模的发布：一个大规模的发布一般是新的软硬件的首次发布或者是对现有构架的功能做 出重大改进。发布类型：A、Delta发布：当

32、发布仅含有少量变更时，你就可以应用Delta发布。B、全发布：全发布通常是指发布一套完整的程序，包括那些没有变更的部分。C、包发布：当要发布一组软件的时候，包发布将是一个不错的选择。ITIL考试过程(10)-服务级别管理服务级别管理流程能够帮助IT组织在客户要求的质量和IT组织提供的质量之间通过协商达到平 衡。服务级别管理流程帮助IT组织：1) 基于客户需求设计IT服务2) 为IT服务提供可度量的绩效指标3) 平衡服务质量和成本4) 缩减长期成本5) 改善客户关系需要注意的名词解释： 提供者、客户与用户：一般说来，提供IT服务的组织被称为服务提供者，享受IT服务 的组织称为客户。 服务级别需求

33、（SLR） 服务清单：服务清单是在明确客户需求后准备的。它把客户的服务需求（外部清单） 翻译”成IT组织所需的技术清单（内部清单），以便于实施。 服务目录 服务级别协议（SLA） 运营级别管理（OLA）: IT组织为了给客户提供IT服务，有时需要其他内部IT部门为 其提供服务，所以IT组织和内部IT部门需要草拟一个协议。 支持合同（UC）：当IT服务要素需要得到外部服务提供商的支持，这时IT组织需要与 外部服务提供商签订支持合同（UC）。UC类似于OLA，但是它用于与外部服务提供商之 间的服务协议。 服务改进计划（SIP） 服务质量计划（SQP） 服务质量计划（SQP）详细描述了如何交付每项服

34、务，以及定义了度量每项服务的绩效指 标。服务级别管理流程的目的是平衡IT服务的质量和客户期望的质量。服务级别管理流程有三个目的：1、整合提供IT服务需要的所有要素。2、用清晰的，文档化方式描述服务的构成。3、用客户能理解的术语提供服务清单。理谑授岫服务级别经理负责-制订与更新服务目录，该目录要详细描述现有的IT服务-确保服务级别管理流程有效，通过定义：SLA，OLA，UCs-更新存在的SIP-更新已有的SLAs、OLA和UC-评审并改善IT组织绩效以满足协定的服务级别。瓶颈阻碍服务管理有效实施的瓶颈可能有1、IT组织所需的文化的变革IT组织的员工必须意识到，要提供IT服务，理解客户需求非常重要

35、。这也许需要IT组织内的 文化变革，当然变革会碰到一些阻力。一个可行的解决方法是服务级别经理与所有涉及该流程的 员工对服务级别管理流程的优点进行沟通。这能使员工相信并接受流程带来的变化。2、客户不能清晰地表达他们的需求一般而言，客户对他们从服务中获得什么只有一种模糊的认识。他们往往不能清晰地表述服务的 特征。这样，服务级别经理要准确确定SLR就很困难。解决该问题的一个方法是：服务级别经 理在准备SLR之前，对客户的需求进行深入的理解。与客户进行充分的沟通并让客户对形成文 档的需求进行确认，这样客户就能够有一个清楚的期望而不至于认识模糊。3、在量化客户期望方面存在如果服务级别没有量化的话，就很难

36、监控其绩效。服务级别经理经常遇到不能把客户所有需求转 化为可量化指标的困难。这往往是因为在SLR中确定的需求看起来很模糊。解决方法：在SLR 中，客户的需求以可量化的方式定义非常重要。客户对他们需求进行赞同和确认，对制定 SLR 特别重要4、和客户达成不切实际的协议有时，服务级别经理受到来自客户、上级或者同行的压力，屈就达到不可行的服务级别。因此， 可能形成不切实际的SLA。这些就会导致服务级别管理流程无效，因为无法达到不切实际的服 务级别，最终也会导致客户的期望得不到满足。解决方法：任命一个经验丰富的服务级别经理非 常重要。他应该让客户与上级相信并且坚持以现实的服务级别作为他们的目标。5、低

37、估了监控与评审服务级别的间接成本当起草SLA时，要估计间接成本（管理成本）非常困难。这将导致IT组织低估在实施服务级别 管理流程中发生的间接成本。解决方法：如果服务级别经理经验比较丰富，并且有该流程的大量 数据，那么他就能准确推断出流程中的间接成本，从而避免成本低估。6、不能一贯地执行服务级别管理流程有时，由于没有时间或者对流程了解不足，高级管理者也许会跳过某些服务级别流程活动。例如， 为了匆忙和客户签订协议，IT组织没有详细理解所有隐含的需求，这样就不能准确地起草SLR。 于是很可能导致服务级别管理流程整体目标不能实现。关键绩效指标 在SLA中对服务级别的量化程度 定义OLA和UC的清晰程度

38、 监控SLA元素的数量 破坏SLA的数量 满足SLA的数量 与协定的服务级别的差距和随后采取的改善措施的效果关键成功因素要成功实施服务级别管理流程，以下因素值得借鉴：-服务级别经理具有丰富的技术与业务知识-准确描述服务级别管理流程的使命与目标-IT组织员工深入理解服务级别管理流程-清晰定义服务级别管理流程的角色与其职责ITIL考试过程（11）-可用性管理 可用性管理的首要目标是确保IT服务组织给客户提供协定的服务可用性级别。另外，服务可用 性应该成本合理，且能实现客户的业务目标。A、平均修复时间-MTTR -指的是在检测故障（检测时间）与解决故障（处理时间）的 时间总和。因而，MTTR是故障发

39、生到服务恢复这段时间的平均值。MTTR指出了系 统的宕机时间。B、平均无故障时间-MTBF-指的是故障解决到下一个故障（或者事故）产生时这段时间 的平均值。MTBF衡量了服务的可靠性并指出了系统的运行时间。C、平均系统事件间隔时间-MTBSI -指的是两次相联的故障发生相隔时间的平均值，因 此它是 MTTR与 MTBF之和。可用性经理职责1、根据时间、成本与交付要求来管理可用性流程2、确保交付的IT服务符合协定的服务级别3、对IT基础设施进行优化，为客户降低成本4、对IT服务响应时间进行监控，并报告给客户5、制定一个前瞻性的可用性计划，来平衡未来可用性管理的需要可用性经理的其它职责1、提高IT

40、组织的可用性管理意识与理解2、根据成本与交付情况，审计与评估可用性管理流程中每个活动3、决定为客户提供新的还是改善的IT服务以满足可用性要求4、制定可用性与恢复计划以改善IT基础设施设计可用性经理的关键技能1、对新IT技术的出现及可用性有很好的理解2、丰富的可用性管理活动经验与技能3、良好的书面、口头等直接沟通能力4、掌握统计、分析及成本管理的基本原则ITIL考试过程（11）-能力管理能力管理流程的目标是维持以下的平衡A、成本和能力：能力的成本应与能力的效用保持平衡。B、供应与需求：可供使用的处理能力应与当前和将来的客户需求保持平衡 实施能力管理流程可以为组织带来以下的好处：A、降低与现有服务

41、相关的风险或新建服务可能带来的风险。B、精确预测将来的需求情况。C、平衡IT资源的供求状况来提高资源的利用率。D、减少与能力相关的费用支出。资源能力管理侧重于技术而服务能力管理偏重于IT服务的提供。能力经理负责监控能力管理流程中的各项活动。系统、网络与应用经理负责监控IT服务的性能。瓶颈在实施能力管理流程的过程中可能出现以下瓶颈：A、开发人员、管理人员和客户的期望值过高往往开发人员、管理人员和客户对能力管理流程的期望都很高，这些期望是由以下因素引起的：1、对应用系统、计算机系统和网络系统的技术可行性理解有限，解决方法：能力管理流程应帮 助开发人员理解他们的设计对能力和性能产生的影响；2、对系统

42、调整估计不合理。解决方法：调整只能在一定程度上提高系统的性能。设计不完善的 应用系统也可能无法通过调整提高性能，在这种情况下，实施一项新的应用反而是更好更有效的 选择。3、对工作负荷安排估计不合理。解决方法：能力管理流程应当辅助实施内置的算法，而非通过 系统工程师的干预来估计工作负荷安排。B、制定能力计划缺乏足够的信息缺乏制作能力计划所需要的信息是由于：1、无法可靠地估算工作负荷；2、不了解客户详细的客户计划。为了解决这个问题，需要借助数学模型（如：建模工具）进行 模拟。当获得更多的信息后，也需要更新这个模型。C、供应商输入的信息不充分或不准确当购买基于最新技术的新系统时，里面可能没有任何历史

43、数据，管理人员不得不依靠供应商输入 的初始数据。然而供应商输入的初始信息不一定符合组织的实际情况，因为供应商可能使用：1、 不同的基线；2、不同的测试方法。这些都可能对度量系统的实际性能产生误导。为了解决这个 问题，在实际环境中实施这个系统之前，能力管理流程应先在组织的测试环境中测试这个系统。D、复杂环境由于组件之间存在大量的依赖关系，在复杂的技术环境下实施能力管理流程可能十分困难。为了 解决这个问题，组件之间的依赖关系应在配置管理数据库（CMDB）中详细陈述，这些信息将帮助 能力管理团队高效地更新能力数据库，并及时估计今后的需求。E、无法确定适当的监控水平确定适当的监控级别与计算机系统管理和

44、网络管理都有关系，如果几个部门共同负责管理这些资 源，那么围绕职责可能会发生冲突。因此，必须清楚地定义监控的级别。关键绩效指标以下关键绩效指标帮助评估能力管理流程的有效性1、通过能力管理流程估计到所有IT服务的性能趋势2、紧急购买次数的减少量3、不必要的昂贵超需求能力的减少量4、由于性能问题导致的事件减少量关键成功因素A、准确有业务预测B、对当前和将来的技术有正确的了解C、与其它ITIL流程保持紧密的相互关系D、能够计划和实施适当的IT基础设施来满足预期的业务需求ITIL考试过程（12）-服务持续性管理瓶颈可能阻碍ITSCM流程有效实施的瓶颈:1、管理层和员工的态度：为了成功实施流程，员工必须

45、意识到ITSCM流程的重要性。管 理层和流程的实施者必须参与流程实施的全过程。同时，IT部门必须与管理部门交流 计划的实施。初始化之后，也必须定期对恢复计划进行测试与更新。为了改善员工和管 理层的态度，必须对人员进行培训并且明确他们的责任。2、对流程的支持和资源不足：资源的短缺，如人员、计算机等，可能阻碍恢复计划的制 定和测试。组织必须确保提供所需的资源，同时组织必须预算流程的开支，分配足够的 资金。3、实施没有计划，测试的频率不够：如果在流程实施之前没有进行充分的调研，就不可 能达到预期的效果，组织的信誉可能受到损害，从而造成不可估量的财务损失，所 以 必须及时消除可能造成损失的因素。同时，

46、业务管理者对流程应有现实可行的预期，而 不应期望在流程实施之后就立即能够化解所有的风险。测试恢复计划的可行性同样非 常重要。关键绩效指标以下是评估ITSCM流程绩效的主要标准：恢复计划的缺陷数量假如没有执行恢复计划，公司业务的损失量灾难发生后，公司恢复IT服务所需要的时间、资源和资金关键成功因素ITSCM的关键成功因素有： 团队相互协作完成制定和执行恢复计划 有效地安装备份工具，用于恢复从灾难点到恢复点的关键业务信息，如磁带、CD等 配置管理流程的有效实施 执行恢复计划的相关培训 不定期对恢复计划进行测试ITIL考试过程（13）-安全管理安全管理流程通过防止信息未经授权的访问，来确保数据安全。安全管理流程的目标是遵守服务级别协议的安全要求满足合同、法律和政策中未定义的外部要求为信息系统提供安全基线（独立于外部要求）确保战略层、战术层和运营层都采取有效的安全措施 *信息安全保护信息免于入侵和非法访问等风险，确保组织的信息安全。信息安全管理 流程就是保护机密信息免遭未经授权访问