【转】如何构建高效的事件管理流程

本文提供了一个可以有效进行事件管理的通用框架，其灵感来自 LinkedIn 的内部流程，不同组织可以根据自己的需要进行定制。事件管理有标准化的 ITIL 流程，但下面要介绍的框架有所不同，它是为解决实时生产中断而定制的。

大多数公司提供在线服务，任何中断都会带来糟糕的终端用户体验。反复中断会影响业务和品牌价值。在高速、复杂的分布式系统中，生产中断经常会频繁发生。组织应该接受事件总会出现的现实，创建事件管理流程，缩短事件解决时间。

什么是事件？

事件是计划外的生产中断，会严重破坏终端用户的体验，需要组织立即进行干预。

根据受影响的用户不同，事件可以分为内部事件和外部事件。

内部事件是指由于用于完成工作的工具出现问题而影响员工工作效率的中断（例如，部署工具在很长一段时间内无法正常使用，员工不能登录到 VPN）。

外部事件是指影响公司产品 / 服务的终端用户体验的中断（例如，用户不能从电子商务网站购买商品，用户不能在即使通讯软件中发送消息）。

上述事件可以根据严重程度进一步划分成次要（Minor）、中等（Medium）和重大（Major）。

• 重大 —— 严重影响许多终端用户的体验，并对业务（由于收入损失）或品牌价值产生了明显的影响。

• 中等 —— 事件影响了相当一部分服务，但不同于重大事件，通常只限于特定的区域。

• 次要 —— 影响面向少数用户的服务的非关键工作流的事件。

假如有一个社交媒体网站发生了严重的事件，那么大部分用户的服务中断超过 30 分钟就可以归类为重大事件。相比之下，中东用户无法使用私聊消息功能可能就只是一个中等事件，而如果是印尼用户的个人资料中没有出现验证徽章则可以归类为次要中断。

强烈建议以业务目标为依据，以数据为基础建立严格的事件分类指南，提高透明度，防止在非关键事件上浪费工程带宽。

什么是事件管理？

事件管理是一系列有序采取的行动，旨在缓解和解决关键事件，使服务尽快恢复健康。

事件管理阶段

• 检测
  通过在基础设施监控 / 预警或各种客户支持渠道的用户报告主动检测中断。

• 创建
  针对检测到的中断创建事件，触发事件管理流程。在理想情况下，组织可以使用一个类似于 Atlassian JIRA 的工单管理系统来记录事件详情。

• 分类
  根据既定的原则对事件进行分类。强烈建议根据业务需求起草这些原则。如今，行业中使用了多种术语，但简单起见，我们将使用重大、中等和次要的分类方式。对于所有事件，事件管理流程和紧迫感都是相同的，但当多个事件同时发生时，确定事件类别有助于确定优先级。

• 排查
  最初报告事件的人会查阅内部值班记录，然后根据自己的知识将其升级到相应服务的值班工程师。升级会继续，直到查明问题的根本原因；有时，一个事件可能需要多个团队协作来发现问题。

• 解决
  相关团队首先要做的是确定步骤，以在尽可能短的时间内缓解正在发生的事件。关键是承担该承担的风险，并在接下来的步骤中果断行事。一旦问题得到缓解，团队就会专注于解决根本原因，以防止问题再次发生。在整个解决过程中，与内部和外部利益相关方的沟通是必不可少的。

• 回顾
  通常，事件回顾是在查明根本原因之后进行。事件中涉及的团队和关键利益相关方聚在一起仔细回顾事件。事件回顾的目标是确定哪里出了问题，可以做什么改进，以便未来可以防止或更快地解决类似的问题，并确定短期 / 长期的行动项以预防问题或改进流程 / 技术栈。

• 跟踪
  定期在管理层面审查事件行动项，以确保所有与事件相关的行动项都得到处理。评估关于事件的关键指标，如 TTD（检测时间）、TTM（缓解时间）、TTR（解决时间）和 SLA（服务水平协议），确定事件管理的有效性，识别战略投资领域，提高服务的可靠性。

事件管理角色 & 职责

在事件处理期间，要有一组经过专门培训的人员承担特定的角色，在妥善处理生产事件的同时，尽量减少混乱，这至关重要。在理想情况下，一人承担一项职能，因为责任重大，需要特定的技能。也可以根据业务需求和事件的严重程度合并和自定义角色。

事件经理

事件经理（下文简称为 IM）是事件的负责人，负责以适当的紧迫感引导事件解决。在事件处理期间，应该有一个人负责事件管理过程的一般组织，包括沟通和决策。这个人有权做出决策，并确保事件根据既定策略得到有效处理。

• 职责：
  事件经理负责事件管理的四个主要方面：组织、沟通、决策管理和事后跟踪。

事件的组织对于事件的有效解决至关重要。IM 将负责召集合适的团队和利益相关方，以确保事件得到快速解决。IM 将与利益相关方合作，分配在调查和补救期间提出的工作项并进行跟踪。

需要在事件处理期间做出许多决策。IM 负责识别调查和快速解决之间的拐点，并确保可以迅速做出决策，让合适的利益相关方参与 / 了解。当故障排查期间无法达成共识时，IM 有权判定谁拥有决策权。

事件结束后，IM 是事件的沟通联络点。由于 IM 积极参与了事件，所以他们要负责与服务所有者和利益相关方合作，主导事后分析。IM 将与服务所有者合作，提供从事后分析到高层管理的事件概述和基本行动项。

值班工程师

在事件发生期间，受影响服务和拥有服务的值班工程师将参与调查和缓解导致事件的问题。

• 职责：
  受影响服务的值班工程师负责评估客户影响和服务影响，并在发出解除预警信号、关闭事件之前验证缓解 / 解决步骤。

对导致中断 / 问题的服务负责的值班工程师负责调查根本原因，并采取补救措施以缓解 / 解决事件。

沟通主管

利益相关者、客户和管理层之间的有效沟通对于事件的快速解决至关重要。将信息传递给利益相关者、管理层，甚至是执行者，可以避免事件的意外恶化，帮助应对混乱局面，在组织中避免重复工作 / 单打独斗，缩短解决问题的时间。

• 职责：
  沟通经理负责所有与内外部各利益相关方（员工和高管的最新情况、社交媒体更新和状态页面）围绕事件进行的书面沟通。

客户升级经理

对于大公司来说，因为要迎合各种各样的企业客户，而且有严格的 SLA，所以他们通常由专门的客户升级经理来架起客户与内部事件团队之间的沟通桥梁。

• 职责：
  与客户保持联系，收集当前事件的详细信息，并将信息传递给调试这个问题的内部团队。

从沟通经理处获取最新的沟通信息，并定期将定制的信息传递给客户。

确定缓解步骤，让客户试着缓解问题，直到问题得到完全解决。

执行经理

对于影响客户的服务，执行经理会持续更新事件状态和客户影响详情。对于可能影响业务的事件，执行经理还会在相关决策中扮演重要角色，分配资源，加速事件解决过程。

事件管理工具

为了更快地缓解问题，事件管理生命周期的每个阶段都需要许多工具。大公司会推出自定义的工具，可以与生态系统的其他部分很好地进行互操作。相比之下，对于不需要构建自定义工具的组织来说，市场上有许多工具可供他们使用，有开源的，也有商业的。本节将回顾事件管理过程中用到的基本工具的几个标准类别。

预警管理

预警管理可以帮助设置告警，并监控特定时间段内时序指标的异常情况。当检测到运营指标异常时，它会向值班人员发送通知。经过适当的配置，预警管理工具可以通过多种媒介将报告升级到值班工程师：紧急预警通过寻呼机 / 电话，非紧急预警通过短信息 / 电子邮件。

预警管理工具应该支持不同的媒介，并能够与可观察性工具（如 Prometheus、Datadog、New Relic、Splunk 和 Chronosphere）互操作。Grafana Alert Manager 是一个开源的预警管理工具；市场上也有一些商业预警管理工具，如 PagerDuty、OpsGenie 和 Firehydrant 等。

值班管理

在一个拥有数千工程师和微服务的大型组织中，在合理的时间内让合适的人参与进来，对于更快地解决事件至关重要。值班管理工具通过值班调度和升级功能，跨团队分担值班职责，并提供值班工程师映射服务，在严重的大规模事件中促成无缝协作。

值班管理工具应该支持调度和服务所有权详情的自定义。PagerDuty 和 Splunk Oncall 是其中最著名的两个商业选项，而 LinkedIn 的 Oncall 工具是一个开源版本，适合寻找低成本选项的组织。

协作工具

在发生严重事件时，数百名员工参与其中的情况并不罕见。协作和沟通对于管理混乱和有效解决事件至关重要。如今，每家软件公司都有通讯或视频会议软件，工程师们可以随时使用这些软件进行协作。可以轻松快速获取信息，弄清楚要在即时通讯应用中加入哪个组或要在视频会议软件中加入哪个会议通道，对于缩短解决事件的时间至关重要。

为每个事件设置单独的讨论渠道，对于简化协作过程至关重要。通常，会议通道的链接会固定放在群聊的描述中，方便新工程师加入会议。完善的流程可以减少诸如“我应该加入哪里”或“谁帮忙分享下会议通道链接”等协调方面的问题的干扰，并保持事件排查的沟通渠道畅通。

事件跟踪

事件会生成大量的重要数据，可能来自自动处理流程，也可能是手动记录以供将来参考的数据。由于缺少结构化，传统的笔记应用程序不会有太大的发展。支持多个自定义字段和协作功能的工单平台会更适合这种情况。获取历史事件数据的 API 接口也至关重要。

许多公司都使用 Atlassian 的 JIRA 跟踪所有事件，但 Notion、Airtable、Coda 等类似的工具也同样有效。Bugzilla 是一个可以帮助我们跟踪事件的开源替代方案。

知识共享

知识共享工具不可或缺，可以帮助工程师轻松找到正确的信息。运行手册、服务信息、事后分析文档和待办事项都是知识共享应用程序的一部分。在这方面，谷歌文档、维基和 Notion 都是很好的商业软件，可以帮助我们在组织内部撷取和共享知识。

状态页面

状态页面是为了方便外部利益相关方了解服务当前的健康状况。感兴趣的人士可以订阅有关的最新资料，了解有关事件处理进展的更多信息。当发生外部事件时，状态页面可以减少客户服务部门收到的咨询系统健康状况的入站请求。

事件响应周期

在前面几节中，我们讨论了事件管理中的不同阶段、角色和工具。本节将使用上述信息详细说明事件响应过程的各个阶段。

检测

通过内部监控系统或是客户支持或社交媒体的用户报告发现问题。一种很常见的情况是，内部员工首先发现问题并将其升级到集中式的站点运营团队。组织应该采用合理的可观察性解决方案来更快地检测问题，从而尽可能地缩短检测时间（Time To Detect，TTD）。

对于用户升级的问题，应该实现一个流程，让员工使用可用的值班管理工具将问题快速升级到相关团队。问题的升级标志着事件管理生命周期的开始。

创建

团队收集有关事件的必要信息，并创建事件跟踪工单。其他有助于工程师排查问题的信息也应该收集，如受影响的产品、开始时间、受影响用户等。

一旦创建了工单，值班事件经理就需要使用内部事件管理工具参与进来。为了方便协作，应在内部消息服务和视频桥中创建共享的沟通渠道。

分析

事件经理与团队一起确定受影响服务的值班工程师，并与他们一起进一步了解用户影响。根据事件的影响大小，事件经理将事件分为重大、中等或次要。重大事件非常严重，通常需要全体出动。

排查

一旦问题被归类为重大事件，就需要向所有利益相关方发出事件初步通报，说明发生了重大事件，并提供当前掌握的有关该事件的信息。最初的通报缺少细节，但应该为接收方提供足够的上下文，使其理解中断会产生什么影响。应及时更新面向外界的状态页面，承认出现了问题，组织正在努力解决。

事件经理应将问题升级，并根据能够获得的最佳信息召集所有相关的值班工程师。沟通主管将负责沟通，客户升级经理应向客户提供最新信息。事件跟踪工单应该包含所有必要的事件跟踪数据。

如果需要其他团队参与，那么事件经理应分别与他们联系，直到解决事件所需的所有人员都到场。

解决

团队应集中精力缓解事件，并在之后找到根本原因和解决方案。在这种情况下，团队可以探索将所有流量从受影响区域重定向到可用健康区域的选项，设法缓解问题。使用任何临时手段缓解事件都有助于缩短事件的 TTM（Time to Mitigate，缓解时间），为工程师消除导致问题的根本原因提供急需的空间。

在整个排查过程中，要详细记录稍后可能需要修复的东西、调试过程中遇到的问题和流程效率低下的情况。一旦问题得到解决，临时缓解步骤将被删除，系统恢复正常状态。

要根据发现的问题、解决问题的详细步骤和下一步可能采取的步骤更新事件通讯。然后，向客户提供最新解决方案。

回顾

定位到根本原因后，编写一份详细的事件文档，其中包含事件期间捕获的所有细节。参与事件管理的所有利益相关方和团队聚在一起，进行事后分析，其间任何人都不会受到指责。这样的回顾会议旨在反思该事件，并识别任何改进技术或流程的机会，帮助更快地缓解问题，防止类似事件的再次发生。要仔细研究事件的时间轴，以便发现事件检测或管理过程中任何效率低下的地方。确定所有必要的行动项，定义好优先级并分配给各自的所有者。高优先级行动项最紧急，应尽快处理，其余优先级比较低的行动项也必须有截止日期。要指定专人帮助跟踪这些行动项，并确保团队承担起相应的责任，完成好各自的工作。

度量指标

就像 SRE 圈里所说的：“可度量的东西才会被修复。”以下是应该在所有事件和组织中度量和跟踪的标准指标。

• 检测时间（TTD）
  检测时间是指从故障开始到检测到故障（手动或自动报警）所花费的时间。团队可以扩大报警覆盖，使用最新的信息来加快故障检测。

• 缓解时间（TTM）
  缓解时间是指从事件发生到缓解用户影响所花费的时间。缓解措施只是解决导致问题的根本原因之前所采用的临时解决办法。设法缩短 TTM 有助于提高服务的可用性。许多公司借助 Active-Active 模式为多个区域的用户提供服务，并将流量重定向到健康区域，从而更快地缓解事件影响。类似地，在某些情况下，服务或节点级的冗余有助于更快地缓解事件影响。

• 解决时间（TTR）
  解决时间是指从事件发生到完全解决事件所花费的时间。解决时间有助于更好地理解组织检测和解决根本原因的能力。由于排查是事件解决周期的重要组成部分，所以团队可以采用复杂的可观察性工具来帮助工程师更快地发现根本原因。

• 关键事件元数据
  事件元数据包括事件数量、根本原因类型、受影响的服务、根源（root cause）服务以及帮助组织识别 TBF（故障间隔时间）的检测方法。组织的目标是增加平均故障间隔时间。分析这些元数据有助于识别组织运营方面的热点。

• 服务可用性
  服务可用性是指在一段时间内服务正常运行时间的占比。可用性指标被用作弹性的衡量标准。

小 结

本文讨论了事件管理过程，并介绍了它如何帮助组织更快地管理混乱和解决事件。事件管理框架有各种风格，但这里提出的思想非常通用，任何规模的组织都可以进行定制和调整适配。

计划引入事件管理框架的组织可以从小事做起，收集事件相关的数据。这些数据有助于我们了解现有系统的低效或不足之处，并提供比较资料，衡量即将推行的新事件管理流程的进步之处。一旦对需求有了更好的了解，就可以从一个与组织规模相匹配的基本框架入手，而这不会产生任何额外的开销。可以根据需要在流程中引入其他步骤或工具。

如果你正在寻找其他关于改进和扩展事件管理流程的信息，则可以从以下几个地方入手：

• 事件剖析——Ayelet Sachto，Adrienne Walcer（https://www.oreilly.com/library/view/anatomy-of-an/9781098113759/）

• 面向运营的事件管理——Rob Schnepp，Ron Vidal，Chris Hawley（https://www.oreilly.com/library/view/incident-management-for/9781491917619/）

• Atlassian 事件管理手册（https://www.atlassian.com/incident-management/handbook#what-is-an-incident）

• SREcon21 —— Slack 事件管理演进（https://www.youtube.com/watch?v=FYYTglQoS3w）

希望改进当前事件管理流程的组织必须进行仔细地测试、度量、调整并重复该方法。重点应该是找出当前过程中出现的问题，进行增量改进，并衡量进展。务必从小事做起。

原文链接：
https://www.infoq.com/articles/effective-incident-management/