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

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

好了，让我们看看我们是如何得出这些结论的。首先，我叫戴夫，今天我在新泽西州泽西城向大家问好。我在Google负责开发人员关系，我的工作包括学习、教授和继续学习与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?

因此，在Google云内部，有一个叫做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?

第二个速度度量是部署频率。我们多久向用户部署或发布一次?是每季度一次还是每天多次，还是介于两者之间?现在，与之相结合的是稳定性指标。所以当我们发布软件时，我们的变更失败率是多少?部署出错的频率有多高?我们说，“哦，周了，”我们需要撤销它，回滚或向前修复。当这种情况发生时，我们的第四个也是最后一个指标是恢复服务的时间，恢复服务的中间时间。从“糟糕”到“好了，它回来了，为用户恢复服务需要多长时间?”总之，这四个指标，这四个关键，组合成一个结构，我们称之为软件交付性能。 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。他们一起工作。但是如果我们达到了我们的sla，那就应该让我们知道我们清楚我们的sla。

那么，我们如何实现这一切呢?我们使用的一种方法叫做误差预算。误差预算是这样说的。我们设定了SLO，也就是99.5%的目标。这意味着我们知道会有0.5个百分点的错误率。并不是所有的事情都会成功。我们能理解，对吧?我们一直在这个街区。我们知道有时候系统会失败，我们必须对它会失败的程度有某种理解和共识，我们愿意让它失败到什么程度，以及我们如何能够与用户保持良好关系。

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

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

我们做备灾演习，对吧?一个备灾计划除非经过实际的尝试，否则就不是一个计划。我们用这种方法做了很多场景。其中一个支撑这一切的技术就是减少辛劳。辛劳是指手动重复的工作，而不是战略性的工作，就像在机器上重新启动服务一样。很好，很好。它可能会阻止房间，但它明天会回来。所以我们宁愿尝试自动化，或者让它在一开始就不会发生。通过消除这些辛劳，我们就有了自由，有了精神循环，可以做更多的工作，帮助我们发展我们的系统，扩大规模。

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

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

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

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

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

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

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

可靠性真正的意思是，这个服务是否达到了它对用户的承诺，无论是明确的还是隐含的?当然，在谷歌，我们试图通过SRE来实现这个目标，我们想知道还有谁在做SRE。这就给了我们一个问题，我们怎么知道的?我们如何知道一个团队是否在进行SRE?目前还没有既定的标准将某人标记为SRE。说Google SRE是SRE的实践者是很合理的，因为这是一个同义反复，但即使在Google这个母船，不同的领域，不同的团队，不同的个人，在他们的SRE实践中都有不同的风格，不同的参与程度和成熟度。

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

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

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

这也反映了我们在Google的经验，有些团队做了很多SRE实践，而有些团队做得并不多。因此，让我感到惊讶的是，这些实践在整个软件开发社区中非常普遍。那么有那么多人在做这些事情，这就引出了一个问题，当然，事情进展如何?好吧，好消息。SRE似乎起作用了。回想一下我们使用的预测模型。如果一个团队做了可以预测Y的X, Y可能是另一种能力或结果。下面是该预测模型的简化视图。您可以在bit.ly/dora-bfd上探索整个过程。这是一个大而友好的图表。

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

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

最后，这有利于业务可靠性，有助于实现这些业务目标。让我们来看看它是如何工作的。它的工作方式是，可靠性是一个力量倍增器。我的意思是。有软件交付性能，这是通过围绕速度和初始成功率的四个关键指标来衡量的。现在，我们发现可靠性与软件交付是垂直的。在其中一个领域取得成功的团队不一定在两个领域都取得成功。它们是独立运动的。但是，当团队在这两个领域都表现出色时，您将获得技术可以为利益相关者提供的价值的复合效应。具有高软件交付性能分数的团队，也广泛地使用SRE实践，有1.8倍的可能性报告他们的业务实现了他们的商业目标。

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

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

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

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

所以我们在DORA研究中做的一件事是我们为人们提供一种指南，一种路线图，告诉他们，你是如何处理我们研究过的每个功能的?这些范围从基于主干的开发，到持续测试，到团队结构，以及为团队提供信任和自主权。通过研究，我们可以发现我们的团队需要帮助的地方。也许我们需要审视我们的操作实践。也许最强大的东西是别的东西。

最后，DevOps是一把大伞，不管中间有没有额外的音节。SRE是我们运营的框架，也是运营和其他团队之间沟通的框架。它确实适合DevOps，就像精益产品是一个在DevOps组织中运行良好的产品开发框架一样。因此，SRE是软件开发整体DevOps方法的一部分。说到这里，我要说，谢谢你。我期待着在问答环节回答你们的问题。

我将为您留下下一步探索的资源。2022世界杯阿根廷预选赛赛程首先是今年DevOps报告的日期，您可以从bit.ly/dora-sodr下载。去那儿吧。谷歌，找到我展示的所有书籍以及其他一些文章和资源的免费访问。2022世界杯阿根廷预选赛赛程我诚挚地邀请你们参加可靠性讨论小组。ly/r9y-讨论，我主持每个月。这是一个关于可靠性工程的公开讨论的地方，我们可以分享什么是有效的，什么是无效的。我希望在那里见到你。谢谢你！