Table of Contents

SRE in Crisis

危机中的SRE

膨胀的种族关系导致广泛的骚乱。硅谷的新创业公司。在英国激起强烈的反移民情绪。一种致命的大流行病，来自亚洲。这听起来像今天，但那是1968年。

在德国，一个更年轻、更小的北约组织，当时处于计算机的最前沿，举行了一个很好的声称是历史上第一个软件工程会议的会议。为了与当时的世界状况保持一致，会议宣布了一个危机：随着机器变得更加强大和复杂性的增加，我们编写高质量软件和可靠运行的能力受到了压力。

认识到这一危机的人之一是年轻的计算机科学家Edsger Dijkstra【1】，他写道：”任何大型复杂系统的设计都将是一项非常困难的工作，每当人们遇到负责此类工作的人时，都会发现他们非常关注可靠性问题，这也是正确的。”

他的解决方案是推动编程的一致性、纪律性和严谨性。这导致了现在被认为是基础性的方法——例如结构化编程——尽管和所有的新事物一样，最初被怀疑。为了纪念Dijkstra，我也宣布：SRE【2】正处于危机之中。我们的老方法不能解决这个问题。

让我们面对现实吧，我们在这个行业中所拥有的关于系统的行为或推理的模板，大部分都是依赖于一个没有什么证据支持的知识体系。在《SRE【2】》一书出版4年后，许多业内人士仍在有效地复制和粘贴书中的标准操作程序，这可以理解，但却是错误的。

我环顾四周，发现在我们的职业中没有多少可以视为严谨的东西。 Dijkstra 自己在分布式系统基础上的开创性工作——信号量、互斥锁、自稳定等——也许是我们所拥有的最接近的，但它只适用于我们所做的计算机科学方面。 我们在 SRE 中所做的很多事情都超出了这个背景——也许甚至是大部分——但我们通常有无可置疑的知识和（充其量）经验法则作为这项工作的基础。

一些例子：

  • 为什么辛劳(toil)【3】与项目工作的比例是50:50？这是个正确的数字，而不是20:80，或者确实没有固定的比例，而是一个灵活的方法？
  • 我们是否有办法理解为什么系统级的变化（例如，对服务网格microservice meshes）应该是成功的，除了尝试和观察？
  • 如果SLO【4】是一个如此好的模型，当一个足够糟糕的事件破坏了一整年的错误预算时，我们该怎么办？

在许多方面，1968年的问题就是今天的问题，其中最重要的是复杂性。复杂性会杀死我们。事实上，它今天正在杀死我们，而我们似乎没有任何有效的防御措施——除了一个整体的实践，即SRE所期望的，但往往达不到的。

1968年，剑桥数学实验室的A.G.弗雷泽【5】说。“我只想说，可靠性真的是一个设计问题，在这个意义上，除非你在整个设计过程中意识到对可靠性的需要，否则你可能会放弃” 。SRE的承诺正是如此；我没有看到它被履行。

如果你一定要用怀疑的态度对待它，但也许这也将被视为一个不可避免的认识的开始：我们不知道我们在做什么，也不知道它为什么有效，甚至不知道它是否有效——然而，把它弄好比任何时候都更重要。否则，我们的1968年最终将看起来像1986年。

我们如何构建本书的结构

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.Edsger W. Dijkstra
https://baike.baidu.com/item/艾兹格·迪科斯彻/5029407?fr=aladdin
https://en.wikipedia.org/wiki/Edsger_W._Dijkstra

2.Site Reliability Engineering-中文
   Site Reliability Engineering-english

3.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:

4.Service-Level

5.Alexander G. Fraser