DO, RE, Me:测量现场可靠性工程的有效性

这里是今天的重点。DORA组织多年来一直在研究软件交付。今年，我们深入研究了站点可靠性工程。我们向团队询问了他们的操作实践以及这些团队能够实现的结果。我们发现SRE和DevOps在一起工作得非常好。它们的起源不同，但它们各自独立地演变成非常相似的哲学，今天它们相互补充。我们发现SRE实践已经在各种类型的组织中被广泛采用，并且我们发现SRE能够真正帮助放大软件交付最佳实践在实现业务目标方面已经产生的强大影响。

好，让我们看看我们是如何得出这些结论的。首先，我叫戴夫，我在新泽西州的泽西城向大家表示欢迎。我在谷歌负责开发人员关系，我的工作包括学习、教授和继续学习与DevOps和SRE相关的最佳实践。我很乐意听到你的消息，所以请在Twitter上@DavidStanke上找到我。好吧。DevOps是什么?对于一个经常被抛出的术语来说，DevOps没有一个规范的定义可能有点令人惊讶，对吧?没有宣言或认证过程。这实际上是故意的。创造这个术语的人实际上是想让DevOps成为一个持续的交流过程。 It’s a conversation.

当然，这并不妨碍我们为它提供定义。你可能听过很多。你也可以有自己的孩子。我有一个。这实际上是一张图片。它是这样的。DevOps是指我们应用通信和自动化来实现速度和可靠性，为用户提供满意的服务。好的,很酷。我们该怎么做呢?DevOps听起来确实不错。 It’s hard to argue with the idea that all of our services should be fast and reliable and we should make our users happy. But how do we apply that? These ideas are supposed to apply to our work to our jobs, right? They should be practical. DevOps can be fun, but we don’t do it for fun. We do it for work. So the question is, how do we put DevOps into practice? I’m here on behalf of a group that takes an empirical approach to that question. That question, how do we do the DevOps?

在谷歌云中，有一个叫做DevOps研究和评估小组的团队，近十年来，我们一直在运行一个最大的研究项目，致力于了解如何让一个软件团队真正出色地为业务交付价值?为了做到这一点，我们研究了很多团队，很多组织。我们从成千上万的技术从业者那里收集了数据，他们在成千上万的组织中工作。有了这些数据，我们应用严格的统计方法来推断出哪些是最佳实践。我们每年发表一份总结调查结果的报告。以下是今年报告的概要，该报告于几周前发布，可在bit.ly/dora-sodr上下载。S-O-D-R, DevOps状态。这是一本很棒的书。它大概有70页左右，但有很多图表和颜色，它是给高管们看的，但对于从业者来说，对于不同层次的人来说，它有很多很好的见解。我强烈建议你们拿起这本书，读一读，然后反馈给我们，让我们知道你们的想法。 This is an ongoing conversation.

我将简要介绍一下我们在报告中了解到的一些事情。你还会发现除了我们今天要讨论的SRE话题之外的其他话题。好吧。多拉研究的核心是能力和结果的预测模型。所以预测关系比相关关系更强。这不完全是因果关系。它的意思是，当我们看团队做的事情，能力，这些可能是技术的，这些可能是文化的，这些可能是工具，它们可能是实践，沟通的方式。我们有一大堆。这些能力可以预测某些结果。这意味着如果我们有这种能力，我们就更有可能得到我们想要的结果。

作为预测模型的一部分，我们已经发现了一套非常可靠的度量标准来衡量软件团队的效率。很长一段时间以来，衡量软件开发一直是一个挑战。很久以前，我们了解到代码行数或bug计数并不是很好的度量，对吧?它们很容易被操纵，而且它们与有意义的结果并不相关。但是通过DORA的研究，我们开发了一套简洁、可靠的指标，可以预测现实世界的结果。有四个。四个关键指标。有两个与速度有关。这就是改变的先导时间。从一段代码提交给版本控制到它发布给用户并部署给用户需要多长时间，不管你的部署机制是什么，或者发布机制是什么? What’s that lag time?

第二个速度度量是部署频率。我们多久向用户部署或发布一次?是一个季度一次，还是一天多次，还是介于两者之间?现在，与此相辅相成的是稳定性度量。当我们发布我们的软件时，我们的变更失败率是多少?这些部署出问题的频率是多少?我们说，“哦，eek”我们需要撤销它，回滚或向前修正。当这种情况发生时，我们的第四个也是最后一个指标是恢复服务的时间，恢复服务的中值时间。从“Eek”到“好了，恢复了，用户的服务恢复了”需要多长时间?总之，这四个指标，这四个关键，组合成一个我们称之为软件交付性能的结构。 This is a part of our mathematical model that works as a single entity to predict other parts of the puzzle.

因此，软件交付性能反过来预测业务性能。所以从最终结果往回算，我们可以说。如果您希望您的业务有好的结果，那么改进软件交付可能会帮助您实现这一目标。然后这些功能，我将深入探讨一下，告诉我们如何改进软件交付。现在我想讲一点附带的东西，但实际上可以说是整个事情中最重要的部分，那就是文化。文化是另一种通常难以量化、难以衡量的东西，当然也很难改变，但它是可以做到的。从如何测量开始。朵拉研究使用了一个叫做Westrum组织类型学的框架，这个框架是由社会学家Ron Westrum和他的团队在几年前提出的。

他们实际上是在研究软件之外的团队。他们研究的是在高信息环境下的团队，在一些非常严重的结果，非常可量化的结果的地方。他们研究的是急诊室和核电站，他们研究的是在这些环境下人们是如何交流的?他们如何共享信息?他画出了三种类型。所以在频谱的一端是权力导向类型的信息共享，人们在寻找个人控制，个人权威，而新信息被视为对这种控制的威胁。因此，他们试图消灭新信息，他们可能会惩罚坏消息的携带者。我们也称之为病理组织。

在中间，通常是一个非常传统的商业模式，是面向规则的组织。所以这是一个你真正定义了责任孤岛的地方，新的信息可能不会受到惩罚，但也不完全受欢迎。当新事物出现时，人们会努力把它放回盒子里，试着把它纳入他们已经知道的框架中。很多时候，在这样的组织中，一个人要想和另一个人建立联系需要很多跳跃，因为他们必须在这种官僚主义中穿行。这就是为什么我们称之为官僚组织。

在这个范围的另一端，我们有绩效导向的文化。在这里，新信息被视为学习的机会。人们相互合作以了解新的信息，并开发出新的方法来回应这些信息以及接下来会发生的事情。我们称其为生成性文化。

韦斯特鲁姆发现，在这些情况下，甚至可能在任何情况下，根据他们自己的kpi，表现最好、结果最好的团队是那些拥有生成文化的团队。在DORA中，我们发现同样的事情也适用于软件团队。因此，生成文化可以预测更好的软件交付结果和更好的业务结果。

现在，这些结果可以是相当广泛的，相应的，软件交付的度量也有很大的范围。当我们比较表现最好的人，最优秀的人，这是我们通过聚类分析得到的，它给出了四组表现者。优秀的执行者比低执行者交付软件的速度和频率都要快得多，同时，他们恢复服务的时间也更快，变更失败率也更低。因此，同样的团队，能够最快地交付产品，也会有最少的缺陷，或者对用户的影响最小，对用户的影响时间最短。这意味着我们看到速度最快的队伍打破的东西最少。所以，高绩效的团队在各个方面都优于他们的竞争对手。

好了，现在。我说过我们要讨论SRE。行为是什么?SRE代表站点可靠性工程，它是一种操作方式。实际上，这是谷歌执行操作的方式。我们在21世纪初就开始做了，这源于我们意识到我们面临着规模上的挑战。我们审视了我们的工作，我们在扩大规模和运营我们的服务上所付出的人工努力，我们说，“孩子，当我们开始从数百万用户扩展到数十亿用户时，这行不通。世界上没有足够的运营人员来做这件事。即使我们有他们，我们也付不起所有的钱。”

所以我们开始应用自动化、可重复性和信息共享的原则来扩大这些个体操作员的能力。在此过程中，我们总结出了一些原则。这些就是SRE原则。第一个是这个。任何系统最重要的特征是它的可靠性。无论我们想为用户提供什么功能，无论我们想为用户提供什么功能，如果系统不能工作，如果他们不能访问我们的系统，我们想为他们提供什么都不重要。他们不能从中受益。所以第一要务，就是可靠性。

那么，可靠性是什么意思呢?我们的监控并不能决定。我们可能有各种各样的信号，各种各样的遥测技术，但这并不是我们是否可靠的最终判断。我们的用户可以做出决定。如果我们的用户能够根据他们的需要体验到我们的系统是可靠的，那么它就是可靠的。如果不是，我们需要改变我们的定义。因此，我们从用户导向的角度来定义系统的可靠性，并努力从这个角度来衡量和改进它。

最后，我们了解到，为了满足这些可靠性目标，我们需要的不仅仅是精心设计的软件。我们还需要精心设计的操作系统。除此之外，为了真正达到服务于真正规模化运营的高水平，我们需要一个精心设计的业务，它理解并支持可靠性工程工作。

好了，我们来看一些术语。所以SRE的关键术语是这些。学校图书馆。服务水平指标。SLOs。服务级别目标。还有sla。服务水平协议。SLI是定义系统运行情况的指标。同样，它反映了客户对系统的看法。 So it may be something like error rates, how many user requests are resulting in a 200, an okay status, versus a 500, a not so well case status. And that can give us a ratio. Out of all the requests that our users are making, how many of them are delivered successfully in a way that the user can recognize as a good response? Now, to that number, we can apply an SLO, service level objective. This says, this is our target. This is our goal. This is the value that we want those metrics to have. This is often expressed in terms of a percentage, a number of nines. Two nines is 99 percent. Three and a half nines is 99.5 percent. These are our targets. These are our SLOs.

最后，SLA是我们在SRE中通常不怎么谈论的东西。这是一种商业协议，它说:“如果我们没有达到我们的目标，我们的承诺，我们会受到什么惩罚?我们该如何弥补呢?”sre通常试图置身于这些对话之外，这意味着我们需要用比SLA更高的标准来要求自己。它一定要知道SLO。他们一起工作。但如果我们达到了最低服务标准，那就说明我们清楚我们的最低服务标准。

那么，我们如何实现这一切呢?我们使用的一种方法叫做误差预算。误差预算是这样的。我们设定了SLO，我们的目标是99.5%。这意味着我们知道出错率会有0.5%不是每件事都能成功。我们能理解，对吧?我们在街区附近转了一圈。我们知道有时系统会失败，我们必须对系统会失败到什么程度，我们愿意让它失败到什么程度，以及我们如何才能让用户满意，有某种程度的理解和共识。

这就是我们的误差预算。这是我们的容忍度，我们的风险容忍度对于系统中可能出现的故障和错误，我们仍然能够为用户提供足够好的服务。这个误差预算让我们有能力去做一些可能有风险的事情。比如发布。我们发现大约90%的失败发生在新的软件或配置更改期间。所以给人们提供他们想要的所有很酷的功能，这是有风险的。我们用我们的错误预算来了解，我们现在是否有风险承受能力来做一些很酷的新东西，还是我们需要保留，专注于可靠性?因为可靠性是最重要的特征。不是唯一的重要特征，但却是最重要的。误差预算是我们的指南。

我们喜欢把提醒合理化。我的意思是，如果你在半夜被一个你无能为力的警报吵醒，或者你根本不关心它，这就没有很好地利用你人类的关心能力。所以我们真的尝试关闭尽可能多的提醒，把它们集中在用户体验受到影响的事情上，你可以做些什么，你应该现在就做。如果它可以等待，如果几天或几周后的反应可能是好的，我们就不要在半夜呼叫某人。让我们把它记录在某个地方，然后我们有时间的时候再来做。

我们有防灾演习，对吧?一个灾难准备计划如果没有被实际尝试过就不是计划。我们用这种方法做了很多场景。支撑这一切的技术之一就是减少辛劳。辛苦工作是指手工重复的工作，而不是战略性的工作，就像向机器中输入SSHing以重新启动服务一样。很好，很好。它可能会停止oom，但它明天会回来。所以我们宁愿尝试自动化，或者让它从一开始就不会发生。通过消除这些辛苦，这给了我们自由，让我们的精神循环去做更多的工作，帮助我们发展我们的系统，扩大我们的规模。

好的，有很多不同的方式sre可以与组织的其他部分联系起来。我在这里展示的这些模型和你可能在DevOpstopologies.com上看到的非常相似。所以没有一种万能的模型，但是有了这个沟通平台，使用slo，使用错误预算作为一种手段来平衡特性，速度和稳定性，这是这些不同角色如何相互关联的核心，不管他们的组织结构是什么样子的。

2016年，我们在谷歌内部开发的这些关于SRE的想法开始成为公众讨论的一部分，当时我们发布了第一本关于站点可靠性工程的书。从那时起，关于SRE又出版了许多书籍和会议，并进行了许多对话。因此，当DevOps社区和其他社区的人开始了解SRE时，他们开始把它与DevOps放在一起看，他们说，“嗯，这些东西是如何关联的?我在这里看到了一些相似之处。我觉得有些熟悉。这些东西是一样的吗?它们完全不同吗?他们有竞争力吗?”

好吧，回答这个问题的一种方法是我们谷歌所提出的，即SRE实现了DevOps。SRE，就像面向对象类实现面向对象接口一样，是实现DevOps的一种方式。它实际上做了DevOps更抽象地规定的事情。现在，对于熟悉这两个学科的人来说，这个断言感觉非常舒服。这听起来是真的，对吧?但这更像是一个假设而不是公理。我们不一定有客观的数据来支持这一点。

现在我想花点时间看看这些术语的广度。DevOps起源于SDLC的这一领域，着眼于如何让我们的开发周期和部署周期更加同步，在它们之间有更好的沟通和更快的速度?SRE开始时稍微往右一点。SRE更多的是关于，当软件部署到pro时，我们如何保持它可靠地运行，然后将反馈机制提供给开发团队?

随着时间的推移，DevOps的范围发生了一些变化。当它开始进入组织时，人们开始意识到，与产品、业务和用户之间有重要的互动。范围开始扩大，对吧?这不是一件坏事，尽管它确实导致了一些相当可怕的portamentos。例如，精益产品被引入DORA研究，作为DevOps产品管理框架的选择。这是如何将产品开发纳入我们看待整个DevOps模型的方式。

那么行动呢?我们一直在研究软件的稳定性，我们的意思是，当我们发布一个版本时，它是否会持续，或者我们是否需要重新部署它，因为它有缺陷?那之后呢?当软件遇到用户时，当他们真正体验它并从中获得价值时，软件的持续运行又如何呢?今年，DORA项目确实希望更好地理解操作及其在整个软件交付价值压力中的角色。DORA早在2019年就开始涉足这一领域，当时我们引入了软件交付和运营绩效的第五个指标。我们有了软件交付的四个关键，并且引入了另一个用于操作性能的关键，即可用性。

现在，我们今年做的第一件事是扩大我们的范围，我们把可用性重命名为可靠性，因为可靠性实际上，当我们从可靠性工程的角度考虑它时，它包含了比可用性多得多的东西。可用性是指，网站上线了吗?我能拿到吗?但是我们考虑可靠性的方式，我们考虑的不仅仅是，我能得到它吗?但同时，它能给我一个足够快的回应，对我有用吗?当我得到响应时，它是否有正确的内容?它是否具有我作为用户所期望的内容?

可靠性实际上意味着，这项服务是否符合它对我作为用户的明确或隐含的承诺?当然，在谷歌，我们试图通过SRE来实现这一点，我们想知道还有谁在做SRE。这给了我们一个问题，我们怎么知道?我们如何知道一个团队是否在进行SRE?没有既定的标准将某人标记为SRE。说谷歌的SRE是SRE的实践者是很合理的，因为这是一个重复，但即使在谷歌的母艇上，不同的领域，不同的团队，不同的个人，都有不同的风格，不同的参与水平和不同的成熟度在他们的SRE实践中。

我们不想只是问人们，你有SRE吗?这可能会导致假阴性和假阳性。我在与客户的交谈中看到了这两种情况。有时团队会说他们有SRE，但他们的操作方式更像传统的系统。有时，团队开发了类似sre的原则，但不使用这个术语。例如，Facebook有一门学科叫做生产工程。在很多方面，它与SRE非常相似，但当然它有一个不同的名字。所以我们采用了一种鸭子类型的方法。如果一个团队表现得像一个SRE团队，那么我们就说他们在做SRE。

为了达到这个目的，我们把SRE书提炼成简明的实践陈述，去掉了大部分行话。我们将其归结为一组陈述，并将其添加到我们的DevOps研究调查中。我们问人们，你是做什么的?从一到七，你做这些事了吗?您将在这里看到一些语句，它们反映了基于理性症状的警报方法。你会看到其他描述减少辛劳或灾难准备的文章。你还会看到一些描述运营和开发之间的关系，以及他们如何沟通，如何划分优先级。

现在，这个列表必然是简化的，它是不完美和不完整的。我确信我们有些地方做错了，但我们确实做得很正确，我们有了统计上显著的发现。这里有些东西。那么我们学到了什么?我们学到的第一件事是SRE被广泛应用。它远远超出了谷歌和Facebook以及我们书中提到的一些大公司。事实上，我们发现52%的受访者在某种程度上报告了SRE实践的使用。现在这种情况可以广泛传播。有些团队只做了一点点。一些团队正在做我们要求的所有SRE实践。 But it really was a very widespread.

这也反映了我们在谷歌的经验，在那里，一些团队做了很多SRE实践，而一些团队做得并不多。因此，在某种程度上，我感到惊讶的是，这些实践在整个软件开发社区中非常普遍。有那么多的人在做这些事情，这就导致了一个问题，当然，它是如何进行的?好消息。SRE似乎有效。回想一下我们使用的预测模型。如果一个团队做了X，这是对Y的预测，Y可能是另一种能力或结果。下面是这个预测模型的一个简化视图。您可以在bit.ly/dora-bfd上查看全部内容。这是一个很大的友好图。

现在，我们发现，基于预测分析，我们可以看到SRE有很多好处。SRE对人类有益。我们发现，使用SRE实践的团队较少倦怠，我认为这可以归因于SRE从业者的工作更多样化，做的工作更具战略性。它还有助于平衡不同类型的工作，以运维为中心的工作，艰苦的工作和编码之间的平衡。因此，实践SREs的团队报告说，他们花了更多的时间写代码，而这通常不是功能代码。这是一种帮助他们管理和自动化系统的代码。

从这个角度来看，SRE对系统和组织都有好处。我提到过，我们询问了团队关于运营人员和开发人员如何沟通和划分优先级。我们关注的一件事是，他们是否分担了系统运行可靠性的责任?我们发现，这样做的团队，在交付系统的最终责任是由这些角色共同承担的，这导致了更好的可靠性。总的来说，我们在SRE构建中研究的所有技术都预测了更高的可靠性。

最后，这有利于业务可靠性有助于实现这些业务目标。让我们来看看它是如何工作的。它的工作原理是，可靠性是力量倍增器。这就是我的意思。还有软件交付性能，由围绕速度和初始成功率的四个关键指标来衡量。现在，我们发现可靠性与软件交付呈正交关系。在其中一个领域取得成功的团队不一定在两个领域都取得成功。所以它们独立运动。但是，当团队在这两个领域都表现出色时，技术可以为涉众提供的价值就会产生复合效应。拥有高软件交付性能分数的团队，也广泛使用SRE实践，报告他们的业务实现了商业目标的可能性是其他团队的1.8倍。

最后，我们发现还有很大的发展空间。SRE被广泛使用，并具有明显的好处，但很少有受访者表示他们的团队已经完全实现了我们研究的每一种SRE技术。所有级别的团队都有一系列的实现。在所有级别上，在软件交付性能的每个集群中，在业务结果方面，满足其可靠性目标的团队要优于集群中的其他成员。

好了，到了我的热拍时间。这些都是我对研究的阅读，但不应该被视为研究团队的正式发现。首先，这里有一个趋同的运动。许多公司和研究人员已经得出结论，在复杂和高信息环境中，这种生成文化推动组织绩效。所以我们从SRE文化，从DevOps和Westrum文化的DORA，从丰田和他们的丰田生产系统，从心理安全研究中学到了这些交流的方式，这些处理信息的方式。

你可以在商业文献中看到大量关于这种高度信任，高度沟通和心理安全的文化，如何最终产生更好的结果的文章。我认为这向我们展示了一些隐藏的东西，一些可能是更深层次的真相，而DevOps ops和SRE以及其他一些方法都是发现这一点的不同方法。我们可能还会发现一些共同点。

其次，SRE不是为谷歌公司设计的。这些可靠性工程实践对所有DevOps成熟度级别的团队都有好处，但重要的是要注意，实现SRE可能不是您的团队的最高优先级。有很多能力和实践都是SRE的先决条件，其中很多都是DevOps模型的一部分。

所以我们在DORA研究中做的一件事就是我们给人们提供一种指南，一种路线图，告诉他们你在我们研究的每一项能力上做得如何?这些内容包括基于主干的开发、持续测试、团队结构以及为团队提供信任和自主权。通过研究，我们可以发现我们的团队需要帮助的地方。也许我们需要看看我们的操作实践。也许最强大的东西是其他东西。

最后，DevOps是一把大伞，中间有或没有额外的音节。SRE是我们运营以及运营和其他团队之间沟通的框架。它真的很适合DevOps，就像精益产品是在DevOps组织中很好地工作的产品开发框架一样。因此，SRE作为软件开发的整体DevOps方法的一部分。因此，我要说，谢谢你。我期待在问答环节回答大家的问题。

接下来我将留给您一些资源供您探索。2022世界杯阿根廷预选赛赛程首先是今年的DevOps报告，你可以在bit.ly/dora-sodr上下载。前往sre。谷歌，可以免费获取我展示的所有书籍以及其他文章和资源。2022世界杯阿根廷预选赛赛程我诚挚地邀请您参加我们的可靠性讨论组。讨论我每月主持的会议。这是一个关于可靠性工程的公开对话的地方，我们可以分享什么是有效的，什么是不有效的。我希望在那里见到你。谢谢你！