sre和devops_什么是SRE，它与DevOps有什么关系？

sre和devops

尽管近年来，站点可靠性工程师（SRE）的角色日渐盛行，但许多人（甚至在软件行业中）也不知道它是什么或做什么。 本文旨在通过解释SRE是什么，它与DevOps的关系以及在整个工程组织都可以容纳在咖啡店中时SRE的工作原理来澄清这一点。

什么是站点可靠性工程？

网站可靠性工程：由一组Google工程师撰写的Google如何运行生产系统 ，被视为有关网站可靠性工程的权威书籍。 Google工程副总裁Ben Treynor Sloss在2000年代初创造了这个词 。 他将其定义为：“当您要求软件工程师设计操作功能时，就会发生这种情况。”

系统管理员已经编写了很长时间的代码，但是多年来，一个系统管理员团队手动管理了许多计算机。 那时，“很多”可能是几十个或几百个，但是当您扩展到成千上万个主机时，您根本无法继续让人们陷入困境。 当计算机数量如此之多时，显而易见的解决方案是使用代码来管理主机（及其上运行的软件）。

另外，直到最近，运营团队还是与开发人员完全分离。 每个工作的技能被认为是完全不同的。 SRE角色试图将两个工作放在一起。

在深入研究SRE的构成要素以及SRE与开发团队的合作方式之前，我们需要了解站点可靠性工程在DevOps范式中的工作方式。

站点可靠性工程和DevOps

站点可靠性工程的核心是DevOps范例的实现。 似乎有很多定义DevOps的方法。 在传统模型中，开发（“ devs”）和运营（“ ops”）团队是分开的，导致编写该代码的团队不负责客户开始使用它时的工作方式。 开发团队将“把代码丢在墙上”给运营团队进行安装和支持。

这种情况会导致严重的功能障碍。 开发人员和操作人员团队的目标始终存在矛盾-开发人员希望客户使用“最新，最出色”的代码段，但是运营团队希望拥有一个稳定的系统，并且尽可能少地进行更改。 他们的前提是任何更改都可能导致不稳定，而没有更改的系统应继续以相同的方式运行。 （请注意，将软件方面的更改减到最少并不是防止不稳定的唯一因素，这一点很重要。例如，如果您的Web应用程序保持不变，但是客户数量增长了10倍，则您的应用程序可能会以许多不同的方式崩溃。 ）

DevOps的前提是，通过将这两个不同的作业合并为一个，可以消除争用。 如果“开发人员”想要一直部署新代码，则他们必须处理新代码创建的任何后果。 正如亚马逊的沃纳·沃格斯 （ Werner Vogels）所说 ，“您制造它，然后运行它”（在生产中）。 但是开发人员已经有很多担忧。 他们不断被要求为雇主产品开发新功能。 要求他们了解基础结构，包括如何部署，配置和监视其服务，可能对他们提出的要求过高。 这是SRE介入的地方。

开发Web应用程序时，通常会有很多人参与其中。 有用户界面设计师，图形设计师，前端工程师，后端工程师以及许多其他专业（取决于所使用的技术）。 要求包括如何管理（例如，部署，配置，监视）代码，这是SRE的专业领域。 但是，正如工程师可以从后端工程师的工作知识中受益（例如，如何从数据库中获取数据）为应用程序开发美观的外观一样，SRE也了解部署系统的工作方式以及如何使其适应该特定代码库或项目的特定需求。

因此，SRE不仅是“编写代码的操作人员”。 相反，SRE是开发团队的另一位成员，具有不同的技能，尤其是围绕部署，配置管理，监视，指标等方面的技能。但是，就像为应用程序开发漂亮外观的工程师一样，必须知道数据是如何工作的。从数据存储区获取数据后，SRE不会单独负责这些区域。 整个团队共同努力，提供可以轻松更新，管理和监控的产品。

当团队正在实施DevOps时，自然就会需要SRE，但他们意识到他们要求太多的开发人员，并且需要专家来确定Ops团队过去要处理的工作。

SRE在启动时如何工作

尝试将SRE帽子戴在开发人员头上的最明显优势是，随着您的团队的成长，它可以很好地扩展。 此外，开发人员将理解该应用程序的所有怪癖。 但是，许多初创公司使用各种各样的SaaS产品来为其基础架构提供支持。 最明显的是基础架构平台本身。 然后添加指标系统，站点监视，日志分析，容器等。 这些技术解决了一些问题时，却增加了额外的复杂性成本。 除了应用程序使用的核心技术（例如语言）外，开发人员还需要了解所有那些技术和服务。 最后，掌握所有这些技术可能是压倒性的。

另一种选择是聘请专家来处理SRE工作。 他们的责任是专注于部署，配置，监视和指标，以节省开发人员编写应用程序的时间。 缺点是SRE必须在多个不同的应用程序之间分配时间（即SRE需要在整个工程过程中支持广泛的应用程序）。 这可能意味着他们可能没有时间对任何应用程序有任何深度的了解。 但是，他们可以查看所有不同部分如何组合在一起。 这种“ 30,000英尺的视图”可以帮助确定薄弱点的优先级，以固定整个系统。

我忽略了一个关键信息：您的其他工程师。 他们可能强烈希望了解部署的工作原理以及如何尽其所能使用指标系统。 此外，聘请SRE也不是一件容易的事。 您正在寻找sysadmin技能和软件工程技能的混合体。 （我专门讲软件工程师，而不是“能够编写代码”，因为软件工程不仅仅涉及编写代码（例如，编写良好的测试或文档）。）

因此，在某些情况下，将“ SRE帽子”戴在开发人员的头上可能更有意义。 如果是这样，请密切注意代码和基础架构（SaaS或内部）的复杂性。 在某一时刻，两端的复杂性可能会推动其更加专业化。

结论

SRE团队是在初创企业中实现DevOps范例的最有效方法之一。 我已经看到了几种不同的方法，但是我相信（在早期）聘请专门的SRE将为开发人员腾出时间来专注于他们的特定挑战。 SRE可以专注于改进使开发人员更具生产力的工具（和过程）。 此外，SRE将专注于确保您的客户拥有可靠和安全的产品。

---

Craig Sebenik将于10月29日至31日在田纳西州纳什维尔举行的LISA18 上的初创企业中展示SRE（和DevOps） 。

翻译自: https://opensource.com/article/18/10/sre-startup

sre和devops