什么是SRE(Site Reliability Engineering)？

从根本上说，当您要求软件工程师设计操作功能时会发生这种情况。软件工程师倾向于使用软件来解决历史上手工解决的问题。因此，当需要创建一个正式的团队来完成这项运营工作时，很自然地将“一切都视为软件问题”的方法与之一起运行。

因此，SRE从根本上开展了一项历史上由运营团队完成的工作，但使用具有软件专业知识的工程师，并依赖于这些工程师本身就倾向于并且有能力替代人工自动化的事实。

最重要的是，在谷歌，我们有一系列参与规则，以及SRE团队如何与他们的环境互动的原则 - 不仅是生产环境，还包括开发团队，测试团队，用户等等。上。这些规则和工作实践有助于我们继续主要从事工程工作而不是运营工作。

这如何反映在SRE团队的日常工作和责任中？

通常，SRE团队负责可用性，延迟，性能，效率，变更管理，监控，紧急响应和容量规划。

今天许多运营团队都有类似的角色，有时没有我发现的一些部分。但SRE的做法却截然不同。这是由于几个原因造成的。

排名第一的是招聘。我们聘请具有软件开发能力和倾向性的工程师。

对于SRE，软件工程师是对编程语言，数据结构和算法以及性能有足够了解的人，能够编写有效的软件。至关重要的是，虽然软件可能在启动时完成任务，但即使任务增长，它也必须高效地完成该任务。

通常情况下，我们雇佣大约50-50名拥有更多软件背景的人和拥有更多系统背景的人。这似乎是一个非常好的组合。

在我们的招聘过程中，我们会检查即将通过Google SWE栏的人员，以及谁还有一套对我们有用的补充技能。网络工程和Unix系统管理是我们看到的两个常见领域; 还有其他人。一个拥有良好软件技能但可能没有专业开发经验的人，他也是网络工程或系统管理方面的专家 - 我们雇用这些人进行SRE。通常，我们雇佣大约50-50名拥有更多软件背景的人和拥有更多系统工程背景的人。这似乎是一个非常好的组合。

多年来我们一直认为这个招聘规则是不变的，即使在很难找到人的时候也是如此，为了增加招聘量，放松这个准则的压力很大。我们从未改变过这方面的标准。我认为，这对该集团来说非常重要。因为你最终得到的是一个团队，他们从根本上不会接受手工一遍又一遍地做事，而且还有一个与开发组织其他人有很多相同学术和知识背景的团队。这确保了SRE和SWE之间的相互尊重和相互融合。

通常在操作角色中看到的与工程角色相反的事情之一是，不仅在职责方面存在鸿沟，而且在背景和理解方面存在鸿沟，最终还是尊重。对我来说，这是一种病态。

在Google之外，我们经常观察到SWE和运营团队之间没有平等的尊重，这与他们经常有不同做法的事实相结合。这就是我们最终得到当今行业中存在的模型的方式，SWE团队在这些模型中写了一些东西并将其扔到了运营团队的墙上，然后运营团队试图让它运作，并且不能，并将其丢回，等等。

在这种背景下，有趣的是，还要考虑使SRE成为现实的组织差异，而不仅仅是个人的工作习惯。

SRE的一个关键特征是它们可以在SRE团队之间自由转移，并且该团队足够大，可以拥有充足的移动性。此外，SWE可以自由转到SRE。但是，一般来说，他们没有。

这种行动自由的必要条件是一般的SWE，恰好是SWE的SRE，以及SRE中的系统工程师之间的补偿平等。他们所有的团体都遵循相同的绩效标准，相同的产出标准，相同的专业标准。SWE和SRE SWE团队之间有免费转移。关于SRE组中任何发现他们正在处理项目或“糟糕”系统的人的自由和轻松迁移的关键点在于它是一个极好的威胁，为开发团队提供了一个不构建系统的激励跑得太可怕了。

这是我一直使用的威胁。说，“看，基本上，我们只雇用工程师进入SRE。如果你建立一个操作灾难的系统，SRE将会离开。我会让他们。” 当他们离开并且团队降到临界质量以下时，我们会将运营责任交给您，即开发团队。

在谷歌，我们已将这种回应制度化，包括生产准备评估（PRR）。PRR通过在接受之前检查系统及其特征，以及通过共同承担责任来帮助我们避免陷入这种情况。这是我所知道的最简单，最有效的方法，可以消除任何关于现实世界中系统的幻想。它还为开发团队提供了一个巨大的激励，使其能够构建一个运行负载较低的系统。

获得正确的激励措施非常重要。为此，为什么SRE很稀缺很重要？

我们将分配SRE，以便他们做最好的事情。

在早期，我们没有太多的选择方式。我们不能像对它们的需求一样快地雇用SRE，因此总是存在稀缺性。我通过简单地说“我们将SRE分配到他们将要做的最好的地方”来利用它。仅运营项目的投资回报率相对较低。我没有把SRE放在那些上面。还有其他项目更加成熟和成熟，这些项目的SRE将具有更高的边际效益。从历史上看，我们所看到的是一个SRE将取代两个从事相同工作的SWE，部分原因是它们往往是生产相关技术和支持模型的专家。粗略地说，这是帮助SRE需求保持高位的方程式。

SRE如何确保一旦启动，就能正确维护？

我们非常关心保持SRE的工程功能，因此我们的经验法则是SRE团队必须至少花费50％的时间进行开发。

SRE每季度进行一次服务评估，旨在衡量团队的运营工作量。您可以习惯这种工作负载，并将大部分时间花在操作上。评论是外部检查，以确保如果您进入该模式，我们会注意到并采取纠正措施，这有时可能意味着解散团队！

我们非常关心保持SRE的工程功能，因此我们的经验法则是SRE团队必须至少花费50％的时间来实际开发。那么你如何执行呢？首先，你必须测量它。在测量之后，您确保团队在开发工作上花费不到50％的时间用于重定向或解散。

我不知道工业同类工作的50％分工。

确实; 就谷歌的SRE与其他理念上的“SRE”工作之间的区别而言，这将是了解你所涉及的内容的简单方法之一。因此，当您与其他小组进行面谈，并与团队中您可能会加入的人员交谈时，请尝试了解他们最近编写了多少行代码，以及他们的工作时间花在了多少上？编写代码。如果他们的答案是“我上个月写了三个函数”，那么，你有答案。

在Google SRE中，无论系统或软件背景如何，我们都会密切关注每个人的促销率，并将其与整体Eng and Eng Software Engineering促销价格进行比较，以确保它们在统计上相同。<u>他们是</u>。

您可以问的另一个问题是，他们是在SRE团队内部还是在SRE团队外部工作的资深开发人员？他们多久经常升职？他们的推广率是否与SWE团队相同？

在Google SRE中，无论系统或软件背景如何，我们都会密切关注每个人的促销率，并将其与整体Eng and Eng Software Engineering促销价格进行比较，以确保它们在统计上相同。他们是。

你能谈谈运营和发展小组中的一些更经典的冲突吗？

开发团队的动机是启动功能并让用户采用该产品。而已！具有运维职责的团队的动机是确保事物不会在他们的手表上爆炸。所以这两个人肯定会处于紧张状态。

业界的一个典型冲突是，运营团队提出了一个长清单，开发团队必须经过这些清单才能说出支持的内容。这是一个重要的冲突，因为它是你清楚地看到两个群体的激励实际上是不同的地方之一。剥离其他所有东西时，开发团队的动机就是启动功能并让用户采用该产品。而已！如果你剥夺了其他所有东西，那么具有运营职责的团队的动机就是确保事情不会在他们的手表上爆炸。所以这两个人肯定会处于紧张状态。你是如何解决这个问题的？

业务或产品必须确定系统的可用性目标。完成后，减去可用性目标就是我们所说的<u>错误预算</u>。

理想情况下，我们会花费所有不可用预算来承担我们推出的产品的风险，以便快速启动它们。

我们在SRE中的解决方案 - 它运行得非常好 - 是一个错误预算。错误预算源于这一基本观察：100％是基本上所有事情的错误可靠性目标。也许心脏起搏器是一个很好的例外！但是，一般而言，对于您可以想到的任何软件服务或系统，100％不是正确的可靠性目标，因为没有用户可以区分100％可用的系统，比如99.999％可用。因为通常在用户和正在运行的软件服务之间存在许多其他因素，所以其他所有可能出错的噪音都会丢失边际差异。

如果100％是系统的错误可靠性目标，那么系统的正确可靠性目标是什么？我建议这是一个产品问题。这根本不是技术问题。这是一个问题，考虑到用户支付的金额，无论是直接还是间接，以及他们的替代品是什么，用户会对此感到满意。

业务或产品必须确定系统的可用性目标。一旦你完成了这个，减去可用性目标就是我们所说的错误预算; 如果99.99％可用，则意味着它不可用0.01％。现在我们被允许有0.01％的不可用性，这是一个预算。我们可以把它花在任何我们想要的东西上，只要我们不超支它。

那么我们想要在错误预算上花多少钱？开发团队希望启动功能并获得用户。理想情况下，我们会花费所有不可用预算来承担我们推出的产品的风险，以便快速启动它们。这个基本前提描述了整个模型。一旦你以这种方式概念化SRE活动，那么你说，哦，好吧，所以有分阶段推出或1％实验的东西，所有这些都是让我们的不可用预算少于风险的方法，以便我们可以采取我们推出的机会更多，因此我们可以更快地推出。听起来不错。

这种方法还有另一个好的结果，即如果服务本身就位于那里并抛出错误，你知道，.01％的时间，你将整个不可用预算都用在什么东西上。因此，您在开发领域和SRE团队中都有动力来提高服务的本地稳定性，这样您就可以节省预算，例如功能发布。

另一个关键优势是SRE不再需要对开发团队正在做什么做出任何判断。SRE测量和执行，但我们不评估或判断。我们的看法是“只要您测量它的可用性高于您的服务水平目标（SLO），您显然做得很好。您正在做出关于风险有多大的准确决策，您应该运行多少实验等等。所以你要把自己踢出去，发动任何你想要的东西。我们不会干涉。“ 这一直持续到你打破预算为止。

一旦你预算完毕，我们就不知道你的测试情况如何。开发团队和SRE团队之间可能存在巨大的信息不对称关于功能，风险程度，测试程度，工程师是谁等等。我们通常不知道，我们猜测也不会有成效。所以我们甚至都不去尝试。我们可以恢复可用性级别的唯一可靠方法是停止所有启动，直到您获得了不可用性。这就是我们所做的。当然，这种情况很少发生，但确实发生了。我们只是冻结启动，而不是P0错误修复 - 这些东西本身代表了改进的可用性。

这有两个很好的效果。其一，SRE并不在这场猜测开发团队正在做什么的游戏中。因此，不需要对抗关系或信息隐藏或其他任何东西。那正是你想要的。

另一件事，也就是我没想到但事实证明非常重要的一点是，一旦开发团队发现这就是游戏的运作方式，他们就会自我警察。通常，对于我们在Google运营的那种系统，它不是一个开发团队; 它是一群致力于不同功能的小型开发团队。如果从个体开发者的角度考虑这个问题，这样的人可能不会想要一个测试不佳的功能来破坏错误预算并阻止一周后出现的酷炫发布。鼓励开发人员找到团队的总经理，以确保在发布之前完成更多测试。通常，开发团队内部的信息不对称程度远远低于开发团队和SRE团队之间的信息不对称性，

SRE的道德权威说不，目前在谷歌已经确立。

这至关重要。

外部组织如何启动SRE功能有助于获得此权限？

道德权威是一个物理问题。确定目标SLO的前期至关重要，因为这是您同意测量服务的标准。那时SRE只是衡量和执行我们已经同意的事情。非常方便的位置。

就你如何实际产生道德权威而言，这很容易。您，开发团队已经告诉我们这项服务的SLO必须是什么，现在我们低于它。我们无能为力; 这是一个物理问题。你现在无法改变主意。我们已经确定这个数字符合用户的最佳利益 - 目前，数据清楚地表明我们低于这个数字。所以我们必须等到我们回到可用性级别。您可以使用这段等待时间来确保您的下一个版本不会再次爆炸。

我们来谈谈SRE团队的生命周期。在生命周期中，参与度如何变化？

今天通常采用的方式是通过能力成熟度 模型。有很多，他们都大多说同样的事情。他们都从基本问题开始，你知道你作为一个团队在做什么吗？或者你只有一个人的集合，每个人都知道问题空间的一部分？大多数球队都是从那时开始的; 你有一群人，每个人都知道一些事情，当你需要做某事时，你会尝试让具有足够综合专业知识的人能够完成你所需要的。

通过这种方式，当服务出现问题时，结果取决于人员是谁。这就是我们所说的混乱局面。随着团队的成熟，你会从混乱变为定义; 也就是说，你开始说“这是我们做的标准事情，并且它们也有记录，以便团队中的任何人都能做到。” 您不再依赖于碰巧在那里的个人的随机选择。从那里，您可以进行优化，实际测量它们。既然你已经说过，“这就是应该发生的事情”，你看看实际发生了什么，并将它与应该发生的事情进行比较。然后，您可以更改说明或更改人们的行为方式或两者，并永久重复或直到完成。

因此，任何随着服务规模线性扩展人数的事情都将失败。

我们在季度服务评论（前面讨论过）中衡量的一个因素是SRE的环境是什么样的。无论他们说什么，他们有多开心，他们是否喜欢他们的开发对手等等，关键是要实际衡量他们的时间。这有两个重要原因。一，因为你想尽快发现团队已经把他们的大部分时间花在了运营工作上。您必须在此时停止并更正它，因为每个Google服务都在增长，而且通常，它们的增长速度都超过了人数的增长速度。因此，任何随着服务规模线性扩展人数的事情都将失败。如果您将大部分时间花在操作上，那么这种情况就无法自我纠正！你最终会遇到危机，你现在把所有的时间都用在了运营上，但仍然不够，然后服务要么停机或者出现另一个重大问题。

第二个是，这是一个工程团队。如果你看一下团队​​中的人，他们的职业生涯和他们的目标不会通过绕过关票或配置资源来进一步发展。他们拥有他们和经理想要发展的工程技能和专业知识。这是开发的，因为他们是软件工程师，通过编写软件并与更高级，经验丰富，能力强的人合作，并学习。所以你必须确保他们真的在做那些事情。

让我们讨论监督，一个核心的SRE责任。你能谈谈SRE和监控背后的哲学吗？

一种经典的监控方式是，你有一些看到价值或条件或其他东西的东西，当它看到有趣的东西时，会吐出一封电子邮件。这是我所知道的最常见的监控。但是电子邮件不是正确的方法; 如果你要求人阅读电子邮件并决定是否需要做某事，那你就犯了一个错误。答案应该是，人类永远不会在警报领域解释任何东西。解释由我们编写的软件完成。我们只是在需要采取行动时得到通知。

因此，在我看来，只有三种有效的监控输出。有警报，说人类现在必须采取行动。正在发生或即将发生的事情，人类需要立即采取行动来改善这种状况。

第二类是门票。人类需要采取行动，但不是立即采取行动。您可能有几个小时，通常是几天，但需要一些人为操作。

第三类是记录。没有人需要查看此信息，但它可用于诊断或法医目的。期望是没有人读它。

我从未见过监测输出不属于这三类之一。我经常看到人们在实施监控时会犯错，这样他们就会生成日志，但会将其视为票证。这是一个很大的错误。你通常发现它的一个地方是：“哦，是的，我们不得不花费大量时间来审查我们的监控系统吐出的所有这些东西。” 好吧，不要那样做。这不会扩展，因为你有更多的用户和更多的实例，这些东西的数量将增加，质量将下降。您需要开发一个系统，无论是监视配置还是解析器或其他什么，您需要编写一个系统，将该输出转换为三个类别之一。

因此，监控可以帮助您注意事情何时失败，还可以帮助您更快地解决问题？

是的。更一般地说，当我们谈论整体系统可用性时，它有两个基本组件。失败之间有平均时间 - 事情停止工作的频率。然后有平均时间进行修复 - 一旦它停止工作，需要多长时间才能修复它？

这两个功能的一些功能是您的可用性。从中脱颖而出，有两种方法可以建立一个高度可用的系统。（当然，如果数字堆积起来，这些极端之间的任何地方也都可以。）你可以很少失败，或者当它失败时你能够很快地修复它。Google因其极高的可用性而享有当之无愧的声誉。而SRE得到的方式就是两者兼而有之。

在第一级 - 这是我们花费大部分时间的地方 - 我们构建了能够容忍失败的系统。我们在优雅退化以及深度防御方面谈论这一点。它们是同一事物的两种不同变体。事情会失败。重要的是，当事情发生故障时，用户体验不会有意义地降级，让您有足够的时间来修复它们，而不会出现用户可见的问题。因此，对于大多数故障，MTTR是毫秒，因为它是自动化的。通常，没有人会在不到两分钟的时间内对出错的事情作出反应。因此，如果您想要在没有用户影响的情况下失败的事情，获得​​它们的最佳方法是自动修复它们。我们通过深度防御来做到这一点。

系统的所有不同层都设计为容忍点故障，甚至是数据中心大小的点故障，而不会影响用户体验。一切都是自动发生的。没有人抬起手指，没有人经常需要知道它。它刚刚发生。这是深度防守。

优雅降级是指在不完全崩溃的情况下容忍失败的能力。例如，如果用户的网络运行缓慢，环聊视频系统将降低视频分辨率并保留音频。对于Gmail，速度较慢的网络可能意味着无法加载大型附件，但用户仍可以阅读其电子邮件。所有这些都是自动回复，无需人工执行任何操作即可为您提供高可用性。

人类必须做某事的情况怎么样？

一旦人类实际上必须做某事，那么MTTR很重要。特别是，“R”部分并不意味着人类已经获得了页面或者人类已经对页面进行了分类，或者甚至是人类已经使用键盘来做某事。这是人类正确评估情况并采取适当的纠正措施，而不是诊断错误或采取无效措施。

在其他行业，您有操作手册; 我们有运营就绪演习，这就是我们如何确保人们知道如何正确应对各种紧急情况。然而，如果你让一群软件工程师在一起并说“我们将要进行操作准备演练”，那么指令膜将会滑落到他们的眼睛上，无论你是否知道，这将有效地成为谈话的终点是不是。解决这个问题的一种可能方法是从角色扮演游戏中获取灵感。软件中有很多人在某个时刻玩过角色扮演游戏，其余人一般都至少听过这些游戏。

因此，虽然没有人愿意进行战斗准备演习，但每个人都想参加“不幸之轮”游戏。在这种背景下，不幸之轮只不过是一个统计调整的选择机制，用于挑选灾难，其次是角色扮演，其中一个人扮演地下城主人的角色 - 在这种情况下，“系统” - 和另一个人扮演待命工程师的角色。文档人员会收听，我们会记录场景中发生的事情，随叫随到的工程师说要做什么，然后我们将这与他们实际应该做的事情进行比较。然后，我们将调整我们的剧本 - 我们的操作手册术语 - 为理想的答案提供额外的信息或背景。

使SRE在运营领域发挥作用的部分原因是，您可以在紧急情况下对人们进行正确的响应，直到他们不必考虑它为止。我们以一种文化兼容的方式做到这一点：如果你看过SRE团队这样做，人们真的很期待这些练习，因为这是一个展示你所知道的东西的机会，而且很有趣。

我们谈到了SRE的一些责任，但不是全部。容量规划怎么样？

可以将需求预测和容量规划视为确保您对预测的未来需求有足够的防御深度。没有什么特别之处，除了大多数公司似乎没有这样做。

谷歌SRE和其他工作地点之间的另一个区别问题是，你在N + M运行你的服务是什么？一个常见的答案是“我不知道，因为我们从未评估过我们的服务能力是什么”。

他们可能不会这么说。但是，如果他们不能告诉你他们如何对他们的服务进行基准测试，以及他们如何衡量其对100％或130％的负载的响应，以及他们在高峰需求时有多少备用容量，那么他们就不知道了。在没有需求预测或容量规划的情况下，您可以预期频繁停机和大量紧急情况。

在传统模型中，IT是成本中心。它们基本上是关于防止损失，并且因为它们被视为成本中心，所以没有特别的动机去改变。在SRE模型中，我们有能力提高效率，扩展容量，并有助于提高产品的运行效率。在这个模型中，高级决策者的动机是什么？

因此，有两层激励措施可以提高效率。一个是SRE人数不是免费的。产品区域获得一定数量的人数。他们可以将它们花在开发者身上，也可以将它们花在SRE上。理论上，他们将在SRE上花费尽可能多的时间来获得最佳特征速度，同时满足他们的服务SLO。事实上，这实际上是我们希望他们在SRE上花多少钱 - 不多也不少。因此，这是他们对自己的SRE节俭的一种激励，同时也要小心他们的团队编写的代码，这样就不会产生很多SRE团队需要处理的工作。另外，如果您构建了错误的代码，那么所有优秀的SRE都会离开，您最终要么自己运行它，要么最好还有一个愿意冒险的初级团队。

第二点是，一旦您意识到容量对可用性至关重要，那么您就会意识到SRE团队必须负责容量规划，这意味着他们还必须负责配置和变更管理。因此，您可以根据服务的工作方式以及配置的方式获得利用率。因此，根据定义，SRE必须参与任何有关利用的工作，因为它们最终会控制供应。因此，通过密切关注您的配置策略，您可以获得非常大的总成本杠杆。

由于竞争环境的加剧，Google SRE是否遭受了损失？其他组织使用“SRE”一词怎么样？

一般来说，我们发现当人们离开其他组织时，他们通常会回来。目前，谷歌SRE与其他公司如何做的事情有所不同，我希望这些公司能够采用这些公司。这只是运行事物的好方法。

它当然需要大量的管理支持和依赖数据来做出决策。当问题进入高级管理层时，已经发生了几次; 在这种情况下，技术基础设施副总裁，最终，首席执行官。他们总是支持SRE团队，因此人们甚至不再费心去尝试了。您可能无法在所有公司获得这种管理支持。

关于差异化的话题，您是否熟悉术语“DevOps”？

我很熟悉。几年前我开始遇到它。它似乎描述了那些正在做与SRE类似的事情的人，并且确实让我们认为让开发人员加入我们的运营团队，我认为这非常好。

该术语不具有统一的定义。让开发人员与运营人员密切合作是个好主意。问题是它会影响运营，如果你购买SRE的方式，那就是错误的愿景。

是的，“DevOps”在实践中的意义似乎存在很多差异。在过去的15年中，我们已经迭代到当前的SRE定义，关键部分包括状态平价，自由转移，稀缺性，运营负载上限，错误预算等。我已经看到这个定义在谷歌的实践中非常有效，我希望我们会继续发展它，使这个角色对开发人员更具吸引力，同时使其更有效地运行高效，高可用性，大型系统。

在过去的15年中，我们已经迭代到当前的SRE定义。

我希望我们将继续发展它，使这个角色对开发人员更具吸引力，同时使其更有效地运行高效，高可用性，大规模的系统。