尽管站点可靠性工程师 (SRE) 角色近年来变得越来越普遍，但许多人——甚至在软件行业——都不知道它是什么或做什么。本文旨在通过解释什么是 SRE，它与 DevOps 有何关系，以及当您的整个工程组织可以容纳在一家咖啡馆时，SRE 如何工作来消除这种疑虑。
什么是站点可靠性工程？
站点可靠性工程：Google 如何运行生产系统，由一群 Google 工程师撰写，被认为是关于站点可靠性工程的权威书籍。 Google 工程副总裁 Ben Treynor Sloss 在 2000 年代初期 创造了这个术语。 他将其定义为：“当你要求软件工程师设计一个运维职能时会发生什么。”
系统管理员编写代码已经很长时间了，但在过去的许多年中，一个系统管理员团队手动管理着许多机器。 过去，“许多”可能只有几十个或几百个，但是当你扩展到数千或数十万个主机时，你根本无法继续投入人力来解决问题。 当机器数量变得如此之大时，显而易见的解决方案是使用代码来管理主机（以及在其上运行的软件）。
此外，直到最近，运维团队才与开发人员完全分开。 每个工作的技能组合都被认为是完全不同的。 SRE 角色试图将这两项工作结合在一起。
在我们深入研究是什么造就了一个 SRE 以及 SRE 如何与开发团队合作之前，我们需要了解站点可靠性工程如何在 DevOps 范例中工作。
站点可靠性工程和 DevOps
站点可靠性工程的核心是 DevOps 范例的实现。似乎有很多方法可以 定义 DevOps。 传统的模型是将开发（“devs”）和运维（“ops”）团队分开，导致编写代码的团队不对客户开始使用时的代码运行情况负责。 开发团队会将代码“扔过墙”给运维团队进行安装和支持。
这种情况可能导致大量的功能失调。 开发和运维团队的目标始终处于对立状态——开发人员希望客户使用“最新和最棒”的代码，但运维团队希望系统稳定，并且尽可能少地进行更改。他们的前提是任何更改都可能导致不稳定，而没有更改的系统应继续以相同的方式运行。 （请注意，最大程度地减少软件方面的更改并不是防止不稳定的唯一因素，这一点很重要。例如，如果您的 Web 应用程序保持完全相同，但客户数量增长了 10 倍，则您的应用程序可能会以多种不同的方式崩溃。）
DevOps 的前提是通过将这两个不同的工作合并为一个，从而消除争论。 如果“dev”希望始终部署新代码，则他们必须处理新代码造成的任何后果。正如亚马逊的 Werner Vogels 所说，“你构建它，你运行它”（在生产中）。 但是开发人员已经有很多事情要担心了。 他们不断被推动为其雇主的产品开发新功能。 要求他们了解基础设施，包括如何部署、配置和监视他们的服务，可能对他们要求有点过高。 这就是 SRE 的用武之地。
开发 Web 应用程序时，通常有很多人参与。 有用户界面设计师、图形设计师、前端工程师、后端工程师以及一大堆其他专业人员（取决于所使用的技术）。 要求包括如何管理代码（例如，部署、配置、监视）——这些都是 SRE 的专业领域。 但是，正如为应用程序开发精美外观的工程师可以从了解后端工程师的工作中受益（例如，如何从数据库中获取数据），SRE 了解部署系统的工作方式以及如何使其适应该特定代码库或项目的特定需求。
因此，SRE 不仅仅是“会编码的运维人员”。 而是，SRE 是开发团队的另一位成员，他们拥有一套不同的技能，尤其是在部署、配置管理、监视、指标等方面。 但是，正如为应用程序开发精美外观的工程师必须知道如何从数据存储中获取数据一样，SRE 并非单独负责这些领域。 整个团队共同努力交付一个可以轻松更新、管理和监视的产品。
当团队实施 DevOps 但意识到他们对开发人员的要求过高，并且需要一个专门人员来处理运维团队过去处理的工作时，自然会需要 SRE。
SRE 在初创公司中的工作方式
当有数百名员工时，这很棒（更不用说当你的规模像 Google 或 Facebook 时）。 大型公司拥有 SRE 团队，这些团队被拆分并嵌入到每个开发团队中。 但是初创公司没有这些规模经济，工程师通常身兼数职。 那么，在一家小公司中，“SRE 的帽子”应该放在哪里呢？ 一种方法是完全采用 DevOps，并让开发人员负责 SRE 在一家大型公司中执行的典型任务。 另一方面，你聘请专家——也就是 SRE。
尝试将 SRE 的帽子戴在开发人员头上的最明显的优势是，随着团队的成长，它可以很好地扩展。 此外，开发人员将了解应用程序的所有怪癖。 但是，许多初创公司使用各种 SaaS 产品来支持其基础设施。 最明显的是基础设施平台本身。 然后，你添加指标系统、站点监视、日志分析、容器等等。 虽然这些技术解决了一些问题，但它们也增加了额外的复杂性成本。 除了应用程序使用的核心技术（例如，语言）之外，开发人员还需要了解所有这些技术和服务。 最后，掌握所有这些技术可能会让人不知所措。
另一种选择是聘请专家来处理 SRE 工作。 他们的职责是专注于部署、配置、监视和指标，从而腾出开发人员的时间来编写应用程序。 缺点是 SRE 必须在多个不同的应用程序之间分配时间（即，SRE 需要支持整个工程部门的各种应用程序）。 这可能意味着他们可能没有时间来深入了解任何应用程序； 但是，他们将能够看到所有不同的部分如何组合在一起。 这种“30,000 英尺的视角”可以帮助确定整个系统中需要修复的薄弱环节的优先级。
我忽略了一个关键信息：你的其他工程师。 他们可能非常渴望了解部署的工作方式以及如何以最佳方式使用指标系统。 此外，招聘 SRE 并非易事。 你正在寻找系统管理员技能和软件工程技能的结合。（我特别强调软件工程师，而不是仅仅“能够编写代码”，因为软件工程不仅仅涉及编写代码[例如，编写良好的测试或文档]。）
因此，在某些情况下，“SRE 的帽子”戴在开发人员头上可能更有意义。 如果是这样，请注意代码和基础设施（SaaS 或内部）的复杂程度。 在某个时候，任何一端的复杂性都可能会推动更多的专业化。
结论
SRE 团队是在初创公司中实施 DevOps 范例的最有效方法之一。 我已经看到了一些不同的方法，但我相信在你的初创公司中（尽早）聘请一名专门的 SRE 将腾出开发人员的时间，让他们专注于他们特定的挑战。 SRE 可以专注于改进工具（和流程），从而提高开发人员的效率。 此外，SRE 将专注于确保你的客户拥有可靠且安全的产品。
Craig Sebenik 将在 10 月 29 日至 31 日在田纳西州纳什维尔举行的 LISA18 会议上介绍 初创公司的 SRE（和 DevOps）。
2 条评论