10 KiB
什么是SRE（网站可靠性工程）？
网站可靠性工程师是近来越来越多看到的一个职位。它是什么意思？它来自哪里？让我们从 Google SRE 团队来学习。
这里有一篇由 Niall Richard Murphy、Jennifer Petoff、Chris Jones、Betsy Beyer 编辑一篇来自网站可靠性工程的摘录。
网站可靠性工程也在11月7-10日在阿姆斯特丹举办的 O'Reilly Velocity 会议上有提到。
介绍
希望不是一种策略。
传统的 SRE 说
一个公认的事实是系统不会自己。 那么，一个特定系统的复杂大规模系统_应该_怎么运行呢？
sysadmin 服务管理方法
sysadmin服务管理模型有几个优点。对于决定该如何运行和服务的公司而言，这种方法相对容易实现：它作为一个熟悉的行业范例，有很多例子可以从中学习和效仿。相关人才库已经广泛普及。有一系列现有的工具，软件组件（现成的或其他）和集成公司可用于帮助运行这些组装的系统，所以新手sysadmin团队不必重新发明轮子以及从头设计系统。
因此，传统运营团队及其在产品开发中的同行往往会发生冲突，最突出的是如何将软件发布到生产环境。在他们核心中，开发团队希望推出新功能，并看到它们被用户采纳。在_他们_的核心上，ops 团队希望确保服务在运行中不会中断。因为大多数中断是由某种变化引起的 - 新的配置、新的功能发布或者新的用户流量类型 - 这两个团队的目标基本上处于紧张状态。
两个团队都明白，以最可能的条款（“我们可以没有阻碍地在任何时间发布任何东西”以及“我们不想在系统工作后改变任何东西”）来表达他们的利益是不可接受的。因为他们的词汇和风险假设都不同，两个团体经常采用熟悉斗争形式来提高他们的利益。 ops 团队试图通过发布介绍和提高门槛来保护运行中的系统免受更改的风险。例如，发布审查可能包含对_每个_问题的显式审查，这些问题过去都_曾经_引起过服务中断 - 它可能是一个任意长度的列表，并且不是所有元素都提供相等的值。开发团队很快学会了如何回应。他们有较少的“发布”和更多的“标志翻转”、“增量更新”或“cherrypicks”。他们采取诸如分割产品功能的策略，以便更少的功能受到发布审查。
Google 服务管理的方法：网站可靠性工程
冲突不是提供软件服务的必然部分。Google 选择以不同的方式运行我们的系统：我们的网站可靠性工程团队专注于雇佣软件工程师来运行我们的产品，并创建系统来完成那些本来由sysadmins手动完成的工作。
什么是网站可靠性工程，是如它在谷歌定义的那样么？我的解释很简单：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 团队专注于工程。没有恒定的工程，运维工作增加，团队将需要更多的人来上工作量。最终，传统的以 ops 为中心的团队与服务规模呈线性关系：如果服务支持的产品成功，运维工作将随着流量而增长。这意味着雇用更多的人一遍又一遍地完成相同的任务。
为了避免这种命运，负责管理服务的团队需要写代码否则就会被工作淹没。因此，Google 设置了一个 “ops” 工作如 ticket、紧急呼叫、手动任务最多只占 50% SRE 工作的上限。此上限确保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 的特定实现。
作者简介：Benjamin Treynor Sloss 创造了“网站可靠性工程”一词，他自2003年以来一直负责 Google 的全球运营、网络和生产工程。截至2016年，他管理着全球范围内一个大约4000名软硬件和网络工程师团队。
via: https://www.oreilly.com/ideas/what-is-sre-site-reliability-engineering
作者：Benjamin Treynor 译者：geekpi 校对：校对者ID