Close

更好的事件管理之路从这里开始

有效事件响应的 7 个阶段

事件响应是组织应对网络攻击、安全漏洞和服务器停机等 IT 威胁的过程。

其他 IT 运维和 DevOps 团队可能会将此实践称为“重大事件管理”,或简单地称为“事件管理”。

以下几小节根据我们自己的事件手册中的材料,描述事件响应流程,介绍从发现服务中断开始到重新启动并运行服务为止应该做些什么。

在本文中,我们将介绍事件响应的七个关键阶段:

  1. 检测事件
  2. 建立团队沟通渠道
  3. 评估影响并应用严重性级别
  4. 与客户沟通
  5. 上报至正确的响应者
  6. 委派事件响应角色
  7. 解决事件
事件响应工作流

检测事件

理想状态下,监控和警报工具可在客户注意到之前检测到事件并通知您的团队。但有些时候,您首先是从 Twitter 或客户支持工作单得知事件的。

No matter how the incident is detected, your first step should be to record that a new incident is open in a tool for tracking incidents. In an incident management solution such as Jira Service Management, alerting and communication is integrated with your tracking tool.

建立团队沟通渠道

One of the first things the incident manager (IM) does when they come online is set up the incident team's communication channels. The goal at this point is to establish and focus all incident team communications in well-known places, such as:

  • Slack 或其他消息服务中的聊天室。
  • Zoom 等会议应用中的视频聊天(或者,如果大家共处一地,可以将团队召集到一个实体房间)。

我们更喜欢在事件中同时使用视频聊天和文字聊天工具,因为这二者各有所长。视频聊天的优势在于通过小组讨论快速创建一幅有关事件的共享心理图像。而 Slack 则可帮助生成带有时间戳的事件记录,以及指向屏幕截图、URL 和仪表板的集中链接。

Slack 和大多数其他聊天工具都允许用户设置房间主题。事件经理应将此字段用于提供有关事件和有用链接的信息。

最后,IM 会将自己的个人聊天状态设为他们正在管理的事件的事务关键字。这样,同事们就会知道他们正在忙于管理事件。

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

事件团队的通信渠道建立后,就需要评估事件了,以便团队决定要告诉大家的内容以及需要谁去解决问题。

IM 需要向团队提出下面的一组问题:

  • 对客户(内部或外部)有什么影响?
  • 客户看到了什么?
  • 有多少客户受到了影响(部分、全部)?
  • 什么时候开始的?
  • 客户开立了多少支持案例?
  • 是否还有其他因素,例如,Twitter、安全性或数据丢失?

The next step typically is to assign a severity level.

事件响应严重性级别

严重性 1
描述:产生极大影响的危机事件
示例:

  • 面向客户的服务对所有用户皆不可用
  • 违反了保密或隐私保护政策
  • 丢失了客户数据

严重性 2
产生巨大影响的重大事件
示例:

  • 面向客户的服务对一部分(而非全部)客户不可用
  • 核心功能受到显著影响。

严重性 3
影响较小的小事件
示例:

  • 对客户造成小小的不便,有变通方案可用。
  • 可用性能降低。

用编号体系标识严重级别有助于快速定义和传达事件。只要有人说“我们可能遇到严重性 1 事件”,适当的人甚至在获得更多信息之前就能立刻明白事情的严重程度。

严重性级别还可以帮助建立响应预期的指导方针。

例如,在某些公司,严重性级别为 3 的事件可以等到办公时间解决,而严重性级别为 1 和 2 的事件则需要召唤团队成员立即解决。

事件严重性定义应记录成文,并在整个组织内保持一致。

与客户沟通

一旦团队确定事件是真实的,则最好尽快告知内部和外部利益相关者。

内部沟通的目的是将事件响应集中到一处,从而减少混乱。

外部沟通的目的是告诉客户,团队已知道出现了状况,并且正在进行调查。快速、准确的沟通有助于与客户和组织其他成员建立信任关系。

许多团队使用 Statuspage 在内部和外部沟通事件。以下是用于更新内部或外部 Statuspage 的两个简单模板:

内部 Statuspage
<事件事务关键字> - <严重性> - <事件摘要>

我们正在调查影响 <产品 x>、<产品 y> 和 <产品 z> 的事件。我们将很快通过电子邮件和 Statuspage 提供更新。

外部 Statuspage
正在调查 <产品> 的问题

我们正在调查 <产品> 的问题,并将很快在这里提供更新。

上报至正确的响应者

Sometimes the initial responders are the ones who resolve the incident. More often than not, those responders need to bring other teams into the incident by paging them using an alerting tool. With Jira Service Management, responders can take their pick as to what alerting method they use, or even use them all in one central location.

借助警报工具,团队可以定义待命人员名册,从而创建事件发生期间应该能联系到的员工的轮班表。相比每次发生事件时都依赖某一个人,这要更胜一筹。同一个人不会总是有空(他们会休假、换工作,或者因为您呼叫他们过于频繁而精疲力尽)。

委派事件响应角色

After a new incident responder is paged and comes online, the incident manager delegates a role to them. As It’s important they understand what's required of their role, and how to contribute to the incident team quickly and effectively.

定义不同角色的另一优势是它允许更大的适应性和灵活性。只要一个人知道如何担当某个角色,就能在任何事件中接下这一角色。

三个关键事件响应角色

事件管理员

每个事件都由事件经理推动,他们对事件负有全面的责任和权限。

事件经理有权采取任何必要的行动来解决事件,包括召唤组织中的任何人,以及让事件涉及的人员专注于尽可能快地恢复服务。

技术负责人

高级技术响应者。技术主管负责制定有关故障及其原因的猜想、决定做出的变更,以及管理技术团队。此角色与事件经理密切合作。

沟通经理

熟悉公众沟通的人员,可能来自客户支持团队或公关部门。负责撰写和发送有关事件的内部和外部沟通。

解决事件

不存在可解决每一事件的一刀切流程。假如有这样的流程,那么只需将其自动化就能万事大吉。相反,我们需要从科学方法中汲取灵感。重复下面的流程来快速适应各种事件响应场景:

  • 观察发生了什么事。分享并确认观察结果。
  • 制定关于事情原因的猜想。
  • 开发和执行实验来证明或反驳这些猜想。
  • 重复这个过程,直到事件得以解决。

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

事件解决后,我们会发送最终的内部和外部沟通。内部沟通会概述事件的影响和持续时间,例如提出的支持案例数量和其他重要的事件维度。同时还要明确指出事件已经解决,不会再就该事件进一步沟通。外部沟通通常简短扼要,告诉客户服务已经恢复,我们将跟进执行事后分析。

Conclusion

There are many moving parts to the incident response process. Keeping track of each step with seamless communication is easy with an incident management tool like Jira Service Management. Centralize alerts and unify teams with flexibility to resolve incidents quickly.

后续内容
事后分析