第9章

事件响应


由Jennifer Mace，Jelena Oertel，Stephen Thorne和Arup Chakrabarti(PagerDuty)与马剑和Jessie Yang撰写



每个人都希望他们的服务始终保持平稳运行，但是我们生活在一个不完美的世界，在这个世界中，确实发生了中断。当一个非常紧急的问题需要多个人或团队来解决时，会发生什么？您突然面临着同时管理事件响应和解决问题的挑战。

解决事件意味着减轻影响和/或将服务恢复到以前的状态。管理事件意味着高效地协调响应团队的工作，并确保响应者之间以及对事件进展感兴趣的人员之间进行交流。包括Google在内的许多科技公司已经采用并采用了最佳实践来管理来自应急响应组织的事件，这些组织已经使用这些实践多年。

事件管理的基本前提是以结构化的方式响应事件。大规模事件可能会造成混乱；团队事先确定的结构可以减少混乱。制定有关如何在灾难发生之前进行沟通和协调工作的规则，使您的团队能够集中精力解决突发事件。如果您的团队已经练习并熟悉了沟通和协调，那么他们在事件发生时就不必担心这些因素。

设置事件响应流程并不一定是一项艰巨的任务。有许多广泛可用的资源可以提供一些指导，例如第一本SRE手册中的管理事件。事件响应的基本原则包括:

本章说明了如何在Google和PagerDuty上设置事件管理，并提供了一些示例说明了正确执行此过程的地方以及不正确之处。如果您还没有一个简单的清单，请参阅第191页的”将最佳实践付诸实践”，可以帮助您开始创建自己的事件响应实践。

Google事件管理

事件响应提供了一种用于响应和管理事件的系统。框架和一组已定义的过程使团队可以有效地响应事件并扩大响应。Google的事件响应系统基于事件指挥系统(ICS)。

事件指挥系统

ICS是由消防员于1968年成立的，旨在管理野火。该框架提供了在事件发生期间进行通信和明确指定角色的标准化方法。基于该模型的成功，公司后来改编了ICS以响应计算机和系统故障。本章探讨了两个这样的框架:PagerDuty的事件响应过程和Google的事件管理(IMAG)。

事件响应框架具有三个共同的目标，也称为事件管理的”三个C”(3C):

当事件响应出现问题时，罪魁祸首可能是这些其中之一。掌握3C对有效的事件响应至关重要。

事件响应中的主要作用

事件响应中的主要角色是事件指挥官(IC)，通信主管(CL)和运维或运维主管(OL)。IMAG将这些角色组织成一个层次结构:IC负责事件响应，CL和OL向IC报告。

当灾难袭来时，发布事件的人员通常会担任IC角色并指挥事件的高级别状态。IC专注于3C，并执行以下操作:

IC可以将其角色移交给其他人并担任OL角色，也可以将OL角色分配给其他人。OL通过应用运维工具缓解或解决事件来响应事件。

在IC和OL致力于缓解和解决事件的过程中，CL是事件响应团队的公开代表。CL的主要职责包括向事件响应团队和利益相关者提供定期更新，以及管理有关事件的查询。

CL和OL都可以领导一个团队来帮助管理他们特定的事件响应区域。这些团队可以根据需要扩展或收缩。如果事件足够小，则可以将CL角色归还给IC角色。

实例探究

以下四个大规模事件说明了事件响应在实践中如何工作。其中三个案例研究来自Google，最后一个案例来自PagerDuty，该案例研究提供了其他组织如何使用ICS派生框架的观点。Google的示例始于未能有效管理的事件，然后发展为管理良好的事件。

案例研究1: 软件Bug—灯亮但没有人在家(Google)

此示例说明了未能尽早发布事件如何使团队无法使用快速有效地响应事件的工具。尽管这一事件在没有重大灾难的情况下得到解决，但提早升级将产生更快，更有组织的响应和更好的结果。

上下文

Google Home是智能扬声器和家庭助理，可响应语音命令。语音命令与Google Home的软件(称为Google Assistant)进行交互。

当用户说出hotword(触发Google Assistant的给定短语)时，便开始与Google Home进行交互。通过训练助手来收听给定的热词，多个用户可以使用同一Google Home设备。识别说话者的热词模型在客户端上进行了训练，但是训练数据(即说话者识别文件)存储在服务器上。服务器处理双向数据流。为了处理繁忙时间的过载，服务器具有Google助手的配额策略。为了保护服务器免受太大的请求值的影响，配额限制明显高于给定设备上Google Assistant的基准使用量。

Google Assistant 1.88版本中的一个错误导致说话者识别文件的获取频率比预期的高50倍，超过了此配额。最初，美国中部的Google Home用户仅遭受很小的流量损失。但是，随着向所有Google Home设备的推广逐步增加，用户在2017年6月3日的周末丢失了一半的请求。

事件

在5月22日星期一PST上午11:48，Jasper(正在开发Google Home的电话)碰巧正在查看每秒查询(QPS)图，并发现了一些奇怪的地方:Google助理一直每30分钟ping一次训练数据，而不是每天一次。他停止了1.88版本的发布，该版本已扩展到25％的用户。他利用Google的错误跟踪系统创建了一个bug-我们将其称为错误12345-以探究这种情况的发生原因。关于该错误，他指出Google助手一天要ping 48次数据，从而使其超出其QPS容量。

另一位开发人员Melinda将问题与以前报告的错误联系在一起，我们将其称为错误67890:每当应用刷新设备身份验证和注册状态时，语音处理器就会重新启动。该错误计划在1.88版发布后修复，因此该团队要求暂时增加该模型的配额，以减轻额外查询带来的过载。

重新启动了1.88版，并继续推出，到5月31日(星期三)已达到50％的用户。不幸的是，该团队后来得知，错误67890虽然造成了一些额外的流量，但并不是Jasper注意到的频繁获取的真正根本原因。

当天早上，客户开始向Google支持团队报告问题:每当有人说”OK Google”(或任何其他激活Google Home的关键词)时，设备就会返回错误消息。此问题阻止用户向Google Assistant发送命令。该团队开始调查可能导致用户报告的错误的原因。他们怀疑配额问题，因此他们要求再次增加配额，这似乎可以缓解问题。

同时，团队继续调查错误12345，以查看导致错误的原因。尽管配额连接是在调试过程的早期建立的，但是客户端和服务器开发人员之间的沟通不畅导致开发人员在故障排除过程中走错了路，并且整个解决方案仍然遥不可及。

该团队还对Google Assistant的访问量为何不断达到配额限制感到困惑。客户端和服务器开发人员对客户端错误感到困惑，这些错误似乎不是由服务器端的任何问题触发的。开发人员在下一个版本中添加了日志记录，以帮助团队更好地理解错误，并有望在解决事件方面取得进展。

到6月1日(星期四)，用户报告该问题已解决。没有新问题的报道，因此版本1.88继续推出。但是，尚未确定原始问题的根本原因。

到6月3日星期六星期六凌晨，1.88版的发布率已超过50％。上线活动是在一个周末进行的，当时开发人员并不容易获得。该团队没有遵循仅在工作日内执行首次上线的最佳做法，以确保开发人员可以在出现问题的情况下及时到达。

当6月3日(星期六)1.88版的发布率达到100％时，客户端再次达到服务器限制Google Assistant流量的要求。客户的新报告开始出现。Google员工报告说，他们的Google Home设备抛出错误。Google Home支持团队收到了许多有关此问题的客户电话，推文和Reddit帖子，并且Google Home的帮助论坛显示了一个正在增长的帖子来讨论此问题。尽管有所有用户报告和反馈，但该错误并未升级为更高的优先级。

在6月4日星期日，随着客户报告数量的不断增加，支持团队最终将Bug优先级提高到了最高级别。该团队没有发布事件，而是继续使用Bug跟踪系统通过”常规”方法对问题进行故障排除。值班的开发人员注意到一个数据中心群集中的错误率，并对SRE进行了ping操作，要求它们引流它。同时，团队又提出了增加配额的请求。之后，开发团队的一名工程师注意到，引流将错误推到了其他单元中，这为配额问题提供了更多证据。下午3:33，开发人员团队经理再次增加了Google Assistant的配额，并且停止了对用户的影响。事件已结束。此后不久，团队确定了根本原因(请参见前面的”上下文”部分)。

评论

事件处理的某些方面确实进展顺利，而其他方面则有改进的余地。

首先，开发者在周末聚会，并提供了宝贵的意见来解决问题。这既好又坏。尽管团队重视这些人在周末所付出的时间和精力，但成功的事件管理不应依赖于个人的英勇努力。如果开发人员无法访问怎么办？归根结底，Google支持良好的工作与生活平衡-不应在空闲时间利用工程师来解决与工作有关的问题。相反，我们应该在上班时间进行首次上线或组织一次轮班，以便在下班时间提供有偿服务。

接下来，团队努力减轻该问题。Google始终致力于首先阻止事件的影响，然后找到根本原因(除非恰好在早期就确定了根本原因)。缓解问题后，了解根本原因对于防止问题再次发生也同样重要。在这种情况下，缓解措施在三个不同的情况下成功地阻止了影响，但是团队只有在发现根本原因后才能阻止问题再次发生。首次缓解后，最好将部署推迟到根本原因完全确定之前，避免周末发生重大干扰。

最后，当问题首次出现时，团队没有发布事件。我们的经验表明，受到管理事件的解决速度更快。尽早发布事件可确保:

集中通信是IMAG协议的重要原则。例如，发生灾难时，SRE通常会聚集在”作战室”中。作战室可以是会议室等物理位置，也可以是虚拟位置:团队可能会聚集在IRC频道或群聊上。这里的关键是将所有事件响应者聚集在一个地方，并进行实时沟通以管理(并最终解决)事件。

案例研究2: 服务故障-如果可以，请缓存我

以下事件说明了当一个专家团队尝试调试具有如此多交互作用的系统时，会发生什么情况，以至于没有一个人可以”全部”掌握所有细节。听起来有点熟？

上下文

Kubernetes是由许多公司和个人贡献者共同构建的开源容器管理系统。Google Kubernetes Engine或GKE是由Google管理的系统，可为用户创建，托管和运行Kubernetes集群。此托管版本可操作控制平面，而用户则以最适合他们的方式上载和管理工作负载。

用户首次创建新集群时，GKE将获取并初始化其集群所需的Docker映像。理想情况下，这些组件是在内部获取并构建的，因此我们可以对其进行验证。但是，由于Kubernetes是一个开源系统，因此有时会在缝隙中插入新的依赖项。

事件

太平洋标准时间(PST)的一个星期四上午6:41，针对位于几个区域的CreateCluster探针故障，在伦敦针对ZKE GKE的SRE进行了呼叫。没有成功创建新集群。Zara检查了探测器的仪表板，发现两个区域的故障率均超过60％。她验证了此问题是否影响了用户创建新集群的尝试，尽管到现有集群的流量没有受到影响。Zara遵循GKE记录的程序，并于上午7:06发布事件。最初，有四人参与了该事件:

由于Rohit总部位于苏黎世，因此Zara(IC)开设了GKE Panic IRC频道，团队可以在此进行调试。当其他两个SRE陷入监控和错误消息时，Zara解释了停机情况及其对Rohit的影响。到早上7:24时，Rohit向用户发布了一条通知，告知CreateCluster在欧美地区出现故障。这变成了一个大事件。

在上午7点至8:20之间，Zara，Rohit和其他人共同致力于解决问题。他们检查了集群启动日志，发现了一个错误:

error: failed to run Kubelet: cannot create certificate signing request: Post https://192.0.2.53/apis/certificates.k8s.io/v1beta1/certificatesigningrequests

他们需要确定证书创建的哪一部分失败。SRE调查了网络，资源可用性和证书签名过程。所有人似乎都可以单独正常工作。上午8:22，Zara将事件调查摘要发布到了事件管理系统，并寻找可以帮助她的开发人员。

值得庆幸的是，GKE安排了一个开发人员待命，可以在紧急情况被呼叫。开发者Victoria加入了该频道。她要求提供跟踪错误，并要求团队将该问题上报给基础架构的值班团队。

现在是上午8:45。西雅图的第一个SRE Il-Seong到达办公室，喝了点咖啡，为当天的工作做好了准备。Il-Seong是一位资深的SRE，在事件响应方面拥有多年经验。当他被告知正在进行的事件时，他跳了起来帮助。首先，Il-Seong根据警报的时间检查了当天的释放情况，并确定当天的版本发布没有引发故障。然后，他开始了一份工作文件1以收集笔记。他建议Zara将事件升级到基础架构，云网络和计算引擎团队，以消除这些区域的根本原因。由于Zara的升级，更多人加入了事件响应:

上午9:10，事件频道有十几位参与者。该事件发生了2.5小时，没有根本原因，也没有缓解措施。沟通正成为挑战。通常，从伦敦到西雅图的应召移交是在上午10点发生的，但是扎拉决定在上午10点之前将事件指挥权移交给Il-Seong，因为他对IMAG有更多的经验。

作为事件指挥官，Il-Seong建立了一个正式的机构来处理事件。然后，他指定Zara为业务负责人，任命Herais为沟通(Comms)负责人。Rohit仍然是外部沟通主管。Herais立即向包括所有开发人员领导的GKE列表发送了”紧急集合”的电子邮件，并请专家加入事件响应。

到目前为止，事件响应者了解以下信息:

多亏了紧急集合的呼吁，GKE安全团队成员Puanani参与了这项工作。她注意到证书签名器尚未启动。证书签名器试图从DockerHub中提取镜像，并且该镜像似乎已损坏。Victoria(正在召集GKE的开发人员)在两个地理位置运行了Docker的pull命令来处理该镜像。当它在欧洲的某个集群上运行而在美国的一个集群上成功时，它失败了。这表明欧洲集群是问题所在。在上午9:56，团队确定了一个合理的根本原因。

由于DockerHub是外部依赖项，因此缓解和定位根本原因将特别具有挑战性。缓解的第一个选择是让Docker中的某人快速修复映像。第二个选项是重新配置群集，以从其他位置获取镜像，例如Google的安全图像托管系统Google Container Registry(GCR)。所有其他依赖项，包括对镜像的其他引用，都位于GCR中。

Il-Seong指派负责人同时推动这两种选择。然后，他委托一个小组研究修复损坏的群集。对于IRC来说，讨论变得过于密集，因此详细的调试移到了共享文档上，IRC成为了决策的中心。

对于第二个选项，推送新配置意味着重建二进制文件，这花费了大约一个小时。上午10:59，当团队完成90％的重建时，他们发现了另一个使用错误的镜像获取路径的位置。作为响应，他们不得不重新启动构建。

在IRC的工程师研究两种缓解方案时，SRE的Tugay有了一个主意。与其重新构建配置并将其发布(这是一个繁琐且冒险的过程)，假如他们拦截了Docker的pull请求并用内部缓存的映像替换了Docker的响应该怎么做？GCR有一个镜像站点可以做到这一点。Tugay与GCR的SRE团队联系，他们确认该团队可以在Docker配置上设置 –registry-mirror=https://mirror.gcr.io。Tugay开始设置此功能，并发现镜像站点已经就位！

在上午11:29，Tugay向IRC报告说这些镜像是从GCR镜像站点而不是DockerHub中提取的。上午11:37，事件指挥官传呼了GCR。上午11:59，GCR待命，从其欧洲存储层清除了损坏的镜像。到12:11 pm，所有欧洲区域的误差均降至0％。

中断已经结束。剩下的就是清理工作，并写出一部真正的史诗般的事后报告。

在修复之前，CreateCluster在欧洲失败了6个小时40分钟。在IRC中，整个事件中出现了41个独立用户，而IRC日志一直扩展到

26,000个字。这项工作在不同的时间组建了7个IMAG工作队，并且在任何给定时间同时工作多达4个。来自六个团队的值班人员，这还不包括在”紧急集合”呼叫中。事后总结包含28个动作项。

回顾

按任何人的标准，GKE CreateCluster中断都是一个大事件。让我们探索进展顺利的地方，以及可以更好地处理的地方。

进展顺利吗？该团队有许多记录在案的上报路径，并且熟悉事件响应策略。GKE待命Zara迅速验证了这种影响正在影响实际客户。然后，她使用事先准备好的事件管理系统来引进Rohit，后者将中断情况传达给客户。

本来可以更好地处理的？服务本身有一些需要关注的领域。复杂性和对专家的依赖是有问题的。日志记录不足以进行诊断，并且团队因DockerHub的损坏而分心，这并不是真正的问题。

在事件开始时，事件指挥官没有建立正式的事件响应结构。当Zara担任这个角色并将对话转移到IRC时，她本可以在协调信息和制定决策方面更加主动。结果，少数急救人员在没有协调的情况下进行了自己的调查。Il-Seong在首页之后两个小时就建立了正式的事件响应结构。

最后，该事件表明GKE的灾难恢复工作存在差距:该服务没有任何早期的通用缓解措施可以减轻用户的痛苦。通用缓解是指即使在根本原因尚未完全了解之前，急救人员采取的缓解疼痛的措施。例如，当中断与发布周期相关联时，响应者可以回滚最近发布的版本，或者重新配置负载均衡器以避免在本地化错误时出现故障。重要的是要注意，通用缓解措施是钝器，可能会导致其他服务中断。但是，尽管它们可能比精确解决方案具有更广泛的影响，但可以在团队发现并解决根本原因的同时迅速部署它们以止血。

让我们再次查看该事件的时间表，以了解通用缓解措施可能在哪些地方有效:

步骤2(发现可能的原因)之后的一般缓解措施在这里非常有用。如果响应者一旦发现问题的大致位置，便已将所有图像回滚到已知的良好状态，则该事件将在上午10点之前缓解。要缓解事件，您不必完全了解详细信息-仅需要知道根本原因的位置。在完全了解故障原因之前具有缓解中断的能力对于运行具有高可用性的强大服务至关重要。

在这种情况下，响应者会从某种有助于回滚的工具中受益。缓解工具确实需要花费工程时间来开发。创建通用缓解工具的正确时间是在事件发生之前，而不是在响应紧急情况时。浏览事后检查是发现缓解措施和/或工具(在回顾中可能有用)并将其构建为服务的一种好方法，以便将来更好地管理事件。

重要的是要记住，第一响应者必须首先将缓解措施放在第一位，否则解决时间会受到影响。采取通用的缓解措施，例如回滚和引流，可以加快恢复速度，并带来更高兴的客户。最终，客户不在乎您是否完全了解造成中断的原因。他们想要的是停止接收错误。

以缓解为重中之重，应对活动中的事件的处理方法如下:

  1. 评估事件的影响。

  2. 减轻影响。

  3. 对事件执行根本原因分析。

  4. 事件结束后，请解决导致事件的原因并撰写事后事后报告。

之后，您可以运行事件响应演练来演练系统中的漏洞，工程师可以在项目上进行工作以解决这些漏洞。

案例研究3: 停电—雷电不会击中两次…直到它做到了

前面的示例显示了当您没有适当的事件响应策略时可能会出问题的地方。下一个示例说明了已成功管理的事件。当您遵循定义明确且清晰的响应协议时，您甚至可以轻松处理罕见或异常事件。

上下文

诸如雷击之类的电网事件会导致进入数据中心设施的功率发生巨大变化。影响电网的雷击很少见，但并非意外。Google使用备用发电机和备用电池来防止突然的，意外的停电，这些备用发电机和电池经过了充分的测试，可以在这些情况下工作。

Google的许多服务器都附有大量磁盘，这些磁盘位于服务器上方或下方的单独托盘中。这些托盘有自己的不间断电源电池(UPS)。发生断电时，备用发电机将激活，但需要几分钟才能启动。在此期间，连接到服务器和磁盘托架的备用电池将一直供电，直到备用发电机完全运行为止，从而防止电网事件影响数据中心的运行。

事件

2015年中，闪电在两分钟内四次击中比利时Google数据中心附近的电网。数据中心的备用生成器已激活，可以为所有计算机供电。在备用发电机启动时，大多数服务器用备用电池运行几分钟。

磁盘托架中的UPS电池在第三和第四次雷击时未将电源切换为备用电池电力，因为这些雷击间距太近。结果，磁盘托架断电，直到备用发电机启动为止。服务器没有断电，但无法访问已关闭电源再打开的磁盘。

在永久性磁盘存储上丢失大量磁盘托盘会导致在Google Compute Engine(GCE)上运行的许多虚拟机(VM)实例发生读写错误。这些错误将立即通知持久化磁盘SRE值班团队。一旦Persistent Disk SRE小组确定了影响，便宣布了一个重大事件并向所有受影响的各方宣布。持久化磁盘SRE值班人员承担了突发事件指挥官的角色。

经过初步调查和利益相关者之间的沟通，我们确定:

持久化磁盘SRE的主要值班人员仍然是IC角色，因为该团队对客户影响具有最佳可见性。

运维团队成员的任务如下:

前两个目标已明确定义，充分理解并记录在案。数据中心运维值班人员立即开始工作，以安全地恢复供电，并向IC提供定期状态报告。持久化磁盘SRE已定义了用于重新启动所有未托管虚拟机的计算机的过程。团队成员开始重新启动这些计算机。

第三个目标比较模糊，任何现有程序都没有涵盖。事件指挥官分配了一个专门的运维团队成员来与GCE SRE和持久化磁盘SRE进行协调。这些团队进行了协作，以安全地将VM从受影响的计算机上移开，以便可以重新启动受影响的计算机。IC密切监控他们的进度，并意识到这项工作要求快速编写新工具。IC组织了更多的工程师向运维团队报告，以便他们可以创建必要的工具。

沟通负责人观察并询问了所有与事件相关的活动，并负责向多个受众报告准确的信息:

在减轻最初对客户的影响之后，我们需要进行一些跟进，例如:

事件后的分析表明，只有极少数的写操作(在事件期间断电的机器上未决的写操作)从未写入磁盘。由于持久化磁盘快照和所有Cloud Storage数据都存储在多个数据中心以实现冗余，因此仅丢失了0.000001％的来自运行中的GCE计算机的数据，并且只有来自运行中的实例的数据处于危险之中。

回顾

通过尽早宣布事件并组织有明确领导的对策，一组精心管理的人员可以有效地处理这一复杂事件。事件指挥官将恢复电源和重新启动服务器的正常问题委托给适当的操作负责人。工程师致力于解决问题，并将其进度报告给了运维负责人。

要同时满足GCE和持久化磁盘的需求，更复杂的问题需要协调决策和多个团队之间的互动。事件指挥官确保从这两个团队中分配适当的操作团队成员，并直接与他们合作以寻求解决方案。事件指挥官明智地专注于事件的最重要方面:尽快解决受影响客户的需求。

案例研究4: PagerDuty的事件响应

由PagerDuty的Arup Chakrabarti撰写

几年来，PagerDuty已经开发并完善了我们的内部事件响应实践。最初，我们在公司范围内任命了一名永久性的事件指挥官，并为每种服务配备了专门的工程师来参与事件响应。随着PagerDuty的员工人数增加到400多人和数十个工程团队，我们的事件响应流程也发生了变化。每隔几个月，我们都会仔细检查流程，并对其进行更新以反映业务需求。我们学到的几乎所有内容都记录在https://response.pagerduty.com上。我们的事件响应流程故意不是静态的；他们就像我们的业务一样不断变化和发展。

PagerDuty的重大事件响应

通常，小事件仅需要一名值班工程师来响应。对于较大的事件，我们非常重视团队合作。在高压力和高影响的情况下，工程师不应感到孤独。我们使用以下技术来促进团队合作:

参加模拟练习

我们教团队合作的一种方式是参加失败星期五。PagerDuty从Netflix Simian Army汲取了灵感。最初，”失败星期五”是一个手动失败注入练习，旨在更多地了解我们的系统可能崩溃的方式。今天，我们还使用每周一次的练习来重现生产和事件响应场景中的常见问题。

在”失败星期五”开始之前，我们将任命一名事故指挥官(通常是经过培训成为IC的人员)。在进行故障注入练习时，它们会表现得像真实的IC一样。在整个演练中，主题专家将使用与实际事件相同的过程和语言。这种做法既使新的值班工程师熟悉事件响应语言和流程，又为经验丰富的值班工程师提供了进修课程。

玩限时模拟游戏

尽管”失败星期五”演习对于培训工程师如何使用不同的角色和流程有很大帮助，但他们无法完全复制实际重大事件的紧迫性。我们使用具有时间紧迫性的模拟游戏来捕获事件响应的这一方面。

“没人会被炸掉”是我们充分利用的一款游戏。它要求玩家共同努力在规定的时间内消灭炸弹。游戏的压力和交流密集性迫使玩家进行有效的协作和合作。

从以前的事件中学习

从先前的事件中学习可以帮助我们更好地应对未来的重大事件。为此，我们进行并定期检查事后报告。

PagerDuty的事后处理涉及公开会议和详尽的文档。通过使这些信息易于访问和发现，我们旨在减少解决未来事件的时间，或完全杜绝未来事件的发生。

我们还会记录重大事件中涉及的所有电话，以便我们可以从实时通信提要中学习。

让我们看一下最近的事件，其中PagerDuty必须利用我们的事件响应过程。该事件发生于2017年10月6日，持续了10多个小时，但对客户的影响却很小。

用于事件响应的工具

我们的事件响应流程利用了三个主要工具:

PagerDuty

我们将所有通话信息，服务所有权，事后报告，事件元数据等存储在PagerDuty中。这使我们可以在出现问题时迅速组建合适的团队。

Slack

我们为所有主题专家和突发事件指挥官提供了一个专用渠道(\＃incident-war-room)作为集会场所。该频道主要用于

作为抄写员的信息分类帐，他记录了操作，所有者和时间戳。

电话会议

当要求加入任何事件响应时，值班工程师需要拨入静态电话会议号码。我们希望所有协调决策都在电话会议中做出，并且决策结果记录在Slack中。我们发现这是做出决定的最快方法。我们还记录每个电话，以确保在抄写员错过重要细节时我们可以重新创建任何时间表。

虽然Slack和电话会议是我们选择的沟通渠道，但您应该使用最适合您的公司及其工程师的沟通方式。

在PagerDuty，我们如何处理事件响应直接关系到公司的成功。我们没有面对未准备好的此类事件，而是通过进行模拟演练，回顾先前的事件并选择合适的工具来有针对性地为事件做准备，以帮助我们抵御可能遇到的任何重大事件。

将最佳实践付诸实践

我们已经看到了处理得很好的事件的例子，有些则没有。当呼叫向您发出问题警报时，考虑如何处理该事件为时已晚。开始考虑事件管理过程的时间是在事件发生之前。那么，在灾难来临之前，您如何准备理论并将其付诸实践？本节提供一些建议。

事件响应培训

我们强烈建议培训响应者以组织事件，这样他们就可以在真正的紧急情况下采取行动。知道如何组织事件，在整个事件中使用通用语言以及共享相同的期望可以减少发生误解的机会。

完整的”事件指挥系统”方法可能远远超出您的需要，但是您可以通过选择事件管理过程中对组织重要的部分来开发用于处理事件的框架。例如:

您可以调整和总结事件响应框架，并创建幻灯片组以向新团队成员展示。我们了解到，人们可以将事件响应理论与实际场景和具体行动联系起来，因此更愿意接受事件响应培训。因此，一定要包括动手练习并分享过去事件中发生的事情，分析进展顺利和不顺利的情况。您也可以考虑使用专门从事事件响应课程和培训的外部机构。

事前准备

除了事件响应培训之外，它还有助于事前准备事件。使用以下提示和策略可以更好地做好准备。

决定沟通渠道

事先确定并同意通信渠道(Slack，电话桥，IRC，HipChat等)—事件指挥官不想在事件发生时做出此决定。练习使用它，所以不会感到惊讶。如果可能，选择团队已经熟悉的沟通渠道，以便团队中的每个人都可以轻松使用它。

让听众知情

除非您确认事件正在发生并得到积极解决，否则人们会自动认为没有任何事情可以解决。同样，如果您在问题得到缓解或解决后忘记取消呼叫响应，则人们会认为事件仍在继续。您可以通过定期更新状态来使事件发生期间的听众保持知情，从而避免这种动态变化。准备好联系人列表(请参阅下一个技巧)可以节省宝贵的时间，并确保您不会错过任何人。

请提前考虑如何起草，审阅，批准和发布公共博客文章或新闻稿。在Google，团队寻求公关团队的指导。另外，准备两个或三个可随时使用的模板以共享信息，以确保通话中知道如何发送它们。没有人愿意在没有指导的情况下承受巨大压力。模板使与公众共享信息变得容易且压力最小。

准备联系人列表

事先准备好要发送电子邮件或页面的人员列表，可以节省关键的时间和精力。在”案例研究2:服务错误–如果可以，请给我缓存”，第180页上的沟通Lead通过向预先准备的几个GKE列表发送电子邮件来进行”紧急集合”的呼叫。

建立事件准则

有时候，很明显呼叫问题确实是一个事件。有时还不清楚。拥有确定的标准列表来确定问题是否确实是有帮助的。团队可以通过查看过去的中断情况，并考虑已知的高风险区域，得出可靠的标准列表。

总之，在应对事件时建立协调和沟通的共同基础很重要。确定沟通事件的方式，受众是谁，以及谁对事件负责。这些准则易于设置，并且对缩短事件的解决时间有很大影响。

操练

事件管理过程的最后一步是练习事件管理技能。通过在不太紧急的情况下进行练习，您的团队会在雷击时养成良好的习惯和行为方式，无论是从形象上还是从字面上看。通过培训介绍事件响应理论之后，实践可确保您的事件响应技能保持最新状态。

有几种方法可以进行事件管理演练。Google在全公司范围内进行了弹性测试(称为灾难恢复测试或DiRT；请参阅Kripa Krishnan的文章”应对意外情况” 2)，在该测试中，我们创建了可控制的紧急情况，实际上并未影响客户。团队对受控紧急情况的响应就像是真正的紧急情况一样。之后，团队将审查应急程序并讨论发生了什么。接受失败作为学习的一种方法，在已发现的差距中寻找价值，并在我们的领导层中发挥领导作用，对于在Google成功建立DiRT计划至关重要。在较小的规模上，我们使用诸如轮盘赌(Wheel of Fortune)之类的练习来练习对特定事件做出响应(请参阅《站点可靠性工程》中的“灾难角色扮演”)。

您还可以通过有意将小问题视为需要大规模响应的重大问题来练习事件响应。这样一来，您的团队就可以在较低风险的实际情况下使用过程和工具进行练习。

演习是尝试新的事件响应技能的一种友好方式。团队中任何可以卷入事件响应的人-SRE，开发人员，甚至客户支持和营销合作伙伴-都应该对这些策略感到满意。

要进行演习，您可以制造中断，并让您的团队对事件进行响应。您还可以从事后总结中创建中断，其中包含事件管理演练的大量想法。尽可能使用真实的工具来管理事件。考虑破坏您的测试环境，以便团队可以使用现有工具进行真正的故障排除。

如果定期运行所有这些演练，它们将更加有用。您可以通过跟进每个练习并附上一份报告来使演习具有影响力，该报告详细说明了哪些方面进展顺利，哪些方面进展不好以及如何更好地处理问题。进行演习最有价值的部分是检查其结果，这可以揭示出事件管理方面的许多空白。一旦知道它们是什么，就可以努力将其关闭。

结论

为灾难袭来做好准备。如果您的团队定期练习并刷新事件响应程序，那么在不可避免的中断发生时，您就不会惊慌。

事件期间您需要与之合作的人员圈子随着事件的规模而扩大。当您与不认识的人一起工作时，过程可帮助您创建快速迈向解决方案所需的结构。我们强烈建议在世界未”着火”时提前建立这些程序。定期检查并迭代事件管理计划和手册。

事件指挥系统是一个易于理解的简单概念。它根据公司的规模和事件的规模来扩大或缩小。尽管很容易理解，但实施起来并不容易，尤其是在紧急情况突然超过您的情况下。在紧急情况下保持镇静并遵循响应结构需要练习，练习可以建立”肌肉记忆”。这使您有信心在真正的紧急情况下需要。

我们强烈建议您在团队繁忙的时间中安排一些时间来定期练习事件管理。在专门的练习时间获得领导的支持，并确保他们了解事件响应的工作方式，以防您需要让他们参与实际事件。备灾可以节省宝贵的几分钟或几小时的响应时间，并为您提供竞争优势。没有公司能一直做到正确—从错误中吸取教训，继续前进，并在下一次做得更好。



  1. 当三个或三个以上的人员处理一个事件时，启动一个协作文档很有用，该文档列出了工作原理，消除的原因以及有用的调试信息，例如错误日志和可疑图形。该文档会保留此信息，因此不会在对话中迷路。 ↩

  2. 克里帕·克里山(Kripa Krishan)，”出乎意料的风雨”，ACM通讯 10，否。 9(2012)，https: //** queue.acm.org/detail.cfm?id=2371516。 ↩