在组织结构中引入网站可靠性工程（SRE）团队，在IT行业和DevOps领域越来越受欢迎。让我们在本文中探讨SRE流行的原因以及DevOps和SRE之间的区别和共同点。
在过去的二十年里，我们目睹了构建和交付软件的方式发生了巨大的转变。首先是敏捷文化，然后是 DevOps 革命，已经改变了技术组织的结构，它们可以被视为 IT 行业的事实标准。
众所周知，IT 是一个不断发展的行业，最近我们看到站点可靠性工程学科越来越受欢迎，尤其是在 DevOps 领域。但什么是 SRE？ SRE 和 DevOps 之间的区别和共同点是什么？
核心摘要
- DevOps 是一种强调开发与运维协作的文化和理念，但它本身不提供完整实施方法。
- SRE 起源于 Google，使用软件工程方法解决运维问题，重点关注可靠性和自动化。
- SRE 和 DevOps 都希望缩小开发与运维之间的鸿沟，但 SRE 更像是一套可落地的实践机制。
- SRE 强调生产环境责任、代码所有权、事故管理、可观测性和自动化流程。
- 可以把 SRE 理解为实现 DevOps 理念的一种方式，但 SRE 也包含一些不完全属于 DevOps 的实践。
术语解释：什么是 SRE
SRE 是 Site Reliability Engineering，即站点可靠性工程。它把软件工程方法用于运维问题，核心目标是让服务保持可靠，并通过自动化减少手工操作和人为错误。
在本文语境中，SRE 不是简单的“高级运维”，也不是 DevOps 的同义词。它更强调用工程化方式管理可靠性、事故响应、可观测性、灾难恢复和生产环境责任。
DevOps
DevOps 文化有助于拆除软件开发和软件操作之间的壁垒，提供了一系列带来以下好处的想法和实践：
- 更好的部门协作和沟通；
- 更短的发布周期；
- 更快的创新速度；
- 更好的系统可靠性；
- 降低IT成本；
- 更高的软件交付绩效;
尽管这听起来很惊人，但仍有相当多的公司在将DevOps文化引入其组织方面遇到困难。原因是DevOps是一种思想而不是方法论或技术，这意味着它并没有说明如何成功实施良好的DevOps策略。
SRE
站点可靠性工程 (SRE) 是 2000 年代初诞生于 Google 的一门学科，旨在缩小软件开发和运营之间的鸿沟，并且完全独立于 DevOps 运动。SRE使用软件工程方法来解决运维问题。
SRE团队的主要关注点是：
- 可靠性;
- 自动化；
让我们深入了解这些方面。
可靠性
SRE的主要目标之一是“无论如何”使系统保持运行。为了实现这一目标，重要的是要记住故障和错误可能会发生。SRE学科通过专注于以下方面来拥抱它们：
- 可观测性；
- 系统性能；
- 高可用性（HA）；
- 应急响应和灾难恢复；
- 事故管理；
- 从过去的问题中学习；
- 灾害缓解和预防；
自动化
自动化所有传统手工执行的任务是SRE的另一个主要目标。自动化和软件工程被用来解决运维问题。
自动化在SRE中发挥着基础性的作用：它使我们能够摆脱系统过程和活动中存在的人为错误。有人可能会认为自动化无论如何都会引入系统漏洞，这是正确的，但有一个重要区别：可以测试自动化流程，但无法测试涉及人类活动的流程。
DevOps、SRE 的对比
正如我们所了解的，DevOps文化和SRE机制都旨在缩小软件开发和运维之间的鸿沟。以下是它们的总结，首先描述它们共同的目标以及它们最大的不同之处。
| 维度 | DevOps | SRE |
|---|---|---|
| 核心定位 | 文化、理念和协作方式 | 工程实践和组织机制 |
| 主要目标 | 打破开发与运维壁垒，提升交付与协作效率 | 用软件工程方法提升可靠性并减少手工运维 |
| 实施方式 | 原文指出 DevOps 不直接说明如何实施 | 通过可靠性、自动化、事故管理等机制落地 |
| 责任边界 | 强调共享责任 | 强调生产环境责任和代码所有权 |
| 共同点 | 都关注协作、可靠性和更好的软件交付 | 都关注协作、可靠性和更好的软件交付 |
SRE 是一个类，实现了 DevOps 接口
如前所述，DevOps并没有提及如何成功地将文化引入组织中，因为它是一种思想意识形态。另一方面，SRE可以被视为实施DevOps哲学的方式。
事实上，尽管SRE的起源完全独立于DevOps，并且该学科提供了不属于DevOps的其他实践方法，但SRE实现了DevOps的理念。
责任和代码所有权
SRE 可以被认为是 DevOps 的下一个阶段，因为它专注于代码所有权：SRE 工程师接受在生产环境中拥有他们开发的代码的责任。这与 DevOps 有些不同，DevOps 中责任是共享的，旨在实现更短的发布周期并改善协作。
总结
在组织结构中引入网站可靠性工程（SRE）团队，在IT行业和DevOps领域越来越受欢迎。其流行的原因可以归结于该学科带来的好处：
- 更好的部门协作和沟通；
- 更短的发布周期；
- 更快的创新速度；
- 更好的系统可靠性；
- 降低IT成本；
- 更高的软件交付绩效；
- 减少生产中的事故事件;
- 代码所有权;
- 自动化流程；
正如您可能已经注意到的那样，其中一些好处与引入DevOps文化到您的组织中所体验到的完全相同。
SRE可以被认为是实施DevOps文化的一种方式，其目标是使服务保持可靠。
FAQ
Q1：SRE 和 DevOps 是同一个概念吗？ A：不是。DevOps 更像文化和理念，SRE 更像用软件工程方法落地可靠性的一套实践机制。二者目标相近，但侧重点不同。
Q2：为什么说 SRE 可以实现 DevOps 接口？ A：原文的意思是，DevOps 提出开发和运维协作的理念，SRE 则提供了可靠性、自动化、事故管理、代码所有权等可执行方式。
Q3：SRE 最关注哪些能力？ A：原文重点提到可靠性和自动化。可靠性包含可观测性、系统性能、高可用、应急响应、事故管理和从过去问题中学习；自动化用于减少传统手工运维。
Q4：SRE 是否只适合大型互联网公司？ A：原文没有限定适用规模。更稳妥的理解是，只要组织需要系统性提升可靠性、减少手工操作、改进事故响应，就可以借鉴 SRE 的实践。
附
本文是一篇译文，原始文章位置在这里：THE INTRODUCTION OF SITE RELIABILITY ENGINEERING (SRE)
