什么是事件管理？

事件管理是开发团队和 IT 运营团队用于响应计划外事件或服务中断，并将服务恢复至正常运行状态的流程。

在 Atlassian，我们将事件定义为导致服务中断或质量下降、需要紧急响应的事件。遵循 ITIL 或 ITSM 实践的团队可能会使用“重大事件”这一术语来指代此类情况。

Incidents are events of any kind that disrupt or reduce the quality of service (or threaten to do so). A business application going down is an incident. A crawling-but-not-yet-dead web server can be an incident, too. It’s running slowly and interfering with productivity. Worse yet, it poses the even-greater risk of complete failure. Incidents can vary widely in severity, ranging from an entire global web service crashing to a small number of users having intermittent errors. An incident is resolved when the affected service resumes functioning in its intended state. This includes only those tasks required to mitigate impact and restore functionality.

事件管理是组织必须正确执行的最关键流程之一。服务中断可能会给业务带来巨大损失，因此团队需要一种高效的方式来快速响应和解决这些问题。团队需要可靠的方法来确定事件优先级、更快达成解决方案，并为用户提供更优质的服务。

当团队面临事件时，他们需要制定一个计划来帮助自己：

• 有效响应，以便快速恢复服务。
• 与客户、利益相关者、服务负责人及组织内其他人员进行清晰沟通。
• 有效协作，以团队之力更快解决问题，并消除阻碍问题解决的障碍。
• 持续改进，从这些中断事件中吸取经验教训，并将其应用于服务优化及未来流程优化。

不同类型的公司往往倾向于采用不同类型的事件管理流程。没有任何一种流程适用于所有公司，因此在不同公司中您可能会看到各种各样的方法。

许多团队依赖于更传统的 IT 式事件管理流程，例如 ITIL 认证中概述的那些流程。另一些团队则更倾向于采用站点可靠性工程师 (SRE) 式或 DevOps 式的事件管理流程。

事件管理流程帮助 IT 团队调查、记录和解决服务中断问题。ITIL 事件管理工作流旨在减少停机时间，并将事件对员工工作效率的影响降至最低。通过使用专为事件管理设计的模板，您可以创建可重复的事件管理工作流，确保团队能够记录、诊断和解决事件，并保留相关活动记录。

ITIL 框架主要供在企业内部提供服务的 IT 团队使用。通常，团队会从 ITIL 中选取所需内容（该框架几乎涵盖了 IT 团队可能遇到的各类事件、问题和流程），而忽略其余部分。当团队需要专注于培养主动故障排除文化时，ITIL 非常适用。其规定的流程能帮助团队以一致的方式跟踪事件和相关操作，从而改进报告和分析工作，并能带来更健康的服务和更成功的团队。

事件可能来自任何渠道：员工、客户、供应商、监控系统等。无论来源如何，前两个步骤都很简单：有人识别到事件，然后有人记录该事件。这些事件日志（即工作单）通常包含以下内容：

• 事件报告人的姓名
• 事件报告的日期和时间
• 事件描述（哪些服务中断或运行异常）
• 为事件分配的唯一标识号（用于跟踪）

为每个事件分配合理且直观的类别（必要时可添加子类别）。这有助于您分析数据中的趋势和模式，而这也是有效的问题管理及预防未来事件的关键环节。

所有事件都必须确定优先级。首先评估事件对业务的影响、受影响人数、任何适用的 SLA，以及事件可能带来的财务、安全和合规影响。将该事件与所有其他未解决的事件进行比较，以确定其相对优先级。最佳实践是在事件发生前定义严重性和优先级级别，这样事件经理就能更轻松地快速评估优先级。

• 初步诊断：理想情况下，您的一线支持团队能够从诊断到关闭全程负责一个事件，但如果无法独立处理，下一步需记录所有相关信息并上报至下一级团队。
• 上报：下一级团队接手已记录的数据并继续进行诊断流程。如果该团队也无法诊断事件，则再将其上报至下一级团队。
• 沟通：团队需定期向受影响的内部及外部利益相关者同步事件进展。
• 调查与诊断：该过程持续进行直至明确事件本质。有时团队会引入外部资源或其他部门成员提供咨询支持，协助解决问题。
• 解决与恢复：在这一步中，团队完成事件诊断并执行必要的解决步骤。恢复仅指业务运营完全恢复正常所需的时间，因为即使在找到正确的解决方案后，某些修复（如缺陷补丁等）可能仍需要测试和部署。
• 关闭：若事件已上报处理，最终需移交至服务台完成关闭。为保证服务质量和流程顺畅，仅服务台员工有权关闭事件。事件负责人应联系事件报告人，确认解决方案是否令人满意，确保事件确实可关闭。

采用 DevOps 或 SRE 事件管理方法时，构建服务的团队同时负责服务的运行，以及服务出现故障时的修复工作。随着全天候云服务、全球访问的 Web 应用、微服务和软件即服务的发展，这种方法的受欢迎程度激增。

如今，您生活和工作中依赖的软件越来越多地不再托管在与您物理位置相同的服务器上，而更可能是部署在数据中心、供全球数千甚至数百万用户访问的 Web 应用。对于负责运行这些服务的团队而言，敏捷性和速度至关重要。任何停机都可能影响成千上万的组织，而不仅仅是一个。

“谁构建、谁运行”方法的优势在于，它能提供敏捷团队所需的灵活性，但也可能模糊责任归属（即谁在何时负责何事）。DevOps 团队通常能够适应结构较松散的开发流程并取得成功，但最好还是标准化一套核心的事件管理流程，这样在事件紧急处理过程中就不会出现响应方式的疑问，同时也能跟踪问题并报告解决情况。

• 轮流待命：DevOps 团队通常采用轮换执行待命值班表，所有成员共同承担可能在夜间被唤醒以响应事件的负担，而非指定部分团队成员专门负责待命工作。
• 构建者即为最佳修复者：“谁构建、谁运行”理念的核心是，最熟悉服务的人（即构建者）最有能力修复服务中断问题。
• 快速构建，权责并重：当工程师知晓自己和团队伙伴在服务中断时需承担责任时，会更有动力确保部署的代码质量。

这种方法能保证快速的响应速度，并向需要了解如何构建可靠服务的团队提供更及时的反馈。

我们在《Atlassian 事件处理手册》中详细阐述了一套非常贴合 DevOps 的事件管理方法。

事件管理并非仅依靠工具就能完成，而是需要工具、实践与人员的有机结合。以下是有效事件管理中最常用的几类工具：

• 事件跟踪：每个事件都应被跟踪和记录，以便您识别趋势并进行长期对比分析。
• 聊天室：实时文本沟通是团队协作诊断和解决事件的关键，同时也能为后续的响应分析提供一组丰富数据。
• 视频聊天：视频聊天是对文本聊天的补充，对于许多事件而言，团队视频聊天有助于讨论调查结果并制定响应策略。
• 警报系统：诸如 Jira Service Management 之类的工具可与您的监控系统集成，管理待命轮换和事件上报流程。
• 文档工具：诸如 Confluence 之类的工具能够记录事件状态文档和事后分析。
• Statuspage：通过 Statuspage 向内部利益相关者和客户同步状态信息，有助于让所有人及时了解情况。