Table of Contents

Trading Places: SRE and Product

交换位置：SRE 和 产品

历史上，SRE【1】团队与产品和功能团队之间存在着一种紧张关系，就像运维团队和开发团队之间的墙一样。前者希望首先对可靠性进行优化，而后者则希望发布新功能，这就导致了变化——导致了事情的破坏。我们不需要生活在这种对立的关系中。如果我们能在产品和SRE团队之间建立共鸣，这不仅会带来更健康的关系，还会为每个人带来更强的双赢结果。

这种情况如何发生？对于两个团队的工程师来说，站在对方的角度去理解并做出正确的权衡是很重要的。当产品工程师没有用可靠性思维来操作时，他们会把不公平的负担转移到SRE身上，这可能会导致不愉快，在最坏的情况下，会导致倦怠【2】。当SRE不采用产品工程师的观点时，他们可能不理解来自高管和利益相关者的压力，而两个团队都错过了拓宽知识的机会。

这里最理想的情况是每个功能团队负责运行自己的服务，而不是在半夜呼唤SREs。然而，这并不总是可能的。on-call【3】是很难的。即使做得很好，它也可能是破坏性的和费力的。如果它缺乏同情心或关心，它可能会产生灾难性的后果。工程师不能也不应该被迫on-call。有些人不想在夜里被吵醒，而且有很好的理由，比如有慢性病或照顾人的责任。如果人们对on-call不满意，这就不可能成功。我们需要建立反馈回路【4】，以建立一个健康的on-call文化。

这就是我们想要达到的目标，尽管我理解团队不可能一开始就达到目标。然而，我们可以有一个有点混合的解决方案，让工程师定期轮换到另一个团队，比如两个季度。(当然，这个期限取决于你的组织，你要找到最适合你的团队的平衡点。) 这将导致未来功能团队和SRE团队之间更好的理解和合作，当每个团队的成员都意识到另一个团队所面临的问题和他们每天必须做出的那种权衡。

这也有助于你扩展你作为工程师的技能，因为SRE的工作与日常的功能工作可能有很大不同。它可以让你看到一个全新的领域，而你一直在自己的领域内工作，但没有机会去探索。如果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.burnout
3.on-call
4.feedback loops