故障管理步骤

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

ITIL定义了故障管理过程中的关键活动如下：●故障识别和记录●分类和初始支持●调查和诊断●解决和恢复●故障关闭●故障所有权，监控，跟踪和通信此列表可用前言在确定故障之前，什么也做不了。故障分类应在调查和诊断之前进行。只有在初步调查后才能执行解决方案和恢复，等等。我们完全同意此列表中列出的操作是必需的，但如果您的组织不是受OGC监管的组织且您不需要OGC认证的证书，则可以对这些活动的顺序进行一些调整。这将加速事件的恢复。首先，我们希望提供上述活动的简化定义。所谓的故障识别和记录是识别影响用户或系统操作的故障，然后进行记录。这两项行动都非常重要，许多公司都有很多方法可以快速，顺利地完成这两项行动。故障识别是监控系统。您是否监控客户行为，以便在客户投诉发生之前发现问题？您是否正在测量与客户相同的东西？根据我们的经验，在系统中试验真实的客户交易，并且重要的是在一段时间内测量交易的结果和交易的响应时间（他们是否正确地返回数据？他们的操作时间是否正确）和你预期的一样快？）成熟的监控框架我们已经看到太多的客户并实施了监控程序，以告诉他们所面临的所有潜在问题的根本原因。这种实现听起来很棒，但很少有效。监控故障主要是由两个问题引起的。●他们试图监控的系统不是为监控而设计的。 ●公司未按计划有组织地实施监控。 如果平台不是设计用于监控，则不应期望通过监控系统（或故障识别系统）正确识别故障，监控系统是一个设计良好的系统，具有内置监控和故障通知功能。代码和系统。例如，世界级的实时监控解决方案能够记录每个内部呼叫服务的时间和错误。这里提到的服务可能是调用数据存储或其他Web服务来显示帐户信息，等等。它还可以使用统计过程控制图实时绘制控制面板上花费的时间，频率和错误类型，并突出显示超出控制上限或下限的数据作为警告。尽管有必要，将系统设计为能够进行监控还不足以快速识别和解决故障。您还需要一个系统，从客户的角度识别事件并识别问题背后的系统。遗憾的是，有太多公司从客户的角度省略了监控系统的步骤。您需要构建或组合一个与客户交互的实时系统，以与客户相同的方式执行最关键的交易。当系统的响应时间和可用性超过内部建立的服务级别时，将发出警告。接下来，您需要做的是帮助识别导致失败的系统。理想情况下，您正在设计一个故障隔离架构，该架构可创建故障域并隔离故障，从而帮助您识别故障发生的位置。如果不这样做，则需要一个可以指示您正在查看的区域的监控系统。通常这是一个统计汇总系统，用于计算负载，CPU或内存使用情况。值得注意的是，我们的第一步不仅是识别故障，还要记录故障。在许多公司正确识别出故障之后，他们没有在采取其他行动之前立即记录故障，或者根本没有记录问题的系统。最好的方法是建立一个自动系统，立即记录故障和发生的时间，让操作员有时间执行剩余的过程。 在ITIL中，下一步是对故障进行分类并提供初始支持，但我们相信在许多公司中，这一步骤只不过是“让合适的人参与”。根据我们的观点，可以在故障解决后进行该活动的分类。调查和诊断之后是解决和恢复。简而言之，这些步骤的作用是确定哪些服务失败，没有响应（调查和诊断），因此我们立即重启服务器（已解决），系统恢复（恢复）并采取正确的步骤恢复服务正常运转。例如，这些步骤可以用于确定应用服务器跟进，通信，跟踪和监视。故障关闭是将所有与故障相关的信息记录到日志中。最后一步是指派负责人跟进。对于小公众来说，它可以在有或没有ITIL的情况下使用。在实施故障管理时，我们通常建议使用易于记忆的缩写。虽然ITIL不支持我，但这个缩写是DRIER，代表: ●通过监控或客户反馈识别（泄漏）故障●报告（报告）故障，或将其输入负责跟踪所有故障和故障的系统等。●调查故障并确定要执行的操作。 ●如果故障未及时解决，请升级（升级）●恢复最终用户的使用。功能和记录所有后续信息，以解决问题。在开发DRIER时，我们尝试让客户更容易理解如何有效地实施事件管理。应该注意的是，尽管我们删除了DRIER中的故障分类步骤，但我们仍然希望能够执行这些操作以从系统获取网站建设数据，这有助于通知其他进程。我们在日常的故障管理会议上推荐这种分类。