Table of Contents

Mitigating and Preventing Cascading Failures

缓解和防止连带故障的发生

想象一下，一摞多米诺骨牌倒下了，每一块都会推倒下一块，直到每一块多米诺骨牌都倒下。当一个理论上松散耦合的系统实际上有我们不知道的紧密连接时，就会发生级联故障。在生产系统中，当一个过载的区域发生故障时，它的流量会转移到健康的邻近区域，而这些区域也会变得过载并反过来发生故障。如果不加以控制，级联故障会迅速发展，在几分钟内导致系统的全面瘫痪。这类故障一直是GCP（谷歌云平台）等服务大规模公开停运的罪魁祸首，甚至是电网。

有多种方法可以触发级联故障。 突然的流量高峰会使系统中的某个组件过载。 尽管总体流量没有增加，但看似无害的代码或配置更改会导致性能下降，从而降低容量，这可能是一个原因。

当发生级联故障时，会同时出现许多过载症状，因此很难在蔓延到全球中断之前及时进行调试和缓解。 第一个目标应该是打破链条。 前线（Front-line）缓解措施可能会有所不同，但这里有一些适用于大多数情况的核心缓解措施。

对于由变更引起的初始区域过载，识别并回滚此更改可以使查询成本恢复正常。 限制已经受影响的区域以减少负载可以帮助它们恢复并防止它们变得完全不可用。

前线缓解程序应有详细记录、定期测试和快速部署。 即使专家团队已经准备好缓解措施，也很难完全缓解级联故障，而不会对用户产生任何严重影响。

一个更有效的策略是通过改进系统设计进行预防。在发布的金丝雀阶段进行性能和回归测试【1】，可以在全局部署可能导致容量不足之前，抓住性能回归，如内存泄漏。

更好的负载节流可以通过在任务达到其容量时拒绝或降低响应，从而使区域更能抵抗过载。对一个区域进行负载测试，以确定在负载平衡器层面上的理想利用率，这样单个任务就不会过载。配置一个合理的任务级的负载平衡算法（如加权轮回），以保持任务尽可能的平等负载。

区域之间更强的隔离可以确保区域性故障不会蔓延到全球。在这种设置中，每个区域的冗余必须单独维护，因为相邻的区域不再能够补偿彼此的容量。这种方法可能是昂贵的，但提供了最有力的隔离保证。

在系统之外，还有对人的伤害。想象一下，星期五下午，每个人都准备为这一周收拾东西。值班工程师的告警机响了。她叹了口气，拿出她的笔记本电脑看了一下。很快，整个团队都在争先恐后地应用缓解措施，因为错误率急剧上升。回滚和上限正在以快速和不安全的方式进行部署，同时，标志着全局过载的告警机风暴响起。来自客户支持部的通知源源不断地涌来。(Tickets from customer support are flooding in.)。很快，总监和副总就打电话来，要求知道缓解措施的时间。

不幸的是，这就是发生级联故障时的典型情况。即使应用了多种缓解措施，也可能需要数十分钟才能完全停止过载。除了面临风险的系统之外，还有处于压力下试图处理这种情况的人。即使系统恢复了，对人的影响也可能存在。这就是为什么预防胜于治疗；避免影响客户的故障的唯一方法是建立一个能抵御级联故障的系统。

我们如何构建本书的结构

SRE虽然涉及复杂的技术系统，但归根结底是一种文化实践。文化是人的产物，这启发我们根据你在组织中的SRE数量来组织本书的各个部分–你具体处理什么，你的一天是怎样的，取决于有多少个SRE工程师。我们将本书的文章分为 “SRE新手” 、0-1个SRE、1-10个SRE、10-100个SRE和 “SRE的未来 ”。

读者如果想找寻先从哪里开始的指导，可以直接跳到最适用于自己的部分；但是，你仍然会发现阅读那些目前并不适用于你日常的部分的文章的价值。

在0到1个SRE时，还没有人被指定为SRE，或者你已经找到了你的第一个SRE，这个角色看起来几乎是孤独的。

在1到10名SRE时，你正在组建一个团队，有知识共享和分工的能力。

在10到100个SRE时，你已经成为一个组织，你需要思考的不仅仅是你所从事的系统，还需要思考如何组织这么多SRE。

“SRE新手” 涵盖了基础性的话题（尽管并不详尽！），对于那些刚刚开始SRE之旅的人来说是很有帮助的，即使是最有经验的SRE，也是一种复习。 “SRE的未来” 包含了一些文章，这些文章探讨了SRE潜在的发展方向，或者是（目前）坐拥时代潮流。

没有必要按照任何特定的顺序阅读本书。你可以从头到尾读一遍。或者，如果你对某个特定的主题感到好奇，可以翻到索引，在那里你可以找到关于该主题的所有文章。把它作为参考指南，或者是灵感的来源–可以在需要的时候提供一个震撼。或者，也许可以建立一个阅读俱乐部，每周一次挑选一篇文章与同事讨论。这就是散文集的魅力所在。我们希望你和我们一样喜欢阅读它们。

结语

SRE系列的文章，有时间我就会翻译一些，希望大家能学到对自己有用的东西。谢谢

翻译不易，转载时请注明原文链接，谢谢

延伸阅读

1.回归测试
回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。自动回归测试将大幅降低系统测试、维护升级等阶段的成本。

回归测试作为软件生命周期的一个组成部分，在整个软件测试过程中占有很大的工作量比重，软件开发的各个阶段都会进行多次回归测试。在渐进和快速迭代开发中，新版本的连续发布使回归测试进行的更加频繁，而在极端编程方法中，更是要求每天都进行若干次回归测试。因此，通过选择正确的回归测试策略来改进回归测试的效率和有效性是很有意义的。