Table of Contents

Metrics Are Not SLIs (The Measure Everything Trap)

指标不是 SLI（衡量一切陷阱）

“衡量一切”是一个陷阱。

这是一条随时间流逝而流传下来的建议，没有人确切地记得为什么。这是当不成熟的组织没有有用的工作可以提供给他们时，强加给暑期实习生的项目。我们花了很多时间来扩充那些假设情况下的代码，最终导致metrics搜索空间充斥着无用的数据点。不要测量一切。

在内存非常昂贵的时候，您必须对要存储的指标非常挑剔。你必须专注于最重要的服务。随着内存成本的降低，存储越来越多的参数变得越来越便宜——这是在(遥远的)未来某一天提供价值的正当理由。对我们大多数人来说，未来的日子从未到来。

那么问题来了，“什么是值得衡量的？” 专注于能够建立高质量SLI[1]的指标。首先，让我们描述一下指标(metrics)和SLI之间的区别。指标是原始数字：队列中有多少个项目，自上次失败以来有多少天，购物车中有多少个项目。SLI是指标的组合，它讲述了一个故事：如果队列以目前的速度不断填充，那么在系统性能开始下降或完全崩溃之前还剩多少时间？指标(metrics)提供了系统简单有效的证据。SLI提供了服务如何运作的证据，以及它将在多长时间内继续运作良好。这就是用户体验的故事，这也是你应该关注的内容。

用户体验影响的不仅仅是付费用户，还有更多。每一个使用你的服务的团队成员或on-call[2]的工作人员也将是一个客户。当你想出要提供哪些指标时，请考虑凌晨2点的因素。当半夜被吵醒时，这个指标是否能帮助我或他们更快地恢复服务？这个指标会对告警有用吗？这个指标能准确地衡量服务的健康状况吗？如果答案是否定的，请重新考虑你对这个指标的投资。

这项工作看似吃力不讨好，但却是至关重要的；在许多组织中，大多数指标永远不会被查看或阅读。2019年Twitter的一份文件指出，只有不到97%的指标被阅读过一次。在Twitter的情况下，那些将不会被阅读的指数是PB级别的。如果没有令人难以置信的复杂工具，浏览指标搜索空间并不容易，而许多SRE和工程团队都没有这样的工具。

做出不衡量某些东西的决定有时是令人生畏的，而且可能看起来不像是一个值得讨论的问题。但你应该怎么做？专注于你的客户的需求，衡量将改善他们的体验的SLI。这将使你的产品成熟，并防止你落入测量一切的陷阱。你的工程师也会感谢你没有一个嘈杂的告警机(pager)。

我们如何构建本书的结构

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.on-call