SRE 与 DevOps 有什么不同?

标签: dev | 发表时间:2020-07-29 00:00 | 作者:
出处:http://itindex.net/relian

SRE和DevOps有什么区别?您可能会说这很大程度上是语义问题,实际上,SRE和DevOps工程师扮演着相同的基本角色。

尽管如此,SRE和DevOps之间还是存在一些区别,即使是细微的区别。考虑到这两种角色在很大程度上具有相同的价值观和实践,它们似乎并不重要,但现实是,最终SRE和DevOps工程师满足了不同的需求。了解这些差异是确保您的IT团队尽可能高效地运营的关键。

什么是SRE?

SRE(Site Reliability Engineering)是站点可靠性工程或站点可靠性工程师的缩写,是指使用软件工程原理来帮助维护和管理IT系统。

至少,这就是 Google的SRE定义,这是在过去几年中推广该概念的公司。正如Google所说,SRE的目的是 像对待软件问题一样对待[IT]操作

这个想法是创新的,因为在传统上,大多数公司在主要负责维护软件的IT运维人员和主要负责编写软件的软件工程师之间存在很大的分歧。这两个小组不仅从事不同类型的工作,而且还以不同类型的方式解决问题。软件工程师倾向于专注于使用代码来解决所有问题,而运维则更习惯于使用各种工具(监视软件,配置管理工具,访问控制框架等)来管理日常工作和软件系统的日常操作。

SRE趋势有助于解释为什么像 基础架构即代码 (IaC)和 声明式配置管理近年来已成为IT系统部署和管理的流行方法。这些实践是使用代码的方式以及软件工程的原理来管理传统上使用不同工具和方法执行的IT流程。它们也恰好是非常适合自动化和可伸缩性的方法,这是SRE优先考虑的价值观。

什么是DevOps?


顾名思义,DevOps旨在弥合开发与IT运维之间的鸿沟。

DevOps背后的核心思想本质上是驱动SRE的相同思想:通过允许软件工程师(或开发人员,在大多数情况下基本上是同一件事)和IT运维人员之间更紧密的协作,使整体IT运维更加可靠和高效。。

像SRE一样,DevOps奖励自动化和可扩展性。尽管DevOps也有一些技巧,例如DevOps对话,但IaC之类的方法通常会出现在DevOps对话中CI / CD,与SRE紧密相关。

SRE VS DevOps

因此,在较高的层次上,DevOps和SRE具有相似的目标和广泛相似的方法。但是DevOps和SRE之间存在重要区别:

  • 开发人员扮演的角色:SRE使用开发人员的思维和工具来解决IT运营问题。因此,在SRE中,大多数事情都是从软件工程师的角度完成的。相比之下,DevOps更多地是要结合开发人员和IT操作工程师的技能,而不是使用前者取代后者;
  • 文化与实现:一般而言,DevOps倾向于将重点更多地放在文化目标和优先事项上,而不是特定的实施过程。不需要任何特定工具或方法即可执行"DevOps"。同样,也没有遵循SRE的特定脚本,但是与DevOps相比,SRE总体上提供了关于如何解决问题以及使用哪种类型的工具的更严格的规定;
  • 组织结构:在大多数情况下,DevOps不会取代现有的开发人员和IT运营部门或角色。公司可能会雇用一些DevOps工程师来帮助指导DevOps,但是他们并不会用DevOps工程师代替所有现有的IT角色。相反,SRE角色往往被视为至少替代IT操作的一种方式。(这是一个笼统的陈述,当然也有例外,但是总的来说,SRE涉及对组织结构的更大改变);
  • 扩展到其他IT角色:DevOps产生了一个大量分支将DevOps概念扩展到开发和IT运维之间。现在,通常会听到有关DevSecOps的讨论,例如,将DevOps应用于安全性的问题或QAOps,这将QA工程师带入DevOps领域。同时,SRE概念还没有看到这种广泛的使用。

SRE和DevOps之间有真正的区别吗?

尽管如此,很难完全解释SRE和DevOps之间的区别。一些观察者有争论差异并不足够大或不一致,不足以使其有意义。其他人可能会争辩说,SRE和DevOps的定义以及公司采用这些概念的方法差异很大,因此实际上不可能一开始就提供这两个术语的通用定义,更不用说清楚地阐明如何他们彼此不同。

这些观点是有价值的。不过,我确实认为,在总体上,使用SRE和DevOps的方式之间存在一些细微但重要的差异。这些概念不可互换,并且寻求为IT战略带来最大价值的公司可以从这两种战略中受益。

SRE使用一种以前仅应用于软件开发的方法,以一种实用的实施方式来帮助简化IT运维。同时,DevOps提倡更高层次的思考,以使整个IT组织更加高效和自动化,而又不将公司限制在一组狭窄的工具或方法论上。

最终,将SRE和DevOps视为截然不同的概念,并接受它们所提供的独特价值是有价值的。

之前也看到了刘征老师公众号发送的视频,这里也分享给大家:

英文原文:http://suo.im/6sMqO7

相关 [sre devops] 推荐:

SRE 与 DevOps 有什么不同?

- - IT瘾-dev
SRE和DevOps有什么区别. 您可能会说这很大程度上是语义问题,实际上,SRE和DevOps工程师扮演着相同的基本角色. 尽管如此,SRE和DevOps之间还是存在一些区别,即使是细微的区别. 考虑到这两种角色在很大程度上具有相同的价值观和实践,它们似乎并不重要,但现实是,最终SRE和DevOps工程师满足了不同的需求.

DevOps和SRE的区别 - 知乎

- -
最近有一位朋友和我聊职业发展方向问题,聊了不少 DevOps 和 SRE 话题. 我几年前刚接触这两个概念时也常常将之混淆,可惜当时没有人来解答我困惑. 现在这虽然已经极为流行,但是我发现我这位朋友对这两个职位还存在一些误区. 于是我给了一些见解并整理成文章以饕大众. DevOps 新概念,好高级哦.

什么是 SRE?与 DevOps 相比,到底谁才是真正的王者

- - IT瘾-dev
有很多人问过我想了解一下 SRE 这个岗位,这是个很大的话题,在这篇博客中把想到的一些介绍一下吧. 这是一个最早由 Google 提出的概念,我的理解是,用软件解决运维问题. 标准化,自动化,可扩展,高可用是主要的工作内容. 这个岗位被提出的时候,想解决的问题是打破开发人员想要快速迭代,与运维人员想要保持稳定,拒绝频繁更新之间的矛盾.

SRE 的工作介绍

- - 卡瓦邦噶!
有很多人问过我想了解一下 SRE 这个岗位,这是个很大的话题,在这篇博客中把想到的一些介绍一下吧. 这是一个最早由 Google 提出的概念,我的理解是,用软件解决运维问题. 标准化,自动化,可扩展,高可用是主要的工作内容. 这个岗位被提出的时候,想解决的问题是打破开发人员想要快速迭代,与运维人员想要保持稳定,拒绝频繁更新之间的矛盾.

DevOps实践一:DevOps概述 - 知乎

- -
DevOps系列文章包含了本人在工作中的实践和认知理论,现总结并分享出来,希望能够给“迷你型”团队在DevOps上的实践提供一个“反面教材”和可行性建议. 本系列主要包含以下文章(过程中可能也会有所更改):. DevOps实践一:DevOps概述. DevOps实践二:持续集成、持续交付和持续部署.

让DevOps起作用

- - InfoQ cn
根据Neil Garnichaud在Dr. Dobb’s上发表的文章《 究竟什么是DevOps》,想要频繁地发布高质量的软件,首先需要弄清如何使开发人员、QA人员和运营人员在一起协同工作. 在软件公司里,特别是在开发基于云的网络应用, 而又缺少有才华的、合格的员工的公司中,压缩的时间进度和最低限度的QA是压力的根源.

云端的SRE发展与实践

- - 美团点评技术团队
本文根据作者在美团点评第21期技术沙龙的分享记录整理而成. SRE(Site Reliability Engineering)是Google于2003年提出的概念,将软件研发引入运维工作. 现在渐渐已经成为各大互联网公司技术团队的标配. 美团点评作为综合性多业务的互联网+生活服务平台,覆盖“吃住行游购娱”各个领域,SRE就会面临一些特殊的挑战.

SRE:“正确做事”的法门

- - DockOne.io
【编者的话】本文是作者多年SRE实践的经验总结,阐明了为什么要选择SRE及SRE的目标,并从六个角度指明如何实践SRE:合作和沟通、人员团队结构、工具和平台、版本工程学、监控、事后回顾. 本文是我对SRE实践的介绍,这些实践来自于我组建过的不同SRE团队,这些团队负责管理SAAS平台快速添加特性. 为什么选择Site Reliability Engineering (SRE)?.

DevOps,你真的了解吗?

- - IT经理网
与大数据和PRISM(NSA的监控项目之一),DevOps(开发运维)如今是科技人士挂在嘴边的热词,但遗憾的是,类似圣经,每个人都引用DevOps的只言片语,但真正理解并能执行的人极少. 根据CA的一项 调查,45%的受访者并不了解DevOps的含义,其余则有17%认为DevOps只不过是炒作. DevOps如今几乎成了创新的同义词,但其原本的含义却在业界的流传中被人们弃之脑后.

Kubernetes 会不会“杀死” DevOps?

- - InfoQ推荐
DevOps 这个概念最早是在 2007 年提出的,那时云计算基础设施的概念也才刚刚提出没多久,而随着互联网的逐渐普及,应用软件的需求爆发式增长,软件开发的理念也逐渐从瀑布模型(waterfall)转向敏捷开发(agile). 传统的软件交付模式(应用开发人员专注于软件开发、IT 运维人员负责将软件部署到服务器运行),再也无法满足互联网软件快速迭代的需求.