Table of Contents

That 50% Thing

那50%的事情

传统的运维模式是，软件工程师将服务 ”扔到墙外“，交给一个专门的团队，让它们在生产中发挥作用。系统管理员用英雄主义来保持他们的网站正常运行，同时自动消除锯齿状的边缘。救火只是工作的一部分。

网站的可靠性给我们带来了一个新的模式。由于可靠性是第一流的功能，运行生产的团队期望获得与创造运行功能的团队相同的地位和薪水。这方面的一个表现是，SRE【1】花在运维工作上的时间不超过50%。当我在2006年开始担任我的第一个SRE角色时，这意味着每个SRE应该把50%的时间用于编码。

然而，当你在生产中运行服务时，总是有运维工作要做。有些服务已经接近了它的扩展极限。有些服务正在发生神秘的、短暂的故障。有些服务的部署是一个怪物。那些不喜欢编码的SRE，或者那些被解决问题所激励的SRE（一种常见的运维人格类型），很难长时间地忽视中断，来交付有意义的编码项目。

随着时间的推移，“至少50%的代码” 变成了 “最多50%的运维”。而且，说实话，这很好。作为一个行业，我们经常过度强调（并过度检查）代码。将 “50%的代码” 演变为 “50%的深思熟虑的项目工作以使你的服务更好” 是成熟的。当然，这仍然可能意味着编码，但它也可能意味着将现成的解决方案连接起来，增加冗余或编写文档。

超越代码的思考是健康的，但另外的50%呢？随着时间的推移，这个规则已经从 “不超过50%的运维工作” 转变为 “不超过50%的辛劳(toil)【2】”。对我来说，这感觉不太健康。

谷歌的SRE书将辛劳(toil)定义为 “与运行生产服务相关的那种工作，往往是手动的、重复的、可自动化的、战术性的、没有持久价值的，并且随着服务的增长而线性扩展“。 从事性能调整、监控或扩展等运维问题的工程师在改善服务的过程中会提高他们的技能。辛劳是不同的。它在每个星期都没有什么变化，而且你很少能从中学到什么。但如果你不做了，服务就会停止工作。

对我来说，50%的运维工作听起来是个不错的生活选择。50%的辛劳则不然。当我们告诉其他团队，SRE可以花一半的时间做重复性的、可自动化的、战术性的等工作时，我们就低估了SRE的技能。

这里有一个可能有争议的观点：我不认为SRE应该比任何其他工程学科做更多的辛劳。在解决危机的同时救火一段时间是可以的，就像我们可能要求任何软件工程团队冲刺，让我们度过一个艰难的时期。但这不应该是典型的。可靠性专家团队永远不应该成为没有重复人工操作就无法正常工作的系统的创可贴®。减少辛劳需要成为整个工程的目标，而不是一个SRE的热门话题。可靠性和可操作性不能是一个事后的想法。

SRE已经抛出了很多系统管理的英雄文化。我们小心地避免报警疲劳。我们警惕倦怠，但我们仍然过于容忍用辛劳来维持服务。

我们如何构建本书的结构

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

2.toil
Toil is not just “work I don’t like to do.” It’s also not simply equivalent to administrative chores or grungy work. Preferences as to what types of work are satisfying and enjoyable vary from person to person, and some people even enjoy manual, repetitive work. There are also administrative chores that have to get done, but should not be categorized as toil: this is overhead. Overhead is often work not directly tied to running a production service, and includes tasks like team meetings, setting and grading goals,19 snippets,20 and HR paperwork. Grungy work can sometimes have long-term value, and in that case, it’s not toil, either. Cleaning up the entire alerting configuration for your service and removing clutter may be grungy, but it’s not toil.

So what is toil? Toil is the kind of work tied to running a production service that tends to be manual, repetitive, automatable, tactical, devoid of enduring value, and that scales linearly as a service grows. Not every task deemed toil has all these attributes, but the more closely work matches one or more of the following descriptions, the more likely it is to be toil: