ITIL 重大事件管理流程及真实案例

视频转录

提升您的重大事件管理（MIM）流程

现在，让我们进入第二个场景，即处理 重大事件 并让您的服务恢复上线。作为组织，我们其实并不喜欢重大事件，对吧？我们尽量避免它们，但最好是提前预见这些事件的发生，并制定应对策略，否则只会带来混乱和困惑。在这个真实案例中，我们来看一个没有事件管理策略的组织，看看他们如何应对重大事件。

案例研究：重大可用性事件冲击一家网络性能公司

这是我们的案例研究。我们有一家提供 CDN、DNS 和 DDoS 保护的网络性能与安全公司，服务众多网站。作为标准操作流程，该公司的防火墙团队定期在其 Web 应用防火墙中部署新规则，以应对互联网中的新安全漏洞。在一次例行更新中，一名工程师的小改动导致服务器 CPU 使用率飙升，全球一半的网站瘫痪。客户看到的是 502 错误网关。正如您所见，这是最高级别的重大事件。

他们的事件团队正在调试情况

让我们按时间线分解事件序列，看看组织如何应对。13:42，故障发生，服务中断。随即，他们收到来自不同监控工具的警报，生成了服务中断警报、财务错误警报等。事件发生 8 分钟后，SRE 团队意识到出现了问题，此时已有 80% 的流量中断。

他们推测是外部攻击，最终宣布重大事件，意识到事件影响。伦敦工程团队收到全球故障警报，整个期间支持团队电话不断，工单大量涌入。事件发生 33 分钟后，成立了一个由多个团队成员组成的 事件响应 团队。让我再说一遍，在混乱高峰期，重大事件发生 33 分钟后才组建事件响应团队。这是一个重大瓶颈。

该 IRT 团队承受管理层巨大压力，但仍未找到根本原因。近一小时后，他们排除了外部攻击可能性，最终发现问题出在 WAF。实施全球 WAF 关闭，网站恢复上线。整个时间线中，识别事件、组建团队、与利益相关者沟通和事件分级等环节都存在重大障碍。我们如何克服这些瓶颈，确保业务不受影响？

重大可用性事件管理框架

这是 Zoho 用于应对重大事件的最佳实践工作流程。首先从监控工具检测警报，将其转换为服务台工具中的工单。警报生成后，识别为重大事件，随后与 CIO、CTO 或 IRT 经理等利益相关者沟通，启动事件分级流程。接着评估事件影响，决定是否宣布重大事件。此时，最终用户可能因无法访问关键业务服务而恐慌。

您需要向外部用户发布公告，说明发生事件并正在处理。随后创建不同任务，分配给相应解决组，提供临时解决方案，确保服务恢复上线。至此，事件管理阶段结束。

接下来需要进行根本原因分析，确保重大事件不再复发。为此，需要创建问题工单。

使用 ServiceDesk Plus 的重大可用性事件管理框架

这就是有效处理重大事件的方法。现在，让我们看看如何利用 ServiceDesk Plus 实现同样的效果。

您屏幕上看到的是 ManageEngine 的网络监控软件 OpManager。您可以 将 OpManager 与 ServiceDesk Plus 集成，确保监控警报生成时自动转换为 ServiceDesk Plus 中的工单。当前显示的正是该实现效果。监控警报一生成，工单即反映在 ServiceDesk Plus 中，包含事件简要描述，几乎与之前服务请求中所见相同。

下一步是与利益相关者沟通，告知重大事件。这里我们再次使用自动化，但这次是业务规则。业务规则是基于条件的操作，确保重大事件沟通无延迟。工单主题为“edified”、“not detected”或“website down”时，将执行一系列操作，如将优先级设置为重大事件，分配至相应支持组以启动故障排查。还可向特定利益相关者发送邮件或短信通知。由此可见，实时沟通利益相关者非常简单，消除了重大瓶颈。

让我回到最佳实践工作流程，展示当前进度。我们已检测到重大事件，并立即与利益相关者沟通。下一步是评估损害并宣布重大事件。我们看到多个工单和监控警报被创建，转化为多个工单。您可以将这些工单关联起来，确保对重大事件进行排查。

如您右侧所见，所有受影响资产均关联至该事件工单。点击这些资产后，显示详细资产信息，包括硬件、软件信息及关系，均来自 CMDB。这有助于判断是否会影响重大服务。比如，位于德里的管理服务将受影响，因为该服务器承载了这两个服务。

接下来，我们将向利益相关者传达该事件。进入技术员主页，点击“添加新公告”。您可以创建新公告，设置显示时间范围，并选择仅向特定受影响用户组展示。比如，某地某部门用户受影响，其他用户可继续工作，受影响用户会收到通知。

再次回到最佳实践工作流程，看看进展。我们已检测重大事件，进行了沟通，评估了影响，并通过公告传达。剩下的就是分配任务，启动故障排查流程，提供临时解决方案。为此，返回事件工单，点击任务。之前在服务请求中已详细讨论任务。

同样，您可以创建不同任务，分配给不同组，确保配置正确依赖关系。依赖关系非常重要，因为事件分级必不可少，重大事件需遵循既定流程。任务完成并提供临时解决方案后，需将其添加至解决方案中。若之前未记录，可添加至知识库，帮助应对未来同类事件。

现在，我们已完成事件管理的边界或领域。剩下的就是创建问题工单，启动根本原因分析，查明事件根源。点击此处的关联，选择“创建新问题”。所有详情将被带入，您可创建新问题，技术员或相应技术组将进行根因分析。就是这么简单。看起来很容易，对吧？我们已克服网络性能公司面临的所有瓶颈，确保理解并将最佳实践应用于您的 ITSM 方法，具备正确能力。

与之前的服务请求一样，我们需要跟踪一些关键指标。这非常重要，只有这样您才能了解策略中的缺口及其弥补情况。

这里有工单量、技术员生产力、解决时间以及工单流转率。我建议您为重大事件管理创建专属仪表盘。比如，我创建了一个重大事件管理仪表盘，实时显示按类别、技术员划分的重大事件及技术员关闭的事件数量。至此，我们第二个场景结束。现在您应该有信心应对未来任何重大事件。