Table of Contents

Create Your Supporting Artifacts[1]

创建你的支持性工件

在SLO【2】实施过程中,不要低估文档对你和你的组织的支持力量。你的目标是将SLO的创建分解成三个阶段:定义SLO,收集SLI,以及后来使用SLO。以下是我们在这个阶段推荐的文档列表:

单页战略文件
  这将是爬行阶段中最重要的文档。你想完成什么?为什么,怎样做?这将是你与人们分享的第一份文件,当他们问:“这项工作的目的是什么?” 让它简短到任何人都能在10分钟内读完。关键是你要把这份文档写好。把这本书作为一种资源,帮助你阐明你的组织为什么需要SLO:创建SLO会得到什么,以及SLO会如何为你的用户提高服务的可靠性并帮助你的工程团队。确保你与你的领导层一起审阅这份文件,并得到他们的认可和对你计划在整个组织内沟通的策略的完全支持。

两页定义SLO的文件(高水平的)
  接下来,你需要一份更详细(但仍然简短)的文档,解释什么是SLO,给出好的SLO的例子,并告诉读者如何能够开始。你不想吓唬你的读者,要求他们读一整本关于SLO的书,只是为了了解什么是SLO。要让工程师们轻松地了解如何实施基于SLO的方法,并努力培养他们的兴趣。

常见问题(FAQ)
  收集一份你希望人们在开始他们自己的SLO之旅时提出的问题的清单,并将它们汇编成一份FAQ文件。首先,你可以包括以下问题:

  • 如果我的用户是另一种服务呢?我还需要关心SLO吗?
  • 如果我的服务的依赖关系没有SLO怎么办?
  • 一个服务应该有多少个SLO?多少个SLI?

逐步为您的服务定义SLO
  您将需要一个文档,逐步解释您组织中的人员如何定义SLO (SLO创建过程的第一阶段)。这里不要谈论工具和参数收集;重点是高层过程。你可能想分享一个团队可以使用的SLO定义模板。

对服务进行检测以收集 SLI
  作为前一份文档的后续,本文档将通过示例提供逐步指导,介绍如何用工具检测服务以收集 SLI(第二阶段)。在这里你可以非常具体,看看你的组织使用的监控平台,为不同类型的服务提供SLI工具的例子。例如,你将如何收集延迟数据并将你的指标转化为SLI,使用百分比?你将如何利用管道服务来收集SLI?尽可能多地举出例子,并提供现成的代码片段,使工程师能够轻松地推进监控仪器化的进程。

使用案例
  如果你已经为你的任何服务(或你在做研究时开发的示例服务)实施了SLO,请在用例文档中写出细节,给你的SLO早期采用者一个具体的例子,说明如何做到这一点。

不要忘了定义你所有的工件的存放位置——例如,一个与代码库配对的wiki——并确保它们是可发现的和容易浏览的。我们在工程组织中看到的最大的错误是没有花时间创建结构良好和可发现的技术文档,也没有要求文档像代码一样经过同样的质量审查过程。

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系列的文章,有时间我就会翻译一些,希望大家能学到对自己有用的东西。谢谢

翻译不易,转载时请注明原文链接,谢谢

延伸阅读

1.[Artifact](https://en.wikipedia.org/wiki/Artifact_(software_development))
An artifact is one of many kinds of tangible by-products produced during the development of software. Some artifacts (e.g., use cases, class diagrams, and other Unified Modeling Language (UML) models, requirements and design documents) help describe the function, architecture, and design of software. Other artifacts are concerned with the process of development itself—such as project plans, business cases, and risk assessments.

2.Service-Level