ITIL 重大事件管理全面指南

星期一早晨，您的服务台一切正常。突然，您收到一个警报工单，提示关键服务宕机，接下来的 15 分钟内，您开始收到大量报告同一问题的工单。可能是您的网站宕机，销售点软件停止工作，或者更严重的情况，比如股市停摆或飞机停飞。当 IT 问题严重影响您的业务，导致收入和/或声誉损失时，您正面临重大事件。

您对重大事件的反应决定了减少事件影响和恢复服务的效果。俗话说，时间就是金钱，这句话在这里尤为真实。如果您的组织已有重大事件管理（MIM）流程，您可以迅速响应并 解决重大事件。如果没有这样的流程，现在是制定应急响应计划，也称为重大 事件响应流程 的时候了。

重大事件的风险比以往任何时候都高，根据 Information Technology Intelligence Consulting 的一项研究，98% 的组织因一小时的停机损失至少 10 万美元。这进一步强调了建立有效且高效应对重大事件的 MIM 流程的重要性。

每个组织都希望消除重大事件，但事实是重大事件无法完全预防，您唯一能做的就是做好准备。

本指南将介绍如何建立有效的 MIM 流程、可能影响您组织 MIM 的常见错误以及改进 MIM 流程的最佳实践。

但首先，什么使得一个事件成为重大事件？

重大事件是高影响、紧急的问题，通常影响整个组织或其主要部分。重大事件几乎总是导致组织服务不可用，进而影响组织业务并最终影响其财务状况。重大事件影响组织服务的方式有两种：

• 阻止客户访问组织的服务。2019 年 7 月的 Cloudflare 宕机就是客户受重大事件影响的例子。此次重大宕机影响了近半数互联网用户，导致数百万互联网用户无法访问各种服务。
• 干扰员工按时完成工作，导致业务中断。2019 年 11 月 IndiGo 宕机影响了航空公司的值机流程，导致长时间延误，影响了数千名乘客。

充分准备的服务台能够评估重大事件，并提出解决方案或变通方法，以减少和控制重大事件的影响。

重大事件管理流程是组织必备的，因为它帮助组织将重大事件对业务的影响降到最低。重大事件管理流程主要包括以下步骤：

阶段 1：识别

宣布重大事件：

第一步是识别可能的重大事件。组织应建立多种识别威胁的方法。技术人员在遇到异常工单时可以标记重大事件，或者通过网络监控工具等解决方案自动标记网络问题并创建工单以提醒服务台。组织还可以为服务台人员设置专用热线，以标记疑似重大事件。

通知相关方：

一旦确认重大事件，需要将其传达给所有关键利益相关者。需要通知重大事件的主要有四个群体：

• 技术团队：立即通知技术团队非常重要，以便他们开始决定解决问题的行动方案。
• 管理层：让高级管理层（如CIO）了解重大事件有助于责任落实。组织还应向管理层通报解决重大事件所采取的所有步骤。
• 关键利益相关者：部门负责人和服务级别业务管理人员也需要被告知重大事件，并定期收到状态更新。
• 用户：用户需要知道哪些服务可能因重大事件而不可用。

阶段2：遏制

组建重大事件团队

重大事件团队（简称MIT）由技术人员、服务级别管理负责人和其他关键利益相关者组成；有时会引入高技能的外部人员来处理重大事件。MIT共同努力，寻找解决重大事件的方法，使运营恢复正常。

设置会议桥接

会议桥接，通常称为电话会议，有助于有效的故障排除和集中沟通。它作为MIT成员之间清晰、快速的沟通渠道。

准备指定的战情室

设立指定的战情室使MIT所有成员能够聚集并排查事件。这增强了协作，有助于MIT更快地提出解决方案。

创建问题工单以识别根本问题

可以创建问题工单以发现和理解重大事件的根本原因。通过解决重大事件的原因，有助于防止未来发生类似的重大事件。

阶段4：维护

进行实施后评审

重要的是在一段时间内对事件进行总结，确保其真正解决。如果根本问题未解决，可能导致另一次重大事件。

制作清晰的文档

记录解决重大事件的整个过程，有助于组织为未来类似事件做好准备。通过对过去事件的妥善记录，组织在遇到类似重大事件时可以立即实施经过验证的解决方案，减少其影响。

测量指标

测量服务台的绩效有助于评估服务台和MIM流程的有效性。一些重要的指标包括平均响应时间（MTTA）、平均解决时间（MTTR）、重大事件总数以及重大事件的平均停机时间。

重大事件需要一支专门的人员团队来处理和解决。MIM角色包括：

服务台技术人员

服务台技术人员是应对重大事件的第一道防线。他们分析事件工单并将其升级给事件经理。服务台技术人员还参与解决方案的实施。

重大事件经理

重大事件经理是重大事件的负责人。他们的职责包括将事件声明为重大事件，确保遵循MIM流程并尽早解决事件。他们是有关重大事件信息的主要联系人，并管理MIT。

MIT

MIT是负责分析重大事件并制定应对计划的专业团队。MIT理想成员包括服务台技术人员、服务级别管理人员、技术人员、其他相关利益相关者，以及在必要时的外部顾问。

技术人员

负责基础设施和运营维护的专业人员，包括系统管理员、网络管理员和信息安全人员，构成了组织的技术人员。技术人员协助排查重大事件，主要负责实施重大事件的解决方案。

变更经理

变更经理是负责执行重大事件修复变更的负责人。变更经理全面负责变更工单，并对此承担责任。

问题经理

如果针对重大事件创建了问题工单，问题经理负责该工单。问题经理努力确定事件的根本原因，确保事件不再发生，或至少使组织为下一次事件做好准备。

外部顾问或第三方供应商

在某些情况下，重大事件可能需要高度专业的人员来协助理解和排查事件。重大事件经理确定所需人员并将其加入MIT，以帮助减少重大事件的影响。

以下是可能阻碍您MIM流程的5个常见错误：

1. 手动沟通与升级

   到目前为止，MIM面临的最大挑战是沟通。在发生重大事件时，需要通知各相关方事件状态、严重程度以及已采取的故障排除措施。手动传达所有这些信息是一项艰巨的任务，可能导致沟通不一致，反而使情况更糟。通过自动化流程，关键相关方将在整个工单生命周期内获得通知，重大事件经理可以将全部注意力集中在解决问题上。

2. 报告重大事件的渠道无效

   每个服务台每天都会收到数十甚至数百张工单，涵盖从笔记本问题到服务请求；在这堆工单中，可能存在一些潜在的重大事件。未设置专门的渠道来报告重大事件会延迟重大事件的识别。

3. 工作重复

   未能有序地委派任务可能导致MIT内部工作重复。分配任务并让MIT成员了解各自职责非常重要。

4. 文档不完善

   缺乏适当的文档会迫使MIT在每次类似重大事件发生时重新探索解决方案，导致解决重大事件的延误和不必要的停机时间。

5. 未能分析根本原因

   类似于事件管理，MIM的视野可能较为狭隘，其主要关注点是尽快修复问题并恢复服务。如果不结合问题管理来识别潜在问题，重大事件的根本原因将持续使组织面临重大事件的风险。

以下是处理MIM流程的最佳方法

1. 启用多渠道报告重大事件

   处理重大事件时，时间至关重要。组织必须在检测到重大事件后尽快识别和分类。为用户提供多种报告事件的方式将使整个过程更快、更便捷。您可以通过电子邮件或网页门户启用工单创建，甚至设置专用热线来报告疑似重大事件。设置网络监控软件以检测异常有助于您主动应对重大事件。

2. 自动化服务台流程

   速度和效率在控制重大事件影响中起关键作用，自动化各种服务台流程有助于实现这一点，释放技术人员免于重复任务，如通知相关方。自动化通知系统和设置重大事件工作流程是自动化服务台流程、提高解决时间和规范MIM流程的有效方法。

3. 力求及时且相关的沟通

   及时向组织管理层和重要相关方通报每个重大事件非常重要。让管理层了解情况有助于获得解决重大事件所需的必要批准和权限。及时沟通确保所有重大事件人员保持信息一致，促进顺畅有效的协作；同时也让最终用户了解可能的停机时间，以便做好准备。

4. 创建清晰的文档

   清晰的文档帮助重大事件经理记录解决重大事件所做的所有工作、影响、受影响的服务及其他关键信息。该文档对于向管理层展示MIM流程的价值及其投资回报率（ROI）非常重要。清晰的文档也有助于未来处理类似的重大事件。

5. 利用与ITOM软件的深度集成

   与ITOM软件的强大集成使IT部门能够主动处理重大事件。被动的重大事件识别依赖大量工单涌入以发出重大事件正在发生的警报。另一方面，利用ITOM集成的主动MIM流程拥有监控网络和服务的系统，能够自动标记可能的重大事件异常。

需要记住，并非所有高优先级事件都是重大事件。由于 MIM 过程涉及大量资源投入，例如实施单独的 MIT，因此对重大事件进行仔细分类非常重要。

来源：https://blog.cloudflare.com/details-of-the-cloudflare-outage-on-july-2-2019/

2019 年的 Cloudflare 故障是定义重大事件的一个非常好的例子。在此案例中，更新 Web 应用防火墙 (WAF) 的托管规则的标准操作程序导致用于处理 HTTP/HTTPS 流量的 CPU 使用率在 Cloudflare 网络中的服务器上几乎达到 100%。随之而来的故障导致 Cloudflare 流量减少了 80%，影响了全球数百万互联网用户。

影响：重大

故障导致 Cloudflare 客户（及其客户）访问任何 Cloudflare 域时看到 502 错误页面。502 错误由前端 Cloudflare Web 服务器生成，这些服务器虽然仍有可用的 CPU 核心，但无法访问处理 HTTP/HTTPS 流量的进程。据估计，至少有一半的互联网在 27 分钟的停机时间内无法访问。

紧急程度：高

所有 Cloudflare 网站均无法访问，导致数千个组织和数百万用户的服务中断。故障还影响了 Cloudflare 的内部运营，阻止员工访问公司的变更管理工具和内部控制面板等各种服务。必须解决该故障以恢复正常的服务操作。

从检测到解决的事件时间线：

WAF 托管规则于 13:42 实施；三分钟后，Cloudflare 的网络运营工具开始标记流量下降，许多其他端到端的 Cloudflare 服务测试开始失败，终端用户注意到各种 502 错误，Cloudflare 收到来自全球多个城市的接入点的 CPU 资源耗尽报告。

站点可靠性工程团队、伦敦工程团队及其他相关团队被召集起来进行故障排除并制定解决方案。14:00 时，WAF 被确定为事件原因。14:07 时，实施了全球范围的 WAF 关闭以恢复流量水平。

到 14:52，Cloudflare 完全确认已了解故障原因并实施了解决方案，因此全球范围内重新启用了 WAF。

从 Zylker 的经验中学习，即使在使用 ServiceDesk Plus 的混合环境中，也能克服重大事件。

Change

对任何可能对服务产生直接或间接影响的事物进行添加、修改或删除。

变更管理

以最小的中断和冲突完成变更的过程。

升级

根据功能或层级需求转移工单所有权的行为。

事件

对服务或资产管理具有重要意义的事件。

失败

服务或资产未按约定的 SLA 正常运行的事件。

层级升级

将所有权垂直转移给更高级别的服务台技术人员或相关权限的行为。

影响

事件严重程度的衡量标准。

事件

对IT服务的非计划中断，或IT服务质量的降低。即使配置项尚未影响服务，其故障也视为事件（例如镜像集中的一个磁盘故障）。

事件管理

管理所有事件生命周期的过程，以尽快恢复正常服务操作并将业务影响降至最低。

事件优先级划分

为事件分配优先级并定义重大事件的标准。

重大事件

具有高影响和高紧急性的事件，需要与事件管理分开处理的单独流程。

重大事件经理

负责 MIT 及 MIM 过程实施的人员。

平均响应时间（MTTA）

衡量服务台对事件响应速度的指标。

平均检测时间 (MTTD)

衡量潜在威胁对服务或配置项检测速度的指标。

平均故障间隔时间 (MTBF)

衡量服务或资产故障频率的指标。

平均修复/解决/响应/恢复时间 (MTTR)

衡量服务故障后恢复速度的指标。

正常服务操作

遵守 service level agreement (SLA) 的服务操作。

问题

一个或多个事件的原因或潜在原因。

RACI 矩阵

它定义了跨职能或部门项目和流程中的角色与职责。

服务台

服务提供者与组织用户之间的沟通点。

服务台经理

负责监督服务台日常活动并对其绩效负责的人。

服务级别目标 (SLO)

它定义了服务提供商的目标，是衡量其绩效的一种手段。

SLA

服务提供商与客户之间关于预期服务水平及其交付时间的协议。

紧急程度

衡量事件需要多快解决的指标。