对事件做出响应

检测

您的公司的员工可以通过多种方式察觉事件。他们可以通过监控、客户报告或自行观察而有所警觉。但是，如果事件发生，团队采取的第一步是对事件工作单进行记录（在我们的例子，是创建一项 Jira 事务）。

出现新事件

如果事件事务已创建，但尚未分配给事件管理员 (IM)，则事件处于新建状态。这是我们的 Jira 事件工作流的初始状态。

我们的一项服务使用 Jira Webhook 在新的重大事件创建之后触发呼叫警报。这会根据所选服务向待命的 IM 发送警报。例如，Bitbucket 事件将呼叫 Bitbucket 事件管理员。我们还有一份全球性的重大事件管理员名单，称为“待命的事件管理员”或 IMOC。

呼叫警报包括事件的事务键、严重性和摘要，告诉事件管理员从哪里开始管理事件（Jira 事务）、通常是什么错误以及有多严重。

开始沟通

IM 上线后做的第一件事就是将事件事务分配给自己，并将事务推进到正在解决状态。Jira 事务经办人字段还会显示当前的 IM 是谁。在紧急响应中，明确负责人员非常重要，因此我们非常严格地要求该字段准确无误。

接下来，IM 设置事件团队的沟通渠道。此时的目标是在大家都知道的位置建立并关注事件团队的所有沟通内容。对于每个事件，我们通常使用三种团队沟通方法，每种方法都由 Jira 事务上的字段表示：

• Slack 或其他消息服务中的聊天室。使用这种方法时，团队可以沟通和分享已保存且带有时间戳的观察结果、链接和屏幕截图。为该聊天渠道指定与事务键相同的名称（例如，HOT-1234），这可以让需要参与进来的人员更轻松地加入对话。
• Skype、Blue Jeans 或类似会议应用中的视频聊天，或者如果你们都在同一个地方，请将团队召集在一个实体房间里。我们发现，面对面沟通可以帮助团队更快地完成工作，减少反复。
• Confluence 页面称为“事件状态文档”。当大家同时编辑同一页面时，可以实时查看正在收集的信息。这是跟踪更改（例如，包含更改人员和更改内容、时间、方式、原因以及恢复方法等内容的表格）、多个工作流或延长了的时间表的好方法。事件状态文档在复杂事件或扩散事件中可以作为真实来源，是非常有用的。

我们发现，在事件中同时使用视频聊天和聊天室效果最佳，因为这二者各有所长。视频聊天的优势在于通过小组讨论快速创建一幅有关事件的共享心理图像，而文字聊天非常适合保留事件的时间戳记录、仪表板的共享链接、屏幕截图和其他 URL。

这些方法还可用来记录不记录在案的对话中出现的重要观察结果、更改和决策。IM 或事件团队中的任何人都可以实时在专用的聊天室中记录观察结果、更改和决策。如果看起来像是人们在自言自语，也没关系！在事后分析的过程中，当团队需要重建事件时间表并找出导致事件发生的原因时，这些记录非常重要。

大多数聊天系统都有房间主题功能。IM 可以使用事件的相关信息和有用的链接更新房间主题，包括：

• 事件摘要和严重性。
• 谁担任什么样的角色，首先是 IM。
• 事件事务、视频聊天室和事件状态文档的链接。

这样一来，拥有事件事务键的任何人都可以加入聊天并快速了解事件（记住，我们根据事件的事务键命名了聊天渠道，例如：HOT-1234）。

最后，IM 会将他们自己的个人聊天状态设置为他们正在管理的事件的事务键。这可以让同事们知道他们正在忙于管理事件。

评估

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

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

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

现在是开始加入事件时间表的好时机。记录团队的观察结果，以便加入的人员可以快速了解进展。这在之后的事后析误流程中也很重要。确保记录事件的开始时间是否与更改（例如，Bamboo 部署）相对应，以便可以回滚更改以潜在解决事件。

根据事件的影响以及我们的团队认为解决实践需要的工作量，我们为事务指定以下的严重性级别：

发送初始沟通

如果您有理由确信事件是真实的，则需要尽快告知内部和外部人员。初始的内部沟通的目的是将事件响应集中在一个地方，从而减少混乱。外部沟通的目的是告诉客户您知道出现了故障，您正在将其当作紧急事件进行调查。就事件展开快速准确的沟通有助于您的员工与客户之间建立信任关系。

我们使用 Statuspage 在内部和外部沟通事件。我们分别为内部公司员工和外部客户提供单独的状态页面。稍后，我们将详细讨论每种状态页面的使用方法，但现在，我们的目的是尽可能快地进行沟通。为了做到这一点，我们需要遵循以下模板：

升级

您已经掌握了事件情况、与团队进行了沟通、评估了情况，并告诉员工和客户事件正在解决中。那么接下来呢？

您的第一响应者可能是解决事件所需的全部人员，但很多时候，您需要呼叫其他团队，让他们也参与事件。我们称之为上报。

该步骤中的关键系统是一个呼叫名单和警报工具，如 OpsGenie。借助 OpsGenie 及类似系统，您可以定义待命人员的名单，这样所有指定的团队都有轮班的员工，这些员工将保持联系，以便在紧急情况下做出响应。这种做法比指定一个人随时待命要好（“再联系 Bob”），因为大家都不会总是有空（如果总是找这一个人，这个人可能会去度假、换工作或者筋疲力尽）。这也比“尽最大努力”随时待命要好，因为由哪些人负责响应是明确指明的。

一定要将事件的 Jira 事务键包含在该事件的呼叫警报中。这是收到警报的人员用来加入事件聊天室的“钥匙”。

委派

上报给其他人后，他们会上线，IM 会将角色委派给他们。只要他们了解他们的角色需要做什么，他们就能迅速高效地作为事件小组中的人员开展工作。

在 Atlassian，我们使用的角色包括：

• 事件管理员，概述页面中有所描述。
• 技术主管，高级技术响应者。负责制定有关故障及其原因的猜想、决定做出的更改以及管理技术团队。与 IM 密切合作。
• 沟通管理员，熟悉公众沟通的人员，可能来自客户支持团队或公关部门。负责撰写和发送有关事件的内部和外部沟通内容。

我们使用聊天室主题来显示各个人员的当前角色，如果角色在事件期间发生变化，会及时更新。

IM 还可以根据事件的需要设计和委派角色，例如，如果正在进行多项工作，可以指派多个技术主管；或者分别指派内部和外部沟通管理员。

如果是复杂或大型事件，可以委派另一名合格的事件管理员作为 IM 的后备人员。他们可以专注于一些任务，例如遵循时间表，从而让 IM 腾出精力做其他事。

发送后续沟通

您已经发送了初始沟通，但一旦事件团队有变动，您必须向涉及事件的员工和客户发送最新动态。

让内部员工了解最新动态非常重要，因为这会让大家一致了解事件的真实状况。出现问题时，相关信息会很少，尤其是在早期阶段，如果您不针对发生的事情以及您的应对之法给出一个可靠的真实信息来源，人们往往会得出自己的结论。

对于内部沟通，我们遵循以下模式：

• 我们通过内部 Statuspage 和电子邮件进行沟通，如上文“初始沟通”中所述。
• 对事件名称和电子邮件主题格式使用相同的规范（<事件事务键> - <严重性> - <事件摘要>）
• 开头用 1-2 句话总结当前的状态和影响。
• “当前状态”部分使用 2-4 个项目符号。
• “后续步骤”部分使用 2-4 个项目符号。
• 说明将在何时何地发起下一轮沟通。

我们使用以下清单检查沟通的完成情况：

• 对客户有什么实际影响？
• 有多少内部客户和外部客户受到影响？
• 如果已知根本原因，那么根本原因是什么？
• 如果恢复有预计完成时间 (ETA)，那么是什么时候？
• 下一次最新情况沟通是在何时何地？

我们鼓励事件管理员在内部沟通中详细说明未知因素。这可以减少不确定性。例如，如果您还不知道根本原因是什么，最好说“根本原因当前未知”，而不是弃之不提。

让外部客户掌握最新情况非常重要，因为这有助于建立信任。即使他们可能会受到影响，但只要他们知道您会及时通报最新情况，就能够接受其他安排。

对于外部沟通，我们只需更新之前在外部 Statuspage 上建立的事件，并根据需要更改状态即可。我们尽量让更新“简短扼要”，因为外部客户对事件的技术细节不感兴趣，他们只想知道问题解决了没有，如果没有，何时会解决。一般来说，1-2 句话就够了。

事件沟通是一门艺术，您练习的越多，就会越熟练。在我们的事件管理员培训中，我们通过角色扮演来处理一个假设的事件，由扮演者起草沟通内容，并将稿件读给班级的其他学员听。这是在实际操作之前培养技能的一种好方法。这也是在您发送沟通内容之前，让别人先检查一遍，提出"补充意见"的好方法。

审查

没有一个既定流程可以解决所有事件，如果有的话，我们只需将其自动化，就万事大吉了。相反，我们需要重复下面的流程来快速适应各种事件响应场景：

• 观察发生了什么事。分享并确认观察结果。
• 就为什么发生事情而列出猜想。
• 设置实验，证明或反驳这些猜想。进行实验。
• 重复流程。

例如，您可能会观察到某项服务具有高错误率，该错误率与区域基础架构提供商在其 Statuspage 上发布的某个故障相对应。您可能推测，这个故障只在这个区域出现，因此决定故障转移到其他区域，并观察结果。

这时，IM 面临的最大挑战就是维持团队纪律：

• 团队是否进行了有效的沟通？
• 当前的观察结果、猜想和工作流是什么？
• 我们是否有效地做出了决定？
• 我们是故意且谨慎地进行更改的吗？我们知道我们在进行什么样的更改吗？
• 角色是否明确？员工是否各司其职？我们需要向更多的团队上报吗？

在任何情况下都不要惊慌，因为这毫无助益。保持冷静，团队的其他人会找出线索。

IM 必须留意团队疲劳问题，并安排团队交接工作。在解决复杂的事件时，专职团队会出现精疲力尽的风险，IM 应该留意团队成员保持清醒工作的时长以及他们处理事件的用时，并决定接下来由谁来填补他们的角色。

解决

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

善后任务可以设置为事件的 Jira 事务中的事务链接，以轻松地进行跟踪。

在 Atlassian，我们使用 Jira 自定义字段来跟踪每个事件的影响开始时间、检测时间和影响结束时间。我们使用这些字段来计算恢复时间 (TTR)（开始和结束之间的间隔）以及检测时间 (TTD)（开始和检测之间的间隔）。您的事件 TTD 和 TTR 的分布情况通常是一个重要的业务指标。

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

Jira Service Management 可以帮助团队执行响应流程的每个步骤，包括集中警报、组织事件沟通，以及通过事后对事件进行根本原因分析来统一团队以实现更好的协作。要了解详情，请点击下面的按钮。