SRE 故障应急的万金油：通用缓解措施

【SRE 漫画】漫画中，值班的 Macey 用滑稽的大剪刀剪断数据中心机架的电缆，同时竖起大拇指。

通用缓解措施是指：“那些在缓解各种故障中都很有用的措施。”

例如，二进制回滚可能是最常见的通用缓解措施。大部分多宿主服务都可能会有一个紧急处置按钮(预案)，用于将流量从故障副本中摘除，这是基于查询服务的一个很好的通用缓解措施。其他类型的应用还可能会有单独的数据回滚工具，或快速增加大量额外容量的扩容工具。

通用缓解措施最重要的特征是：你不需要完全了解故障就可以使用它。

答案是，不可以。

好吧，让我在详细解释清楚：你应该在故障被缓解了以后，再去开展故障排查工作，并详细理解它。让我们先画一个典型的故障处理决策简图。

【SRE 漫画】漫画中，时间轴图示了两种不同的处理故障的方法。时间轴开始相同，从“问题产生”到“损害开始”(此时出现红色的“用户受影响”状态条)到“值班人员接到通知”，但在决策点上分叉：如果选择“应用通用缓解措施”，用户影响被停止，时间轴继续到“调查”、“最终修复”和“应用修复”。如果不选择缓解，用户影响将持续——通过“调查”、“找到完美修复”，最后在“应用修复”时停止。时间轴上线上火山爆发已经淹没了整个小岛;显然，在“早期缓解”时间轴中，岛民要快乐得多，而如果选择先调查，小岛最终被火山灰烬覆盖，居民很受伤。

通用缓解措施的核心目标是：对未来可能的故障尽早准备好有效的止血手段。如果你所使用的缓解措施仅能适用于某种特定的问题，那么在全面了解故障之前，这些特定的措施可能就会无法帮助你迅速恢复用户服务。实际上，想要缩短理解故障问题的时间是非常困难的；毕竟，如果问题原因都很易于发现，那么我们可能在一开始就不会遇到这些问题了。

因此，如果我们将团队事故管理的成功标准从“修复时间”转变为“缓解时间”，那么我们就应着眼于：最小化用户服务从受影响到完全崩溃的时间。相比加快根本原因分析的速度而言，开发一些能广泛适用的通用缓解措施，是更加有用且可行的做法。

【SRE 漫画】漫画，中的 Macey 高举一把标有“不要太纠缠问题!”的剑。她站在一团纠缠如乱麻的电缆上。

实际上，虽然叫做通用缓解措施，但这些措施其实也非常具体。

这句话听起来有点儿矛盾。再解释一下，在紧急情况下，一个好的、通用的“快速修复”方案的使用应该是简单且安全的;优秀可靠的通用缓解工具都需要在事前做大量工作，并需要经过仔细的调整以适应所对应的服务。

下面有一些非常好的通用缓解模式，值得大家一起学习，虽然这些都需要仔细的调整，以适配具体的服务。

● 回滚: 将你的服务恢复到已知的良好状态(版本)，通常是恢复二进制文件，但也有其他选项。几乎每个服务都可以实现这个策略的某种状态。很多服务都以为自己有安全的回滚措施，但在故障期间才发现，往往并非如此。

● 数据回滚：这是上一种情况的一个分支——它只恢复你应用的数据。内容密集型服务特别需要这个，尤其是那些依赖数据管道(数据后台)的服务。

● 降级：你的服务过载了吗?能降低负载并保持运行，就总比崩溃好得多。在系统崩溃的过程中，在去尝试创建新的降级机制总是让人相当抓狂。

● 扩展/扩容：流量太大了么?或者所有东西都在无缘无故地超载运行?那就要迅速的增加更多应用副本。这虽然比较昂贵，但总比因为故障而惹恼用户要更具性价比。注意，这通常不像“扩容一个二进制文件”那么简单；系统扩容会更复杂一些。

● 屏蔽：遭遇致命查询了么?一个垃圾用户就导致一个可用区瘫痪?火速屏蔽他们。

● 引流/切流：将你的流量转移到其他地方。如果你是多宿主和流量驱动的服务，这个方法效果很好：如果一个区域看到高错误率，将请求转移到其他地方。

● 隔离：一个好方法是隔离“发生问题的实例”。将一个使用单元隔离开来，可能的情况是：一个热点数据库行、一个垃圾用户、一个有问题的流量；这样不管它们碰到任何问题，都不会影响到其他的部分，或者不会影响到其他的用户。

【SRE 漫画】 Macey，看起来在深思，头上有“嗯”的字样，思考四个可能的缓解选项。顺时针从左上角开始，泡泡中有：Macey 将一个小鱼缸倒入一个大鱼缸；Macey 将一块巨石推上山；一个写着“NOPE!”的大红色停止标志；呼叫飞驰的救护车。

【SRE 漫画】一个数据中心的服务器机架看起来很痛苦，它着火了，前面贴了一块创可贴。显然这个解决方案不足以解决问题。

这些模式对所有服务的用处也不尽相同。例如，对于很多固定在单一物理区域的本地化产品来说，摘除实例流量是没有意义的。当你的工作负载无法分离，或已经处于完全隔离时，那么隔离也没有用。降级模式并不总是可行的。

所以问问自己：哪些策略对你的服务有意义。把它作为生产就绪评审的一部分——记录有效的通用缓解措施，如果还不够，就要计划添加更多。（但也不用太多！质量胜过数量！）缓解措施越优良、越标准化，能支持扩展场景就越容易；如果你用缓解措施就能撑到早上上班；那么，你就不需要在凌晨 2 点叫醒技术专家。

另外，如果你不去使用它们，它们就不会发挥作用。

即使是熟练的值班人员，使用不熟悉的工具也是危险的。无论你选择哪种方法。都要进行演练、添加自动化测试、编写新团队成员必须完成的入职清单，以获得生产运维准入——确保你的团队接触过相关缓解措施。毕竟，如果没人练习过恢复磁带备份，当有人在生产环境中运行 rm -r /* 时，那些磁带就只能是高级的纸镇了。

【SRE 漫画】四个磁带备份堆叠在凌乱的桌子上的文件上，标签分别是“古老备份 #1”到“2020 年备份”。附近的一张便签写着“恢复你的备份!”

通过定期演练你的缓解措施，你还可以验证它们的行为。我们的系统足够复杂，只有在真正使用你的通用缓解措施时，我们才能知道它们的连锁效应。

目标是为你的服务创建易于使用、安全、无摩擦的紧急按钮(应急预案)，让任何值班人员都可以在稍有怀疑时，就都能够安心的使用。想要实现并不容易，需要付出一定代价。但提前开始构建它们，就要比在没有缓解措施的情况下，忍受长时间的服务停机要好得多。

简而言之：在故障中，用户有感知的时段是最有风险的阶段。一个快速到达“基本正常可用”的路径，要比等待“完全修复”，对用户来说要好得多。如果你开的是一辆破旧的汽车，有时最好的策略是确保手套箱里有黑胶带，这样当后视镜掉下来时，你还是可以开到修理厂。

请准备好你的黑胶带。你会需要它的。