sre和devops_DevOps与SRE：它们之间有什么区别，您是哪一个？

sre和devops

DevOps还是SRE？ 我们将讨论这两个概念，重点介绍它们之间的差异，并试图了解每个概念的发展。

DevOps和SRE似乎是同一枚硬币的两个侧面。 这两个标题旨在弥合开发团队与运营团队之间的鸿沟，其统一目标是在不造成任何妥协的情况下延长发布周期。

实际上，在大多数公司中，我们可以看到只需要其中一个职位，职责和能力就会重叠。 这两个标题共存于同一空间，并且都是开发团队的重要组成部分。 那么它们有什么不同，每个意味着什么？ 让我们来看看。

开发，运营和可靠性

在实施DevOps之前，开发和运营团队是两个独立的小组，每个小组都有自己的目标。 这些团队之间的差异和缺乏沟通通常会影响产品，从而影响最终用户和公司。

为了更好地沟通和构建更好的产品，DevOps成为每个公司中最关键的职位之一。

DevOps的正式定义是“一种软件工程文化和实践，旨在统一软件开发和软件操作。” 这个词最初是由Andrew Shafer和Patrick Debois于2008年创造的，尽管它花了几年时间才成为一个通用概念，但如今几乎从企业到初创企业的每家公司都在雇用DevOps。

站点可靠性工程师（SRE）的概念自2003年以来就存在，使其比DevOps还要古老。 它是由创建Google网站可靠性小组的Ben Treynor创造的。 根据Treynor的说法，SRE是“当软件工程师承担了过去称为操作的任务时会发生什么。”

就像DevOps一样，SRE还将合并开发和运营团队，帮助他们了解流程的另一面，同时为整个应用程序生命周期引入可见性。

这两个标题都倡导自动化和监视，其相似的目标是减少从开发人员进行更改到将其部署到生产中的时间。 DevOps和SRE都希望这样做，同时又不影响代码或产品的质量。

Google本身指出，SRE和DevOps彼此之间并没有太大区别：“它们不是软件开发和运营的两种竞争方法，而是旨在打破组织障碍以更快地交付更好的软件的亲密朋友。”

那么，为什么Google需要创建自己的定义？

DevOps和SRE之间的差异

如前所述，DevOps的概念就是将开发与运营结合起来，定义系统的行为，并了解需要做些什么来弥合两个团队之间的“鸿沟”。 这个标题背后的理论是关于使两个团队合而为一需要做些什么。

根据Google的说法，这就是DevOps和SRE之间的主要区别所在。 尽管DevOps只是关于“需要做什么 ”，但SRE却谈到了“ 如何 ”可以做到。 它是通过使用正确的工作方法，工具等将理论部分扩展为有效的工作流程。 这还涉及到在每个人之间分担责任，并使每个人都具有相同的目标和愿景。

为了进一步说明两者之间的区别，Google发布了一系列视频和帖子，介绍了这两个标题的不同之处。 在其中一篇由两名Google员工撰写的帖子中 ，他们是由Google开发人员的倡导者Seth Vargo和站点可靠性工程师Liz Fong-Jones撰写的，他们解释说SRE“体现了DevOps的理念，更加注重通过工程和技术来衡量和实现可靠性。操作工作。”

塞思（Seth）和利兹（Liz）通过DevOps的前5个Struts代表了两者之间的异同，并解释了它们对SRE的意义：

＃1减少组织孤岛

大型企业通常具有复杂的组织结构，有许多团队在孤岛上工作。 每个团队都将产品推向不同的方向，没有与公司的其他成员进行交流，因此，他们无法从整体上了解全局。 由于延迟，这可能会导致挫败感，部署退步和高昂的成本。

DevOps的工作是减少孤岛，并确保团队中不存在与公司其他部门不符的团队。 他们以共同的愿景将团队最小化并桥接到一个小组中。

SRE并不是在谈论公司中有多少孤岛，而是在谈论如何让所有人进行讨论。 这可以通过使用整个公司相同的工具和技术来完成，而这些工具和技术可以帮助所有人共享所有权。

＃2正常接受失败

尽管DevOps的概念是在故障发生之前进行处理和应对，但不幸的是，我们无法避免故障。 DevOps通过将失败视为必然发生的事情来拥抱这一点，这可以帮助团队学习和成长。

在SRE的世界中，通过制定一个公式来平衡事故和失败与新版本之间的关系来实现此目标。 换句话说，SRE希望确保没有太多错误或失败，即使这是我们可以学习的东西。

使用两个关键标识符来衡量此公式：服务水平指标（SLI）和服务水平目标（SLO）。

SLI通过计算请求延迟，每秒请求的吞吐量或随时间测量的每个请求的失败来衡量每个请求的失败。 SLO源自此阈值，百分比或数量，代表SLI在一定时间内的成功。

＃3实施渐进式变革

公司希望比以前更快地行动。 他们希望发布频繁，不断更新产品的产品，并使团队成员始终关注新技术。

DevOps都是针对此更改的，但要以渐进和可处理的方式进行。 DevOps和SRE都希望快速发展，Google指出SRE强调在这样做的同时降低故障成本。

＃4利用工具和自动化

如前所述，自动化是DevOps和SRE的主要重点之一。 这两个标题都鼓励增加尽可能多的自动化和工具，只要它们通过消除手动任务为开发人员和运营提供价值。

＃5衡量一切

快速移动的自动化工作流程需要不断监控。 DevOps和SRE团队都需要确保他们朝着正确的方向前进，并且他们通过衡量所有事情来做到这一点。

这里的主要区别在于，SRE围绕操作是软件问题的概念展开，这使他们定义了用于度量可用性，正常运行时间，中断，工作量等的规定性方法。

SRE还确保公司中的每个人都同意如何衡量可靠性，以及在可用性超出规范时该怎么做。 这包括从开发人员到团队经理的各个级别的贡献者，一直到副总裁和高管。

可靠意味着什么？

我们谈到了分担责任，接受失败和衡量一切。 现在，我们需要一种方法来确保一切都按预期运行，并且可靠。 换句话说，应该有一个统一的方法来测量每个级别的可靠性。

SRE用来衡量SLI和SLO，DevOps团队会衡量失败率以及一段时间内的成功率，并且两者通常都是使用不同的工具和方法来进行的。 尽管这些团队对正在发生的事情有一个概述，但还不完整。 可靠性不仅与基础架构有关，而且与从应用程序质量到性能到安全性的每一步都息息相关。

故障和问题可能且将在应用程序的不同方面发生，并且当发生故障时，我们需要拥有可靠的数据，以首先了解问题发生的原因，原因以及解决方法。 如果我们将其细分，则该数据应包括：

• 执行栈和字节码
• 完整的变量状态（覆盖完整的源代码）
• JVM状态：线程，环境变量
• 相关日志语句（包括生产中的DEBUG和TRACE）
• 事件分析（频率，失败率，部署，应用程序）

并且由于这是至关重要的信息，因此我们必须确保它是可靠且可操作的。 这可以借助针对不同情况设置警报，采用对等代码审查，单元测试等方法来完成。

虽然这些方法有助于促进每个人之间的共同责任，但它们最终可能会影响产品的性能。 组织规模越大，失败的成本就越高，无论是客户满意度，员工流失或产品价值下降。

这就是为什么最小化手动系统工作并自动收集信息很重要的原因。 当您使用它时，您还需要掌握产品中发生的一切。 换句话说，您需要正确的数据来衡量整个CI / CD工作流程中软件的可靠性 。

最后的想法

那么，DevOps和SRE之间有区别吗？ Google是SRE头衔的“创始人”，对它进行了明确的定义，并提出了一系列直接的期望。 看起来，DevOps更像是一种“自由精神”，其定义和观点因组织而异。

但是，DevOps和SRE团队并没有太大区别。 两者都有助于合并开发人员和运营团队，同时承担相似的责任，并专注于实现自动化和可靠性。

最重要的是，一切都与数据有关。 您需要信息以了解如何衡量成功和失败以及如何在整个应用程序中获得连续的可靠性。

翻译自: https://www.javacodegeeks.com/2018/07/devops-vs-sre-difference.html

sre和devops