传统的开发和运营模型与站点可靠性工程之间有什么区别？

“当您要求软件工程师设计运营团队时，就会发生SRE。” – 站点可靠性工程

自Google发布《网站可靠性工程手册》以来，我不止一次被告知SRE是现有运营或应用程序支持模型的扩展。

我们有几个问题定义了Sys之间的差异。管理员，DevOps工程师和站点可靠性工程师：

• Sysadmin和DevOps Engineer有什么区别？
• SRE和DevOps有什么区别？
• 将DevOps引入新手的有效定义是什么？

但是，这些问题或其答案均无法说明系统管理员与站点可靠性工程师之间的区别。

从广义上讲：Google的站点可靠性工程实践与企业中传统的分离开发与运营职能之间的主要区别是什么？

值得庆幸的是，由于Site Reliability Engineering是Google内部开发的，直到最近才开始进入更广泛的社区，因此它的定义非常明确。什么是没有，不过，是网络运营（或“系统管理” -由于缺乏清晰的例子，你在你的问题同时使用）。当您无法完全确定两者之间的区别时，很难讨论两者之间的差异。

但是我是一个喜欢冒险的人，所以我会试一试。

在非常传统的商店中，开发人员和系统管理员彼此之间非常孤立。开发人员构建一个应用程序，然后在提交代码后立即考虑完成其工作。系统管理员将构建工件（如果是解释性语言，则可能只是代码）并将其部署到生产服务器。保持应用程序的正常运行是sysadmins的工作，通常是管理生产环境。但是，性能问题通常来自应用程序中的体系结构问题。系统管理员没有编程知识，无法知道应用程序在做什么，开发人员也不知道应用程序在生产拓扑中如何随着生产流量进行操作，因此没有人可以自己解决问题。

此外，通常会根据开发人员能够多快地产生新功能来判断开发人员，而系统管理员通常会根据应用程序中断生产的频率来判断。由于变更是导致业务中断的主要原因之一，因此这使两个部门相互矛盾–一场古老的竞争损害了企业和相关人员。

在某些时候，一些以开发人员为中心的公司对此感到非常恼火，以至于他们开始实行“ NoOps”-他们消除了运营部门以及随之而来的障碍。实际上，这意味着开发人员担当了运营角色，但保留了旧职称。

在围绕NoOps的讨论中，时任Etsy的技术运营副总裁和著名的Web Operations书的编辑John Allspaw通过以下方式定义了Etsy的角色：

Etsy Operations负责：

• 响应中断，随时待命
• 警报系统阈值设计
• 建筑设计与审查
• 建立指标收集
• 应用配置
• 基础设施扩建/管理

Etsy Development负责：

• 响应中断，随时待命
• 警报系统阈值设计
• 建筑设计与审查
• 建立指标收集
• 应用配置
• 运送面向公众的代码

这些列表都不是全面的，我确定我在那里缺少任何东西。尽管Etsy Ops进行了面向生产的应用程序更改，但这些更改很少，但是是真实的（有时还很深）。虽然Etsy Dev进行Chef更改，但这些更改很少，但是是真实的。如果职责重叠太多，您可能会问为什么会有所不同？领域专业知识和背景。没有很多开发人员对TCP慢速启动的工作原理有深入的了解，但是Ops可以。并没有很多Ops具有排序或相关性算法的全面知识，但Dev确实如此。Ops具有多年的经验，可以以可接受的准确性快速预测资源使用情况，而Dev没有。开发人员可能不了解在所有第1-7层上分配工作负载选项的优缺点，也许只是在Ops的第7层。实体关系建模对于开发人员来说可能很自然，而对操作人员则可能不那么自然。最后，他们俩都在所有层和层上发现了各种形式的拜占庭式故障场景和弹性模式的解决方案。

在他的世界中，开发人员和操作工程师具有非常相似的高级技能和职责。他们的不同之处在于他们的专业知识。他们不同的专业鼓励他们共同解决问题，而他们共同的基础技能为他们提供了一种解决问题的语言。

通常，这是大多数情况下我所依赖的Web操作的定义。因此，这是我们将继续进行的工作。

那么，什么是站点可靠性工程？

Google SRE的书开始时先定义了SRE ...，然后再定义了...，然后用一章继续定义角色，并用一本书来详细介绍这些细节。即使是在一个组织中开发，似乎也很难将工作精简为一个统一的定义。

首先，我们需要追溯到2003年，当时Be​​n Traynor加入Google并创立了后来的第一个站点可靠性工程团队。回想一下几段之前，我们是在2010年代初期。但是在2003年，该行业仍然很自然地将sysadmin / developer划分为自然事物。因此，当Ben说软件工程师组建运营团队会发生SRE时，这两个领域的融合要比现在看起来更加激进。

前言中的定义分别强调了三个词中的每个词：

• 工程 -使用计算机科学和工程概念解决问题
• 可靠性 -致力于使系统更具可扩展性，可靠性和效率
• 服务 -“站点”的后来演变，强调SRE负责网络服务

简介章节将站点可靠性工程的宗旨列出为：

• 确保长期专注于工程 -采取先发制人的行动以避免频繁的页面和其他“麻烦”
• 在不违反服务的SLO的情况下，保持最大的更改速度 -该主题可以轻松地拥有自己的数百个单词的答案，但可以概括为帮助开发人员进行更改，只要它们不会引起太多问题
• 监控 -发生错误时自动发出警报
• 紧急响应 -修复损坏的东西
• 更换管理层
• 容量规划
• 供应
• 效率和性能 -确保服务以预期的水平运行-瓶颈会伤及用户，但容量过大会花费金钱

我将站点可靠性工程归类为现代Web运营的专门子集。一个SRE组织在很大程度上集中于自动化一切，这在相当大的公司中才具有成本效益。错误预算之类的想法只能在您的服务有很多请求时才起作用，否则会失去粒度（对于较小的服务，特定错误可能会影响您请求的0-20％，具体取决于分钟）。SRE定义中缺少诸如安全性之类的相关领域，因为规模足以拥有真正的SRE团队的公司拥有专门的安全团队。

Google定义的SRE程序是为满足Google的特定需求而开发的网络操作，不一定适用于其他地方。

但是，站点可靠性工程最近在更广泛的行业中得到了扩展。我目前的职位是SRE，即使我在一家规模较小的公司工作，并且我的职位描述与John Allspaw的2012 Etsy网络运营定义非常吻合。我的理论是，我们一直在努力推动标题的发展，以支持单一领域的发展：

• 我们以sysadmins身份开始。
• 然后，随着网站逐渐成为一种“事物”，职位发布开始指向Web运营工程师，以将专门从事Web的系统管理员与那些同时处理一般办公室IT的系统管理员区分开。
• 然后，DevOps应该将那些愿意使用编程来减少其Web操作工作量的人分开。
• 但是，由于缺乏明确的定义使 DevOps感到困惑，我们采用了站点可靠性工程来指定我们正在寻找可以随时提供支持的生产服务人员。

那么，系统管理员和SRE有什么区别？他们获得称号的年份。传统运营和站点可靠性工程之间有什么区别？SRE仅仅是使用新工具（您好，容器！）的最新形式，并且随着网络程序的不断发展和日益重要，人们越来越关注允许一名工程师做更多事情的实践。