一份处理宕机的应急响应入门指南

本文最初发布于 byrayray.dev 网站，经原作者授权由 InfoQ 中文站翻译并分享。

在职业生涯中，我跟事故仿佛“结下不解之缘”。也许，这是命运使然，或者我喜欢看到事物是怎么出问题的。也许，罪魁祸首是我？不管出于何种原因，这种经历给我很大帮助，让我总结出一套应对事故的方法论。

从那时起，Matthieu 就时常鼓励我向更多人分享这些理念。于是我接受了他的建议，写下这篇文章。

如果你搜索过应急响应（Incident Response）这个概念，会发现有很多结果是关于应急角色（incident role）的。Atlassian 上有一些优秀的文档很好地解释了这些概念。

简单来说：

• 应急角色可随着你响应团队的成长而帮助扩展应急规模。角色有助于分离职责，确保应急工作的各个方面都有专人值守。定义这些角色可以让每个人都清楚自己应该做的事情，以及对彼此应有的期望。

• 有两个角色是你必须关注的：

• 应急指挥官，是针对事故所采取措施的唯一联系人。他们不需要亲临一线采取行动，但是在重新启动服务器之前，请先与他们做好确认。这样就避免了某位好心办坏事的同事说出那句经典的“糟了，我不知道你正在将数据库还原到这个节点上”。

• 联络角色。这个角色是必不可少的，也是缺少结构化应急响应流程时最容易被遗忘的角色。你当然不能重蹈覆辙，而是要尽早任命某人来管理联络事宜，并确保所有响应人都主动分担与他们的联络工作。永远不要要求人们同时做调试和联络工作，这样会分散他们的注意力，结果两件事情都会搞砸！

• 文献中还定义了其他许多角色，但是只有当你的团队对每个角色的含义有深刻的了解时，这些角色才能派上用场。我认为，指挥官和联络人是至关重要的——在没有足够培训的前提下增加粒度会扰乱应急工作，并削弱你的响应能力。

如果你对想要使用的角色感到相当满意，并且你的团队在所有角色上都有良好的实践经验，那么你就迈出了高效响应的第一步。可是，现在有了各种角色，你的团队该如何解决问题呢？

第一，快速找到流血部位

首先，找出流血部位（what is bleeding）。如果你可以尽早确定应急响应的范围，就意味着你接下来的措施就更可能解决问题。

尝试：

• 确定是哪些系统发生了故障，然后检查各个依赖项，判定问题是由上游组件还是下游组件引起的；

• 一定要警惕假设。对于你从第三方获得的所有信息，一方面给予信任，另一方面请务必验证。记录你所做的验证工作，例如你运行的命令和运行的时间。错误的假设可能会让你的响应偏离正轨，因此请尽力避免它们。

• 找到技术上的问题源头后，请考虑做一些影响分析。不要因为这部分工作而影响进度，但如果有人愿意，请让他们估计影响的范围——哪些人受影响，人数有多少。对影响的不正确理解可能会导致错误的决定，而清楚地了解受影响的对象可以帮助组织的其他部分（客户成功、客户支持等）做出适当的响应。

一旦团队理解了事故的性质，就可以开始止血（stop the bleeding）。换句话说，你的目标应该是尽快阻止当前的麻烦，并将清理工作推迟到压力更小的时间段再做。

第二，确定行动的优先级

为此，我们需要确定行动的优先次序，以尽可能取得最佳的成果。请注意“尽可能”这一短语：应该立即采取能够迅速实施的例行补救措施，就算你怀疑它只能解决部分问题也无所谓。

这些措施包括：

• 回滚到一个确认没问题的版本，就算你觉得自己很快就能写好修复程序，也可以在回滚后压力较小的情况下再徐徐而图之。

• 采取措施保护关键系统，就算牺牲其他一些不太关键的流程也可以。如果某个端点导致整个系统出现故障，请在这个端点恢复了关键服务后立刻 no-op 掉它。

• 充分调动团队，并主动应用你认为风险较低的修补程序，就算你怀疑它可能无法解决全部问题也不怕：缩减不必要的队列、冻结部署、重新启动服务器。充分调动人力就可以快速做尝试，前提是其他响应者要继续分析问题的根源，同时假设简单的修补会无济于事。

这样你就应该大致了解自己的团队应该做什么事情了。现在的问题是，他们应该如何协作来执行这些任务呢？

第三，使用高效率工具、创建应急文档

鉴于沟通交流在应急响应工作中的重要性，你需要一款高效率工具来传递即时消息并记录操作日志。

可以使用 Slack（或其他有着相同功能的软件）：

• 在任何事故中，第一项操作就应该是创建一个消息频道。有很多工具（monzo/response、Netflix 的 Dispatch）可以为你自动创建它（还有很多其他东西），但就算你得自己手动完成这一步，也一定不能跳过它。为了准备好这个通道，多花费一分钟的停机时间也是值得的。

• 我坚决反对私有应急响应频道。公司内部使用的公共通道可以提升信息访问的便捷性，从而加强你的响应能力。这样可以避免很多会让你头痛的协调（有一次，我见过两支彼此独立的应急团队在处理同一个事故，但他们之间根本不知道对方的存在……）

• 每当你要执行破坏性操作（例如运行一条命令或重新启动某些资源）时，请向频道发送告知消息。这不仅可以让整个团队提高警觉性，而且为善后阶段编写事故日志提供了宝贵的记录。

即时消息非常适合用来传递带有时间戳且不应更改的信息。对于你希望随着应急工作的进展而调整的内容，请在你喜欢的协作编辑器中创建一个应急文档（Google 文档、Dropbox Paper、Notion 等）：

• 你的组织可以草拟一些包含所需结构的应急文档模板：也许你有报告职责，或者有特定的沟通流程？全都放在这里，这样只需点击一下即可从这些模板创建文档。

• 特别是针对大规模事故的应急工作中，应急团队会有人员轮换，这时候这些文档可以充当人员进入应急团队的切入点。让管理通讯的人员来管理这些文档、维护一份重要事件的时间表，甚至在事故特别复杂时起草一份执行摘要。

• 让你的技术团队将代码段或相关日志行贴到文档附录中，这样每个人都可以对齐同一份应急工作的中心视图。

聊天记录和应急文档结合在一起能成为强大的工具组合，可以帮助协调响应团队，同时为视察工作的投资者提供透明度。还有一点好处是，等到尘埃落定，可以很容易地将这些​​内容重塑成一份善后报告。

第四，注意人为因素

最后，也是最重要的是人为因素。人们在承受压力时会做出错误决定，而沉浸在应急工作中会让你完全忘记照顾自己。在这方面，你应该以身作则，并强硬地要求你的团队成员照顾好自己的身体状况。

这里要考虑的一些事情：

• 减轻压力的一种有效方法是休息，远离屏幕，然后深呼吸。主动带领你的团队和你一起停下来，这样就会减少匆忙之间搞砸事情的潜在风险。

• 一般来说，只要出现以下情况就暂停一下：

• 有人呼你。不必太长；仅仅十秒的呼吸就能提醒你的身体一切尽在掌握，并降低肾上腺素水平。

• 当生产故障停止时。警报平息并且情况看起来稳定后，请让整个团队休息一下。大多数事故都需要很多后续工作：在开始这些流程前，请让自己休息至少 15 分钟。

• 跟踪过程中，在开始执行任何类型的流程之前，例如“X 群集的恢复”。让大家在开始做任务列表前先呼吸些新鲜空气，让每个人都能回点血，避免流程出错或超时。

• 一定要对应急指挥官做好培训，让指挥官及时撤出精疲力尽的响应人员。一项重要的工作是在人们饥肠辘辘之前订好外卖。也许应急响应团队会大声抗议，说他们根本用不着吃饭，可是等外卖上桌了，你就会看到他们狼吞虎咽的样子了。

这份列表缺失的内容还有很多，但你可以把它当作一个入门包，也可以作为经验丰富的人员在制定应急响应流程中关键环节时的一个参考。

只要记住：深吸一口气、关照好同事、批判系统而非人员、不要着急。祝大家好运！

这篇文章中缺少对善后分析、事故发生前的准备工作，以及在安全性、数据完整性、可用性之间如何权衡的内容。如果你有兴趣听取我对这些观点的意见，请在 Twitter 上联系我，我很高兴与你分享。

原文链接：

https://blog.lawrencejones.dev/incident-response/index.html