Table of Contents

When SLOs Attack: Pathological SLOs and How to Fix Them

当SLO攻击时：病态的SLO以及如何修复它们

SLO【1】是一个非常直观的概念：一个描述预期服务行为的量化契约。这些经常被用来建立反馈回路【2】，以确定可靠性的优先级，在接受新的依赖时传达预期行为，并在问题发生时同步各团队的优先级，以及其他用例。

然而，SLO是建立在一个隐式的服务行为模型上的，其中有许多并不普遍成立的简化假设——如请求的独立性、错误的均匀分布和所有请求的平等。这些假设使SLO的经验法则在现实世界的服务中失效了。了解这些假设在哪里以及如何崩溃是至关重要的：因为在某些情况下，SLO会不经意地将我们引向错误的方向。

考虑错误预算：在一个时间间隔内失败的数量或百分比。这些错误可能在短时间内发生，也可能在很长一段时间内以低比率发生。它们可以分布在所有的用户中，也可以集中在少数人身上。单个用户的错误率可能很低或100%。所有这些因素都会影响人们对故障的看法，以及它们对用户的影响。

此外，如何最好地处理灾难？许多服务提供商试图将坏日子纳入SLO的承诺；然而，有些坏日子是非常非常坏的日子。这就导致了一种在晴天和雨天都能服务的妥协。两者都没有很好的描述。

当事情进展得非常糟糕，并且消耗了多个错误预算期时，然后呢？尽管冻结服务多年的前景可能很有吸引力，但它很少符合用户或服务提供商的最佳利益。

同样，由于错误预算经常包含尾部风险，它们代表了P99+的坏经验。因此，积极地花费错误预算是向客户提供持续糟糕体验的好方法。

SLO和客户想要的平均体验之间的不匹配也会导致服务提供商和他们的客户之间的分歧。客户倾向于期待他们昨天得到的体验，即使那是在整个服务基础上的一个积极的异常值，而这种行为的改变往往会导致他们的架构出现问题。

在一天结束时，SLO是关于量化交付的服务，设置适当的期望，并在事情不顺利时改变策略。所有这些活动对于提供值得信赖的服务都是至关重要的。那么，我们能做些什么来解决SLO的问题呢？

有了这些准则，我们不仅可以有不那么病态的SLO，而且还可以得到一系列的指标，我们可以用这些指标来有针对性地改进我们的服务。有了这些，我们就能以充分量化的行为提供可靠的服务。

我们如何构建本书的结构

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.Service-Level
2.feedback loops
3.Tail risk
通俗的说，尾部风险（Tail Risk）指的就是罕见事件（Rare Event）发生的风险，黑天鹅事件就是一种尾部风险事件。这里的罕见事件指的是负面的、不好的事件，中奖五千万之类的事件虽然也罕见，但不是坏事，所以不能算作尾部风险事件。