Google SRE - IT 服务管理：自动化运维

来源: https://sre.google/sre-book/introduction/ 抓取时间: 2026-07-21 16:24:23

第 1 章 - 引言

引言

作者：Benjamin Treynor Sloss6 编辑：Betsy Beyer

希望不是策略。 —— 传统 SRE 格言

系统不会自己运行，这是公认的事实。那么，一个系统——特别是大规模运行的复杂计算系统——应该如何运行？

系统管理员的服务管理方法

历史上，公司雇用系统管理员来运行复杂的计算系统。

这种系统管理员（sysadmin）方法涉及组装现有软件组件并部署它们协同工作以提供服务。然后，系统管理员负责运行服务并响应发生的事件和更新。随着系统复杂性和流量的增长，事件和更新相应增加，系统管理员团队也随之扩大以吸收额外的工作。因为系统管理员角色需要与产品开发人员截然不同的技能集，开发人员和系统管理员被分成独立的团队："开发"和"运维"或"ops"。

系统管理员的服务管理模型有几个优点。对于决定如何运行服务和配备人员的公司来说，这种方法相对容易实现：作为熟悉的行业范例，有很多可以学习和效仿的例子。相关的人才库已经广泛可用。大量现有工具、软件组件（现成或其他）和集成公司可以帮助运行这些组装的系统，因此新手系统管理员团队不必重新发明轮子并从头开始设计系统。

系统管理员方法以及伴随的开发/运维分裂有许多缺点和陷阱。这些大致分为两类：直接成本和间接成本。

直接成本既不微妙也不含糊。使用依赖手动干预进行变更管理和事件处理的团队运行服务，随着服务和/或服务流量的增长，成本会变得昂贵，因为团队的规模必然与系统产生的负载成比例。

开发/运维分裂的间接成本可能很微妙，但对组织来说往往比直接成本更昂贵。这些成本源于两个团队在背景、技能集和激励措施上截然不同的事实。他们使用不同的词汇描述情况；他们对技术解决方案的风险和可能性持有不同的假设；他们对产品稳定性的目标水平有不同的假设。群体之间的分裂很容易变得不仅仅是激励措施的分裂，而且是沟通、目标，最终是信任和尊重的分裂。这种结果是一种病态。

因此，传统的运维团队和产品开发团队经常陷入冲突，最明显的是关于软件可以多快发布到生产环境。核心上，开发团队想要发布新功能并看到它们被用户采用。核心上，运维团队想要确保在他们持有寻呼机时服务不会中断。因为大多数中断是由某种变化引起的——新配置、新功能发布或新类型的用户流量——两个团队的目标基本上是矛盾的。

两个群体都明白，以最直白的方式陈述他们的利益是不可接受的（"我们想在任何时候无障碍地发布任何东西"对比"系统一旦工作，我们就不想改变任何东西"）。而且因为他们的词汇和风险假设不同，两个群体经常诉诸熟悉的堑壕战形式来推进他们的利益。运维团队试图通过引入发布和变更门来保护运行系统免受变更风险。例如，发布审查可能包含对过去导致中断的每个问题的明确检查——这可能是一个任意长的列表，并非所有元素都提供同等价值。开发团队很快学会如何回应。他们减少"发布"，增加更多"标志翻转"、"增量更新"或"精选"。他们采用诸如分片产品之类的策略，以便更少的功能受到发布审查的约束。

Google 的服务管理方法：站点可靠性工程

冲突并非提供软件服务的必然部分。Google 选择以不同的方法运行我们的系统：我们的站点可靠性工程团队专注于雇用软件工程师来运行我们的产品，并创建系统来完成原本通常由系统管理员手动执行的工作。

在 Google 定义的站点可靠性工程到底是什么？我的解释很简单：SRE 就是当你要求软件工程师设计一个运维团队时会发生的事情。当我 2003 年加入 Google 并被要求管理一个由七名工程师组成的"生产团队"时，我之前的整个生活都是软件工程。所以我以如果我自己作为 SRE 工作会希望的方式设计和管理这个团队。该团队自此成熟为 Google 现在的 SRE 团队，仍然忠实于一位终身软件工程师构想的起源。

Google 服务管理方法的主要构建块是每个 SRE 团队的组成。总体而言，SRE 可以分为两大类。

50-60% 是 Google 软件工程师，或者更准确地说，是通过 Google 软件工程师标准程序雇用的人。其他 40-50% 是非常接近 Google 软件工程资格的候选人（即所需技能集的 85-99%），并且他们另外拥有一套对 SRE 有用但对大多数软件工程师来说罕见的技术技能。到目前为止，UNIX 系统内部和网络（第 1 层到第 3 层）专业知识是我们寻求的两种最常见的替代技术技能。

所有 SRE 的共同点是对开发软件系统来解决复杂问题的信念和才能。在 SRE 内部，我们密切跟踪两个群体的职业进展，并且迄今为止发现两个轨道的工程师在绩效上没有实际差异。事实上，SRE 团队有些多样化的背景经常产生巧妙、高质量的系统，这些系统显然是几种技能集合成的产物。

我们雇用 SRE 的方法的结果是，我们最终得到一个团队，他们（a）会很快对手动执行任务感到厌倦，并且（b）拥有编写软件来代替他们以前的手动工作所需的技能集，即使解决方案很复杂。SRE 最终也与开发组织的其他人共享学术和智力背景。因此，SRE 从根本上做了历史上由运维团队完成的工作，但使用具有软件专业知识的工程师，并寄希望于这些工程师天生既倾向于又有能力用软件设计和实现自动化来代替人力劳动。

按照设计，SRE 团队专注于工程至关重要。没有持续的工程，运维负载会增加，团队将需要更多人才能跟上工作量。最终，传统的以运维为中心的团队与服务规模线性扩展：如果服务支持的产品成功，运营负载将随流量增长。这意味着雇用更多人一遍又一遍地做同样的任务。

为了避免这种命运，负责管理服务的团队必须编码，否则就会被淹没。因此，Google 对所有 SRE 的总"运维"工作设定了 50% 的上限——工单、值班、手动任务等。这个上限确保 SRE 团队在他们的日程中有足够的时间来使服务稳定和可操作。这个上限是上限；随着时间的推移，任凭他们自己的设备，SRE 团队应该最终只有很少的运营负载，几乎完全从事开发任务，因为服务基本上自己运行和修复：我们想要的是自动的系统，而不仅仅是自动化的系统。在实践中，规模和新功能让 SRE 保持警惕。

Google 的经验法则是，SRE 团队必须将剩余 50% 的时间实际用于开发。那么我们如何强制执行这个门槛呢？首先，我们必须衡量 SRE 时间是如何花费的。有了这个衡量标准，我们确保确保持续花费不到 50% 的时间在开发工作上的团队改变他们的做法。通常这意味着将一些运维负担转移回开发团队，或者在不为团队分配额外运维责任的情况下为团队增加人员。有意识地保持运维和开发工作之间的这种平衡，使我们能够确保 SRE 有带宽从事创造性、自主的工程，同时仍然保留从运行服务的运维方面收集的智慧。

我们发现 Google SRE 运行大规模系统的方法有很多优点。因为 SRE 为了使 Google 系统自己运行而直接修改代码，SRE 团队的特点是快速创新和对变化的高度接受。这样的团队相对便宜——用面向运维的团队支持相同的服务将需要更多的人。相反，运行、维护和改进系统所需的 SRE 数量与系统规模成亚线性增长。最后，SRE 不仅规避了开发/运维分裂的功能失调，而且这种结构还改进了我们的产品开发团队：产品开发和 SRE 团队之间的轻松转移交叉培训整个团队，并提高了否则可能难以学习如何构建百万核分布式系统的开发人员的技能。

尽管有这些净收益，SRE 模型的特点是其自己独特的挑战集。Google 面临的一个持续挑战是雇用 SRE：SRE 不仅与产品开发招聘管道竞争相同的候选人，而且我们在编码和系统工程技能方面设定如此高的招聘标准，这意味着我们的招聘池必然很小。由于我们的学科相对较新且独特，关于如何构建和管理 SRE 团队的行业信息不多（尽管希望本书将在这方面取得进展！）。一旦 SRE 团队到位，他们可能非正统的服务管理方法需要强大的管理支持。例如，一旦错误预算耗尽就停止本季度剩余发布的决定，可能不会被产品开发团队接受，除非由他们的管理层强制执行。

DevOps 还是 SRE？

"DevOps"一词于 2008 年底出现在行业中，在撰写本文时（2016 年初）仍处于不断变化的状态。其核心原则——IT 职能在系统设计和开发的每个阶段的参与、对自动化与人力的高度依赖、将工程实践和工具应用于运维任务——与SRE 的许多原则和实践一致。可以将 DevOps 视为几个核心 SRE 原则对更广泛的组织、管理结构和人员的推广。可以等效地将 SRE 视为 DevOps 的特定实现，带有一些独特的扩展。

SRE 的原则

虽然工作流、优先级和日常运营的细微差别因 SRE 团队而异，但所有团队对其支持的服务都有一套基本责任，并遵守相同的核心原则。一般来说，SRE 团队负责其服务的可用性、延迟、性能、效率、变更管理、监控、应急响应和容量规划。我们已经编纂了 SRE 团队如何与他们的环境互动的规则和原则——不仅是生产环境，还有产品开发团队、测试团队、用户等等。这些规则和工作实践帮助我们保持对工程工作的关注，而不是运维工作。

以下部分讨论 Google SRE 的每个核心原则。

确保持久地专注于工程

如前所述，Google 将 SRE 的运维工作上限设定为其时间的 50%。他们的剩余时间应该用于将他们的编码技能用于项目工作。在实践中，这是通过监控 SRE 完成的运维工作量，并将过量的运维工作重定向到产品开发团队来实现的：将 bug 和工单重新分配给开发经理，[重新]将开发人员整合到值班寻呼机轮换中，等等。当运维负载降至 50% 或更低时，重定向结束。这也提供了一个有效的反馈机制，指导开发人员构建不需要手动干预的系统。当整个组织——SRE 和开发人员都——理解为什么安全阀机制存在，并支持因为产品不产生足够的运维负载而不需要它的目标时，这种方法效果很好。

当 SRE 专注于运维工作时，平均而言，每个 8-12 小时的值班班次最多应该收到两个事件。这个目标量给值班工程师足够的时间来准确、快速地处理事件，清理和恢复正常服务，然后进行事后复盘。如果每个值班班次定期发生两个以上的事件，问题就无法彻底调查，工程师会足够不堪重负，以防止他们从这些事件中学习。寻呼机疲劳的情况也不会随着规模的扩大而改善。相反，如果值班 SRE 每个班次持续收到少于一个事件，让他们待命就是浪费他们的时间。

所有重大事件都应撰写事后复盘，无论它们是否触发了寻呼；没有触发寻呼的事后复盘更有价值，因为它们可能指出明显的监控差距。这项调查应详细确定发生了什么，找出事件的所有根本原因，并分配行动来纠正问题或改进下次处理方式。Google 在无指责的事后复盘文化下运作，目标是揭露故障并应用工程来修复这些故障，而不是避免或最小化它们。

在不违反服务 SLO 的情况下追求最大变更速度

产品开发和 SRE 团队可以通过消除各自目标中的结构性冲突来享受富有成效的工作关系。结构性冲突存在于创新速度和产品稳定性之间，如前所述，这种冲突通常是间接表达的。在 SRE 中，我们将这种冲突置于前台，然后通过引入错误预算来解决它。

错误预算源于这样的观察：100% 基本上是所有事物的错误可靠性目标（起搏器和防抱死制动系统是值得注意的例外）。一般来说，对于任何软件服务或系统，100% 不是正确的可靠性目标，因为没有用户可以区分系统 100% 可用和 99.999% 可用之间的区别。用户和服务之间的路径中有许多其他系统（他们的笔记本电脑、他们的家庭 WiFi、他们的 ISP、电网……），这些系统加起来远低于 99.999% 的可用性。因此，99.999% 和 100% 之间的边际差异在其他不可用性的噪音中消失了，用户从添加最后 0.001% 可用性所需的巨大努力中没有获得任何好处。

如果 100% 是系统的错误可靠性目标，那么系统的正确可靠性目标是什么？这实际上根本不是技术问题——这是一个产品问题，应该考虑以下因素：

鉴于用户如何使用产品，他们会对什么级别的可用性感到满意？
对产品可用性不满意的用户有什么替代方案？
在不同的可用性级别下，用户对产品的使用情况会发生什么变化？

业务或产品必须确定系统的可用性目标。一旦确定了目标，错误预算就是 1 减去可用性目标。可用性为 99.99% 的服务有 0.01% 的不可用性。这允许的 0.01% 不可用性是服务的错误预算。我们可以把预算花在任何我们想要的东西上，只要我们不超支。

那么我们想如何花费错误预算呢？开发团队想要发布功能并吸引新用户。理想情况下，我们会把所有的错误预算都花在我们发布的东西上冒险，以便快速发布它们。这个基本前提描述了整个错误预算模型。一旦 SRE 活动在这个框架中被概念化，通过分阶段推出和 1% 实验等策略来释放错误预算可以优化以加快发布速度。

使用错误预算解决了开发和 SRE 之间激励措施的结构性冲突。SRE 的目标不再是"零中断"；相反，SRE 和产品开发人员的目标是花费错误预算来获得最大的功能速度。这种改变带来了所有的不同。中断不再是一件"坏事"——它是创新过程中预期的一部分，是开发和 SRE 团队管理而不是害怕的事件。

监控

监控是服务所有者跟踪系统健康和可用性的主要手段之一。因此，应该深思熟虑地构建监控策略。一种经典且常见的监控方法是监视特定值或条件，然后当该值超过或该条件发生时触发电子邮件警报。然而，这种类型的电子邮件警报不是有效的解决方案：一个需要人类阅读电子邮件并决定是否需要采取某种行动来响应的系统从根本上是有缺陷的。监控永远不应该要求人类解释警报领域的任何部分。相反，软件应该进行解释，只有当人类需要采取行动时才应该通知他们。

有三种有效的监控输出：

警报表示人类需要立即对正在发生或即将发生的事情采取行动，以改善情况。

工单表示人类需要采取行动，但不是立即。系统无法自动处理情况，但如果人类在几天内采取行动，不会造成损害。

日志没有人需要查看这些信息，但它被记录用于诊断或取证目的。期望是除非有其他事情提示他们这样做，否则没有人会阅读日志。

应急响应

可靠性是平均故障时间（MTTF）和平均修复时间（MTTR）的函数 [Sch15]。评估应急响应有效性最相关的指标是响应团队能多快将系统恢复到健康状态——即 MTTR。

人类增加延迟。即使给定系统经历更多实际故障，一个可以避免需要人工干预的紧急情况的系统，其可用性也会高于需要人工干预的系统。当人类是必要的时，我们发现提前在"剧本"中思考并记录最佳实践，与"即兴发挥"的策略相比，MTTR 大约提高了 3 倍。英雄式的万事通值班工程师确实有效，但有剧本武装的训练有素的值班工程师工作得更好。虽然没有剧本，无论多么全面，都不能替代能够即时思考的聪明工程师，但在响应高风险或时间敏感的寻呼时，清晰而全面的故障排除步骤和提示是有价值的。因此，Google SRE 依赖值班剧本，以及诸如"不幸之轮"7之类的练习，来帮助工程师准备好对值班事件做出反应。

变更管理

SRE 发现，大约 70% 的中断是由于实时系统的变更引起的。该领域的最佳实践使用自动化来完成以下任务：

实施渐进式推出
快速准确地检测问题
出现问题时安全回滚变更

这三项实践有效地最小化了暴露于不良变更的用户和操作的总数。通过将人类从循环中移除，这些实践避免了疲劳、熟悉/蔑视和对高度重复任务的注意力不集中等常见问题。结果，发布速度和安全性都提高了。

需求预测和容量规划

需求预测和容量规划可以被视为确保有足够的容量和冗余，以所需的可用性为预期的未来需求提供服务。这些概念没有什么特别之处，除了数量惊人的服务和团队没有采取必要的步骤来确保在需要时所需的容量到位。容量规划应该同时考虑有机增长（源于客户对产品的自然采用和使用）和无机增长（源于功能发布、营销活动或其他业务驱动的变化等事件）。

容量规划中有几个步骤是强制性的：

准确的有机需求预测，延伸超过获取容量所需的准备时间
将无机需求来源准确纳入需求预测
定期对系统进行负载测试，以将原始容量（服务器、磁盘等）与服务容量相关联

因为容量对可用性至关重要，所以 SRE 团队必须负责容量规划，这意味着他们也必须负责配置。

配置

配置结合了变更管理和容量规划。根据我们的经验，配置必须快速进行，并且只在必要时进行，因为容量很昂贵。这项工作也必须正确完成，否则容量在需要时就无法工作。添加新容量通常涉及启动新实例或位置，对现有系统（配置文件、负载均衡器、网络）进行重大修改，并验证新容量的性能和交付正确结果。因此，这是一个比负载转移风险更大的操作，负载转移通常每小时进行多次，必须相应地以额外的谨慎程度对待。

效率和性能

任何时候服务关心成本，资源的有效使用都很重要。因为 SRE 最终控制配置，它也必须参与任何关于利用率的工作，因为利用率是给定服务如何工作以及如何配置的函数。因此，密切关注服务的配置策略，从而关注其利用率，为服务的总成本提供了一个非常非常大的杠杆。

资源使用是需求（负载）、容量和软件效率的函数。SRE 预测需求，配置容量，并可以修改软件。这三个因素是服务效率的很大一部分（尽管不是全部）。

随着负载的增加，软件系统变得更慢。服务变慢等同于容量损失。在某个时候，变慢的系统停止服务，这对应于无限慢。SRE 进行配置以在特定响应速度下满足容量目标，因此对服务的性能非常感兴趣。SRE 和产品开发人员将（并且应该）监控和修改服务以提高其性能，从而增加容量并提高效率。8

开始的结束

站点可靠性工程代表了与管理大型、复杂服务的现有行业最佳实践的重大突破。最初源于熟悉——"作为一名软件工程师，这是我希望投入时间来完成一系列重复性任务的方式"——它已经变得更多：一套原则、一套实践、一套激励措施，以及更广泛的软件工程学科中的一个努力领域。本书的其余部分详细探讨了 SRE 之道。

6 Google 工程副总裁，Google SRE 创始人 7 参见灾难角色扮演。 8 关于这种协作在实践中如何工作的进一步讨论，请参见沟通：生产会议。

上一页第一部分 - 引言下一页第 2 章 - 从 SRE 视角看 Google 的生产环境

Google SRE - IT 服务管理：自动化运维

Google SRE - IT 服务管理：自动化运维

第 1 章 - 引言

引言

系统管理员的服务管理方法

Google 的服务管理方法：站点可靠性工程

DevOps 还是 SRE？

SRE 的原则

确保持久地专注于工程

在不违反服务 SLO 的情况下追求最大变更速度

监控

应急响应

变更管理

需求预测和容量规划

配置

效率和性能

开始的结束

评论 (0)