加速IT事件的根本原因分析

对于任何 IT 团队来说，事件解决后的那一刻可能是最放松的。当您的系统最终正常运行时，它会让整个组织放心，但最艰巨的任务尚未到来：根本原因分析 (RCA)。类似于足球队观看以前的比赛以查明改进领域，根本原因分析通过数据并找出最初导致事件的原因。

分析问题的根本原因对组织来说是一项独特的挑战。可能有许多因素使这个过程变得更加困难，从太多的警报到缺乏文档。也许最有害的是没有一个固定的程序。许多组织的事件计划都缺少这一关键步骤。任何好的事件计划都包括一个用于根本原因分析的过程，而不仅仅是一个要求。

请注意，在开始根本原因分析过程之前，在事件解决期间可以做一些事情。这些任务使根本原因分析更容易；例如分配和定义角色、建立最佳实践以及利用可用工具。虽然，每个企业都会根据其功能和规模的不同而有不同的需求。通过明确定义每个角色的角色、功能和范围来避免重大事件。以下是每个组织应具备的几个关键角色：

组织中有效根本原因分析的关键角色

事件线索

事件负责人将充当队长，因为每个事件应该只有一个事件负责人。拥有强大的指挥技能和事件管理经验至关重要。他们还应该能够理解问题的诊断和解决方法。他们的一般知识应该从系统监控和诊断工具扩展到应用程序和基础设施组件，以及可用的工程工具。 他们会将资源引导到最需要的地方，并根据需要推动所有问题解决行动。由于这是有效负责的角色，他们将负责收集最终根本原因分析所需的数据。

服务主管

服务主管将帮助指导恢复工作，并根据他们对业务重要性的了解确定优先级。他们应该是经验丰富的工程师或经理，了解受影响服务的系统方面和交付要求。他们还应该熟悉并能够指导服务恢复例程和程序。 服务负责人会知道必须考虑和解决的潜在下游影响。 此外，他们必须知道必须与哪些业务部门和联系人合作，以最大程度地减少事故处理期间的影响。

技术主管

技术主管是专家或主题专家。这通常是对生产环境有充分了解的高级高级工程师。他们的工作是在他们的组件领域（例如存储、网络、DBMS 等）诊断并领导解决问题的工作。整个组织的技术主管必须相互协调和沟通，以解决可能存在于组件区域之间或之外的问题。

根本原因分析的最佳实践

现在已经定义了所有角色，重要的是概述团队在事件解决过程中应遵循的一些最佳实践，以使根本原因分析 (RCA) 更容易。

• 如果根本原因无法追溯，这是最常见的原因之一。如果您有多个团队同时进行更改，则很难评估哪个团队解决了问题。事件负责人必须仔细跟踪团队修复系统的内容、时间和顺序。
• 在恢复过程中，首要也是唯一的优先事项应该是解决事件并记录可能的根本原因。大多数根本原因分析 (RCA) 工作都是在服务恢复后很久才进行的，并且有了适当的文档，它可以使过程变得更加容易。
• 系统文档的一部分应该是配置信息。能够查看是否有可能导致错误的更改非常重要。以及监视哪些更改解决了问题。这对于防止未来可能发生的事件很重要。解决问题的最快方法是恢复到上次已知的稳定配置。您可以使用配置管理工具来检测计划外的更改并评估更改的内容和时间。正向设计解决方案可能很诱人，但它不应该是您唯一的选择，因为巨大的变化可能会导致无法预料的问题。
• 建立明确的指挥线并确保执行。业务方最好不要参与技术电话。技术数据可能是压倒性的，并可能导致误解。
• 在合理和可能的情况下并行工作。这应该包括产生并行活动以工作多个合理的解决方案或备份。但是，重要的是要记住在实际执行时“一次更改”的做法。

管理警报

警报过多会使根本原因分析变得更加困难。有一些方法可以减少可能掩盖事件根本原因的警报噪音量。一般的经验法则是确保活动警报仅针对可操作的项目。

• 如果通知没有使您立即采取行动，则不应向您发出警报。例如，关于 CPU 使用率或内存空间的警报。如果你一直忽视警报，很可能有一天一个重要的警报会从裂缝中溜走。更有帮助的是接收每日报告，为您提供一般系统指标，以便您知道如何处理以防止事件发生。
• 自动化报告使日常流程变得更容易，因此不会遗漏 任何事情，也不会因为不紧急的事情而引发警报。

利用操作系统

确保您以最佳方式使用您的工具是加快事件解决和根本原因分析的关键。

• 与通知管理器集成可以简化待命安排，并提供一种不依赖于内部邮件基础设施的警报分发方式。
• 如果您正在使用 ServiceNow 或 RemedyForce 等票务或 ITSM 系统，则应确保您的计划包括将这些系统与您的监控和警报系统以及事件管理流程集成。

结论

根本原因分析对于更快地解决未来事件并防止它们再次发生非常重要。通过在您的解决计划中实施上述内容，它将使组织更加高效和优化。通过其自动报告和集成平台为您提供了轻松实现这一目标的关键。