AdvancedITIL: 服务支持度量标准
主办者:
服务支持度量标准
故障管理
第 6 章
《ITIL 服务支持》中的“故障管理”一节讨论从两个方面进行测定和监视：管理信息和比照“服务级别”的性能优劣。首先我们来看管理信息，然后再来讨论“服务级别”。
对于管理信息，请记住 ITIL 的故障管理目标：
“故障管理的目标就是尽量减少由 IT 基础设施出现问题而导致的事故和故障对业务产生的负面影响，并防止与这些错误相关的事故再度出现。”“为了达到此目标，故障管理寻求找到引发事故的根源，并随后采取措施改善或纠正此情况。”
在 ITIL 中还说明了应该从被动和主动两个角度进行故障管理：
“故障管理流程有被动和主动两个方面。被动方面是指作为对出现的一个或多个事故的反应来解决故障。主动故障管理是指在出现事故前预先确定并解决故障和已知错误”。
用于衡量管理信息的大多数度量标准的用意并不是如此直接，而是用于获取就员工工作量和 IT 质量作出决策所需的信息。如果通过主动故障管理发现了潜在的缺陷和/或进行干预以更改行动过程，这些度量标准通常用于获取进行证明所需的有用信息。ITIL 推荐用以下度量标准进行测定：
- 变更请求的数量上升了，而这些变更请求对服务可用性和可靠性产生的影响却被掩盖了起来。
- 每个公司的部门或供应商用在调查和诊断上的时间（按故障类型划分）。
- 查明根本故障或确认已知错误之前出现的事故的数量和影响。
- 故障管理中直接（被动）支持与计划支持间的比率。
- 未解决故障的解决方案涉及以下资源：
- 人员
- 其他已用资源
- 成本（相对于预算）
- 将要采取的行为的简短描述。
这些度量标准可能会在任何特定时段内发生变动，这取决于故障的数量。引发变动的因素可能多种多样，包括实施新系统和新服务、升级系统和服务、新变更、软件的新版本以及其他更新所引起的新故障。切记其目的就是为了消除故障。对于刚刚实施 ITIL 的公司，与那些先行采用 ITIL 从而已大大减少其故障的公司相比，其信息管理度量标准通常远未达标。
我们分别介绍每个度量标准：
变更请求的数量上升了，而这些变更请求对服务可用性和可靠性产生的影响却被掩盖了起来。该度量标准的第一部分规定变更请求 (RFC) 数量的上升是由故障管理引起的，并且是是一个非常简单的指导方针。第二部分则不同，需要相似但实际不同的度量标准。该指标与影响有关，但并未指明影响是自上个报告以来新 RFC 数量的上升所致（潜在影响），还是自上个报告以来实施 RFC 的结果。如果假设这两种情况都包括，那么我们需要制定用以测定自上个报告以来发生的 RFC 的合理性的标准，并制定用以验证自上个报告以来已实施的变更的标准。
对于自上个报告后由于进行故障管理而导致的变更，用以对 RFC 合理性进行测定的标准所产生的影响与用以对已实施的 RFC 验证 进行测定的标准所产生的实际效果之间的差异尚未得到确定。通过此分析，我们可以更好地理解由进行故障管理而导致的变更所造成的影响。例如，如果根据服务台每天遇到的事故数量减少 50 起来证明 原始 RFC 的合理性，但经验证 服务台每天遇到的事故数量只减少了 30 起，那么我们可能需要重新审视该证明 方法。
- 业务取向指标 — 客户必须接收（或者能够在线查看）已经提交的关于所有 RFC 的定期报告及更新，这些报告和更新将对有关其服务的可用性和可靠性所产生的冲突产生影响。还应该向客户征求有关 RFC 验证和证明测定标准的信息和看法。
每个公司的部门或供应商用在调查和诊断上的时间（按故障类型划分）。经理和项目经理可以利用此测定标准确定其员工查找故障根源所耗费的时间和作出的努力。对于经理和项目经理而言，这是非常重要的数据。该数据有助于他们更好地控制当前和未来的员工工作量，并可由经理和项目经理用以计算在特定 RFC 上其员工的开销。
- 业务取向指标 — 业务经理需要查看此报告。切记将协助调查和诊断的业务群体成员所花费的全部时间包括在内。
查明根本故障或确认已知错误之前出现的事故的数量和影响。在我们讨论该测定标准前进行一下澄清是有益的。在 ITIL 中说明了当发生新事故时应该打开故障记录。每当出现与故障相关的新事故时都应该更新故障记录，并将故障记录中“事故”字段中的数量增加 1。此数据非常重要，因为事故的数量及其影响可以改变故障的优先级。例如，对于每天仅引发两起事故并对业务影响较小的故障可能会分配较低的优先级。然而，如果事故数量突然增加到每天 50 起，那么故障的优先级也会相应增加。同样，每天仅引发两起事故但对业务影响较大的故障的优先级可能会很高。
这是一个关键的报告，需要完全集成的“事故管理”和“故障管理”技术。此报告应该发送给所有的 IT 经理。
- 业务取向指标 — 对于需要了解故障数量以及故障对各自业务范围所产生影响的业务经理，此报告同样重要。业务经理需要确保他们的优先级能够得到满足。理想状态下，业务经理应该能够在线查看此报告，并且当影响其业务范围的新故障的发生次数增加时，这些业务经理应该能够迅速地得到通知。
故障管理中直接（被动）支持与计划支持间的比率。下面我们将再次讨论工作量，但所用的方法更为结构化。ITIL 建议所有的支持小组都应花时间进行故障管理，以确保能够为消除故障争取足够的时间。这些时间通常耗费在为主动和被动活动进行分配的过程中。不幸的是，IT 通常会以经常与推荐的模式相悖的模式来运行。例如，员工将立即处理那些除非确定根源并实施永久解决方案之后才能解决的事故。IT 经理可以利用此报告复查直接支持和计划支持的比率，以便可以改善将来的工作量计划工作。
- 业务取向指标 — 起初您可能认为业务经理对此报告不会感兴趣。然而，如果业务经理可为其支持工作得到报酬（例如通过费用分摊），那么他们可能会对此报告非常感兴趣。业务经理应该能够收到此报告，如果可能还可以在线查看此报告。
未解决故障的解决方案涉及的资源包括人员、其他已用资源，以及成本（相对于预算）。所有 IT 部门都必须提交此报告，但是只有在已经为故障管理作出预算且已掌握作出报告的技术时才能创建此报告。作为计划文档，此报告非常重要。
- 业务取向指标 — 因为要了解成本要素，业务经理需要查看此报告。此外，此度量标准中提到的“人员和其他资源”可能包括业务方面的人员或资源。业务经理应该能够收到此报告，而且在理想状态下还可以在线查看此报告。
将要采取的行为的简短描述。因为该报告篇幅可能很长，可能需要花费很长时间才能读完，所以此报告应该作为参考，并将其发布到网上，以便用于管理访问。例如，如果有 50 个尚未处理的故障，那么将有 50 项将要采取的行为的说明。经理将会只对一或两个故障所采取的行为感兴趣，这些故障是为进行故障管理而作出的其他管理报告中所重点强调的。
- 业务取向指标 — 如果业务经理能够收到其他报告，那么他们还应该收到此报告，最好是在线接收。
上述管理信息报告非常重要，因为从中可加深对管理工作的理解。其中还有关键计划数据，特别是支持员工工作量方面的数据。然而，要对故障管理进行控制，我们还需要 ITIL 推荐的更多详细报告，具体如下：
- 故障数量和错误数量的分类如下：
- 状态
- 服务
- 影响
- 种类
- 用户/业务组
- 已查明故障的总用时。
- 到目前为止在尚在对其进行处理的故障上所耗费的时间。
- 从打开故障记录开始直到查明故障或确认“已知”错误的平均用时和最长用时，按影响代码和支持小组（包括供应商）分类。
- 任何临时的排除故障的行为。
- 尚未得到处理的故障的预期解决时间。
假设您已经掌握了必要的技术，在“故障管理”流程中可能需要提交上述报告。仔细查看这些报告可能会看出：
故障和错误的数量的分类为：状态、服务、影响、种类和用户/业务组。虽然此报告只含有总体统计数字，但它很有用，因为可用其将故障分成若干不同的种类。上述种类只是推荐的分类。可随意添加您的公司特别感兴趣的种类，如技术或供应商。参加“故障管理”会议的“服务管理”人员和来自不同“支持小组”的代表会用到此报告中的数据。
- 业务取向指标 — 业务群体可能对作出这些种类中的大多数报告并不感兴趣，而“用户/业务组”却脱不了干系，并且应该将其提交给高级业务经理。可询问业务经理，以便确定他们是否还希望进行其他的分类。
已查明故障的总用时。在此报告中应列出自上个报告或时间段以来所有已查明的故障，列出每个已查明故障的总用时并在结尾进行摘要汇总。此数据对于将来进行工作量计划的工作很有用。
- 业务取向指标 — 应该将此报告提交给业务经理，用作可以从中查看所用时间的“异常报告”。
到目前为止在尚在对其进行处理的故障上所耗费的时间。此报告与上一个报告类似，但列出的是未解决的而不是已查明故障的状态。在此报告末尾的摘要汇总中所列的是所有未解决故障的总用时。此数据对于将来进行工作量计划工作很有用。
- 业务取向指标 — 应该将此报告提交给业务经理，用作可以从中查看所用时间的“异常报告”。如果业务经理认为在解决对于业务不重要的故障上浪费了时间，那就应该进行干预。
从打开故障记录开始直到查明“故障”或确认“已知”错误的平均用时和最长用时，按影响代码和支持小组（包括供应商）分类。平均用时和最长用时是很有用的，但也是容易令人误解的。应用此数据时务必小心，并一定不要只根据此数据安排将来的员工工作量。
- 业务取向指标 — 与其认为这是是业务取向，不如将其视为一个警告。请注意不要让业务经理曲解此数据，并误将其视为用于衡量查明其特殊故障的平均用时。您也可不将此报告提交给业务经理。如果确实要提交报告，那就需要澄清这些是基本计划指标而不必受其约束。
任何临时的排除故障的行为。临时排除故障行为 — 例如，经安装“修补程序”用以消除事故的行为，但其不是正式的或已批准的解决方案 — 也称为规避方法。此报告是很重要的，因为一旦将临时解决方案用于排除故障，支持小组可能禁不住想忽略该故障，而不是继续寻求和实施已批准的长期解决方案。应该将此报告提交给所有服务和支持小组经理，以确保执行的是已批准的解决方案而不是临时行动。当提出使用新版软件的理由或使用新版软件时，此报告尤为重要。例如，使用新版软件的关键理由可能就是减少应用临时解决方案的次数。同样，利用此报告可确保所有适当的临时解决方案都会应用到新版本中。
- 业务取向指标 — 业务经理是否需要了解临时解决方案，这一点是有争议的。大多数情况下，如果修补程序有助于他们排除故障，那么他们就不会在乎进行更持久的修复。然而，如果是有偿劳动，那么他们可能就会乐于对此报告进行分析。
尚未得到处理的故障的预期解决时间。在对每个故障作出的起因报告中将说明预期的解决时间。负责排除故障的人员应该能够通过复查每个尚未得到处理的故障的状态算出预期的解决用时长度。对于服务和支持小组经理，这是一个很重要的报告，因为此报告有助于他们安排短期工作量。
- 业务取向指标 — 业务经理在下列情况下才会查看此报告：他们为此将获得报酬，他们有迅速锁定故障的迫切需要，他们已经为其进行工作，或他们是 IT 计划人员。否则，业务经理通常对此报告不感兴趣。
虽然您可以精确地安排 IT 其他方面的工作，但您无法为故障及其影响作出充分的准备。然而，故障管理报告有助于公司改进其对故障的处理方式。
> > 第 7 章 - 变更管理