反模式

让所有人加入通话。#

信不信由你，当我们遇到SEV-2事件时，我们曾经呼叫PagerDuty的每一位工程师。如果SEV-2事件发生在凌晨3点，那么我们会在凌晨3点呼叫整个工程部门。我们走这条路有几个原因，

1. 当公司规模较小时，只有少数几位工程师。因此这个流程效果很好，因为你确实需要每一位工程师加入通话。
2. 与其对事件进行分类然后不得不呼叫额外的人员，如果所有人从一开始就在通话中，那么我们的想法是我们可以更快地响应。

随着我们的工程师部门扩大，这个流程根本无法很好地扩展，问题很快就变得明显，

1. 通话中的大多数人无事可做。他们被无缘无故地叫醒。
2. 呼叫人员有成本影响。无论是员工健康还是财务方面。在凌晨3点叫醒整个工程部门意味着第二天整个部门都不会有什么生产力。
3. 那些不在值班的人仍然会被呼叫。

在任何事件响应中保持有效的控制范围非常重要。如果你有超过7或8个人直接向事件指挥官报告，事情很快就会变得难以应付。现在我们只会呼叫特定服务的值班工程师，而不是整个团队。如果需要更多的响应者，那么他们将由内部联络员动员加入响应。十次中有九次我们不需要额外的响应者，因此工程部门的其余人员可以在不受干扰的情况下休息。这导致了一个更快乐的工程部门和一个更精简的响应流程。

强迫每个人留在通话中。#

我们最初的思考是，如果你被动员加入响应通话，那么我们需要你一直待到结束，因为如果你在某一点被需要，很可能在事件解决之前你会再次被需要。不幸的是，我们后来发现这从来都不是真的。通常某人会被动员去调查一个特定的系统，或执行一个特定的行动，之后就不会再需要他们了。我们会有一通全是无所事事的人，他们本可以回去睡觉。这也可能助长“英雄”心态，个人感到压力必须留在通话中。

现在我们要求人们离开通话，如果他们不再需要的话。一旦事件指挥官确定了哪些系统受到影响，他们会让其他系统的代表离开通话，以便他们可以休息。如果他们真的需要，你随时可以再次动员他们。大多数时候他们不会再被需要，所以我们优化了99%的情况。

过于频繁的状态更新。#

高管需要知道发生了什么，并希望每5分钟提供一次状态更新，以让他们了解情况。问题是，你会花全部时间提供状态更新，而不是解决问题。

我们发现，在重大事件期间每20-30分钟提供一次状态更新是一个典型的工作节奏。这确保我们不是为了提供更新而提供更新，而是更有可能包含一些实际有用的信息。这并不是说如果真的有新信息要分享，你不能更频繁地提供更新，但这不应该是一个要求。我们希望尽可能多地解决问题，但我们也希望确保让利益相关者了解情况。这是一个微妙的平衡，很容易出错。

假设沉默意味着没有进展。#

在事件通话中保持沉默可能意味着什么都没做，但这很少是情况。加入通话时，要知道一个没有对话的会议是可以接受的和合理的。沉默通常意味着每个人都在努力解决问题，而不是交谈和提供更新。我们不是在玩“一直说话就不会被解雇”的游戏。事件指挥官应该是在通话中说话最多的人。如果合适，他们通常会用状态更新填补沉默，但组织中的其他人需要被训练知道通话中的沉默不是坏事，也不意味着进展停滞。确保员工事先了解这一点，可以防止在事件通话中出现尴尬的对话，这最终会分散解决事件的注意力。

在事件通话中讨论严重性。#

PagerDuty过去许多事件通话的开始都是关于我们是否真的处于SEV-2情况，或者是否是一个可以在没有事件通话的情况下处理的小问题的讨论。这个讨论通常会占用相当多的时间，因为每个人都想发表意见。问题是，当你进行这个讨论时，事件仍在幕后继续，当你结束讨论时，它已经变成了SEV-1，你刚刚浪费了10分钟讨论严重性。

我们现在有一条规则：我们不在事件通话中讨论事件严重性，我们总是假设它是更高的严重性并这样处理。所以如果我们不确定它是SEV-2还是SEV-3，我们把它当作SEV-2并继续。我们已经启动了事件响应的齿轮并呼叫了响应者，所以即使它最终是SEV-3，我们不妨继续这个过程，如果没有什么别的，就当作练习。

犹豫不决地升级到其他响应者。#

如果现在是凌晨3点，你正在响应一个事件，我们有过这样的情况，一个主题专家（SME）会卡在试图调试一个问题上，他们会因为时间的原因不愿意涉及他们的团队成员。这最终导致我们的事件持续时间比需要的更长。

“永远不要犹豫升级”现在是我们的座右铭之一。如果你卡在一个问题上，现在是凌晨3点，不要犹豫呼叫一个更有知识的人来帮助解决问题。不要走得太远呼叫所有人，否则你会陷入早期的反模式。但你应该永远不要觉得如果你需要帮助就不能呼叫某人。

在事件通话中讨论流程和政策决策。#

有时响应者不同意我们可能使用的应急响应政策和流程。有时这会导致在事件通话中进行讨论，这最终会破坏每个人的流程，并导致潜在的事件持续更长时间，阻碍响应。对流程有异议并希望做出改变是完全OK的（事实上，这是我们鼓励的事情，因为它允许我们迭代改进我们的流程），但在事件期间不是讨论的时候。

政策和流程不应该在事件期间讨论，就像严重性一样。在事件期间应遵循当前流程，任何担忧应在事后提出，无论是事后分析还是直接向管理应急响应流程的团队提出。

忽视事后分析和后续活动。#

一旦事件解决，很容易忽视事后分析。你可能觉得原因已经很清楚，或者你认为这不值得。不要陷入这个陷阱！事后分析总是值得的。人们被动员起来响应一个事件，这有相关的成本。我们希望确保我们理解为什么会发生这种情况，以便我们将来避免这种成本。

不要在事件后忽视事后分析。没有事后分析，你无法认识到你做得对的地方，你可以在哪里改进，最重要的是，如何避免下次犯同样的错误。一个设计良好的、无责备的事后分析允许团队持续学习，并作为一种迭代改进你的基础设施和应急响应流程的方式。

如果你动员了响应者并确定这不是一个“真实”的事件，你仍然应该进行事后分析。因为下次你将再次动员响应者并浪费时间。找出为什么在可能不需要的情况下触发了应急响应，并解决这个问题。

过于专注于你面前的问题。#

作为一个事件的响应者，你通常会专注于你面前的特定任务。事件指挥官通常是那个有更大画面的人。有时会有一种倾向，即SME过于专注于他们面前的问题，而不是考虑更大的画面。这通常在事件通话中表现为SME不断提出同一个问题，不听从事件指挥官的指示，并对他们系统上的特定问题有隧道视野。

事件指挥官的指示应该始终被遵循，因为他们通常会有更多的整体上下文。尽量不要陷入过于专注于你面前的问题的陷阱，以至于你破坏了流程。我们希望治疗原因，而不是事件的症状。

对政策和流程变化持反感态度。#

一旦一个稳定的流程到位，并且事件得到解决，对于改变那个流程会有很多犹豫和抵制。“如果它没坏，就不要修它”，等等。随着公司的发展，你的响应需要改变。坚持你的旧流程和实践太久会阻碍你未来的应急响应。当然，不要鲁莽，但尝试引入合理的改变，不要害怕做出可能会在短期内减慢事情，但在长期内会加快速度的改变。这些是最难做出的改变，但通常是最有价值的。

试图承担多个角色。#

在过去的PagerDuty事件中，我们有过这样的情况，事件指挥官开始承担主题专家的角色，并试图自己解决问题。这通常发生在IC是他们的日常工作中的工程师时。他们在一个事件中，原因似乎是一个他们非常了解的系统，并且有必要的知识来修复。想要快速解决事件，IC会开始尝试解决问题。有时你可能会幸运，它会解决事件，但大多数时候立即可见的问题不一定是事件的根本原因。当这一点变得明显时，你有一个事件指挥官不再关注其他系统，只是专注于他们面前的一个问题。这意味着实际上没有事件指挥官，因为他们会忙于试图解决问题。不可避免地，问题比预期的要大得多，响应已经完全脱轨。

你不能在担任事件指挥官的同时承担另一个角色。当你想作为一个SME跳进去时，担任IC可能很困难，但你必须抵制这个诱惑，放弃IC的角色。如果你真的是唯一能解决问题的人，你应该交给另一个事件指挥官，然后承担SME的角色。这确保了响应流程保持轨道，有一个专门的事件指挥官。

记住，IC的工作还包括准备备份计划，以防当前行动没有解决事件。如果你作为一个SME在修复特定问题，你没有考虑备份计划。

试图成为英雄。#

如果你作为一个主题专家，试图自己解决每一个问题，这可能很诱人。每一个请求出现，你都想跳上去说你会处理它。你将成为那个解决所有问题的不可或缺的人。尽管意图是高尚的，但它很少导致一个有效的结果。你希望尽可能避免在事件中的多任务处理，并专注于一个问题。不要试图自己解决所有问题。如果你的专业领域有多个请求，将它们委托给其他专家，甚至根据需要呼叫备份响应者。

同样，如果另一个SME被分配了一个任务，不要未经他们咨询就代表他们做任务。虽然你试图帮助，但它最终会阻碍响应，因为会有两个人在同一个问题上工作，他们可能会以意想不到的方式相互干扰。

没有向响应者传达政策变化。#

我们过去曾陷入这样的陷阱：通过简单地更新我们的内部文档（即这个）来做出政策和流程变化，假设每个人会在事件之前阅读文档。当然，这从未发生过。

任何政策变化都需要提前适当地传达给你的响应者，这样在事件期间就不会有意外。这可以是电子邮件的形式，或者是聊天室的更新，但重大的政策变化永远不应该让响应者感到意外。

要求事件指挥官具有深厚的技术知识。#

这是我们在应急响应早期陷入的一个陷阱。我们对任何新的事件指挥官有几个强烈的技术要求，目的是只让具有深厚技术专长的IC，意图是他们可以非常快速地诊断问题。当变得明显我们需要大量的IC来维持有效的值班轮换时，我们很快意识到我们人为地限制了我们潜在的IC候选人池。

事件指挥官可以来自你的组织的各个部分，不需要是技术专家。由于事件指挥官只协调响应，他们不需要对系统有深厚的技术知识来执行他们的角色。主题专家是需要深厚技术知识的人。事件指挥官只需要对系统如何工作有一个高层次的了解。数据从哪里流入，系统如何使用它，以及数据从哪里流出。技术细节可以留给SME，IC可以问相关的问题。

通过放弃我们对事件指挥官的强烈技术要求，我们已经能够显著增加我们的IC池，保持我们响应的高质量和效率，并帮助将值班工作量的同理心扩展到公司更大的部分。