您应该了解的 DevOps 和 SRE 之间的 5 个基本区别
已发表: 2021-02-22信息技术和软件开发领域经常将 DevOps 与 SRE 混为一谈，意思相同。 但是，两者之间存在巨大差异。 尽管站点可靠性工程 (SRE) 近年来受到了广泛关注，但 DevOps 的存在时间要长得多（甚至在 DevOps 一词出现之前）。
简而言之，DevOps 和 SRE 都是为了更快地交付软件而实施的实践。 两者之间的唯一区别在于他们的方法。 DevOps 专注于缩短软件开发生命周期，而 SRE 专注于消除系统弱点以达到相同的目的。
在本文中，我们将探讨 DevOps 和 SRE 彼此不同的基本方式。 在我们这样做之前，让我们先了解一下 DevOps 和 SRE 是什么。
目录
什么是 DevOps？
用 DevOps 手册和凤凰计划的作者 Gene Kim 的话来说，
“DevOps 是 [the] 一套文化规范和技术实践，[使] 计划工作从开发等到测试到运营的快速流动，同时保持世界级的可靠性、运营和安全性。 DevOps 不是关于你做了什么，而是你的结果是什么。”
因此，DevOps 主要专注于转变组织内部的文化实践，以加快软件开发生命周期 (SDLC)。 它不针对个人、团体或职位。 DevOps 旨在加强信息技术运营和软件开发团队之间的协作。
它做什么以及如何做并不重要。 只有过程的结果才能得到承认。
DevOps 使用一组原则来加强软件工程团队对生产系统的了解，并使 IT 运营团队能够更有效地将差异上报给开发团队。 事实上，SRE 通过促进主动测试、速度、允许可观察性和提高服务可靠性，在 DevOps 组织中发挥着至关重要的作用。 DevOps 鼓励每个以 DevOps 为中心的组织按照其模型 CALMS 中概述的文化原则进行操作。
什么是 SRE？
SRE 是 Site Reliability Engineering 的缩写，是谷歌负责监督技术运营的高级副总裁 Ben Treynor 创造的一个术语。
Drew Farnsworth（来自 Green Lane Design）解释说：“我通常喜欢将 SRE 视为一个开发控制操作的系统。 在这个系统中，环境被分解为 IT 堆栈的最基本组件，并在硬件中采用了最佳实践。”
从本质上讲，具有软件开发专业知识的 SRE 团队的任务是解决系统生产中的问题，同时在交付速度和系统可靠性之间保持平衡。 通过这种方式，SRE 方法将运营角色下的软件开发人员聚集在一起，以应用结构化的工程实践来维护组织的政策。
他们确保系统始终可用并高效运行，以便软件团队开发技术服务以提高系统的可靠性。 SRE 有责任在任何潜在的弱点发展为重大问题之前识别它。
DevOps 与 SRE：DevOps 和 SRE 之间的主要区别
在实践中，DevOps 和 SRE 应该被视为互补的学科，其中 SRE 作为以 DevOps 为中心的结构的一部分，专注于提高其技术服务的可靠性。 因此，基本上没有 DevOps 与 SRE 之类的东西。
因此，我们在本节中所做的是评估 DevOps 和 SRE 之间的根本区别。
实施变革
为了更新频繁，用户可以访问更新和更相关的技术，DevOps 和 SRE 都打算加快步伐。 然而，DevOps 谨慎地逐步推进，而 SRE 则考虑了加快行动失败的成本。
两者都实施自动化并使用工具来实现这一目的。
将失败视为常态
DevOps 在接受失败并将其视为学习压迫方面非常重要。 出于这个原因，它通过接受失败是过程的一部分而不是专注于使系统 100% 容错来鼓励一种无可指责的文化。 这方面的一个例子是 Netflix 及其 Simian Army。
另一方面，SRE 支持无可指责的事后分析。 这背后的目的是确定失败的原因，分配责任并努力避免将来发生类似的失败。 系统可以经历多少次故障包含在错误预算中。 SLI、SLO 和 SLA 指标确定了这一点，以降低生产成本。 基本上，SRE 采用主动监控和警报实践来避免潜在的故障。
从世界顶级大学在线学习软件开发课程。 获得行政 PG 课程、高级证书课程或硕士课程，以加快您的职业生涯。
自动化与创新
DevOps 非常重视自动化。 在以 DevOps 为中心的环境中，这意味着系统尽可能地自动化，从而导致发布乏味。 开发人员提交代码后，以下大多数活动（如果不是全部）必须自动化。
因此，DevOps 追求 CI/CD 的原因是为了以更高的速度开发高质量的系统。
SRE 追求 CI/CD 的原因是不同的，它们的目的是降低失败的成本。 部署和备份等操作中的任何常见、通用或重复性任务都被认为不太值得关注。 因此，SRE 会留出特定的时间来避免操作繁琐。 这样做是为了让他们可以从事更具吸引力的任务，例如执行或创新新技术或与架构相关的活动。
结帐：面向初学者的 DevOps 项目
打破组织孤岛
在部署过程中，开发人员和运营商会发生冲突。 虽然开发人员会在编码后立即部署功能，但操作人员专注于使系统可用，这会阻碍部署过程。
DevOps 和 SRE 的不同之处在于它们如何消除组织中的孤岛。
正如 The DevOps Handbook 中所解释的，DevOps 通过包括小批量操作和更好地管理配置等实践来解决这个问题。
SRE 不仅旨在优化团队之间的流程，还有助于生产中的系统。 他们通过作为顾问融入团队并通过分担运行系统的责任来支持开发人员来做到这一点。 这就是 SRE 如何打破组织中的孤岛。
衡量成功的实施
DevOps 指标都是关于运营速度的； 这包括部署的频率、部署时间以及遇到问题的频率。
根据 Puppet 和 DORA 的 2017 年报告，衡量 DevOps 的成功实施取决于以下几点：
- 部署发生的频率
- 代码提交与其部署之间的持续时间
- 部署失败的频率
- 从部署失败中恢复所需的时间
这些反馈循环旨在帮助 DevOps 提高系统质量，同时促进实验中的变化。
另一方面，SRE 致力于改进系统，同时牢记其可靠性。 它考虑以下关键指标来确定成功的实施：
- 服务水平目标 (SLO)
- 服务水平指标 (SLI)
- 服务水平协议 (SLA)
上述指标是系统可靠性的指标。 这些指标预先确定变更发布是否会投入生产。
在 SRE 中，这些速度和质量指标在构建错误预算和提高系统可靠性而不是开发新功能时会派上用场。
阅读：印度的 DevOps 工程师薪水
结论
Google 发布了一本关于他们如何在其生产系统中实施站点可靠性工程的电子书，其中 Treynor 将 SRE 解释为，
“当您要求软件工程师设计运营团队时，就会发生 SRE。”
当谈到 DevOps 和 SRE 的不同之处时，您需要记住的是，SRE 是由开发人员而不是运营团队驱动的。 维护和监控都主要在开发人员的控制之下。 这就是这两个学科的主要区别。
如果您有兴趣了解有关大型 DevOps、全栈开发的更多信息，请查看 upGrad 和 IIIT-B 的软件开发执行 PG 计划 - 全栈开发专业化，该计划专为工作专业人士设计，并提供 500 多个小时的严格培训， 9 个以上的项目和任务，IIIT-B 校友身份，实用的实践顶点项目和顶级公司的工作协助。
