事件沟通最佳实践

对于 IT 和运维部门的人而言，事件一直是无法避免的现状。如今，DevOps 和客户支持团队也在参加事件沟通速成班。

事件沟通是指提醒用户服务正在遭遇某种中断或性能下降的过程。此功能对于 Web 和软件服务尤其重要，因为这些服务应全天可用。

Web 规模的事件沟通不是简单地群发电子邮件，它要复杂得多。需要考虑不同的受众，还有适用于消息传递和响应期望的不同阈值。

一些停机是难免的，因此最好是提前规划并确保团队做足准备。

这里介绍我们的事件沟通最佳实践指南。具体涵盖以下主题：

• 事件沟通有什么重要性

• 怎样为事件沟通做准备

• 专业人士如何处理事件沟通任务

• 事件沟通为何不随事件结束而告终

事件沟通：有谁在乎？

客户会关心，同事会在乎，您也应该重视。停机事件倘若处理不当，可能会造成客户和团队体验不佳，影响您的业务利润。一些客户可能担心您还有其他糟糕体验，因而投向竞争对手的怀抱。由于缺乏信任，您将失去未来的客户。团队士气可能会受影响，生产力会降低，啧啧称道的口碑也会离您而去。

所幸的是，计划外停机不一定转变为客服噩梦。事实证明，只要通过沟通让客户知道正在发生的事以及您为解决问题所做的工作，他们就会理解整个局面，做出不太消极的反应。

为事件沟通做准备

未雨绸缪，有备无患。如果这是一个足够好的战斗口号，对于您的事件沟通策略来说也已足够。在事件白热化时，您会庆幸自己花时间进行事件沟通。

定义什么是事件

在进行事件沟通前，首先需要确定事件的构成。许多 Web 公司依赖标准化的 4 级严重性定义体系。以下是我们自己的事件手册中有关严重性定义的指南。

无论事件严重性的阈值是多少，界限务必要分明（最好是围绕某种可衡量的指标）。如果您将某一事件指定为 1 级严重性，那么团队中的所有人都要知道它的确切含义，这一点至关重要。

严重性体系还有助于消除停机期间固有的灰色阴影。

不论选择哪种体系，对于任何涉及安全问题或数据丢失的事件，我们都建议采用零容忍沟通计划。

提前选好沟通解决方案、渠道和消息模板

专业支持团队和现场可靠性工程师不会即时决定通过哪些渠道进行沟通，他们已提前制定计划。

事件沟通主要六种沟通渠道：

• 专用状态页面

• 嵌入式状态

• 电子邮件

• 办公聊天工具

• 社交媒体

• 短信

专用状态页面

我们建议团队使用专用状态页面，作为其主要事件沟通解决方案。无论是自行构建还是使用 Statuspage 等托管解决方案，在事件发生时为客户和同事提供明确的事实来源都很重要。Statuspage 还为用户提供订阅选项，以便他们在更新发布时立即获得更新。这减轻了团队的支持负担，让他们回归到专心解决问题上。

嵌入式状态

借助 Statuspage，状态信息也可以轻松地直接嵌入到客户运营的任何网站上。我们知道，大多数访客在寻找状态页面之前可能会先查看提供商的主页或支持页。嵌入小工具（示例在此）是一种让访客知道事件是否正在发生的简便方法。访客还可以点击小工具来进入状态页面。

电子邮件

您可以根据喜好选用 Statuspage 等产品，为受众提供订阅电子邮件更新的选项。不论是直接通过电子邮件工具发送，还是使用状态页面触发，电子邮件都是一个可靠的事件沟通渠道。

聊天工具

使用 Jira Service Management 聊天，减少员工和支持人员的上下文切换和信息不对等情况。Jira Service Management 聊天可将 Slack 或 Microsoft Teams 中的对话与您的工作单进行同步。在热门聊天工具和支持部门之间开展无缝对话，有助于为某一问题提供可靠的背景信息，从而快速解决该问题。

社交媒体

许多团队使用诸如 Twitter 之类的社交渠道作为事件发生期间的沟通途径。将它纳入到您的策略中是件好事，但不要作为唯一沟通手段来依赖它。

短信

接收短信息或文本信息通常是联系他人时更为直接的方式，当涉及停机公告等关键入站警报时，许多人更喜欢采用这种方式。但这也是一个很快令人感觉消息疲劳的渠道，如果收到太多与自己无关的消息，用户就会取消订阅。

以上渠道都不是事件沟通的灵丹妙药。它们各有优势；如果组合使用，您就能真正感受到它们的强大。例如在 Atlassian，我们会将事件发布到一个状态页面，但同时会将这些更新推送到 Twitter。与事件相关的公告也会出现在我们的 Jira Service Management 门户上。然后，这些消息会引导用户返回状态页面，获取有关事件的更多详细信息。在 Jira Service Management 中管理事件可以实现多个沟通点，而不会造成误解或失去客户对翻译的信任。

为合适的受众量身定制警报和沟通

发生事件时，您需要知道应与谁沟通、如何联系他们，以及如何尽可能减少沟通中产生的摩擦和消耗的资源，从而避免客服噩梦和/或沟通失控。最好是以一个即时响应团队从内部开始，然后向外延伸，为适当的受众编撰信息。

虽然组织之间各不相同，但总的来说，将这些受众视为需要与之沟通的 5 个不同群体会有帮助：

1. 核心待命团队：最先知道出了状况的人，几乎在产生影响后立即得知（通常来自监控和警报工具）。内部团队在幕后工作，使用协作通信工具检测、聚集、情境化和解决事件。

2. 一线支持团队：事件发生期间直接回答问题并向客户提供最新消息的人。这是一个非常重要的角色，因此该团队必须获得正确的信息以传递给最终用户。

3. 经理和高管团队：核心团队需要与此群体沟通，以便其知道发生的具体情况、对后面两个群体的潜在影响，以及关于事件可能会持续多久的估计。

4. 普通员工群体：当员工依赖的服务停止工作和恢复运行时，他们需要及时获得通知。主动与这些用户沟通，以便减少“这处于什么状态”问题，削减重复的 IT 支持工作单，将更多精力集中到解决眼前的问题上。

5. 外部客户：如果事件影响到外部客户，则必须发出一些通信来解释问题并说明有望在何时修复，或者至少每隔一定时间告知最新消息。对于目前仍在影响客户能否使用您产品的问题，我们建议发送更新的间隔切不可超过一小时。另外，您还应始终指出下次更新的预计时间。如果事件足够严重，尤其是涉及安全或数据丢失，您一定会希望加快外部沟通并引入必要的其他团队（法律、人力资源、安全等）。

设置事件和中断沟通模板

在事件的白热化时期，你最不想操心的就是如何撰写事件公告。对于可能出于任何理由批评您团队的响应流程的非技术经理来说，在陈述事件时措辞不当是一个完美的攻击目标。

提前确定通用语言，获得经理批准，并保存到模板中。这样，事件发生时您就能轻松插入相关细节并发送出去。

以下是我们在自己的状态页面上使用的两个事件模板：

• 网站当前负载量高于正常水平，可能导致页面反应变慢或无响应。我们正在调查原因，并将尽快提供最新消息。

• 我们的公共指标数据存储提供商目前遇到了基础架构问题。获得更新动态或信息时，我们会立即发布相关消息。

像专业人士一样管理沟通

事件的生命周期可能包括多个联系点。管理得当的事件有一个熟悉的三幕式结构：首次联系、事件期间动态更新，以及解决方案与事后分析。

序言：集中内部团队沟通

首先，事件后端的内部团队应该有一个既定的沟通平台，并且准备好在出现问题时召集到一起。

在不同的监控、日志记录和 CI/CD 工具中集中和筛选警报，确保您的团队快速响应。借助 Jira Service Management 这样的平台，团队可以快速会合以应对事件、获取背景信息，并在事件发生期间保持联系。

第 1 部分：首次联系

初始更新最为重要。从陈述的内容，到表述的方式和发布的时间，全都为您的响应会被如何看待定下了基调。正因为此，提前准备好模板会有极大帮助。

您的目标应该是快速承认问题，简要总结已知影响，承诺进一步更新，以及（倘若可以）缓和对安全性或数据丢失的担忧。即使不知道确切细节，也要承认存在问题，这一点很重要。

第 2 部分：事件发生期间定期更新

事件过程中沟通至关重要。

Google 的 SRE 团队将沟通主管列为事件发生期间应由他人监督的关键角色之一。

摘自 Google 关于沟通主管角色的《网站可靠性工程》一书：

“此人是事件响应工作小组的公众形象。职责基本上包括定期向事件响应团队和利益相关者发布最新消息（通常通过电子邮件），并可能延伸到诸如保持事件文档的准确和更新之类的任务。”

随着事态发展，此人还将负责继续更新状态页面或将更新发布到其他渠道。即便是“我们仍在努力解决问题，没什么新的消息可以报告”这样的更新，也要胜过默不作声并让受众心悬半空。蒙在鼓里的人会开始往最坏的方面去想。

与受影响用户和其他利益相关者沟通势在必行。利用预先确定的渠道告知用户发生了什么。可以是主页上的一个 Statuspage 警报，以帮助客户获知您的团队已意识到问题，并节省支持人员处理冗余问题的时间。通过多个通知渠道（包括短信、电子邮件和移动推送）使客户了解最新情况。

无论选择使用哪种工具，我们都建议您将其中之一标识为主要沟通工具，然后将其他渠道的所有人引导到那里。通过 Jira Service Management 来管理事件沟通，可确保将正确的消息传达给正确的人。

第 3 部分：解决方案、事后分析、后续步骤

2010 年，Facebook 遭遇了迄今规模最大的一次中断。在大约 2.5 小时内，其 5 亿用户中有数百万人无法使用该社交网络。

对于这家蓬勃发展的科技巨头来说，时机非常糟糕，该公司当时仍处于用户爆炸式增长初期，依旧在向企业界证明其服务值得大肆宣传。

尘埃落定之后，一名 Facebook 工程师在该公司的工程博客上发表了关于此事件的 395 字摘要。

博客摘录：

对许多人来说，Facebook 在今天早些时候有大约 2.5 小时处于宕机或无法访问的状态。这是我们四年多来最严重的中断。首先，我们为此表示歉意。我们也想提供关于所发生事件的更多技术细节，并分享一个重要的教训。

事后分析的梗概很简单：

• 承认问题，对受影响的人表达同情并致以歉意

• 解释具体的问题和原因

• 说明为解决事件而采取的行动，以及为防止事件再次发生而采取的措施

• 再次承认问题、表达同情并致以歉意

这类沟通无需华丽的辞藻或浮夸的宣言。保持简明扼要，直截了当。例如，Facebook 博客的摘录：

我们再次就网站中断表示歉意。也希望您知道，我们十分重视 Facebook 的性能和可靠性。

这样的措辞利于客户和同事相信您在管理一个头脑冷静的团队，并且您在始终关注着。浏览我们自己的事件响应事后分析模板，以获得更多灵感。

运行永远在线的服务面临这样一个现实，事情会意外出错。停机期间有效沟通实际上可以建立与同事和客户的信任关系。响应得当可以产生全新的结果。我们还创建了这个简单工具，帮助您在发生事件期间快速编写有效的通信。