DevOps 和 SRE 似乎是同一枚硬币的两个面。他们都旨在弥合开发团队和运维团队之间的鸿沟，都想要提高软件部署的效率和软件运行的可靠性。

在大多数公司中，我们可以看到开发团队和运维团队的职责和能力会有重叠。那么 DevOps 和 SRE 有什么不同，每个意味着什么？让我们来看看。


开发，运维和可靠性


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


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


DevOps 的定义是“一种软件工程文化和实践，旨在统一开发和运维” 。这个术语最初是由 Andrew Shafer 和 Patrick Debois 于2008年创造的，虽然花了几年时间才成为一个通用概念，但如今，几乎每个企业都在使用 DevOps。


Site Reliability Engineer(SRE) 的概念自2003年以来一直存在，比 DevOps 还要古老。它是由创建 Google 的本·特雷诺（Ben Treynor）创造的。根据 Treynor 所说，SRE 是“软件开发工程师开始承担运维人员的任务”


像 DevOps 一样，SRE 也会整合开发团队和运维团队，帮助他们熟悉另一个团队的工作和任务，同时使得整个应用程序生命周期具有可见性。


DevOps 和 SRE 都倡导自动化和监视，其目标都是减少从开发到部署生产中的时间，同时又不影响代码或产品的质量。


Google 指出，SRE 和 DevOps 彼此之间并没有太大区别：“在软件开发和运维方面，他们不是竞争关系，而是旨在打破组织障碍，使得更快地交付更好的软件的亲密朋友。”


DevOps 和 SRE 之间的差异


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


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


为了进一步说明两者之间的区别，Google 发布了一系列视频和帖子，介绍了DevOps和SRE的不同之处。其中两位 Google 员工（Seth Vargo和Liz Fong-Jones）撰写的一篇文章中，他们解释了 SRE

“体现了 DevOps 的理念，更加注重通过软件工程师和运维人员的工作来衡量和实现可靠性。”

Seth Vargo 和 Liz Fong-Jones 通过以下5个方面解释了 DevOps 和 SRE 之间的异同：

1.减少组织项目独立

通常组织结构复杂的的大型企业，有许多团队是独立工作。每个团队都将产品推向不同的方向，没有与公司的其他成员进行交流，因此，他们无法从整体上了解产品全局。这可能会在部署中的引发问题。

DevOps 的工作是减少孤岛，并确保不同团队最终目标一致。通过共同的愿景将团队组织起来。SRE 不再谈论公司中有多少独立项目，而是在谈论如何让所有人参与。这是通过使用整个公司相同的工具和技术来完成的，作为回报，这有助于在每个人之间共享所有权。

2.接受故障

尽管 DevOps 的概念是在故障出现之前进行预防，但是不幸的是，我们无法避免故障。DevOps 通过将故障视为必然发生的事情。

在SRE中，通过制定一个公式来统计故障。换句话说，SRE希望没有太多错误或失败。

该公式，用两个关键标识符来衡量：服务水平指标（ Service Level Indicators ，即SLIs）和服务水平目标（ Service Level Objectives ，即SLOs）。

SLIs 通过计算请求延迟，每秒请求的吞吐量、失败次数来衡量每个请求的失败。SLOs 源表示SLI在一定时间内的成功。

3.实施渐进式变革

越来越多的公司希望能够频繁发布，不断更新迭代自己的产品，并使团队成员时刻关注新技术和相关技术。

DevOps 的目标也是如此，但要以渐进和可处理的方式进行。DevOps 和 SRE 都希望快速发展，SRE 强调在这样做的同时降低故障成本。

4.工具化和自动化

如前所述，自动化是 DevOps 和 SRE 的主要重点之一。DevOps和SRE都鼓励尽可能增加工具和实现自动化，通过消除人为操作为开发人员和运维降低出错率。

5.衡量一切

自动化工作流程需要不断监控。DevOps 和 SRE 团队都需要确保他们朝着正确的方向发展，并通过衡量一切来做到这一点。

这里的主要区别在于，SRE围绕”运维是软件问题（ operations are a software problem）“的概念展开，从而使他们定义了一些可用性度量方法。

SRE 还确保公司中的每个人知道如何衡量可靠性，以及在出现故障时该怎么做。

可靠意味着什么？

上面，我们讨论了责任划分，接受失败以及衡量一切。现在，我们需要一种方法来确保一切都确实能够正常运行并且可靠。换句话说，应该有一个统一的方法来测量每个级别的可靠性。

SRE通过 SLIs 和 SLOs 来衡量，DevOps团队会衡量失败率以及一段时间内的成功率，并且两者通常都是使用不同的工具和方法来进行的。可靠性不仅与基础架构有关，而且也与应用程序质量，性能、安全性息息相关。

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

• 堆栈信息
• 变量状态
• JVM状态：线程，环境变量
• 相关日志语句（包括生产中的DEBUG和TRACE）
• 事件分析（频率，失败率，部署，应用程序）
• 
  

由于这些数据是至关重要的信息，因此我们必须确保它是可靠且可操作的总结SRE，有明确的定义，并提出了一系列直接的期望。然而，DevOps 更像是一种“自由精神”，其定义和观点因组织而异。但是，DevOps 和 SRE 团队并没有太大区别。两者都有助于整合开发人员和运维团队，同时承担相似的责任，并专注于实现自动化和可靠性。最重要的是，一切都与数据有关。你需要数据信息来衡量成功和失败，以及如何在整个应用程序中获得持续的可靠性。

DevOps 和 SRE 似乎是同一枚硬币的两个面。他们都旨在弥合开发团队和运维团队之间的鸿沟，都想要提高软件部署的效率和软件运行的可靠性。

在大多数公司中，我们可以看到开发团队和运维团队的职责和能力会有重叠。那么 DevOps 和 SRE 有什么不同，每个意味着什么？让我们来看看。


开发，运维和可靠性


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


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


DevOps 的定义是“一种软件工程文化和实践，旨在统一开发和运维” 。这个术语最初是由 Andrew Shafer 和 Patrick Debois 于2008年创造的，虽然花了几年时间才成为一个通用概念，但如今，几乎每个企业都在使用 DevOps。


Site Reliability Engineer(SRE) 的概念自2003年以来一直存在，比 DevOps 还要古老。它是由创建 Google 的本·特雷诺（Ben Treynor）创造的。根据 Treynor 所说，SRE 是“软件开发工程师开始承担运维人员的任务”


像 DevOps 一样，SRE 也会整合开发团队和运维团队，帮助他们熟悉另一个团队的工作和任务，同时使得整个应用程序生命周期具有可见性。


DevOps 和 SRE 都倡导自动化和监视，其目标都是减少从开发到部署生产中的时间，同时又不影响代码或产品的质量。


Google 指出，SRE 和 DevOps 彼此之间并没有太大区别：“在软件开发和运维方面，他们不是竞争关系，而是旨在打破组织障碍，使得更快地交付更好的软件的亲密朋友。”


DevOps 和 SRE 之间的差异


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


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


为了进一步说明两者之间的区别，Google 发布了一系列视频和帖子，介绍了DevOps和SRE的不同之处。其中两位 Google 员工（Seth Vargo和Liz Fong-Jones）撰写的一篇文章中，他们解释了 SRE

“体现了 DevOps 的理念，更加注重通过软件工程师和运维人员的工作来衡量和实现可靠性。”

Seth Vargo 和 Liz Fong-Jones 通过以下5个方面解释了 DevOps 和 SRE 之间的异同：

1.减少组织项目独立

通常组织结构复杂的的大型企业，有许多团队是独立工作。每个团队都将产品推向不同的方向，没有与公司的其他成员进行交流，因此，他们无法从整体上了解产品全局。这可能会在部署中的引发问题。

DevOps 的工作是减少孤岛，并确保不同团队最终目标一致。通过共同的愿景将团队组织起来。SRE 不再谈论公司中有多少独立项目，而是在谈论如何让所有人参与。这是通过使用整个公司相同的工具和技术来完成的，作为回报，这有助于在每个人之间共享所有权。

2.接受故障

尽管 DevOps 的概念是在故障出现之前进行预防，但是不幸的是，我们无法避免故障。DevOps 通过将故障视为必然发生的事情。

在SRE中，通过制定一个公式来统计故障。换句话说，SRE希望没有太多错误或失败。

该公式，用两个关键标识符来衡量：服务水平指标（ Service Level Indicators ，即SLIs）和服务水平目标（ Service Level Objectives ，即SLOs）。

SLIs 通过计算请求延迟，每秒请求的吞吐量、失败次数来衡量每个请求的失败。SLOs 源表示SLI在一定时间内的成功。

3.实施渐进式变革

越来越多的公司希望能够频繁发布，不断更新迭代自己的产品，并使团队成员时刻关注新技术和相关技术。

DevOps 的目标也是如此，但要以渐进和可处理的方式进行。DevOps 和 SRE 都希望快速发展，SRE 强调在这样做的同时降低故障成本。

4.工具化和自动化

如前所述，自动化是 DevOps 和 SRE 的主要重点之一。DevOps和SRE都鼓励尽可能增加工具和实现自动化，通过消除人为操作为开发人员和运维降低出错率。

5.衡量一切

自动化工作流程需要不断监控。DevOps 和 SRE 团队都需要确保他们朝着正确的方向发展，并通过衡量一切来做到这一点。

这里的主要区别在于，SRE围绕”运维是软件问题（ operations are a software problem）“的概念展开，从而使他们定义了一些可用性度量方法。

SRE 还确保公司中的每个人知道如何衡量可靠性，以及在出现故障时该怎么做。

可靠意味着什么？

上面，我们讨论了责任划分，接受失败以及衡量一切。现在，我们需要一种方法来确保一切都确实能够正常运行并且可靠。换句话说，应该有一个统一的方法来测量每个级别的可靠性。

SRE通过 SLIs 和 SLOs 来衡量，DevOps团队会衡量失败率以及一段时间内的成功率，并且两者通常都是使用不同的工具和方法来进行的。可靠性不仅与基础架构有关，而且也与应用程序质量，性能、安全性息息相关。

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

• 堆栈信息
• 变量状态
• JVM状态：线程，环境变量
• 相关日志语句（包括生产中的DEBUG和TRACE）
• 事件分析（频率，失败率，部署，应用程序）
• 
  

由于这些数据是至关重要的信息，因此我们必须确保它是可靠且可操作的总结SRE，有明确的定义，并提出了一系列直接的期望。然而，DevOps 更像是一种“自由精神”，其定义和观点因组织而异。但是，DevOps 和 SRE 团队并没有太大区别。两者都有助于整合开发人员和运维团队，同时承担相似的责任，并专注于实现自动化和可靠性。最重要的是，一切都与数据有关。你需要数据信息来衡量成功和失败，以及如何在整个应用程序中获得持续的可靠性。