通用缓解措施

问候，互联网上文​​章的读者！您是否正在使用您（以及可能是您的用户）想要继续工作的服务？好吧，如果是这样，我在这里是要说服您，您的服务应至少准备好一两个通用缓解措施。如果不是这样，那您将陷入困境。如果这样，请珍惜它们，加以维护并使用，以免它们在您的脚下腐烂。

好的从顶部开始：缓解是您可能会采取的减少断裂影响的任何措施，通常是在生产中。修补程序是一种缓解措施。 SSH进入实例并清除缓存是一种缓解措施。将次要电池用管道输送给劣质笔记本电脑也很重要。我想，切断数据中心的电源以消除漏洞是一种缓解措施，就像断头台治愈普通感冒一样。

因此，通用缓解措施可用于缓解各种中断。

例如，二进制回滚可能是最常见的通用缓解措施。许多多宿主服务都将有一个紧急耗用流量中断的副本按钮，对于基于查询的服务，这是一个很好的通用缓解方法。其他人可能有单独的数据回滚，或者是一种快速添加一大堆额外容量的工具。

通用缓解措施的最重要特征是：您无需完全了解中断就可以使用它。

好的，让我对此进行扩展：您希望了解缓解后的中断。让我们快速了解一下典型的停机情况。

建立良好的通用缓解措施的目的是要准备在时间轴上尽早使用武器。如果唯一可用的缓解措施是特定于问题的，那么您将无法帮助您的用户，除非您详细了解该问题。减少理解问题所花费的时间非常困难。如果我们可以轻松地发现问题，那么我们很可能根本不会造成问题。

因此，我们假设团队事件管理成功与否的衡量标准不是“修复时间”，而是“缓解时间”，而我们要最小化的事情是用户的总花费时间。建立具有广泛应用的缓解措施要比使根源更快变得容易得多。

那是一句废话。让我们再试一次。一个好的通用的，发生故障的快速修复按钮很容易（而且安全！）在紧急情况下使用。可靠的通用缓解工具需要事先进行大量工作才能创建，并且需要针对要缓解的服务进行精心定制。

但是，我们可以从中学习一些非常好的通用缓解模式，尽管这些模式需要仔细调整才能使其适合您的特定服务。

回滚这会将您的服务（最常见的是二进制文件）还原到已知良好的状态。几乎每个服务都可以实现此策略的一个版本。太多的人认为他们有安全的回滚，只是在停电期间学习其他方法。

数据回滚这是前一个的子情况，它仅还原您的数据。内容密集型服务更可能发现此功能有用，尤其是那些通过管道构建数据的服务。

降级您的服务过载了吗？有一种方法可以减少工作量但又可以保持正常工作，这是对崩溃的巨大改进。在系统刻录过程中尝试创建新的降级机制总是会伤您。

大型流量过多？还是一切都没有理由热起来？添加更多副本。它很昂贵，但是比因中断而惹怒用户便宜。注意，这很少像“按比例放大一个二进制文件”那样简单。系统扩展很复杂。

阻止列表是否有死亡查询？单个垃圾邮件用户正在删除区域？阻止他们。

排水将您的交通移至其他地方。如果您是多宿主和交通拥堵者，那么此方法非常有用：如果一个地区出现高错误，请将请求移到其他地方。

隔离解决“坏实例”问题的一种好方法是强制执行隔离。隔离给定的使用单位（热数据库行，垃圾用户，有毒流量），因此无论遇到什么错误，它都不会破坏其他漏洞。

是的，如果因为最近的版本触发了错误而耗尽了一个实例，您看起来会很傻，直到下一个实例升级30分钟后才看到相同的错误。这些都不是魔术：您需要进行诊断才能了解您要处理的故障情况。

这些模式也并非对所有服务都同样有用。例如，对于许多本地化产品，将用户固定在单个物理区域上，浪费资源是无稽之谈。当工作负载不可分割或已经完全隔离时，隔离是没有用的。降级模式并非总是一种选择。

因此，问问自己哪些策略对您的服务有意义。在您的生产准备情况审查中，包括减少现有的通用缓解措施，并计划在不足的情况下增加更多。 （但不要太多！质量胜于数量！）缓解措施越规范，越标准化，支持扩展就越容易；如果缓解措施持续到早上，则无需在凌晨2点呼叫专家醒来。

即使在熟练的呼叫者手中，陌生的工具也是危险的。无论您选择什么，都要进行钻探，添加自动化测试，编写新的清单以确保新团队成员必须完成才能获得生产证书，从而确保您的团队已经触及了缓解措施。毕竟：磁带备份从来没有人尝试过进行还原，这可能不是花哨的纸镇，因为所有帮助都是他们第一次在产品中运行rm -r / *。

还有第二个好处：通过定期执行缓解措施，可以验证其行为。我们的系统非常复杂，以至于您不了解实际使用通用缓解措施所产生的连锁反应。

目标是为您的服务创建简单，安全，无摩擦的紧急按钮，使任何通话时都感到舒适，而丝毫怀疑它们可能会有所帮助。搭建起来并不容易。但是，相比于忍受长时间无休止的停机，提前构建它们要便宜得多。

简而言之：中断中最昂贵的部分是用户可以看到的时间。对于用户来说，快速进入“大部分工作状态”的途径比等待“完全解决”问题要好得多。如果您驾驶的是雄伟的旧丰田卡罗拉，有时最好的策略是确保手套箱中有胶带，以便在后视镜掉落时可以将它贴在机修工身上。

这篇文章是O’Reilly和Google之间的合作。请参阅我们关于编辑独立性的声明。