Table of Contents

To All the SREs I’ve Loved

献给所有我爱过的SRE们

我们都遇到过一个可靠性有问题的应用程序。 当应用程序不可避免地经历第一次中断时，它会让我们的生活变得更加艰难，我们被要求帮助提高应用程序的可靠性。 我们对此并不感到惊讶，但希望我们能够参与应用程序的设计和规划，并使可靠性成为一等公民。 这是完全可以避免的——而且它会让我们筋疲力尽。

我不是一个SRE【1】–嗯，现在不是了。我回到了我最初的激情，安全，被吸引到加强系统的安全性，保护我们用户的数据，并将坏人拒之门外。从转换团队的角度来看，我得到了一个启示：安全对于SRE来说就像SRE对于产品团队一样。我们在这里支持你，使你的系统安全，运行，并最终保持可靠。在某种程度上，我们就是你的SRE团队。然而，你却经常用单一的产品团队对待你的方式来对待我们。

我已经听到了这些抱怨。你觉得我们因为偏执，总是想着最坏的情况而拖累了你。更糟糕的是，我们甚至没有好的数据来说服你这是值得的。这不像我们可以说，“你需要更新这个库，否则服务器会被黑掉”。

为下一个 DDoS（分布式拒绝服务）或闪购扩展服务器是非常切实可行的。 查看单个实例可以处理多少连接，查看上次尝试连接的人数，然后您就可以扩展。 作为一名安全工程师，我无法指出您需要修复的那个 CVE（常见漏洞和暴露）部分。 只要您没有遭到破坏，就无法判断您是否安全。 没有办法证明一个系统是安全的。

这是一份吃力不讨好的工作；安全团队没有被认为像SRE团队那样给公司带来同样的价值，主要是因为我们的工作是模糊的。我们有一些很好的工具和技术，包括保持操作系统、VM（虚拟机）和容器的更新；安装安全补丁；扫描公司的网络和IP（互联网协议），以检测某人在未咨询我们的情况下上网的所有软件；鼓励开发人员更新他们的依赖关系；在他们的代码发布之前进行模糊处理；并确保权限没有被过度授予。因此，我们尽力而为，尽管如果我们做得好，没有人会注意到。

那么，怎样才能使生产安全工程师的生活更轻松呢？给予安全问题同样的空间和关注，你希望产品团队能给予SRE同样的关注。让我们从一开始就保持联系。尽可能早地沟通基础设施的变化。让我们参与决策。不要在某个虚拟机上运行一个你忘记了的旧操作系统。及时点击Dependabot PR（拉动请求）的合并。信任我们的建议。最终，通过将我们融入你的日常工作和决策，使我们成为你组织的一部分。这对你来说有明显的好处，因为一个被黑的系统可能会瘫痪，造成大量的停机时间–我很难称其为可靠。因此，当我们下次向你提出一个看似偏执的建议时，请记住，我们非常关心保持我们的客户安全和一切正常运行。不要让安全成为事后的考虑!

并且永远记住：对待你的安全团队就像你希望那一个产品团队对待你一样。

我们如何构建本书的结构

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