Table of Contents

Holistic Approach to Product Reliability

对产品可靠性的整体处理方法

你已经成功了。

通过冗余，你消除了所有单点故障。服务得到了适当的监控，并配置了告警。你的恢复策略被定期测试，以确保你的on-call【1】团队能在一瞬间做出反应。你已经仔细研究了你的要求，并宣布了可实现的SLO。

工作做得很好! 或者是这样吗？为了确保产品成功，您必须采取端到端的整体方法，从用户交互到磁盘上的字节。典型的前端-后端划分不再那么简单了。这里有层层叠叠的抽象概念。你的网络服务是你的客户的前端；它向你的处理后端发送请求，后端实际上只是其他服务的前端，如缓存和存储服务器。一路上都是海龟(Turtles all the way down)。

而我们只是在上面堆放了更多的乌龟：客户端应用程序。它们有各种形状和大小，从渐进式Web应用程序到在智能设备上原生运行的应用程序。这些应用程序也有其后端：共享库、数据库和本地存储。可靠的客户端现在比以往任何时候都更重要，因为目前全球使用的智能设备超过35亿台。

SRE【2】最常看的指标是RPC（远程过程调用）的成功率和失败率。但是，如果你的客户端在用户设备上出现崩溃循环怎么办？你的成功率实际上可能会上升，但如果你的应用程序无法使用，这就是冷酷的安慰。

下面是另一个例子。对于一个有一百万QPM（每分钟查询次数）的服务，一个合理的 99% SLO 可以通过每分钟 10,000 个用户遇到单个错误或一个确定的用户每分钟重试 10,000 次并获得 10,000 个错误来耗尽其错误预算； 比例是一样的，但体验却大不相同。

那么你应该衡量什么呢？看看你的用户与产品互动的能力：关键的用户互动（例如，打开一个信息，然后删除它）。这些互动告诉你，你的用户是否能使用你的产品。此外，别忘了按不同平台和版本上受影响的用户数量来划分你的数据，以确保没有任何一组设备长时间受到某种故障模式的不成比例的影响。

时代变了；现在的互联网比以往任何时候都更加多样化，大部分流量不再来自PC。在IoT（物联网）设备之上有大量的移动操作系统，我们不能假装客户端不是我们的责任。

采取整体的方法将有助于减少MTTR（平均修复时间）。几分钟的停机时间可能会被你的用户所忽视（只是一个小故障），但几个小时就会导致用户信任的丧失，不良的媒体报道，以及潜在的收入损失。将紧急支持扩展到客户端将导致更短的响应时间，并在面临故障时引起用户的信任。从用户开始，找到解决问题的方法。你以后会感谢自己的。

我们如何构建本书的结构

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.on-call
2.Site Reliability Engineering-中文
   Site Reliability Engineering-english