后端开发教程 - Java、Spring Boot 实战 - msg200.com
DevOps 是什么？真正理解它
DevOps 定义困难
应用程序发布流程
DevOps 试图解决的挑战
DevOps 概念作为解决方案
DevOps 实践：DevOps 作为独立角色
DevOps 实践：如何成为 DevOps 工程师
DevOps 与 SRE —— SRE 如何融入整个 DevOps 流程
详细了解DevOps 的真正含义，以澄清围绕它的所有问题和疑虑✅
这是我的新 YouTube 视频的书面版本✍️🙂
DevOps 已经越来越受欢迎并且正在取代传统的软件开发方式。
DevOps 定义困难
然而，“DevOps”这个术语本身含义广泛，涵盖的内容也非常广泛，因此很难准确定义它，也很难与其他 IT 领域相比，明确划定 DevOps 的界限。因此，本文将尝试详细解答“DevOps 是什么”这个问题。
最简单的定义是"DevOps is an intersection of Development and Operations"。
但是 DevOps 的界限究竟在哪里呢？开发中的哪些部分不是 DevOps？或者运维中的哪些部分不是 DevOps？为什么开发和运维之间需要有某种东西？🙉
开发和运营是整个应用程序发布流程中的两个主要组成部分：
那么让我们从头开始详细了解这个发布过程！
应用程序发布流程
每当我们开发应用程序时，我们总是遵循相同的流程将该应用程序交付给最终用户。因此，无论您使用瀑布式开发、敏捷开发还是其他任何方法，这都是主要目标。其核心是：1）您创建一个应用程序；2）您希望将其交付给最终用户，以便他们能够使用它。👩💻
假设你对一款很酷的应用有了一个很棒的创意。你定义了它的功能，或者换句话说，它应该具备哪些特性，
- 你编写代码，
- 你测试一下
- 现在您已经有了一个经过测试的应用程序，您想将其部署到公共服务器上并让用户访问它。
为此，您需要构建并打包应用程序，使其以某种可执行文件的形式运行。您需要配置公共服务器，包括所有必要的内容，例如安装应用程序所需的所有工具，并将应用程序部署到服务器上，配置防火墙规则以允许访问服务器上的应用程序，然后应用程序启动完毕，用户就可以开始使用了！🚀
这就是任何应用程序发布的简化基础，但这并不是旅程的终点。在使用过程中，您当然需要检查您的应用程序：
- 一切顺利吗？
- 用户是否遇到任何问题？
- 也许应用程序中存在一些你在测试时没有发现的错误
- 应用程序能否处理高用户负载？
- ETC
因此，在启动之后，您必须真正确保您的应用程序可供最终用户访问和使用，如果用户遇到任何问题，当然应该修复它们。
以上就是您应用程序的首次发布，但应用程序开发尚未完成。如果您发现用户喜欢您的应用程序，您就会想让它变得更酷，添加新功能，甚至可能通过升级服务器或提高应用程序速度来优化性能等等。因此，您还有很多事情要做，每次改进应用程序时，无论是代码本身还是服务器配置，您都希望最终用户能够立即感受到这些改进。
因此，在首次启动后，您会对应用程序进行多次更新，并跟踪这些更新，从而对这些更改进行版本控制。
然后你一遍又一遍地这样做：
- 你有改进的想法
- 你在代码中实现它
- 你测试一下
- 构建并打包
- 你部署它
- 发布后，您可以在生产中观察它，看看是否有任何新的改进可能性或任何需要立即修复的问题
因此，这为您提供了一个持续交付变更的过程，对您的应用程序进行了无休止的改进。
DevOps 就是要让持续交付的过程更加快速，并尽量减少错误和缺陷：
因此，通过 DevOps，改进可以快速创建并交付给用户，而且这些改进质量高且经过充分测试。快速交付高质量的代码是一个很大的挑战。😳
DevOps 试图解决的挑战
现在让我们看看团队在这个过程中可能面临的挑战到底是什么，以及 DevOps 试图解决哪些挑战。
在整个发布过程中，我们遇到了障碍和摩擦：
那么发布过程中有哪些摩擦和障碍呢？🤔
1）沟通不畅和缺乏协作⛔️
第一个也是最重要的挑战是开发人员和运营人员之间的沟通不畅和缺乏协作。
因此发布应用程序主要有两个部分：
- 你编写应用程序代码
- 部署并运行应用程序
开发人员负责编写代码，运维人员负责运行应用程序。
这两者之间可能存在这样的差距：“我编写了一个应用程序，但我无法运行它”或“我正在运行该应用程序，但我不知道它是如何工作的”🙇🏻♂️：
因此，开发人员在编写代码时不会考虑代码将部署到哪里或如何部署，而运维人员在部署时也不会真正理解部署的内容、原因，甚至应用程序的工作原理。这会导致两者之间的沟通不畅。
例如：
开发人员完成了编码，但运营团队的部署指南不够好或记录不够完善，因此运营团队难以部署，因此发布需要更长的时间。
这种沟通不畅可能会导致发布周期延长数天或数周，在复杂且维护不善的项目中甚至可能延长数月。
因此，从开发人员完成功能开发到运维人员开始部署，并没有明确定义的自动化交接流程。它基于一个复杂的官僚程序，包含需要完成哪些清单📝、需要记录哪些内容、谁需要手动批准哪些内容发布等等。所以这里没有精简的流程或自动化的流程。
2）利益冲突⛔️
除了开发和运营之间的沟通不畅之外，在传统的设置中，一个团队只负责开发，另一个团队只负责运营，这两个团队似乎有不同的动机，这使得他们很难合作。
开发人员希望快速推出新功能，而运维人员则希望确保这些更改不会破坏任何功能，因为运维人员有动力维护生产环境的稳定性。他们的主要关注点是确保应用程序可用、不崩溃、不向用户显示 500 错误等等。
这意味着运维人员需要抵制发布速度，并检查新版本的各个方面，以确保其 100% 安全，这又会减慢整个流程，尤其是考虑到运维人员并不真正了解代码或应用程序。因此，他们评估新版本需要付出更多努力。
因此，尽管公司每个人的主要共同目标应该是快速向最终用户交付高质量的应用程序，但实际上，每个角色更直接的目标是做好自己的工作。开发人员的工作是快速创建新功能并发布，而运维的工作是维护系统稳定性并抵御新变更的推出：
这给我们带来了利益冲突，这种设置自然使得这两个人很难合作。🤷♀️
3）安全性⛔️
发布功能时另一个令人头疼的问题就是安全性。正如运维团队会仔细评估和修改以确保它们不会影响系统稳定性一样，安全团队也会评估任何更改，以确保它们不会影响系统安全性：
在传统设置中，这与操作一样，都是相同的手动官僚流程，需要几天或几周的时间，并减慢发布过程。
正如我提到的，DevOps 是关于消除任何减慢流程的障碍，所以它也包括这一点。
然而，尽管这是 DevOps 解决方案的一部分，但为了强调并提醒团队安全的重要性，还是创建了一个单独的术语“DevSecOps” ，因为它不知何故被忽略了。
我实际上有一个关于 DevSecOps 的单独专用视频，如果你感兴趣的话也可以看看：DevSecOps 讲解
4）应用程序测试⛔️
现在，应用程序测试又成了一大难题。许多项目都有专门的测试团队或角色，负责在不同层面测试应用程序的变更：
- 就像测试功能一样
- 测试整个应用程序，
- 在多种环境上进行测试等。
通常这些测试都是手动完成的，当团队不能完全依赖自动化测试时，只有完成手动测试后，才能发布更改：
尽管这可能不是由开发或运营角色完成的，而是由单独的测试人员角色完成的，但这是发布过程的重要部分，并且也可能大大减慢发布速度！
5）体力劳动⛔️
正如我所提到的，发布过程中的许多任务，例如测试、安全检查、部署等，过去都是手动完成的。🙇🏻♂️
例如，运维人员会手动完成大部分运维任务，要么直接在服务器上执行命令来安装工具、配置内容、打补丁，要么执行脚本或小程序。但这两种情况都需要手动完成：
手工工作的缺点
手工 工作速度慢，而且更容易出错，因为人为错误加上手工工作的缺点，知识共享非常困难，因为执行任务的人必须记录下来，其他人必须阅读它。
它也非常不透明，因为很难追踪，谁在何时执行了什么操作，以及最终何时手动完成了基础设施配置等。如果基础设施出现问题，可能很难快速恢复并复制准确的状态。你必须准确地记住在服务器上执行了哪些操作，以及按照什么顺序才能恢复到之前的状态。🤦🏽♀️
DevOps 尝试消除这些障碍
所以，你会发现所有这些问题的主要特点是，它们都会减慢发布周期，并在发布过程中制造障碍。你还会看到，在安全和测试方面，DevOps 甚至可能只涉及开发或运维的职责和任务：
这就是为什么要理解 DevOps，我们不应该关注它的名称和含义，而应该关注它试图实现的目标：💡
DevOps 试图消除所有阻碍发布过程的障碍和因素，无论它们是什么，并且有助于创建完全自动化的发布周期简化流程，而不是手动的低效流程。
这可以一步一步地完成，一次消除一个障碍，直到您拥有一个完全优化和自动化的 DevOps 流程，从而使您的应用程序发布变得非常容易。🚀
DevOps 概念作为解决方案
那么 DevOps 如何帮助实现这一目标并解决所有这些挑战呢？👀
嗯，根据官方定义，这是 DevOps 最初的想法：
DevOps defines a combination of cultural philosophies, practices and tools for doing that.
所以，DevOps 不仅仅是一套工具或一个特定的概念，它是所有能够快速高质量发布软件的流程的组合。这个概念的核心在于，开发人员和运维人员应该更频繁地合作，更频繁地交流，更好地协作，以实现这一目标。
DevOps 实践：DevOps 作为独立角色
但实际上，这个定义过于宽泛和高深，让人难以想象它在实践中是如何运作的。🙉 所以它不够具体。所以，不同的公司自然会以不同的方式实施 DevOps。因此，不同公司实际的 DevOps 实施情况也大相径庭。
但自从公司开始采用它以来，它逐渐获得了更具体的形式，并形成了许多公司的某些常见模式，其中一种模式是DevOps 演变成一个称为“Devops 工程师”的实际角色，其中要么是开发人员将 DevOps 作为开发之外的工作，要么是运营人员在做，或者有人专门将 DevOps 作为他们唯一的工作。
而一套用于实现 DevOps 原则的技术成为了DevOps 技术，现在 DevOps 工程师需要学习这些技术：
我知道很多人对 DevOps 工程师这个概念持抵触态度，DevOps 概念的提出者也没想到它会被如此运用，但现实往往与理论不符。我们看到，这个概念被调整和扭曲，以满足最终目标的需求，而 DevOps 工程师这个角色就是由此诞生的。🤷♀️
DevOps 角色负责创建精简的发布流程，避免任何阻碍发布速度的障碍，这就是为什么DevOps 的核心是众所周知的持续集成/持续交付流程
DevOps 实践：如何成为 DevOps 工程师
查看我的其他博客文章以了解：
读完这篇文章后，你可能会想，要学的东西太多了，可能很难知道从哪里开始，先学什么，或者使用什么资源。🤯
嗯，有很多资源可以学习单独的 DevOps 技术，👍实际上，我在我的 YouTube 频道上介绍了许多 DevOps 技术。😊
但理想情况下，您希望遵循一个结构良好的循序渐进的路线图，更重要的是学习如何结合使用这些技术，因为这就是 DevOps 工程师所做的。他们使用和集成多种技术来创建 DevOps 流程，当然，您希望通过实际的实际项目示例来学习所有这些，以了解它在实际工作中会是什么样子。很少有课程和学习资源提供这一点，这正是我们创建完整的 DevOps 训练营的原因，它具有清晰的结构和大量的实践项目。
因此，如果您正在考虑成为一名 DevOps 工程师或慢慢过渡到 DevOps，那么您绝对可以看看我们的 DevOps 训练营🚀
DevOps 与 SRE —— SRE 如何融入整个 DevOps 流程
为了全面了解 DevOps，我想再提一个概念，即 SRE 或站点可靠性工程，以及它如何融入 DevOps。
我们刚刚了解到 DevOps 有两种定义
- 原始定义更高层次、更宽泛，并没有具体说明 DevOps 应该如何实施
- 还有一种更实用的，随着时间的推移，它逐渐发展出自己的 DevOps 工程师角色。
因此，当我们将 DevOps 与 SRE 进行比较时，了解我们使用哪种 DevOps 定义进行比较非常重要？
1. 首先 DevOps vs. SRE 更广泛的定义
DevOps 是一个更高级的概念，它定义了实现自动化精简发布流程需要做什么，而 SRE 则更具体地说明了如何精确地实现这个过程以及如何实现 DevOps 原则。
很多人会说SRE 是 DevOps 概念的具体实现：
2. 实用 DevOps 与 SRE 的比较
但正如我们所见，DevOps 本身也变得更加实用，拥有其独特的角色、特定的技术和实现方式。那么
，两者之间的比较是什么呢？🤔 在许多公司中，这种实用的 DevOps 实施更加注重应用程序变更的交付速度。当然，尽管快速发布和高质量代码是 DevOps 原则的一部分，但许多 DevOps 团队在实践中似乎更注重速度而不是可靠性。
因此，作为DevOps 的一个重要补充部分，SRE 应运而生，秉承着相同的原则和目标，即快速发布高质量的代码，但顾名思义，它更注重可靠性和保持系统稳定，同时允许快速更改：
所以，SRE 本身就是一个角色，它有一套自己的工具来确保系统可靠。所以，这两者曾经是并行发展的，现在常常被视为同一事物的两个方面。团队同时拥有 DevOps 工程师和 SRE 来帮助实施 DevOps 原则的情况并不少见。
自己的“什么是 SRE”视频即将推出..🎬
这只是对 SRE 的简要介绍，以便与 DevOps 进行比较，但由于我收到了很多关于 SRE 是什么的问题，我将在接下来的几周内发布关于 SRE 的后续视频，以更详细地解释 SRE 在实践中是如何工作的，站点可靠性工程师的任务和职责是什么等等。
关于 DevOps，我希望我能解答你们所有疑问。如果没有，请在视频下方留言，我会尽力解答😊
祝你的 DevOps 之旅一切顺利！🎉 💪
喜欢、分享并关注我😍以获取更多内容：
文章来源：https://dev.to/techworld_with_nana/what-is-devops-really-understand-it-29j7