DO, RE, Me:测量站点可靠性工程的有效性

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

好了，我们来看看我们是如何得出这些结论的。首先，我是戴夫，今天我从新泽西州泽西城向大家问好。我为谷歌做开发人员关系，我的工作包括学习、教授和继续学习与DevOps和SRE相关的最佳实践。我很乐意收到你的来信，所以请在推特@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话题，你们还会发现其他的话题。好的。所以DORA研究的核心是这个能力和结果的预测模型。所以预测关系比相关关系更强。这并不完全是因果关系。这意味着当我们观察团队所做的事情，能力时，这些可能是技术的，可能是文化的，可能是工具，可能是实践，沟通的方式。我们有一大堆。这些能力可以预测某些结果。这意味着如果我们有这种能力，我们更有可能得到我们想要的结果。

作为这个预测模型的一部分，我们已经发现了一套非常可靠的度量标准来衡量软件团队的效率。现在，很长一段时间以来，度量软件开发都是一个挑战。很久以前，我们就知道，计算代码行数或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.

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

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

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

在这个范围的另一端，我们有绩效导向的文化。在这种情况下，新信息被视为学习的机会。探究是当下最重要的事情，人们合作去理解新的信息，并开发新的方法来回应这些信息以及接下来会发生的事情。我们称之为生成文化。

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中通常不怎么谈论的东西。这是一种商业协议，它说:“如果我们没有实现我们的目标，我们的承诺，会有什么惩罚?我们该如何弥补呢?”SREs通常会试图置身于这些对话之外，这意味着我们需要以比SLA更高的标准来要求自己。它一定要意识到SLO。他们一起工作。但如果我们满足了slo要求，就能保证我们明确了slo要求。

那么，我们如何实现这一切呢?我们使用的一种方法叫做误差预估。误差预算是这样说的。我们把我们的SLO，我们的目标设定为99.5%。这意味着我们知道会有0.5%的错误率。不是每件事都能成功。我们都能理解，对吧?我们已经绕着街区转了一圈。我们知道有时候系统会出故障，我们必须对系统会出多大的故障，我们愿意让它出多大的故障，以及我们如何能与用户相处，达成某种程度的理解和共识。

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

我们喜欢合理化警报。我的意思是，如果你在半夜被一个你无能为力，或者你不在乎的警报吵醒，那就没有很好地利用你人类的关爱能力。所以我们尽量关闭尽可能多的提醒，把它们集中在那些真正影响用户体验的事情上，你可以做些什么，你应该现在就做。如果可以等，如果回复在几天或几周后就可以了，我们就不要在半夜呼叫某人了。我们把它记录在某个地方，有时间的时候再看。

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

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

2016年，我们在谷歌内部开发的这些关于SRE的想法开始成为公众讨论的一部分，当时我们发布了第一本关于站点可靠性工程的书。从那时起，就有了多本额外的书和会议，还有很多关于SRE的对话。因此，当DevOps社区和社区以外的人开始了解SRE时，他们开始把它与DevOps放在一起看，他们说:“啊，这些东西是怎么联系起来的?我看到了一些相似之处。我觉得你很熟悉。这些事情是一样的吗?它们完全不同吗?他们有竞争力吗?”

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

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

随着时间的推移，DevOps已经有了一些范围渐变。当它开始进入组织，人们开始意识到，有理由，与产品，与业务，与用户有重要的交互。范围开始扩大，对吧?这不是一件坏事，尽管它确实导致了一些相当糟糕的portamentos。例如，精益产品作为选择的DevOps产品管理框架被引入到DORA研究中。这是如何将产品开发与我们如何看待整个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世界杯阿根廷预选赛赛程我诚挚地邀请您参加今天的可靠性讨论组。ly/r9 -讨论我每个月主持的。这是一个公开讨论可靠性工程的地方，在那里我们可以分享什么是有效的，什么是无效的。我希望能在那里见到你。谢谢你！