Google SRE网站可靠性工程

网站可靠性工程师是近来越来越多看到的一个职位。它是什么意思？它来自哪里？让我们从 Google SRE 团队来学习。本文为 Niall Richard Murphy、Jennifer Petoff、Chris Jones、Betsy Beyer 编辑的 《网站可靠性工程》 一书的摘录

SRE（ 网站可靠性工程）在 11 月 7-10 日在阿姆斯特丹举办的 O’Reilly Velocity 会议上也有提到。
介绍

希望不是一种策略。

—— 传统的 SRE 如是说

一个公认的事实是系统不会自己运行。 那么，一个系统 — 尤其是复杂大规模系统 — 应该怎么运行呢？
系统管理员的服务管理方法
以前，公司雇用系统管理员来运行复杂的计算系统。

系统管理员（或者称为 sysadmin）这种方式包括整合现有软件组件，使之互相协作来完成一个服务。系统管理员的任务是运行服务，响应事件，并在事件发生时进行更新。随着系统复杂度的增长和流量的增长，事件和更新也相应增长，导致管理员团队也越来越庞大才能完成更多的工作。由于系统管理员的角色需要的技能与产品开发人员有很大不同，开发和系统管理员被分为不同的团队：“开发”和“运维”。

系统管理员模式的服务管理有几个优点。对于决定该如何运行和服务的公司而言，这种方法相对容易实现：它作为一个已被人们所熟悉的行业范例，有很多例子可以从中学习和效仿。相关人才库已经广泛普及。有一系列现有的工具，软件组件（现成的或其他）和集成公司可用于帮助运行这些组装的系统，所以新手系统管理团队不必重新发明轮子以及从头设计系统。

此方式将公司开发和运维分离，也有一些缺点和困难。主要有两类：直接代价和间接代价。

直接代价很显而易见了。利用依靠手工干预来进行变更管理和事件处理的团队进行服务管理，当服务和/或流量增长时，成本是很昂贵的，因为团队随着系统负载的增长也在相应增长。

开发/运维分离的间接代价可能不那么明显，但常常比直接代价还要昂贵。代价来自于两个团队背景，技术，激励都非常不同。他们使用不同的词汇来描述所面临的情境；对技术方案的风险和可能性他们持不同的假设；对产品稳定性的目标级别也会有不同的争议。团队的分离很容易导致不只是激励的不同，还有沟通、目标的不同，以及最终，信任和尊重的分离。这是一种恶性循环。

因此，传统运营团队及其在产品开发中的同行往往会发生冲突，最突出的是如何将软件发布到生产环境。在开发团队的核心上，他们希望推出新功能，并看到它们被用户采纳。在运维团队的核心上， 他们希望确保服务在运行中不会中断。因为大多数中断是由某种变化引起的 – 新的配置、新的功能发布或者新的用户流量类型 – 这两个团队的目标基本上处于紧张状态。

两个团队都明白，以最想要的条款（“我们可以没有阻碍地在任何时间发布任何东西”以及“我们不想在系统工作后改变任何东西”）来表达他们的利益是不可接受的。因为他们的词汇和风险假设都不同，两个团体经常采用常见的斗争形式来提高他们的利益。 运维团队试图通过提高发布和变更门槛来保护运行中的系统免受更改的风险。例如，发布审查可能包含对每个问题的显式审查，这些问题过去都曾经引起过服务中断 – 它可能是一个任意长度的列表，并且不是所有检查元素都一样重要。开发团队很快学会了如何回应。他们通过较少的“发布”和更多的“功能切换”、“增量更新”或 “选择性失明”来规避。他们采取诸如分割产品功能的策略，以便更少的功能受到发布审查。
Google 的服务管理方法：网站可靠性工程
冲突不是提供软件服务的必然部分。Google 选择以不同的方式运行自己的系统：我们的网站可靠性工程团队专注于雇佣软件工程师来运行我们的产品，并创建系统来完成那些本来由系统工程师手动完成的工作。

什么是网站可靠性工程，是如它在谷歌定义的那样么？我的解释很简单：SRE 是当你要求一位软件工程师设计一个运维团队时所发生的结果。当我在 2003 年加入 Google 并负责运行一个由 7 名工程师组成的“生产团队”时，那时我工作的全部都是软件工程。所以我以自己是一名 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 团队在其计划中有足够的时间使服务稳定及可操作。50% 是上限；随着时间的推移，除了自己的设备，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 的特定实现。