ITIL培训课件

2016/4/13 训讲义 欢 迎 欢迎参加本次 训！ 非常荣幸有机会与各位一道分享国际 佳实践”！ 友情提示 请将您的手机声音调至最低或设为振动！ 上课时间： 上午： 9:150 下午： 1:300 上课过程中，如有问题，可随时举手提出； 本讲义仅供参加培训者个人使用，不得外传； 请勿进行课堂录音； 课程目标 准确理解 务质量、服务管理、 清晰描述 全面掌握 掌握 获得参加 学会如何利用 通过培训，使培训对象了解主流服务支持系统的相关知识，提高其操作水平、操作能力。 自我介绍 您个人的基本情况？（姓名、工作经验、工作单位等） 您当前对 您对本课程有什么期望？ 2016/4/13 现 实 20的原因是技术方面的， 80的原因是管理方面的 调查发现（一） ：导致服务器、网络和应用出现故障的十大原因： 病毒攻击（ 缺乏有效的监控制度和手段（ 应用系统 /数据库本身存在 员工缺少技能培训（ 维护不及时或缺乏有计划的维护（ 缺少总体规划 /重复建设（ 不同部门的 缺少运营管理方法论的指导（ 员工不按规定 /流程操作（ 20% 技术 40% 操作错误 40% 应用故障 对 策 调查发现（二） ：减少基础设施故障最有效的措施： 推行流程管理 （ 实行统一的安全管理与控制 （ 争取公司高层领导的重视和支持（ 对员工进行有针对性的培训（ ） 定期分析系统和网络的性能（ ） 进行集中式管理 （ 进行冗余备份和灾备（ 加强对用户的培训和教育 （ 设立统一的 使用网络、系统或数据库监控系统（ 管理的问题还是需要用管理的手段来解决！ & 服务的层次和定位 术管理 网络 服务器 数据库 主机 桌面 系统 应用 其它 服务管理 业务管理 安全管理 运营管理 外包管理 其他 需求管理 项目组合管理 项目 1 项目 3 项目 2 项目 4 客 户 用 户 5 5 服务提供者 安 全 存储 & 备份 面向项目的管理和面向服务的管理 备 件 我们的解决方案？ n. “支离”的 1 通过流程进行整合： 2 如何实现流程管理？ 3 4 含义 一个领域 , 它将 进行有效而合理的整合，以提供高质量的 文化 1 组织结构 2 流程 3 工具 4 融合了系统管理、网络管理、系统开发管理等管理活动以及变更管理、资产管理、问题管理等许多流程理论和实践。 客户为中心的方法。它通过整合 高了企业的 传统的 转 变 术导向 流程导向 “救火队” “保健医” 被动 主动 用户 客户 集中式，企业自己完成 分布式，外包 孤立的，分散的 集成的，企业范围 内的 “一次性的”，混乱的 可重复的 , 职责明确的 非正式的流程 正式的最佳实践 从 从业务的角度考虑 具体的运营 面向服务的 管是企业内部的还是外部的，都是 主要工作就是提供低成本、高质量的 买 用户（使用 加以判断。 与传统的 是一种以服务为中心的 大目标” ： 以客户为中心 1 高质量、低成本的服务 3 服务可计量 2 “范围” S. 不是企业的业务管理； 前者面向 者面向业务管理。 S. 不是 S. 技术管理 有关 “ 支持服务真的就能满足我们所有的需求吗？一些 我们当小孩哄。服务价格完全由它们说了算。 ” 中国化工信息中心副主任李中 规范化 规模化 “ 牵涉到核心业务， 没有安全保障？定价怎样算合理？ ” 协和医科大学肿瘤医院计算机室主任李怀成 在规定的时间，完成规定的任务！ 1 2 通过调查，我们看到：只有 大型企业选择将后台系统外包给第三方； 大型企业将前后台全部外包给第三方。 2003年度中国大型企业信息化调查报告 “ 双 规 ” 像制造产品一样生产服务 输入 输出 服务 成本 流程（ 工厂生产车间 传统 基于 统一规格原材料 硬件 90%,软件 50%,人 20% 硬件 90%,软件 80%,人 50% 标准生产工艺 基本上没有 准制造流程 基本上没有 量可测量的产品 基本上没有 如何实现 务管理 人 ( 流 程( 技 术 ( 工具！ 用户 客户 应用管理 服务级别管理 能力管理 可用性管理 配置管理 变更管理 安全管理 事件管理 问题管理 服务台 网络管理 务支持 服务提供 发布管理 70s 80s 90s 系统管理 网络管理 分布式应用管理 务管理的普及程度 00 01 02 03 04 年 05 50% 100% 25% 75% 数据来源 : 2001 市场成长率 : 32% 30% 26% ） 15万 人获得 2000家公司加入 15个 国家成立 10万 册 100种 80 的 财富 500强企业实施过 1999年进入中国 目前处于推广阶段 力推广 实施 上海证交所、国家统计局 中国移动、中国联通 中国银联、中国工商银行 汇丰银行、交通银行 太平洋保险、海关总署 2016/4/13 什么？ : 英国商务办公室从 20世纪 80年代开始开发的一套 已成为事实上的行业标准，并以其为中心在全球形成了完整的产业； 任何单位和个人都可免费使用的 “ 公共框架 ” ； 实际上是一系列由所谓 “ 最佳实践 ” （ 成的图书： 是 : 硬 件 软 件 一个可以直接使用的标准 目标 建立一系列完全的、一致的、连贯的最佳实践规范，以提高 推动采用 鼓励私营机构开发相关服务和产品（培训、咨询及工具）以支持 技 术 服务管理 服务支持 业 务 业 务 管 理 应用管理 础 架 构 管 理 架 服务提供 安全管理 1） 业务管理（ 在提供 先应该考虑业务需求，根据业务需求来确定 业务管理模块指导业务管理者以自己习惯的思维模式： 分析 了解 了解 服务管理 服务管理模块是 后利用这些流程进行有关 一共包括十大流程和一项服务台职能。 2） 侧重于从技术角度对基础设施进行管理； 覆盖了 括识别业务需求、实施和部署、对基础设施进行支持和维护等活动； 目标是确保 够满足业务需求和支撑业务运作。 应用管理（ 为了确保应用系统满足客户需求并方便对其进行支持和维护， 入应用系统的开发、测试和部署； 应用管理模块指导 使它们一致地为客户的业务运作提供支持和服务。 3） 安全管理 1999年新增到 目标是保护 其避免未经授权的使用； 为确定安全需求、制定安全政策和策略以及处理安全事件提供全面指导； 侧重从政策、策略和方法的角度指导如何进行安全管理。 “如何做”（ 作用是指导如何实施上述模块中的各个流程，包括对这些流程的整合； 指导客户确立远景目标，分析和评价现状； 确定合理的目标并进行差距分析； 确定任务的优先级，以及对流程的实施情况进行评审。 服务支持与服务提供职能与流程 服务支持 服务提供 服务台 (职能 ) 事件管理 问题管理 变更管理 配置管理 发布管理 服务级别管理 可用性管理 能力管理 事件管理 问题管理 变更管理 发布管理 配置管理 事 故 问题和已知错误 变更 发布 配置项关系 事 故 事 故 服务台 业务 、客户和用户 沟通、更新和权益措施 事件请求、需求 客户调查报告 变 更 发 布 管理工具 程 可用性管理 能力管理 需求、目标和绩效 服务级别管理 业务 、客户和用户 请求和需求 警告和期望调整 管理工具和沟通、更新和报告 为什么使用 概念和实践可以 : 提高客户对 加强与客户的交流 对于关键系统和基础架构，使之达到更高的可靠性 提升服务的性价比 在所有员工中建立一种共识 谁在使用 世界范围内超过 10,000家的公司 欧洲，加拿大，和澳大利亚的 微软，惠普， 受 响的工具 根据 和 和 ” “基于世界范围内顶尖的 及最佳实践的全球标准，包括 ” 基于 框架 “结合了 及微软产品与技术的特殊要求 ” T “建立在惠普的服务管理与流程的经验，以及 ” 管理者 息系统考试委员会） 信息科学考试学院 ) 2 3 4 “四架马车” 2 3 1 4 2016/4/13 服务台（ 议 程 概述 基本概念 主要活动 与其它流程之间的关系 成本、效益和问题 关键成功因素和绩效指标 总结 概 述 定义： 报告事件和请求提供用户支持的中心，它主要关注运作层次的用户支持。 目标： 为客户和用户提供单一联系点； 协调客户（用户）和 而提高客户的满意度； 作为首次联系点，服务台通过截取不相关问题和容易回答的问题减轻了其他 “过滤器”、“路由器”、“应答机”、“监控器”、“灭火器”、“传声机” 基本概念（ 1）：呼叫中心 /帮助台 /服务台 呼叫中心 /帮助台 /服务台 呼叫中心 ：组织中负责处理大规模基于电话的交易的部门，这种方式在银行和保险业中使用较多。 帮助台 ：负责管理、协调并尽快地解决 助台需要确保客户的每个请求不会被丢失、遗忘或忽略。 服务台 ：不仅负责处理事件、问题和询问，同时还为其它活动和流程提供接口。这些活动包括客户变更请求、维护合同、软件协议、服务级别管理、配置管理、可用性管理和 基本概念（ 2）：集中式服务台 定义： 由一个物理上的服务中心集中处理所有的服务请求，为用户提供了单一联系点。 优点： 降低总体运营成本； 管理控制上得到了加强； 提高了资源利用率。 缺点： 灵活性较差，难以针对各地用户的特殊情况提供个性化的服务。 用户 1 用户 2 用户 3 集中式服务台 第三方支持 网络运营支持 应用系统支持 桌面支持 二线支持 基本概念（ 3）：分布式服务台 定义： 每个地区或分部都创建了自己的服务台以支持自己的业务运作。 优点： 便于提供本土化、个性化的服务，响应速度快。 缺点： 当用户很多且需要的服务比较相似时，这种模式容易造成重复建设，浪费人力和物力，增加服务台运作的总体成本。 用户 1 用户 2 用户 3 服务台 第三方支持 网络运营支持 应用系统支持 桌面支持 一线支持 基本概念（ 4）：虚拟式服务台 定义：和用户保持单点联系的一种特殊的分布式服务台。 优点： 降低了运营成本； 加强了统一管理； 提高了资源利用率。 缺点： 难以提供现场支持； 实施要点： 统一接入方式，包括流程、规程和术语； 统一数据输入语言； 保持客户和用户的单点联系，如利用虚拟桌和呼叫自动转移技术实现全球或地区统一电话号码； 适当安排服务专家或工程师出现在客户服务现场； 使用统一的事件处理和管理流程。 虚拟服务台 巴黎服务台 纽约服务台 伦敦服务台 第三方供应商服务台 北京服务台 服务管理 数据库 海服务台 用户 1 用户 1 用户 1 用户 1 电 话 传 真 本概念（ 5）：呼叫中心 /非技能型服务台 呼叫中心 只负责记录呼叫请求而不提供解决； 呼叫请求被转发到相应的专家部门； 在有些情况下，呼叫请求的记录和转发可以通过语音响应系统自动进行。 非技能型服务台 呼叫请求被记录下来，并用通用的术语进行描述； 大多数被立即转发至相应的支持人员； 在很大程度上只是一个调度部门 优点在于事件记录被标准化了，并且是代表着用户的利益对事件进行监控和管理的； 其缺点是响应时间更长，首次呼叫解决率要远低于技能型服务台。 基本概念（ 6）：技能型服务台 /专家型服务台 技能型服务台 比前面的几种服务台具有更多的技能和经验； 通过使用文档化的解决方案，它可以解决许多事件，虽然有些事件还是要转发给相关的支持小组； 首次呼叫解决率通常都要远远高于非技能型服务台。 专家型服务台 具有关于全部 主要活动 响应呼叫请求 发布信息 供应商联络 运营管理任务 基础架构监控 呼叫请求 用户与服务台进行的联系； 所有的呼叫请求都应该记录下来以便进行进展监控以及为流程控制提供有关的数量指标。 呼叫请求：事件（包括标准变更） 错误报告：真实的故障以及对服务的抱怨 服务请求：服务请求在 它并不包括 呼叫请求：变更（非标准变更） 不被当作服务请求处理的非标准变更； 针对这种变更的请求必须遵循标准的变更管理流程，需要提出一项正式的变更请求（ 主要活动： 响应呼叫 发布信息 供应商联络 运营管理 基础架构监控 发布内容 当前或预期发生的错误，特别是在他们受到影响之前； 有关新的和现有的服务项目、服务级别协议（ 供应以及定购程序和成本等方面的信息 发布方式 消极的方式，如提供一个公告牌 积极的方式，如 幕上显示的联机消息或屏幕求助消息 主要活动： 响应呼叫 发布信息 供应商联络 运营管理 基础架构监控 联系事项： 打印机、工作站的维修和替换； 电信设备的维修和替换； 对纯粹感觉上的事件（干扰）以及变更和服务请求的处理。 主要活动： 响应呼叫 发布信息 供应商联络 运营管理 基础架构监控 进行备份和恢复、提供局域网连接。对当地服务器进行磁盘空间管理、创建帐号、设定和重设密码等也是服务台的职责。 主要活动： 响应呼叫 发布信息 供应商联络 运营管理 基础架构监控 主要活动： 响应呼叫 发布信息 供应商联络 运营管理 基础架构监控 服务台可能有权进入各种工具系统，这些系统被用来估计那些影响关键设备的故障可能产生的影响，如路由器、服务器、网关、关键任务系统、应用系统以及数据库等。 通常，这些工具在某个故障出现或正对基础架构产生威胁时就能自动地排除这些故障并通知事件管理。 正常情况下，使用这些工具系统主要是运营小组的任务，由他们将有关的信息报告给服务台。 与其它流程之间的关系 服务台与事件管理 服务台与变更和发布管理 服务台为变更和发布管理接收相关的 服务台可能还要承担软件和硬件的安装工作，因而在发布管理或变更管理中也承担了一个角色。 服务台致力于在错误发生时尽可能快地恢复约定的服务级别。 服务台通常提供有关用户对服务级别管理流程质量的体验（用户满意度）方面的有价值的信息。 用户满意度 客户满意度； 服务台协助降低服务中断所造成的影响的响应时间和解决时间。 与其它流程之间的关系（续 1） 服务台与配置管理 服务台与服务级别管理 服务台可以告知用户其受到支持的产品以及有权使用的服务。如果服务台没有被授权来解决用户的请求，则应该礼貌地告知用户这点并将请求通报服务级别管理。 服务台在处理用户请求时应该以服务级别协议作为双方协调的依据。 当服务台记录有关事件和问题时，需要验证呼叫者以及相关的 需要结合配置管理流程中的 关键成功因素和绩效指标 关键成功因素： 如果呼叫请求很难到达服务台，则用户可能不会去联系它转而试图自己解决错误，或在组织内找一个可以帮助他们的人来帮忙解决。 如果用户试图直接联系有关的专家，则他们通常应该先向服务台询问。 应该制定良好的 关键绩效指标： 对来电是否快速接听（如 90的呼叫在 呼叫是否在 果它们不能在服务台得到解决）？ 在没有求助其它支持层次如二线支持、三线支持或供应商的情况下事件被解决的百分比； 每个工作站 /用户被处理的呼叫的数目，以及整个服务台该项指标的总数； 2016/4/13 事件管理（ 议 程 概 述 基本概念 主要活动 关键角色 与其它流程之间的关系 成本效益及可能的问题分析 关键成功因素和绩效指标 总 结 概 述 定义： 事件管理是负责记录、归类和安排专家处理事件并监督整个处理过程直至事件得到解决和终止的流程。 目标： 在给用户和公司正常的业务活动带来最小影响的情况下，尽快的返回到 保留事件的有效记录以便能够权衡并改进处理流程，给其他的服务管理流程提供合适的信息，以及正确报告进展情况。 基本概念（ 1）：事件 /服务请求 事件（ 在某一服务中不属于标准操作的并能导致或可能导致这个服务的中断或服务质量下降的任何事件； 服务请求（ 用户想要获得有关的支持、提供、信息、建议或文档而提出的请求，它并不属于 一个服务请求可能是要求进行一个标准变更，但是只要它属于 标准服务 的范畴，那么就应当由事件管理而不是变更请求流程进行处理。 如果被请求的服务不是事先已经定义好的 标准服务 ，并且它将改变 么我们将据此提交一个变更请求（ 基本概念（ 2）：影响度 /紧急度 /优先级 影响度： 影响度指就所影响的用户或业务数量而言，事件偏离正常服务级别的程度； 紧急度： 解决故障时，对用户或业务来说可接受的耽搁时间； 优先级： 处理事件和问题的先后顺序； 影 响 度 紧 急 度 优 先 级 估计：人力、 资源和时间 受影响的用户数 受影响的系统数 用户要求 服务级别协议 错误的严重性 基本概念（ 3）：升级 定义： 如果某一事件不能在规定的时间内由一线支持小组解决，那么更多的有经验的人员和有更高权限的人员将不得不参与进来，这就是升级。它可能发生在事件解决过程的任何时间和任何支持级别。 职能性升级（ 需要具有更多时间、专业技能或接入特权（技术机构）的人员来参与事件的解决。 这种升级可能会超越部门界限而且可能会包括外部支持者。 结构性升级（ 当经授权的当前级别的机构不足以保证事件能及时、满意的得到解决时，需要更高级别的机构参与进来； 一般情况下应优先使用职能性升级，只有当在某些事件不能得到及时解决时才考虑使用结构性升级； 基本概念（ 4）：一线、二线、 第 1线支持（也称为第 1排支持人员）通常由服务台来提供； 第 2线的支持则由管理部门提供； 第 3线的支持由软件开发人员和系统结构人员提供； 第 4线的支持由供应商提供。 检测和记录 事件匹配 事件归类 初步支持 解决？ 调查分析 解决？ 调查分析 解决？ 确定解决 确定解决 确定解决 结束事件 继续 否 否 否 是 是 是 事件升级流程 一线支持 服务台 二线支持 管理部门 三线支持 软件开发 四线支持 供应商 主要活动 接收和记录 归类和初步支持 匹配 调查和诊断 解决与恢复 终止 跟踪与监控 事件接收和记录 初步归类和支持 事件调查和分析 服务请求 解决事件和恢复服务 处理服务请求 终止事件 负责解决事件并跟踪、监督、控制和协调解决过程 主要活动： 接收记录 归类和初步支持 匹配 调查诊断 解决恢复 终止 已有的事件记录可帮助对新发生的事件进行诊断； 问题管理可通过对事件的记录来发现问题的原因； 如果所有的来电呼叫都被记录下来，那么对某一事件的影响度的判断会容易一些； 如果没有事件记录，那么将不能监控经过协商服务级别是否得到履行； 避免在解决问题时出现几个人同时解决同样的问题，或在对某一事件的处理过程中什么工作都没有做等情形； 由某一用户发现 由系统发现 由某一服务台员发现 由另一 跟踪监控 主要活动： 记录 部分） 事件编号（唯一的）；事件类别； 记录事件的时间和日期；事件记录人（或组）的姓名（或 有关用户的姓名、部门、电话和工作地点； 回复用户的方式（如电话，电子邮件等）； 事件症状描述； 分配一个事件索引序号 大多数情况下系统会自动分配一个唯一的事件索引序号。通常，在后续沟通过程中用户可使用通过提供的查询序号来查看事件状态。 记录基本的诊断信息 时间、症状、用户、处理问题的人、地点以及受影响的服务或硬件等信息； 附加事件信息 包括与事件相关的其他信息（例如一个脚本或交谈程序记录）或配置管理数据库中的一些信息（通常以数据库中定义的关系为基础）。 警告 如果存在一个具有高影响度的事件，例如某一重要服务器的瘫痪，则应警告其他用户和管理部门 。 接收记录 匹配 调查诊断 解决恢复 终止 跟踪监控 归类和初步支持 类别 将事件归入某一类别或某一子类 如按事件发生的可能原因分类或按与事件相关的支持小组进行分类。 优先级影响度 紧急度 服务 按照 要用一个列表来标识与事件相关的服务。 这个列表同时也提供了按照 否 是 事件警告 事件查明和记录 请求？ 调查 义优先级 初步评价事件 服务台能解决事件？ 解决事件 终止事件 安排特定支持小组 处理服务请求 否 是 事件调查和分析 主要活动： 接收记录 归类和初步支持 匹配 调查诊断 解决恢复 终止 跟踪监控 支持小组 如果服务台不能在预先确定的时间范围内解决事件，决定应该由那个支持小组来负责处理该事件。 时间表 以优先级和 影响的用户将会被通知预计解决问题的最长时间（一个周期时间）； 以及什么时候可进行进一步的升级。 事件索引号 工作流状态： 新建；已接收； 已计划；已分配； 活跃状态；已暂停； 已解决；已终止。 主要活动： 接收记录 归类和初步支持 匹配 调查诊断 解决恢复 终止 跟踪监控 否 是 事件警告 事件查明和记录 请求？ 调查 义优先级 初步评价事件 服务台能解决事件？ 解决事件 终止事件 安排特定支持小组 处理服务请求 否 是 事件调查和分析 主要活动： 接收记录 归类和初步支持 对事件进行分类之后，要检查以前是否发生过类似的事件。如果发生过，则查看是否存在解决方法和应急措施。如果新事件与某一问题或某一已知错误具有相同症状，那么可将事件指向这些已知的问题或错误。 匹配 调查诊断 解决恢复 终止 跟踪监控 服务台将那些没有快速解决方法或超过他们专业水平的事件安排给具有更高专业水平和技术能力的支持群体。 支持小组将对事件进行调查并尽快加以解决，如不能解决，则将其转交给其他的支持小组。 接收记录 归类和初步支持 匹配 调查诊断 解决恢复 终止 跟踪监控 事 件 安排支持人员 收集基本信息 查询历史数据 搜索调查数据 分析？ 件、问题和已知错误数据库 是 否 将事件处理责任反馈给服务台 终止事件调查 主要活动： 主要活动： 接收记录 归类和初步支持 成功完成对事件的分析解决之后，负责解决问题的支持小组应在系统中记录故障的解决方法； 对某些解决方法来说，必须要向变更管理发送一个变更请求（ 如果没有找到解决事件的方法，那么事件依然保持开放（ 态。 匹配 调查诊断 解决恢复 终止 跟踪监控 主要活动： 接收记录 归类和初步支持 一旦解决方法执行完毕，支持小组要把事件处理情况反馈给服务台。服务台应联系事件的报告人以确认问题的确已经得到解决。 如果服务台可以确定问题已经得到很好的解决，那么事件就可以关闭（ ，否则需要在适当的地方重新开始处理流程。 在事件关闭的过程中，必须要对事件的记录进行 更新 以指明对事件最终的分类和优先级，受影响的服务、用户、客户，以及导致事件发生的配置项（ 。 匹配 调查诊断 解决恢复 终止 跟踪监控 主要活动： 接收记录 归类和初步支持 作为所有事件的拥有者（ 服务台负责对事件的发展情况进行监控以及通知用户有关事件的状态。 用户在某一状态变更后可能作出适当的反馈，如在预期的事件周期内发生的进一步的事件移交安排或变更等。 在对事件进展进行跟踪和监控时，可能需要将事件进行职能性升级，转派给其他支持小组来处理，或进行结构性升级，以加强处理事件的力度。 匹配 调查诊断 解决恢复 终止 跟踪监控 关键角色 事件经理： 对以下事情负责： 监控处理流程的效果和效率； 控制支持小组的工作； 为改进工作提供建议； 开发并维护事件管理系统； 通常指派给服务台经理； 支持人员： 第一线支持负责记录、分类、匹配、转交、解决和终止事件； 其它的支持小组主要参与调查、诊断和恢复工作。 与其它流程之间的关系 事件管理与配置管理 事件管理与问题管理 问题管理需要了解事件记录以便查出任何潜在错误。 问题管理通过提供与特定问题相关的信息、已知错误、应急措施以及当前修补方法等来给事件管理提供帮助。 配置管理显示基础架构的某一部分由谁来负责，这样当与这一部分相关的事件发生时可以迅速地进行追踪。 转移打印队列，将用户转移到另一个服务器等。 在进行事件注册时，配置的详细信息也被链接到了事件记录以提供更好的相关错误信息。 与其它流程之间的关系（续 1） 事件管理与变更管理 事件管理与服务级别管理 服务级别管理监控与用户就提供的服务支持达成的协议。事件管理必须熟悉服务级别协议（ 便在与用户进行沟通时可用到这些信息。事件记录可用来生成报告来判断是否真正地提供了规定级别的服务。 可通过实施变更来解决事件，如更换监视器等。 变更管理为事件管理提供关于预定变更及其状态的信息。 不正确的变更实施或者包含错误的变更也可能引发事件。此时，事件管理也可以为变更管理提供关于这类事件的信息。 与其它流程之间的关系（续 2） 事件管理与可用性管理 事件管理与能力管理 能力管理关注与其职能相关的事件，如由缺少磁盘空间或响应时间过长导致的事件。 业务经理、系统经理或系统本身可将这些事件通报事件管理系统。 可用性管理需要使用由配置管理提供的事件记录和状态监控。 成本效益分析和可能的问题 成本： 初始执行成本（如对流程和过程的定义以及相互间的沟通）； 培训和指导人员（顾客和支持人员）； 选择和购买支持流程的工具等； 与人事和工具使用相关的成本。 可能的问题： 用户和 事件处理超载和堆积； 过多的升级可能会打乱专业技术人员的正常工作而产生负面影响； 缺乏清楚的定义和协议； 缺少奉献精神 关键成功因素和绩效指标 成功的事件管理需要： 及时更新的 知识库（例如一个最新的问题数据库或已知错误数据库）。帮助识别事件，以及有什么解决方法和应急措施可以使用； 适当的自动系统。用于记录、跟踪以及监控事件； 与服务级别管理间的紧密联系以确保适当的优先级和解决时间。 事件管理流程的关键绩效指标 ： 事件的总数 ； 平均解决时间 ； 每个事件的平均支持成本； 在 ； 不需拜访用户就解决的事件数； 每个服务台工作站或每个服务台员工平均解决的事件数 。 2016/4/13 问题管理（ 议 程 概 述 基本概念 主要活动 关键角色 与其它流程之间的关系 成本、效益和问题 关键成功因素和绩效指标 总 结 概 述 定义： 通过调查和分析 明事件产生的潜在原因并制定解决事件的方案和防止事件再次发生的措施，将由于问题和事件对业务产生的负面影响减小到最低的服务管理流程。 调查基础架构和所有可用信息，包括事件数据库，来确定引起事件的真正的潜在原因以及提供的服务中可能存在的故障。 目标： 将由 查明事件或问题产生的根本原因，制定解决方案和防止事件再次发生的预防措施； 实施主动问题管理，在事件发生之前发现和解决可能导致事件产生的问题。 基本概念（ 1）：问题 /已知错误 /变更请求 问题 ( 一个问题描述了一种非预料的情况，它表示引起一个或多个现存或潜在事件的深层根源 已知错误 ( 一个已知错误是指一个已经确定产生根源的问题 变更请求 ( 变更请求处理变更，如消除一个已知错误 变更请求 说明了变更的内容及与变更有关的配置项。根据请求，变更管理小组和用户及其它有关人员对变更实施结果进行评价并计划进一步的变更。 如果出现了一个 已知错误 ，则应当提出一个变更请求。但是，在通过一项变更将此已知错误永久性地修复之前，它将仍将作为一个已知错误。 基本概念（ 2）：事件管理 事件管理 问题管理： 问题管理的主要目标是要查明事件发生的潜在原因并找到解决此事件的方法或防止其再次发生的措施； 事件管理的主要目标是在事件发生后尽可能快地恢复客户服务，即使采取的是一些应急措施而不是永久性的解决方案； 事件管理强调速度； 问题管理强调质量，把速度放在第二位； 为了发现事件原因和防止事件再次发生，问题管理可能需要花费更多时间解决事件且可能推迟恢复服务。 基本概念（ 3）：应急措施 急措施） 解决某个事件的替代方案，这种方案可在限定的时间内产生一个可接受的结果。 基本概念（ 4）：问题控制 /错误控制 问题控制 问题控制是问题管理流程的第一项活动。问题控制负责找出问题并调查其根源，其目标是通过确定问题根源并采取应急措施来把问题转化成已知错误。 错误控制 错误控制指监控和管理已知错误直到其尽可能地得到适当的处理。为此，它需要向变更管理提交变更请求（ 并在实施变更后对变更进行实施后评审以评估其效果。 基本概念（ 5）：实施后评审（ 实施后评审（ 用于解决问题、已知错误及相关事件的变更一旦实施后，在终止有关记录工作之前必须对变更进行实施后评审（ 如果变更成功实施，那么对所有问题和已知错误及相关事件的记录工作都可以终止了。 许多公司进行实施后评审是为了确保与问题相关的所有事件终止（包括确认客户是否同意终止事件）之后才能终止此问题。如果与其相关的所有事件没有全部终止，则需将该问题重新置为“未解决”状态。 主要活动 问题控制（ 错误控制（ 主动问题管理 （ 如何确定问题？举例： 对某一事件进行分析表明该事件可能再次发生，或者有大量发生并且加重的趋势。 对基础架构进行分析可以找出可能会产生事件的薄弱环节（也可由可用性管理和能力管理来进行分析）； 服务级别可能会受到威胁（能力、性能、成本等） 记录下来的事件不能与一个现有的问题或已知错误发生关联。 发现和记录 归 类和分配 调查和分析 错误控制 跟踪和监督 问题数据库 分 析 临时修复措施 主要活动： 问题控制 错误控制 主动问题管理 如何归类？ 类别 ： - 确定问题的相关领域，如是硬件还是软件问题； 影响度 主要指对业务流程的影响 紧急度 也包含多长时间的延期是可接受的； 优先级 紧急度、影响度、风险和所需资源的综合考虑 状态 如问题、已知错误、已解决、已关闭但正在进行实施后评审等。 发现和记录 归 类和分配 调查和分析 错误控制 跟踪和监督 问题数据库 分 析 临时修复措施 主要活动： 问题控制 错误控制 主动问题管理 主要活动： 问题控制 错误控制 主动问题管理 调查和诊断 一旦找到问题的根源以及与此问题相关的一个或多个配置项，就可建立配置项和相应事件之间的关联； 之后如果找到了解决此问题的应急措施，此问题就转变为已知错误。 临时修复措施（ 在解决问题的过程中，如果问题导致了严重的事件，那么找到一个临时修复或紧急修复的方法是非常必要的。 但是如果临时修复措施需要对基础架构进行一些改动，那么必须首先提交变更请求（ 这主要是指在找到问题的最终原因之前）。 如果特别严重而且不容耽搁，就必须启动紧急变更请求处理程序。 现和记录错误 错误评估 确定解决方案 跟踪和监督错误 实施后评审 变更管理 问题数据库 问题终止 问题数据库 变更实施 问题控制 主要活动： 问题控制 错误控制 主动问题管理 描 述： 根据对 题管理可以找到可能出现问题的薄弱环节，在事件发生前发现和解决有关问题和已知错误，以尽量减少问题和已知错误对业务的影响。 趋势分析： 找出 析其原因，以便采取措施降低配置项故障对业务的影响； 分析已发生的事件和问题，研究其变化趋势； 通过其它方式和途径分析，比如系统管理工具、用户反馈等。 制定预防措施： 提交变更请求（ 提交有关测试、规程、培训和文档方面的反馈信息