ITIL之故障管理（IncidentManagement）中文翻译.pdf
合集下载
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
4.2 故障管理
关于“故障”的定义： 在ITIL中，故障包括：1）非计划性的IT服务中断，或者IT服务性能的下降。2）配置项的失效，即 便没有影响到服务，也是故障。例如：一组镜像中的一块磁盘损坏。
关于故障管理： 故障管理是对所有故障进行处理的流程；包括报告的失效、疑问、咨询等。可能是用户（通过电话 或服务台进入）、技术方面的同事或者事件监控工具自动检测和报告的。
在所有情况下，要给支持人员提供清晰的指南说明（包含一些实例）以帮助他们确定正确的紧急度 和严重等级，从而确定正确的优先级。这份指南应当在Service Level的协商中确定。
然而，必须指出，有的时候因为商业上的特殊原因，可能会修改按照通常方法计算出来的优先级。 如果用户坚持要得到一个高的优先级，服务台应当满足用户的要求，即便用户的要求是不正确的， 也不应该在电话中与用户进行纠纷，可以用其他方式解决这个分歧。
故障确保有足够的资源并得到足够的关注，以便能够尽快地找到一个变通解决方法。如果在有的组 织中服务台经理同时兼任故障经理的情况下，应该有单独另外的人领导重大故障研究小组（以避免 时间和优先程度上的冲突），并且及时向故障经理汇报。如果同时还需要对引起故障的根源进行调 查，那么问题经理会参与到其中，但是故障经理一定要确保服务的恢复与根源原因的排除要进行分 离。
-解决故障所采取的步骤； -故障解决的日期和时间； -关闭的类型； -关闭的日期和时间。 **注意：如果服务台不是7*24小时的，在非工作时间内需要由其他小组，如：IT运营组、网络支持 组进行处理的。那么也应当培训使他们也能完全了解故障记录的要求。
4.2.5.3 故障分类
部分初始的记录必须要被合适分配故障的分类代码，以便确定这些来电的确切分类。这对于后续在 问题管理，或者供应商管理以及其他的ITSM活动中进行故障类别和频度的趋势分析时非常有用。
每个组织都有自己的特点，因此很难给出一个组织中应当如何进行分类划分的指南，特别是在低层 级上的划分。然而，有个方法可以帮助组织从头开始建立一个完整适用的分类集合。这些步骤包括： 1. 与相关的支持团队进行头脑风暴，包括支持团队的主管以及故障、问题经理。 2. 通过头脑风暴先确定一个最容易分辨的（最容易猜到的）顶层分类。顶层分类中应当包含“其他”
4.2.5.4 故障优先级
每个故障记录时的另一个重要方面是确定故障的优先级。根据优先级将确定故障处理所需要的工具 和人员。 优先级通常由紧急度（从业务的角度来看，需要如何迅速地解决）和故障引发的影响度来确定。在 有些情况下，同时也很重要的，对某些特定对业务有重大影响的用户，不能仅仅通过数字来衡量。
对于优先级来说，其他一些重要的因素有： 生命或肢残的风险； 所影响的服务数量； 带来的经济损失级别； 业务中断可能带来的风险； 违反法律或监管条例；
有些组织中会有一些VIP，他们的故障需要优先得到处理，这种情况下应满足，并且在服务台的作业 指导中说明对这类用户如何应用优先级。这样他们能够了解哪些是VIP用户，对VIP所需要应用的原 则是什么。
故障中必须要记录的信息可能但不仅限于以下方面： -唯一的编号 -故障的分类（通常会被再细分2到4级子分类） -故障的紧急度； -故障的影响度； -故障的优先级； -故障记录的时间日期； -记录故障的人员或组的名称和ID； -获悉故障的渠道（电话、自动工具、邮件、自己等等） -用户的姓名、部门、电话、区域位置； -回复的方式（电话、邮件等） -症状描述 -相关的CI -分配进行故障处理支持的人员和团队； -相关的问题/已知错误；
分类进行较大的调整时都会对故障趋势分析和管理报告造成一定的困难。所以分类应该是稳定的， 除非分类真正有必要进行调整。
如果已经有一个分类模式在使用，但是使用并不是很适用的时候，上面推荐的方法可以用来对现有 的模式进行回顾和修订。
**注意：有时候根据当时掌握的具体情况还不充分，从而导致故障记录不正确、不完整、有错误。 所以必要的话，在关闭阶段对故障的分类还要进行检查和修改（要用另外一个域来记录关闭阶段判 断的分类，以免覆盖了初始的故障分类）。
**注意：在故障处理中进行Service Request的检查，并不意味着服务请求是一种故障。必须得承认， 服务请求难免会被误登记为故障（比如：用户在web界面中误把请求作为报障进行输入。）通过检查， 可以发现这种误判，并且能将他们转入Request Fulfilment流程进行处理。
大多数工具都支持多级的故障分类，通常是3~4级粒度划分。
4.2.5 流程活动、方法、技术
流程中包括：故障识别、故障记录、故障分类、确定优先级、初步诊断、故障升级、调查与诊断、 解决与恢复、故障关闭。
4.2.5.1 故障识别
只有知道了故障发生才会启动故障处理流程对故障进行处理。 从业务的角度，故障一般都是不能预期的，直到由用户受到影响并且联系服务台时才发现故障。尽 可能地，对所有关键的组件都进行监控，尽早发现失效或可能失效的情况，启动故障处理流程。理 想情况下，应该在故障影响到用户之前得到解决。
**服务台既受理故障也受理服务请求，但两者的流程是不一样的。
4.2.3 流程的价值
减少业务中断的时间，从而提升服务的可用性；可以将服务转入更深层次的功能性设计。 能够识别业务的优先度并且动态地调配资源；可以使IT活动能够实时的响应业务的优先级。 通过分析故障的组成类别，和与业务运营人员的接触，能够识别出服务需要改进的地方。 服务台在处理故障的过程中，识别出IT或者业务上需要增加的服务或培训需求。
4.2.4.2 故障模式
由于故障通常都是重复发生的，因此，如果定义一些故障模式，对于故障的处理非常有帮助。 故障模式，预先定义了一个处理流程（事先定义好的）需要采取的步骤。一般要有支持工具，能够 帮助管理所需要的流程。 采用故障模式，确保故障能够在预先定义的路径和时间表内进行处理。在故障模式中，也可以把有 特殊要求的故障进行特殊对待（例如:安全故障-转入信息安全管理；能力、性能方面的转入能力管 理等等）
4.2.5.2 故障记录
所有的故障必须得到进行完整地记录，不论是通过服务台的电话报障还是通过事件的自动检测发现 的故障，都需要记录当时的时间戳。 **注意：如果服务台或者技术支持人员在客户现场处理故障，他们会被要求顺便再处理一些其他故 障。如果他们确实协助处理了故障，应当确保要有额外单独的故障单纪录，以便留下故障的历史纪 录并且证明当时的工作量。 所有关于故障本身的信息都必须进行记录，这样可以确保记录完整的历史信息，当需要转给其他支 持团队时，他们可以获得所有的信息以支持他们进行处理。
分类。在相关的工具中用这些分类进行记录，并跟踪一段时间。 3. 跟踪这些分类的使用一段时间后（要足够长，直到记录了数百个故障并且基本上落在各分类下。
但是也不能太长，致使要花太长的时间进行分析）。 4. 对这段跟踪期内的故障记录进行分析。在每个顶层分类下记录的故障数能够表明哪些分类应该保
留，同时要对“其他”分类下的故障进行分析，以确定是否有必要在顶层分类中进行补充增加。 5. 对每个顶层分类下的故障进行细目分析，以确定下面的子级分类。 6. 在接下来一段时间内（1~3个月内）回顾并重复上述步骤，逐步确定这些分类是恰当地。注意：对
4.2.1 目标
故障管理的目标是“尽快恢复服务到正常运行，并且最小化对业务运营的不利影响，从而尽可能地保 证服务质量和可用性的水平”。服务的正常运行，在这里是指符合SLA约定的服务运行水平。
4.2.2 范围
故障管理的范围: 任何已经或者可能导致服务中断的事件。事件可能是直接从用户报告的，或者通过服务台，或者通 过事件管理工具到故障管理的。也可能来自技术部门的同事记录的故障（例如：注意到硬件或网络 组件的不太正常，他们可能记录或向服务台报告故障）。并不是所有的事件都会成为故障，只有那 种已经或者可能对服务产生影响的事件才会进故障管理流程。
故障模式应该包括以下方面： 处理故障时所需采取的步骤； 按照时序排列步骤，并且考虑到所有的关联性。 职责分派，谁应该做什么。 各任务完成的时间表和期限要求。 升级程序；应该在什么时间联系谁？ 所有必要的证据保全活动（特别是针对安全或性能相关的故障）
4.2.4.3 重大故障
对于“重大”的故障，应该有另外的处理程序，相应要求的处理时间更短、紧急度更高。 定义哪些事件属于重大故障，必须能够很好地映射到整个故障优先级系统。 **注意：重大故障不等同于问题。因为重大故障仍然属于故障管理，它的目标是尽快地恢复服务。 必要时，重大故障程序应该包括建立故障经理领导下的动态的独立的重大故障小组，系统地关注于
4.2.4 政策/原则/基本概念
4.2.4.1 时间表
必须根据SLA中响应和处目标，制定故障处理的各个阶段的时间要求（根据故障的优先级不同，各 有不同）。并且落实到OLA和UC的目标中。 所有的支持团队必须知晓时间要求。 服务管理工具应该能够进行的自动的时间计算，并且根据事先定义好的规则进行故障的升级。
4.2 故障管理.................................................................................................................................. 1 4.2.1 目标............................................................................................................................... 1 4.2.2 范围............................................................................................................................... 1 4.2.3 流程的价值................................................................................................................... 2 4.2.4 政策/原则/基本概念...................................................................................................... 2 4.2.5 流程活动、方法、技术................................................................................................ 3 4.2.6 触发、输入、输出以及流程间的接口 ....................................................................... 7 4.2.7 信息管理....................................................................................................................... 8 4.2.8 测量指标....................................................................................................................... 9 4.2.9 挑战，关键成功因素和风险....................................................................................... 9
关于“故障”的定义： 在ITIL中，故障包括：1）非计划性的IT服务中断，或者IT服务性能的下降。2）配置项的失效，即 便没有影响到服务，也是故障。例如：一组镜像中的一块磁盘损坏。
关于故障管理： 故障管理是对所有故障进行处理的流程；包括报告的失效、疑问、咨询等。可能是用户（通过电话 或服务台进入）、技术方面的同事或者事件监控工具自动检测和报告的。
在所有情况下，要给支持人员提供清晰的指南说明（包含一些实例）以帮助他们确定正确的紧急度 和严重等级，从而确定正确的优先级。这份指南应当在Service Level的协商中确定。
然而，必须指出，有的时候因为商业上的特殊原因，可能会修改按照通常方法计算出来的优先级。 如果用户坚持要得到一个高的优先级，服务台应当满足用户的要求，即便用户的要求是不正确的， 也不应该在电话中与用户进行纠纷，可以用其他方式解决这个分歧。
故障确保有足够的资源并得到足够的关注，以便能够尽快地找到一个变通解决方法。如果在有的组 织中服务台经理同时兼任故障经理的情况下，应该有单独另外的人领导重大故障研究小组（以避免 时间和优先程度上的冲突），并且及时向故障经理汇报。如果同时还需要对引起故障的根源进行调 查，那么问题经理会参与到其中，但是故障经理一定要确保服务的恢复与根源原因的排除要进行分 离。
-解决故障所采取的步骤； -故障解决的日期和时间； -关闭的类型； -关闭的日期和时间。 **注意：如果服务台不是7*24小时的，在非工作时间内需要由其他小组，如：IT运营组、网络支持 组进行处理的。那么也应当培训使他们也能完全了解故障记录的要求。
4.2.5.3 故障分类
部分初始的记录必须要被合适分配故障的分类代码，以便确定这些来电的确切分类。这对于后续在 问题管理，或者供应商管理以及其他的ITSM活动中进行故障类别和频度的趋势分析时非常有用。
每个组织都有自己的特点，因此很难给出一个组织中应当如何进行分类划分的指南，特别是在低层 级上的划分。然而，有个方法可以帮助组织从头开始建立一个完整适用的分类集合。这些步骤包括： 1. 与相关的支持团队进行头脑风暴，包括支持团队的主管以及故障、问题经理。 2. 通过头脑风暴先确定一个最容易分辨的（最容易猜到的）顶层分类。顶层分类中应当包含“其他”
4.2.5.4 故障优先级
每个故障记录时的另一个重要方面是确定故障的优先级。根据优先级将确定故障处理所需要的工具 和人员。 优先级通常由紧急度（从业务的角度来看，需要如何迅速地解决）和故障引发的影响度来确定。在 有些情况下，同时也很重要的，对某些特定对业务有重大影响的用户，不能仅仅通过数字来衡量。
对于优先级来说，其他一些重要的因素有： 生命或肢残的风险； 所影响的服务数量； 带来的经济损失级别； 业务中断可能带来的风险； 违反法律或监管条例；
有些组织中会有一些VIP，他们的故障需要优先得到处理，这种情况下应满足，并且在服务台的作业 指导中说明对这类用户如何应用优先级。这样他们能够了解哪些是VIP用户，对VIP所需要应用的原 则是什么。
故障中必须要记录的信息可能但不仅限于以下方面： -唯一的编号 -故障的分类（通常会被再细分2到4级子分类） -故障的紧急度； -故障的影响度； -故障的优先级； -故障记录的时间日期； -记录故障的人员或组的名称和ID； -获悉故障的渠道（电话、自动工具、邮件、自己等等） -用户的姓名、部门、电话、区域位置； -回复的方式（电话、邮件等） -症状描述 -相关的CI -分配进行故障处理支持的人员和团队； -相关的问题/已知错误；
分类进行较大的调整时都会对故障趋势分析和管理报告造成一定的困难。所以分类应该是稳定的， 除非分类真正有必要进行调整。
如果已经有一个分类模式在使用，但是使用并不是很适用的时候，上面推荐的方法可以用来对现有 的模式进行回顾和修订。
**注意：有时候根据当时掌握的具体情况还不充分，从而导致故障记录不正确、不完整、有错误。 所以必要的话，在关闭阶段对故障的分类还要进行检查和修改（要用另外一个域来记录关闭阶段判 断的分类，以免覆盖了初始的故障分类）。
**注意：在故障处理中进行Service Request的检查，并不意味着服务请求是一种故障。必须得承认， 服务请求难免会被误登记为故障（比如：用户在web界面中误把请求作为报障进行输入。）通过检查， 可以发现这种误判，并且能将他们转入Request Fulfilment流程进行处理。
大多数工具都支持多级的故障分类，通常是3~4级粒度划分。
4.2.5 流程活动、方法、技术
流程中包括：故障识别、故障记录、故障分类、确定优先级、初步诊断、故障升级、调查与诊断、 解决与恢复、故障关闭。
4.2.5.1 故障识别
只有知道了故障发生才会启动故障处理流程对故障进行处理。 从业务的角度，故障一般都是不能预期的，直到由用户受到影响并且联系服务台时才发现故障。尽 可能地，对所有关键的组件都进行监控，尽早发现失效或可能失效的情况，启动故障处理流程。理 想情况下，应该在故障影响到用户之前得到解决。
**服务台既受理故障也受理服务请求，但两者的流程是不一样的。
4.2.3 流程的价值
减少业务中断的时间，从而提升服务的可用性；可以将服务转入更深层次的功能性设计。 能够识别业务的优先度并且动态地调配资源；可以使IT活动能够实时的响应业务的优先级。 通过分析故障的组成类别，和与业务运营人员的接触，能够识别出服务需要改进的地方。 服务台在处理故障的过程中，识别出IT或者业务上需要增加的服务或培训需求。
4.2.4.2 故障模式
由于故障通常都是重复发生的，因此，如果定义一些故障模式，对于故障的处理非常有帮助。 故障模式，预先定义了一个处理流程（事先定义好的）需要采取的步骤。一般要有支持工具，能够 帮助管理所需要的流程。 采用故障模式，确保故障能够在预先定义的路径和时间表内进行处理。在故障模式中，也可以把有 特殊要求的故障进行特殊对待（例如:安全故障-转入信息安全管理；能力、性能方面的转入能力管 理等等）
4.2.5.2 故障记录
所有的故障必须得到进行完整地记录，不论是通过服务台的电话报障还是通过事件的自动检测发现 的故障，都需要记录当时的时间戳。 **注意：如果服务台或者技术支持人员在客户现场处理故障，他们会被要求顺便再处理一些其他故 障。如果他们确实协助处理了故障，应当确保要有额外单独的故障单纪录，以便留下故障的历史纪 录并且证明当时的工作量。 所有关于故障本身的信息都必须进行记录，这样可以确保记录完整的历史信息，当需要转给其他支 持团队时，他们可以获得所有的信息以支持他们进行处理。
分类。在相关的工具中用这些分类进行记录，并跟踪一段时间。 3. 跟踪这些分类的使用一段时间后（要足够长，直到记录了数百个故障并且基本上落在各分类下。
但是也不能太长，致使要花太长的时间进行分析）。 4. 对这段跟踪期内的故障记录进行分析。在每个顶层分类下记录的故障数能够表明哪些分类应该保
留，同时要对“其他”分类下的故障进行分析，以确定是否有必要在顶层分类中进行补充增加。 5. 对每个顶层分类下的故障进行细目分析，以确定下面的子级分类。 6. 在接下来一段时间内（1~3个月内）回顾并重复上述步骤，逐步确定这些分类是恰当地。注意：对
4.2.1 目标
故障管理的目标是“尽快恢复服务到正常运行，并且最小化对业务运营的不利影响，从而尽可能地保 证服务质量和可用性的水平”。服务的正常运行，在这里是指符合SLA约定的服务运行水平。
4.2.2 范围
故障管理的范围: 任何已经或者可能导致服务中断的事件。事件可能是直接从用户报告的，或者通过服务台，或者通 过事件管理工具到故障管理的。也可能来自技术部门的同事记录的故障（例如：注意到硬件或网络 组件的不太正常，他们可能记录或向服务台报告故障）。并不是所有的事件都会成为故障，只有那 种已经或者可能对服务产生影响的事件才会进故障管理流程。
故障模式应该包括以下方面： 处理故障时所需采取的步骤； 按照时序排列步骤，并且考虑到所有的关联性。 职责分派，谁应该做什么。 各任务完成的时间表和期限要求。 升级程序；应该在什么时间联系谁？ 所有必要的证据保全活动（特别是针对安全或性能相关的故障）
4.2.4.3 重大故障
对于“重大”的故障，应该有另外的处理程序，相应要求的处理时间更短、紧急度更高。 定义哪些事件属于重大故障，必须能够很好地映射到整个故障优先级系统。 **注意：重大故障不等同于问题。因为重大故障仍然属于故障管理，它的目标是尽快地恢复服务。 必要时，重大故障程序应该包括建立故障经理领导下的动态的独立的重大故障小组，系统地关注于
4.2.4 政策/原则/基本概念
4.2.4.1 时间表
必须根据SLA中响应和处目标，制定故障处理的各个阶段的时间要求（根据故障的优先级不同，各 有不同）。并且落实到OLA和UC的目标中。 所有的支持团队必须知晓时间要求。 服务管理工具应该能够进行的自动的时间计算，并且根据事先定义好的规则进行故障的升级。
4.2 故障管理.................................................................................................................................. 1 4.2.1 目标............................................................................................................................... 1 4.2.2 范围............................................................................................................................... 1 4.2.3 流程的价值................................................................................................................... 2 4.2.4 政策/原则/基本概念...................................................................................................... 2 4.2.5 流程活动、方法、技术................................................................................................ 3 4.2.6 触发、输入、输出以及流程间的接口 ....................................................................... 7 4.2.7 信息管理....................................................................................................................... 8 4.2.8 测量指标....................................................................................................................... 9 4.2.9 挑战，关键成功因素和风险....................................................................................... 9