ITIL定义了故障管理流程中的关键活动，如下所示:

ITIL定义了故障管理流程中的关键活动，如下所示:
 
●故障识别和记录
 
●分类和最初支持
 
●调查和诊断
 
●解决和恢复
 
●故障关闭
 
●故障所有权、监控、跟踪和沟通



这个列表是有序的，在故障识别之前，什么都做不了，故障分类要在调查和诊断之前，只有经过最初调查之后，才可以执行解决和恢复，以此类推。我们完全同意，这个列表中列出的行动都是必需的，但如果你的组织不是由OGC严格管控的组织，而你也不需要OGC认证的证书，那么可以对这些活动的顺序进行一些调整，这样可以加速事件的恢复。首先，我们希望对上述活动提供一个简化的定义。

所谓故障识别和记录，就是识别出一个影响用户或系统运营的故障，然后把它记录在案。这两个行动都非常重要，许多公司都有很多方法让这两个行动完成得又快又好。故障识别就是监控系统。你是否对客户行为有监控，以便在发生第-一起客户投诉之前就识别出问题?你衡量事情的方法是否与客户采用的一样?根据我们的经验，在系统中试验执行真正的客户交易，并衡量一段时间内交易的结果和交易的响应时间是否符合预期(它们返回的数据对吗?它们的操作时间是否像你预期的那样快?)，这样做非常重要。
 
成熟的监控框架 我们见过太多的客户，实施的监控方案是为了告诉他们所面对的所有潜在问题的根本原因。这种实施方案听起来很好，但很少是有效的。监控失 败在很大程度上是由两个问题造成的:
 
●他们尝试监控的系统并未被设计为能够监控的。

●公司并没有以有计划、有条理的方式实施监控。如果没有把平台设计为能够监控的，那么就不应该期望能够通过监控系统(或故障识别系统)正确地识别故障，设计良好的系统，会在代码和系统中内置监控和故障通知的功能。例如，世界一流的实时监控解决方案具有把每个内部调用服务的时间和错误记录在案的功能。这里所说的服务可能是调用数据存储或另一个Web服务来显示账户信息，等等。它还可以在控制面板上把所花费的时间、频率和错误类型用一个统计性的进程控制图实时地绘制出来，并突出显示超出控制上限或控制下限的数据作为警告。

把系统设计为能够监控的，虽然必要，但对于迅速地识别和解决故障还不够。你还需要一个系统，能够从客户的角度识别事件，并识别出造成问题的背后系统。

可惜的是，太多公司都省略了从客户角度监控系统这一步骤。需要构建或者组成一个能够以与客户同样的方式与平台进行交互的实时系统，执行最关键的交易。当系统的响应时间和可用性超出了内部制定的服务水平时，要给出警告。

接下来，要做的是帮助识别造成故障的系统。在理想状况下，你设计的是一个故障隔离的架构，会创造出故障域，把故障隔离起来，这样有助于你确认哪里发生了故障。如果没有做到这一点，就需要一个监控系统，能够指示大概要查看的区域。通常这是一个统计汇总系统，会统计负载、CPU或内存的使用情况。

要注意，我们的第一步不仅仅是识别故障，还要记录故障。许多公司正确识别了故障后，在采取其他行动之前，却没有立即把它们记录下来，或者根本没有记录问题的系统。最好的方法是有一个自动的系统，能够立即记录故障和它发生的时间，这样可以让操作员有时间执行流程剩下的操作。

在ITIL中，接下来的行动是对故障进行分类并提供最初的支持，但我们认为在许多公司中，这一步只不过是“让正确的人参与进来”。据我们看，分类这一活动可以在故障解决之后再进行。调查和诊断之后是解决和恢复。简而言之，这些步骤所做的就是识别什么服务发生了故障，没有响应(调查和诊断)，于是我们立刻重启了该服务器(解抉)，系统就恢复了(恢复)然后采取正确的步骤把该服务恢复回正常的运转状态。例如，这些步骤可能是确定了应用服务器跟进、沟通、跟踪以及监控。故障关闭是把所有与故障相关的信息都记录到日志中。最后的步骤包括指派个负责人继续跟进。

对于小公同来说，不论有没有采用ITIL.都可以采用它。在实施故障管理时，我们通常推荐采用一种易于记住的缩写.虽然ITIL并不支持我这一缩写是DRIER，它代表的是:

●通过监控或客户反馈来识别(Delce)故障
 
●报告(Report)故障，或者把它录入负责跟踪所有故障和失败等的系统中
 
●调查(Investigate)故障，决定应该做什么

●如果没有及时解决故障，就是把它升级(Escalate)

●通过恢复最终用户使用的功能并把所有信息记人日志以便跟进，从而解决(Resolve)故障决
在制定DRIER时，我们尝试着让客户更容易理解如何才能有效地实施事件管理。需要注意的是，虽然我们在DRIER中删除了故障分类这一步，但我们仍然希望能够执行这些操作，以便从系统中获取数据，有助于通知其他的流程。我们建议在故障管理每天的例会上进行这一分类操作。