处理停机时间的紧急响应介绍指南
作者|劳伦斯琼斯
翻译|王强
策划|万佳
本文最初发布于 byrayray.dev 网站，经原作者授权由 InfoQ 中文站翻译并分享。
在我的职业生涯中，我似乎与事故有着不解之缘。可能是缘分吧，也可能是我喜欢看事情怎么发展。也许，罪魁祸首是我？不管是什么原因，这段经历对我帮助很大，让我总结出一套处理事故的方法论。
从那以后，马蒂厄经常鼓励我和更多的人分享这些想法。于是我接受了他的建议，写了这篇文章。
如果你搜索事件响应的概念，你会发现有很多关于事件角色的结果。亚特兰蒂斯有一些优秀的文献很好地解释了这些概念。
简单来说：
随着您的响应团队的成长，应急角色可以帮助扩大应急规模。角色有助于区分责任，并确保应急工作的所有方面都有专门人员参与。定义这些角色可以让每个人都知道自己应该做什么，应该对对方有什么期望。
您必须注意两个角色：
应急指挥官是针对事故采取措施的唯一联系人。他们不需要亲自采取行动，但请在重新启动服务器之前与他们确认。这样就防止了一个好心做坏事的同事说出经典的“哎呀，我不知道你在把数据库还原到这个节点上”。
联系人角色。这个角色不可或缺，也是没有结构化应急流程时最容易被遗忘的角色。当然，你也不要重蹈覆辙，尽快指定专人管理联络事宜，确保所有回答者主动与他们分享联络工作。千万不要让人同时做调试和联络工作，因为这样会分散他们的注意力，两者都乱了！
文献中定义了很多其他角色，但是只有当你的团队对每个角色的含义有了深入的理解，这些角色才能发挥作用。在我看来，指挥官和人脉很重要。没有经过足够的培训就增加粒度，会打乱应急工作，削弱你的应对能力。
如果你对你想使用的角色相当满意，并且你的团队在所有角色上都有很好的实践经验，那么你已经迈出了高效回应的第一步。但是，现在有了各种角色，你的团队应该如何解决问题？
首先，迅速找到出血部位
首先，找出出血的原因。如果你能尽快确定应急响应的范围，就意味着你接下来的措施更有可能解决问题。
尝试：
确定哪些系统出现故障，然后检查依赖关系，以确定问题是由上游组件还是下游组件引起的；
警惕假设。一方面，相信你从第三方那里得到的所有信息，另一方面，一定要核实。记录您的验证工作，例如您运行的命令和运行它们的时间。错误的假设可能会让你的回应脱轨，所以请尽量避免。
找到技术问题的源头后，请考虑做一些影响分析。不要因为这部分工作影响进度，但如果有人愿意，请让他们估计影响范围——。谁会受到影响，有多少人会受到影响。对影响的不正确理解可能导致错误的决策，而对受影响对象的清晰理解可以帮助组织的其他部分(客户成功、客户支持等)。)做出适当的回应。
一旦小组了解了事故的性质，就可以止血了。换句话说，你的目标应该是尽快停止目前的麻烦，把清洁工作推迟到压力较小的时候。
第二，确定行动的优先顺序
为此，我们需要确定行动的优先次序，以便取得尽可能好的结果。请注意“尽可能”这句话：可以快速实施的常规补救措施，即使怀疑只能解决部分问题，也要立即采取。
这些措施包括：
回滚到已确认的版本，即使您
觉得自己很快就能写好修复程序，也可以在回滚后压力较小的情况下再徐徐而图之。采取措施保护关键系统，就算牺牲其他一些不太关键的流程也可以。如果某个端点导致整个系统出现故障，请在这个端点恢复了关键服务后立刻 no-op 掉它。
充分调动团队，并主动应用你认为风险较低的修补程序，就算你怀疑它可能无法解决全部问题也不怕：缩减不必要的队列、冻结部署、重新启动服务器。充分调动人力就可以快速做尝试，前提是其他响应者要继续分析问题的根源，同时假设简单的修补会无济于事。
这样你就应该大致了解自己的团队应该做什么事情了。现在的问题是，他们应该如何协作来执行这些任务呢？
第三，使用高效率工具、创建应急文档
鉴于沟通交流在应急响应工作中的重要性，你需要一款高效率工具来传递即时消息并记录操作日志。
可以使用 Slack（或其他有着相同功能的软件）：
在任何事故中，第一项操作就应该是创建一个消息频道。有很多工具（monzo/response、Netflix 的 Dispatch）可以为你自动创建它（还有很多其他东西），但就算你得自己手动完成这一步，也一定不能跳过它。为了准备好这个通道，多花费一分钟的停机时间也是值得的。
我坚决反对私有应急响应频道。公司内部使用的公共通道可以提升信息访问的便捷性，从而加强你的响应能力。这样可以避免很多会让你头痛的协调（有一次，我见过两支彼此独立的应急团队在处理同一个事故，但他们之间根本不知道对方的存在……）
每当你要执行破坏性操作（例如运行一条命令或重新启动某些资源）时，请向频道发送告知消息。这不仅可以让整个团队提高警觉性，而且为善后阶段编写事故日志提供了宝贵的记录。
即时消息非常适合用来传递带有时间戳且不应更改的信息。对于你希望随着应急工作的进展而调整的内容，请在你喜欢的协作编辑器中创建一个应急文档（Google 文档、Dropbox Paper、Notion 等）：
你的组织可以草拟一些包含所需结构的应急文档模板：也许你有报告职责，或者有特定的沟通流程？全都放在这里，这样只需点击一下即可从这些模板创建文档。
特别是针对大规模事故的应急工作中，应急团队会有人员轮换，这时候这些文档可以充当人员进入应急团队的切入点。让管理通讯的人员来管理这些文档、维护一份重要事件的时间表，甚至在事故特别复杂时起草一份执行摘要。
让你的技术团队将代码段或相关日志行贴到文档附录中，这样每个人都可以对齐同一份应急工作的中心视图。
聊天记录和应急文档结合在一起能成为强大的工具组合，可以帮助协调响应团队，同时为视察工作的投资者提供透明度。还有一点好处是，等到尘埃落定，可以很容易地将这些内容重塑成一份善后报告。
第四，注意人为因素
最后，也是最重要的是人为因素。人们在承受压力时会做出错误决定，而沉浸在应急工作中会让你完全忘记照顾自己。在这方面，你应该以身作则，并强硬地要求你的团队成员照顾好自己的身体状况。
这里要考虑的一些事情：
减轻压力的一种有效方法是休息，远离屏幕，然后深呼吸。主动带领你的团队和你一起停下来，这样就会减少匆忙之间搞砸事情的潜在风险。
一般来说，只要出现以下情况就暂停一下：
有人呼你。不必太长；仅仅十秒的呼吸就能提醒你的身体一切尽在掌握，并降低肾上腺素水平。
当生产故障停止时。警报平息并且情况看起来稳定后，请让整个团队休息一下。大多数事故都需要很多后续工作：在开始这些流程前，请让自己休息至少 15 分钟。
跟踪过程中，在开始执行任何类型的流程之前，例如“X 群集的恢复”。让大家在开始做任务列表前先呼吸些新鲜空气，让每个人都能回点血，避免流程出错或超时。
一定要对应急指挥官做好培训，让指挥官及时撤出精疲力尽的响应人员。一项重要的工作是在人们饥肠辘辘之前订好外卖。也许应急响应团队会大声抗议，说他们根本用不着吃饭，可是等外卖上桌了，你就会看到他们狼吞虎咽的样子了。
这份列表缺失的内容还有很多，但你可以把它当作一个入门包，也可以作为经验丰富的人员在制定应急响应流程中关键环节时的一个参考。
只要记住：深吸一口气、关照好同事、批判系统而非人员、不要着急。祝大家好运！
这篇文章中缺少对善后分析、事故发生前的准备工作，以及在安全性、数据完整性、可用性之间如何权衡的内容。如果你有兴趣听取我对这些观点的意见，请在 Twitter 上联系我，我很高兴与你分享。
https://blog.lawrencejones.dev/incident-response/index.html