宕机报告，宕机后首先要解决的问题是

本文最初发布于byrayray.dev 网站，经原作者许可，由InfoQ 中文站翻译并分享。在我的职业生涯中，事故与我之间似乎有着“牢不可破的联系”。也许这是命运，也许我只是喜欢看到事情出错。也许罪魁祸首就是我？不管出于什么原因，这段经历帮助我形成了处理事故的方法。

从那时起，马修就鼓励我与更多人分享这些想法。于是我接受了他的建议，写了这篇文章。如果您搜索事件响应概念，您将看到出现许多有关事件角色的结果。 Atlassian 有一些很棒的文档，非常清楚地解释了这些概念。简而言之：

随着响应团队的壮大，紧急角色有助于扩大响应规模。角色有助于区分职责并确保紧急响应的各个方面都有人员配备。定义这些角色可以让每个人都知道他们应该做什么以及彼此之间的期望是什么。您应该关注两个角色。其中之一是应急响应指挥官，他是针对事件采取行动的单一联系人。他们不需要在现场采取行动，但在重新启动服务器之前请与他们核实。这避免了一位好心的同事发出的经典的“哎呀，我不知道你正在将数据库恢复到这个节点”。联络。尽管这一作用至关重要，但在缺乏结构化应急响应流程的情况下，它是最容易被遗忘的一个作用。您不能再犯同样的错误，但应尽早指定专人管理沟通，并确保所有响应者积极分担沟通负担。永远不要要求人们同时进行调试和沟通。这会分散你的注意力并毁掉你的两项任务。文献中还有许多其他角色定义，但只有当团队充分理解每个角色的含义时，这些定义才有用。我认为指挥官和联络员很重要。 —— 在没有适当培训的情况下增加粒度会扰乱应急响应工作并削弱响应能力。如果您对要使用的角色有一定的了解，并且您的团队在所有角色上都有良好的实践，那么您已经迈出了有效响应的第一步。但面对如此多不同的角色，您的团队如何解决问题？

首先，快速找到出血部位，首先检查出血部位（什么是出血？）。您越早确定紧急响应的范围，就越有可能在后续步骤中解决问题。尝试：

确定哪个系统出现故障并检查各个依赖关系以确定问题是由上游组件还是下游组件引起的。小心你的假设。与我们从第三方获得的所有信息一样，请相信该信息，但始终要对其进行验证。请务必记录您执行的任何验证任务，包括运行命令的时间。错误的假设可能会破坏你的反应，所以要尽力避免它们。一旦找到技术问题的原因，请考虑执行影响分析。不要让这部分工作影响你的进度。但是，如果有人愿意，请他们估计谁会受到影响以及有多少人会受到影响。误解的影响可能会导致错误的决策，但清楚了解受影响的人可以帮助组织的其他部分（客户成功、客户支持等）做出适当的反应。很有帮助。一旦团队了解了事件的性质，他们就可以开始止血。换句话说，你的目标应该是尽快解决当前的问题，并将清理工作推迟到压力较小的时间。

其次，确定您的行动的优先顺序为此，您需要确定您的行动的优先顺序，以实现最佳的结果。请注意“尽可能”这句话。应立即采取例行纠正措施，即使这些措施看起来只能解决部分问题。这些措施包括：

回滚到已知良好的版本。即使您认为可以立即创建修复程序，当回滚后压力消失时，您也可以慢慢地完成它。采取措施保护关键系统，即使以牺牲其他不太关键的流程为代价。如果端点导致系统范围的故障，请在端点恢复关键服务后立即执行无操作。即使您认为自己无法解决所有问题，也可以动员您的团队并主动应用您认为风险较低的修复措施。例如，缩小不必要的队列、冻结部署或重新启动服务器。当其他响应人员继续分析问题的根本原因并认为简单的修复不会有帮助时，动员的工作人员可以快速接受测试。这应该能让您的团队大致了解该做什么。现在的问题是：我们应该如何共同努力完成这些任务？

第三，使用高效的工具创建应急文档沟通是应急响应操作的关键，因此您需要高效的工具来传递即时消息并记录操作日志。您可以使用Slack（或具有相同功能的其他软件）。

任何事件中的第一个操作都是创建消息传递通道。有许多工具（monzo/response、Netflix 的Dispatch）可以自动创建此步骤（等等），但即使您需要自己执行此步骤，也不要跳过它。为了让这个通道做好准备，多花一分钟的停机时间是值得的。我坚决反对私人应急渠道。内部使用的公共渠道可以使信息更容易访问并提高响应能力。每当您执行发送破坏性通知消息时，这都会节省很多协调麻烦（有一次我亲眼目睹了两个独立的应急响应团队在处理同一事件），他们不知道彼此的存在.）。执行操作（例如运行命令或重新启动资源）时发送到通道。这不仅使整个团队保持警惕，而且还为事后整理事件日志提供了宝贵的记录。即时消息传递非常适合传递不应更改的带有时间戳的信息。对于您想要在紧急工作进展时调整的内容，请在您最喜欢的协作编辑器（Google Docs、Dropbox Paper、Notion 等）中创建紧急文档。

您的组织可以起草多个包含所需结构的紧急文档模板。也许您有报告职责或特定的沟通流程？一切都在这里，因此您只需从这些模板中单击即可创建文档。特别是在大规模事故等应急行动中，救护人员进行轮换，这些证件成为加入救护队伍的切入点。让管理沟通的人员管理这些文档，管理关键事件的时间表，如果事件特别复杂，甚至可以起草一份摘要。让您的技术团队在文档的附录中发布代码片段或相关日志行，以便每个人都能就紧急响应的相同中心视图达成一致。聊天日志和紧急文件一起成为强大的工具集，帮助协调响应团队，同时为投资者调查工作提供透明度。另一个好处是，一旦问题解决，您可以轻松地将其重新调整为事后分析报告。

第四，注重人的因素最后，也是最重要的，人的因素。人们在承受压力时会做出错误的决定，当他们忙于紧急任务时，他们可能会完全忘记照顾自己。对此，你需要以身作则，督促你的团队成员照顾好自己。这里有一些要考虑的事情：

减轻压力的一种有效方法是休息、远离屏幕并深呼吸。建议您的团队一起暂停可以减少匆忙和失败的潜在风险。一般来说，每当有人打电话给你时，都要暂停。不需要很长。只需10 秒的呼吸就可以提醒您的身体一切都在掌控之中，并降低您的肾上腺素水平。如果停止生产。一旦警报停止响起并且情况稳定下来，就让整个团队休息一下。大多数事故都需要大量的后续工作。在开始这些过程之前，请休息至少15 分钟。在跟踪期间，在启动任何进程（例如“恢复X 集群”）之前。在开始执行任务列表之前，让每个人呼吸新鲜空气，以便每个人都可以恢复并避免流程错误和超时。应急指挥员必须接受培训，以快速疏散精疲力竭的救援人员。这项工作的一个关键部分是在人们饥饿之前订购外卖。紧急响应小组可能会大声抗议他们不需要吃饭，但很可能会看到他们在吃外卖食品时大嚼特嚼。尽管此列表缺少很多内容，但它可以用作入门工具包或作为经验丰富的人员在制定应急响应流程的重要方面时的参考。请记住。深吸一口气，照顾好你的同事，批评制度，而不是人，不要着急。请大家努力吧！本文缺乏有关如何权衡事后分析、事件前准备、安全性、数据完整性和可用性之间的信息。如果您想听听我对这些观点的看法，请在Twitter 上与我联系。我很乐意与您分享。原文链接：https://blog.lawrencejones.dev/incident-response/index.html 详情：

QUIC 加入IETF 征求最终意见。这对于互联网来说是一个巨大的进步- 在InfoQ 上关注我并转发这篇文章以获取学**材料。如果您想了解更多，还可以访问InfoQ官网获取最新信息。来自InfoQ~