97 Things Every SRE Should Know-68
Table of Contents
The Order of Operations for Getting SLO Buy-In
获得SLO支持的操作顺序
作为推动你的团队、组织或公司采用 SLI、SLO 和错误预算【1】的人，你将不得不做相当多的说服工作。对于一些人来说，SLO的基本论点与他们为自己和团队设定的目标相悖。还有一些人希望把功能速度放在可靠性工作之前，还有一些人怀疑公司是否足够成熟或足够好，能够真正采用这些原则和技术。
重要的是现在要认识到，采用基于SLO的方法的好处不会对每个人都是不言而喻的，你将不得不做相当多的耐心解释。让我们建立一个游戏计划，让每个人都加入进来。像工程中的大多数事情一样，操作的顺序很重要。
根据经验，以下是我对获得认同的顺序的建议：
工程和运营 你的第一步是让工程和运营团队都加入到SLO中来。这应该是相当直接的，因为SLA、SLO和错误预算给每个小组提供了真正的好处。他们对SLO的原则的相互认同对于让其他团队加入进来是至关重要的。请注意，我说的是原则。实施细节（错误预算政策、SLO目标等）将在以后协商。
产品 你的下一站可能是你的产品经理（或编写产品需求文件的人，或PRD）。你向他们提出的关键论点是，这种方法会给他们带来更好的功能速度。他们会想知道工程和运营部门是否同意，这就是他们在第二步的原因。
领导层 一旦工程、运营和产品团队都接受了，就该和你的高层领导谈谈了。这种变化的好处（更大的发布速度、对用户体验的早期洞察、更好的工作环境等）是显而易见的，但他们会想知道这三大团队是否达成一致。
法律 你的下一站是律师。如果你已经完成了第1-3步，你就不可能在这里遇到很多阻力。他们会担心（这是正确的）这种变化对公共SLA意味着什么（回答：如果他们还没有遇到很多违反SLA的情况，那么这些变化几乎没有影响，而且可能会提供一个采用更有竞争力的SLA的机会；如果他们遇到的情况比他们希望的多，这个数字会下降）。
QA 这是你的最后一站。这是一个将最关心这些变化对他们意味着什么的小组。这次谈话的重要部分是让团队专注于他们带来的技能，而不是他们加入的组织。没有人会失去他们的工作–远非如此。你不是真的去说服QA团队。你要告诉他们（温和地），公司正在向SLO转变，领导层、工程部、产品部和运营部都同意这是正确的事情。
你将需要与其他团体–销售、营销、客户支持等交谈，但他们是这个决定的消费者，而不是实施者。
Adapted from the book Implementing Service Level Objectives: A Practical Guide to SLIs, SLOs, and Error Budgets (O’Reilly).
我们如何构建本书的结构
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系列的文章，有时间我就会翻译一些，希望大家能学到对自己有用的东西。谢谢
翻译不易，转载时请注明原文链接，谢谢