ITSM-Service Support-Incident Management供参习.docVIP

事故管理 版本号（可选） 2004年3月25日 事故管理 事故管理的目标 事故管理流程的主要目标是尽可能快地恢复正常的服务运营，最小化对业务运营的不利影响，以此保证维持尽可能最好的服务质量和服务可用性。“正常的服务运营”在这里定义为服务水平协议（SLA）限制内的服务运营。 事故管理的范围 在ITIL的术语中，“事故”定义为：不是标准服务运营中的一部分的任何事件，它能够引起（或可能引起）服务的中断（或服务质量的降低）。 事故分类的例子如： 应用 服务不可用 应用的BUG/查询阻止了客户的正常工作 磁盘使用超限 硬件 系统宕机 自动报警 打印机不打印 不能够进行配置 服务请求 信息、建议、文档的请求 忘记密码 对于新的或额外的服务请求（如硬件或软件）经常不被看作事故，而是变更请求（RFC-Request for Change）。然而实践表明，基础设施故障的处理与服务请求的处理是相似的，因此两者都被包括在事故管理流程的定义和范围内。尽管企业可以决定开发它们自己的服务请求过程来将服务请求与更多的技术专题区分开，本章中“事故”一词，除非明显指出，否则指上述两者。 在技术上更侧重面向系统管理的功能中，自动登记的事件（如超出磁盘使用限制）经常被看作“正常”运营部分。尽管对客户的服务交付不受影响，这些事件也被包括在事故的定义中。 下图展示了事故管理流程： 事故管理流程 输入 来源于服务台、网络或计算机操作的事故详细描述 来源于配置管理数据库的配置明细 来源于与问题和知名错误相匹配的事故的响应 解决方案的详细资料 对实现事故解决方案的变更请求的响应 输出 事故解决方案的变更请求；更新事故记录（包括解决方案和/或临时措施） 解决并结束事故处理 与客户交流 管理信息（报表） 事故管理的活动 事故检测和记录 分类和初始支持 调查和诊断 解决与恢复 事故处理结束 事故的所有权、监视、跟踪和交流 与事故管理流程相关的角色和功能包括： 一、二、三线支持组，包括专家支持组和外部供应商（角色） 事故管理员（角色） 服务台管理员（功能） 基本概念 事故处理 大多数IT部门和专家组经常致身于事故处理。服务台负责监控所有登记的事故的解决过程－在效果上服务台是所有事故的所有者。这个流程大部分是被动反应的，因此，为了有效地做出反应，需要有软件工具支持的标准的工作方法。 不能被服务台立即解决的事故可以被分配给专家组。应该在对用户的工作最小破坏的范围内，尽可能快地提供解决方案或临时措施恢复对用户的服务。在事故的原因找到解决方案，协定的服务恢复后，事故处理结束。 下图展现了事故生命周期中的活动，另外一种表示方法在附录5E中。 事故生命周期 事故的状态反应了在生命周期中的当前位置，有时称作它的“工作流位置”。每个人应该关注每个状态和它的含义。下面是一些状态分类的例子： 新事故 已经接受 调度中 分配/分派到专家 处理中（WIP） 搁置 已经解决 结束 在整个事故生命周期中，维护事故记录是非常重要的，它使得服务团队中每个成员能够向客户提供必威体育精装版的进展报告。更新活动的例子包括： 更新历史资料 修改状态（如从“新事故”到“处理中”或“搁置”） 修改业务影响/优先级 输入花费的时间和成本 监控升级状态 随着事故的进展，原来报告的客户描述可能会改变，然而保留原来症状的描述，对于分析以及你能够参考初始报告中客户抱怨都是很重要的。例如，客户可能已经报告打印机不能工作，已经发现是由网络原因引起的。这时回应客户打印机事故已经被解决，要比与客户谈论网络问题的解决方案好得多。 当回顾进展时审计历史是必要的，当解决SLA被违背的问题时特别重要。下面对事故记录的更新应该在事故的生命周期中被登记： 修改人的名字 修改日期和时间 修改的内容（如优先级、状态、历史） 为什么进行变更 花费的时间 如果第三方不被允许有权更新服务台支持记录（这是首选的方案），那么就要求有一个代表供应商更新记录的流程。这保证了资源的使用被正确地计帐。如果软件能够允许事故分段和信息分屏，那么对一些组织就能够允许第三方直接更新，这样可能就更加方便工作。在这个决定中，你需要考虑你不准备允许供应商看到什么以及要多么紧密地注意到供应商正在做什么。 当服务台代表工作在这个领域的支持人员更新时，同样的情况可能也存在。对于以下的情况可能需要以往的事故更新，例如，工程师在晚上工作，而服务台必须在次日早晨代表他们做记录更新。 一、二、三级支持 经常地，是部门和（专家）支持组而不是服务台作为二线或三线支持小组，他们有更多的专家技能、时间或其它资源来解决事故。在这种关系中，服务台作为一线支持，下图示例了这个术语怎样关联到前面提到的事故管理中的活动。 注意三线和（或）N线支持可能最后包括外部的供应商，他们可能直接