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

#1 楼

值得庆幸的是，由于站点可靠性工程是Google内部开发的，直到最近才开始进入更广泛的社区，因此它的定义相当明确。但是，不是Web操作（或“系统管理” –作为缺乏清晰性的一个示例，您在问题中同时使用了两者）。当您不确定一个事物到底是什么时，很难讨论这两个事物之间的区别。

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


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

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

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

在围绕NoOps的讨论中，Etsy的技术运营副总裁兼受人尊敬的Web Operations书籍的编辑John Allspaw通过以下方式定义了Etsy的角色：


Etsy Operations是负责：


响应中断，进行呼叫
警报系统阈值，设计
体系结构设计和审查
构建度量标准收集
>应用程序配置
基础架构构建/管理

Etsy Development负责：


响应中断，进行呼叫
警报系统阈值，设计
体系结构设计和审查
构建度量标准收集
应用程序配置
发行面向公众的代码

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


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

这通常是我所从事的Web操作的定义在大多数情况下。因此，这是我们将要继续的内容。


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

Google SRE本书以定义开头SRE ...然后是另一本书...然后花一章继续定义角色，并整本书介绍这些细节。即使是在一个组织中开发，似乎也很难将工作简化为一个统一的定义。

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

前言中的定义强调了三个单词分别单独出现：



工程-使用计算机科学和工程学概念解决问题

可靠性-专注于系统更可扩展，更可靠，更高效

服务-“站点”的后续发展，强调SRE负责网络服务

引言章节列出了宗旨站点可靠性工程的说明如下：



确保持久关注工程-采取先发制人的行动以避免频繁的页面和其他“麻烦”

在不违反服务的SLO的情况下，以最大的变化速度来实现-这个主题可以轻松地拥有自己的数百个单词的答案，但可以概括为帮助开发人员进行更改，只要它们不会引起太多问题即可。

监控-发生错误时自动发出警报

紧急响应-发生故障时修复问题
变更管理
容量计划
配置

效率和性能-确保服务以预期的水平运行-瓶颈会伤害用户，但是容量过大会花费金钱


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

Google定义的SRE程序是为满足特定需求而开发的网络操作程序

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


我们从sysadmins开始。
然后网站变得越来越多关于“事物”，职位发布开始指的是Web运营工程师，以区分专门从事Web的sysadmin和那些同时处理一般办公室IT的sysadmin。
然后，DevOps应该将那些愿意使用编程来减少其Web操作工作量的人分开。
但是由于缺乏明确的定义，DevOps陷入混乱，我们采用了站点可靠性工程来指定我们正在寻找的对象随时待命的支持生产服务人员。

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