什么是事件响应生命周期

主要收获：事件响应生命周期是一个可重复的循环过程，团队遵循该过程来检测事件、协调响应、解决事件，并将学到的经验教训反馈到下一个周期的准备工作中。

• 它的含义：一个分阶段框架（Atlassian 的七个步骤或 NIST 的四个阶段），其中定义了从首次警报到事后分析的整个过程。

• 为什么它很重要：将事件视为一个循环而不是一次性事件，才能将每次中断转化为更好的检测、更快的响应和更少的重复事件。

• Jira Service Management 如何提供帮助：集中管理警报、沟通渠道、严重程度、上报和事件时间线，以便每个阶段都在一个位置运行，并确保事后分析拥有完整的记录。

事件响应生命周期是团队使用的一个分步框架，可用于检测服务中断或安全威胁、协调和沟通响应、还原服务，然后分析发生的情况，以便更早发现下一个事件并更快加以解决。它是一个循环而不是一条直线：当服务再次“正常运行”时，此工作并没有结束，因为事后分析、路线图更改以及改进的运行手册才是防止下一个事件的关键。

根据不同的观点，有几种方法可将该周期划分为不同阶段。本指南将介绍 Atlassian 在其自身的事件响应中使用的七个步骤、NIST 的四阶段模型，以及 DevOps 团队如何调整运用这两种方法。

Atlassian 事件响应生命周期

1. 检测事件

事件检测通常从监控和警报工具着手。但有些时候，我们首先是从客户或团队成员那里得知事件的。

事件警报可能来自不同的来源，因此，拥有一个集成各种警报和报告工具的解决方案，可能成为脱节繁琐的响应和连贯协同的响应之间的区别所在。借助 Jira Service Management 等解决方案，团队可以自定义和筛选所有监控、日志记录和 CI/CD 工具中的警报，确保团队快速响应事件，同时避免警报疲劳。

2. 建立团队沟通渠道

首先要完成的一个重要步骤是建立事件响应团队的沟通渠道。在此步骤，目标是将团队沟通集中放到一个众人皆知的位置，例如专设的 Slack 通道和视频会议桥路。

在 Jira Service Management 中，协调事件响应可以是一个顺畅的过程。不仅是团队能以最适合自己的方式（例如 Slack 和视频会议）进行交流，而且与客户的沟通也可借助自动化和自定义变得更加容易。我们将在第 4 步中介绍外部沟通。

3. 评估影响并应用严重性级别

现在，是时候评估事件的影响了，从而使团队能够决定还要跟谁联系，以及与客户和利益相关者沟通什么。指定严重性级别不仅可以识别事件的影响，还可以为解决计划和外部沟通奠定基础。在 Jira Service Management 中，上报事件和分配严重性会触发自动操作并通知响应者，从而能够掌握解决进展。

4. 与客户沟通

我们的目标是尽快告知内部与外部利益相关者。快速、准确的沟通有助于与客户和组织其他成员建立信任关系。正如前文所述，对沟通方式进行自定义，可以让团队按照自己想要的方式工作，从而更快解决问题。此外，自定义沟通还可让团队掌控它们想要发送的消息以及发送的时间。另外在事件进展过程中，从工作单内自动向客户直接发送回复可以节省团队的时间。

5. 上报至正确的响应者

初始响应者通常需要邀请其他团队介入事件，这可通过使用 Jira Service Management 中的警报功能来呼叫。通过将相关工作单分组到一起并直接在工作单上标记相关响应者，把响应者直接拉入事件工作单。这样，通知是协调的，每个人都可掌握完整的背景信息。

6. 委派事件响应角色

其他团队成员加入事件响应时，事件经理会向他们委派角色。因此，提前编写恰当的事件响应行动手册来概述明确的角色和职责会有所帮助。事件响应团队的成员熟悉每个角色，并且清楚知晓自己在事件发生期间的职责。

7. 解决事件

如果当前或即将发生的业务影响已经消除，则表示事件已得到解决。此时，紧急响应结束，团队过渡到处理善后工作和事后分析。

理想情况下，事件管理解决方案将保持稳健的事件时间线，使用 Jira Service Management 可以做到这一点。之后，响应者可以访问关键事件数据并制作报告，帮助团队避免将来发生类似事件并寻找根本原因。事后分析也可以充当一种资源，以防未来偶然发生类似状况。

NIST 事件响应生命周期

另一行业标准事件响应生命周期来自于美国国家标准与技术研究所（简称 NIST）。NIST 是一个政府机构，围绕事件响应和网络安全等主题制定标准和实践。

与 Atlassian 一样，NIST 也认为并非所有事件都能预防。因此，做好万全准备才是上策：

“基于风险评估结果的预防性活动可以减少事件数量，但并非所有事件都能预防。因此，必须要具备事件响应能力，从而能快速检测事件、最大限度减少损失和破坏、消除被利用的漏洞，并且恢复 IT 服务。”— NIST

NIST 事件响应生命周期将事件响应划分为四个主要阶段：准备；检测和分析；遏制、根除和恢复；以及事件后活动。

第 1 阶段：准备

准备阶段涵盖组织为准备事件响应所做的工作，包括确立正确的工具和资源以及培训团队。此阶段也包括为防止事件发生而做的工作。

第 2 阶段：检测和分析

根据 NIST，准确检测和评估事件通常是事件响应中让许多组织感觉最棘手的部分。

第 3 阶段：遏制、根除和恢复

此阶段的重点是尽可能减轻事件影响并缓解服务中断。

第 4 阶段：事件后活动

在事件发生后进行学习和改进，是事件响应中最重要一个部分，也是最常被忽视的部分。在这个阶段，对事件和事件响应工作进行分析。目标是限制事件再次发生的可能性，并确定改进未来事件响应活动的方法。

这 4 个阶段均出自《SP 800-61 第 2 修订版》（NIST 的 2025 年修订版（第 3 修订版）），其中围绕网络安全框架 2.0 的功能对事件响应进行了重新组织，尽管 4 阶段模型仍是最广泛引用的版本。

现代 DevOps 团队的事件响应

过去十年，DevOps 运动帮助团队重塑了构建、部署和运维软件的方式。除此之外，还有关于团队如何应对事件的创新。

DevOps 管理事件的方法与传统的有效事件管理步骤并无太大区别。DevOps 事件管理包括明确强调让开发人员团队从头开始参与（包括待命），并根据专长而不是职称来分配工作。

事件响应和持续改进

我们在本文开头谈到了循环与直线。您会发现这些事件管理方法都有一个共同点：它们不是线性的。它们都包括相同的基本组件：定义、检测和识别事件的方法；快速响应和行动来缓解事件的方法；以及分析事件以改进未来检测和响应的方法。仅为事件本身而分析已发生的事件毫无意义。我们无法让时间倒退去改变历史，但可从事件中吸取经验教训，以改进未来的检测和响应。惟有持之以恒地学习和改进，团队才能闭合这一循环。

（非线性）事件响应流程包含多个活动部分。借助 Jira Service Management 等事件管理解决方案，使用集成的协作和沟通工具来轻松跟踪各个步骤。集中处理警报并联合各个团队，灵活地快速响应和解决事件。