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