97 Things Every SRE Should Know-05
Table of Contents
The Reliability Stack
可靠性堆栈
想想你最喜欢的数字流媒体服务。当你坐在沙发上想看一部电影时，你按了一下遥控器上的按钮。大多数时候，电影会缓冲几秒钟，然后开始播放。
但如果电影需要整整20秒的缓冲时间呢？你可能会在那一刻有点恼火，但最终，电影的其余部分流转得很好。即使有这一点点的故障，这个服务对你来说仍然表现得很可靠，因为大部分时间都不会花费接近20秒的时间。
如果每次都需要20秒的缓冲时间会怎样？现在事情就从一时的烦躁变成了完全不可靠。随着数字媒体流媒体服务层出不穷，你可能会选择放弃这项服务，转而使用其他服务。
没有什么事情是完美的，也没有什么事情可以百分之百的可靠。这不仅是世界的方式，事实证明，人们也完全可以接受这一点! 其实没有人期望计算机系统一直完美地运行，我们只需要它们经常足够可靠。
我们如何找出合适的可靠性水平呢？这就是可靠性堆栈发挥作用的地方。它由三个部分组成。SLI（服务水平指标），SLO（服务水平目标），以及错误预算。
可靠性堆栈的基础是SLI，它是从用户的角度对你的服务进行测量。为什么是用户？因为那是你的系统必须要为其良好运行的对象。你的用户决定了你是否可靠。如果用户的电影每次都需要20秒的缓冲时间，那么没有用户会关心你的终端是否好看。一个SLI的例子可能是，“电影缓冲5秒或更少” 。
其次是SLOs本身。SLOs是由SLI推动的。如果说SLI是关于你的服务如何运行的测量，那么SLO则是你希望它们在多长时间内运行得足够好的目标。使用我们的例子，你现在可能想说：“99%的时间内电影缓冲时间为5秒或更少” 。 如果缓冲时间在100次中只有一次超过5秒，人们可能会接受这个要求。
没有什么事情是永远完美的，所以不要以它为目标。而是要确保你的目标是在足够的时间内可靠。你会花费无限多的资源–包括财力和人力–去追求完美。
最后，在可靠性堆栈的顶端是错误预算，它由SLOs提供信息，是简单的衡量你在一段时间内的目标表现。从用户的角度来了解你在一周、一个月或一个季度的表现，比简单地了解你现在的表现要有用得多。错误预算可以让你说：“我们无法每30天可靠地缓冲7小时、18分钟和17秒” 。你可以使用错误预算来更全面地思考你的服务的可靠性。使用这些数据来进行更好的讨论，并就解决可靠性问题做出更好的决策。
你不可能是完美的，事实证明无论如何没有人期望你是完美的。使用可靠性堆栈来确保你足够可靠。
我们如何构建本书的结构
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系列的文章，有时间我就会翻译一些，希望大家能学到对自己有用的东西。谢谢