如今几乎每一家软件公司都有某种事件响应流程来帮助他们应对重大服务中断。对讲机也不例外，直到2018年年中，我们的事件响应流程都很成功。我们有许多经验丰富的工程师，他们曾参与过其他公司的随叫随到，我们进行了基本的事后检查，总体而言，对于我们这样规模的公司，我们的停机频率和持续时间都相当不错。然而，在一次特别复杂且持续时间较长的事件（内部称为"SpamHaus事件"）之后，我们意识到我们需要大幅提升我们的游戏水平。随着我们业务的增长，任何事件对客户的潜在影响也在增加。我们的工程组织也在发展，现在有更多的利益相关者需要知道大修期间发生了什么。我们对较小事件的事件响应过程是可靠的，但对于特别关键的问题，显然有许多改进的机会。在过去的几个月里，我们一直致力于巩固我们的事故响应流程和文档。我们现在分享它，希望它能帮助其他人更快、更轻松地采用更好的事件管理流程。定义事件的不同阶段要建立一个成功的事件响应流程，首先要做的是后退一步，看看大多数事件在发展过程中发生了什么。当然，事件有各种不同的形状和大小。例如，一种相对常见的事件可能是由于数据库故障转移而导致的对讲机短暂中断。然而，根据我们在2018年年中的经验，我们对解决更严重的停机问题特别感兴趣，这需要更正式的事件管理流程。这些情况下，没有明确的问题解决方案，问题的持续时间延长，或客户影响严重。第一步是确定事件的不同阶段：识别：停机通常由随叫随到的工程师进行识别，并分配优先级，当我们了解到全部影响时，这一点可以稍后更改。分类：事件响应小组将进行调查，遵循随事件发展而变化的程序。这通常由经验丰富的工程领导来管理。沟通：必要时，可以与客户、支持、销售和领导层进行沟通。这可以由客户支持团队或通过非正式渠道完成。解决方案：事件得到解决，并采取后续行动，如事件回顾。这是由工程师在工程领导的监督下管理的。我们还努力对事故的严重程度进行了明确分类。例如，我们的一些团队有一个错误的假设，即P0总是与安全相关的，所以我们在这方面投入了大量的教育，除了提供更多的例子来说明我们将P0（一个使公司的公众声誉处于危险的大事件）到P3（一个应该被修复的小缺陷或bug）。我们还提供了一些指导方针，说明如何将某件事情从P1升级到P0（例如延长事件持续时间，或灾难性的客户影响，如数据丢失），这在特别复杂的情况下有帮助。以前，有不同的人在不同的阶段参与进来，根据自己的心理模型来判断需要做什么，而且没有明确的指导去做什么，尤其是当事情没有计划好的时候。虽然这对较小的公司来说是可行的，但对于一家运营成熟的公司，比如内部通信公司，在任何特定阶段谁在做什么，都需要有一些表面上的清晰和责任感。这让我们很好地谈到下一点…定义角色事件本身就足以引发压力，因此团队最不需要的就是不确定他们需要帮助谁，以及谁需要与谁沟通。通过预先定义明确的角色，你创造了一个环境，使你的队友之间的沟通更加简单明了。首先，我们介绍了一个正式的事件指挥员角色。过去，我们通常都有人来管理这件事，但这是非正式的，没有明确的责任。有了事件指挥员，我们现在有人可以作为唯一的真相来源，负责管理事件的技术解决方案，端到端。这不是我们凭空发明的角色。这是我们整个行业（以及其他行业）的一个常用角色，尽管有各种不同的头衔和职责。除了管理事件本身，事件指挥官还负责所有发生的技术通信。与其他公司不同的是，我们经过深思熟虑后决定不再担任单独的"技术领导"角色。考虑到我们组织的规模，将事件指挥员和技术负责人的角色分开并不是完全合理的，尽管我们认为对于一个特别复杂的事件，事件指挥员有能力提名一名技术负责人。我们创建的第二个角色是业务主管，这是为了解决我们如何与工程组织之外的人员进行沟通而设计的。为此，我们创建了我们称之为业务主管的角色。这是负责协调事件响应室以外的所有通信的人。这意味着与我们的客户、我们的客户支持团队沟通，有时还包括我们的领导团队。我们已经有了一个与客户支持团队合作的轻量级流程（例如，为较低优先级的事件更新对讲机的状态页面），但当发生特别严重的事件时，业务主管可以帮助更频繁、更主动地与客户沟通，并确保销售，领导层和客户支持团队意识到潜在的业务影响。定义原则在对讲机，我们一般都喜欢尽可能从第一原则开始工作。原则在快速变化的事件（如停机）中尤其重要。即使有了最好的文档和最健壮的流程，实际情况是停机本质上是不可预测的事件，在这种情况下，您不可能预测到自己可能遇到的每一种情况。这就是为什么有一套指导原则很重要，以帮助人们在没有明确步骤的情况下做出自主决策。以下是我们创建的事件管理原则的几个示例：一次做一件事同时改变两个或两个以上的东西是危险的，可能是有害的。它会产生更多的工作来跟踪正在发生的事情，有更多的事情会同时出错，你可能不确定到底是什么让事情变得更好或更糟。按顺序做事，除非有很好的理由去做。在进行下一个更改之前，请验证每个更改的影响。先试试简单的东西有一些常见的恢复策略可以在各种情况下发挥作用，有时即使你没有任何东西可以准确地将其与你所看到的联系起来。回滚应用程序。故障转移数据库。切换功能标志。清除缓存。这些行为是经常发生的常见事件，执行起来既快又安全。代码或基础结构更改的实现速度可能较慢，并且可能依赖于健康的构建和部署管道。询问团队"我们可以快速尝试什么？"在对问题进行精确诊断之前，快速、安全地处理问题可以导致快速解决。快点把东西包起来在结束一个事件之前让事情拖一段时间是很常见的。别这样。一旦确定情况稳定，并且您不再处于危机模式，请立即将人员从房间中移出并关闭设备。确保后续行动的负责人知道他们有工作要做，以及我们对他们有什么期望。我们越快恢复正常业务，影响就越小。培训和文件文档是可靠事件管理过程中最关键的方面之一。在一个重大事件的火药箱环境中，你最不希望看到的就是人们坐在一张空白的页面上，或者重新发明轮子，从头开始创建新的流程。在关键事件期间，每秒钟的计数和文档记录将为您的团队提供一个非常重要的起点，以确保您尽可能快速、无缝地恢复。我们最引以为豪的文档是一个有趣的培训视频，我们为那些有兴趣成为事件指挥官的人制作的。我们在都柏林和旧金山的办公室培训了四名指挥官，并建立了一个与我们办公时间一致的轮换制度，因为我们的大多数事件都是在这个时候发生的。但我们也希望使程序民主化，确保每个人都能使用我们的事件管理工具和资源。

我们还编写了大量传统文档，如事件检查表和入职指南。

事件指挥官文件摘录由于这项工作，我们的处境要好得多。当出现问题时，我们为客户提供在线恢复服务。当我们需要告诉我们的客户或内部利益相关者正在发生的事情时，我们的工作效率要高得多。付诸实践同样的，如果没有经过beta测试，你就不会发布新产品，因此，在将事件管理流程推广到整个公司之前，对我们的事件管理流程进行测试是非常重要的。我们最有价值的练习之一是让人们头脑风暴，想出可能以各种方式伤害对讲机和我们客户的情景，然后使用这些方法