Table of Contents

The Performance Emergency Fund

性能应急基金

SRE 【1】依靠错误预算等概念来管理整个组织的变更，这是否意味着确定发布是否可以向前推进或确定在哪里进行改进。 错误预算与可用性有关，但当然，你需要知道的不仅仅是你是否可用，还包括可用性的质量。

如果你不考虑质量问题，那么你就只能得到部分情况——但我们如何定义质量？我认为，最重要的方式之一是通过性能。当它似乎要花很长时间才能加载时，你有什么感觉？或者你的智能手机上的性能比你的笔记本电脑上的慢？

一个组织中的每个人都应该关心性能问题。如果一个网站的加载速度太慢或不一致，你就会有失去客户和失去销售的风险。没有人希望这样。

  许多研究表明，更快的加载页面会带来更高的收入，增加用户参与度，并降低跳出率。加载缓慢的页面也可能是问题的早期指示器。由于缓慢而发现问题比等待失败要好。

就像你可以创建一个错误预算一样，你也可以为性能做同样的事情。性能预算是对用于指导设计和开发的性能指标的一个明确的限制。你可以为不同的指标制定多个预算。这里有一些我认为特别有价值的：

• 总页面权重
• 最大文件大小
• 响应时间阈值
• HTTP请求的数量

类似于把组织的不同部分聚集在一起考虑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.Site Reliability Engineering-中文
   Site Reliability Engineering-english