如果您不确定“DevOps”的含义以及您的组织中是否需要 DevOps 团队，那么本文适合您。在这里，我提供了 DevOps 及其各个方面的概述，讨论了为什么您最可能希望在您的公司中有一个专门的 DevOps 团队，并涵盖您可能不需要的那些边缘情况。
主要分享低代码、微服务、容器化、SAAS、系统架构方面的的内容，希望大家点赞，评论，关注。
什么是“DevOps”？
“DevOps”是一种融合了“开发”和“运营”的工作场所文化。在 DevOps 方法论建立之前，工程师们各自为政，只专注于他们特定的专业领域，通常不愿意了解其他领域。DevOps 通过确保开发人员和运营工程师在整个软件开发生命周期 (SDLC) 中的协作来消除孤岛。因此，团队可以更快地交付优化的产品。
传统的孤立工作环境由一方面的开发人员组成——负责编写软件代码并确保它在他们的机器上运行——另一方面由操作人员组成，他们尽最大努力在生产环境中运行该软件。从开发者的角度来看，他们的责任在软件发布时就结束了，这意味着生产中的任何问题都是运营团队的问题。另一方面，运营工程师认为如果部署的软件中出现任何错误，他们不应该调查代码，这意味着他们会将球扔给开发人员。在大多数情况下，运维工程师无论如何都不具备调试软件的必要技能。
“DevOps”试图弥合这一差距，并在实践中具有更广泛的含义，包括持续集成、持续部署、自动化、可观察性、云架构等。
结果，您可能已经注意到没有太多的系统管理员。那是因为他们都成为了 DevOps 工程师！因此，在某些情况下，DevOps 工程师可以被视为仅仅是美化的系统管理员，而其他人……/和……
从本质上讲，我相信 DevOps 是一种哲学：使用各种工具和技术通过多种方式有效地交付软件产品：
- 自动化（可以说是 DevOps 对软件工程最重要的贡献）
- 安全
- 可靠性
- 再现性
- 可扩展性
- 弹性
- 可观察性
自动化软件交付
我们现在正在进入作为 DevOps 核心的持续集成 (CI) 和持续交付/部署 (CD) 领域。我将在下面分别讨论它们。
持续集成
从技术上讲，CI 不是 DevOps 的一部分，而是敏捷软件开发的一种技术（尽管 DevOps 工程师可以做出贡献，例如，通过自动化运行静态分析或单元测试作为 CI 管道的一部分）。CI 本质上意味着开发人员可以快速且经常地将他们的更改提交到主代码分支。
过去，开发人员经常花费数周或数月的时间分别开发不同的功能。当发布软件的时间到来时，他们需要合并所有更改。通常，差异会很大，并导致可怕的“大爆炸合并”，开发团队有时会花费数天时间试图让彼此的代码一起工作。
CI 的主要优点是它避免了个别工作过于分散并变得难以合并。如果使用单元测试、静态分析和其他此类检查创建 CI 管道，则可以快速向开发人员反馈。因此，它可以让他们在问题造成进一步损害或阻止其他开发人员工作之前解决问题。
持续交付/部署
CD 可以被认为是 DevOps 的一部分，并且建立在 CI 之上。CD 管道通过在将更改提交到代码存储库时自动构建软件并以软件版本的形式提供工件来自动化软件交付。当管道在这个阶段停止时，我们称之为“持续交付”。此外，CD 管道可以自动部署工件，在这种情况下，它被称为“持续部署”。
过去，构建和部署软件通常是手动过程，这些任务既耗时又容易出错。
CD 的主要优势在于它使用经过消毒（因此完全受控）的环境自动构建可交付成果，从而为工程师腾出宝贵的时间来从事更高效的工作。当然，自动部署软件的能力也很有吸引力，但这对于一些工程师和管理人员来说可能是超出了舒适区的一步。CD 管道还可以包括高级测试，例如集成测试、功能和非功能测试等。
自动化软件安全
DevOps 的这个子分支有时称为DevSecOps。它的目标是自动化安全和最佳软件开发和交付实践。此外，它还使遵守安全标准以及制作和保留证明遵守此类措施所需的证据变得更加容易。
通常，在软件开发中，安全是事后才想到的，这是必须在某个时候完成的事情，但往往留到最后一刻，因为没有时间正确地去做。开发人员面临着在通常非常紧迫的时间范围内执行和交付的压力。因此，引入 DevSecOps 团队可能是一个积极的贡献。它将确定必须满足哪些安全方面并使用各种工具来强制执行这些要求。
DevSecOps 可以在软件生命周期的所有级别，例如：
- 代码静态分析
- 自动运行测试
- 生成的工件的漏洞扫描
- 软件运行时的威胁检测（以及可能的自动缓解）
- 审计
- 自动检查是否遵循特定的安全标准
自动化可靠性
DevOps 的任务通常是确保给定系统具有高可用性，这是通过使用负载平衡器、应用程序网格和其他自动检测失败实例并采取补救措施的工具来实现的。自动扩展也是一个重要方面，通常由 DevOps 工程师作为自动化流程实施。
所有这一切的关键是整个系统的设计必须使其每个组件都是短暂的。通过这种方式，任何组件都可以立即被新的、健康的组件替换，从而实现自我修复系统。设计这样的系统通常不是开发人员的职责，而是 DevOps 团队的职责。
传统上，组织使用运行单一软件堆栈的雪花服务器，所有内容都在该单一服务器上。这样的设计非常脆弱，每个人都生活在对下一次故障的恐惧中，工程师 24/7 值班。诚然，您还需要在自动化系统中值班的工程师以防万一，但他们通常很少使用。
自动化再现性
各种工具可让您自动配置服务器和系统以及配置基础设施元素（网络、数据库、服务器、容器）。这些示例包括配置管理和基础设施即代码 (IaC) 工具。
利用这些，您可以确保在按下按钮时立即实例化给定系统的精确镜像。它们还允许您部署新的软件版本或使服务器或无服务器服务的配置保持最新。
IaC 通常与 CD 集成。事实上，CD 管道的最后阶段之一可以是使用 IaC 在生产环境中部署软件版本。
何时避免 DevOps 实践
与传统的手动软件开发相比，DevOps 实践需要大量的前期工作。这种初始投资通常会在长期内收回成本；如果您的项目是短暂的，这可能是一个错误的商业决策。
因此，在任何想要获得不会在生产中使用的“足够好”的软件的情况下，盲目地应用 DevOps 实践可能不是一个好主意，只会增加您的开发时间而几乎没有额外的好处。典型例子包括：
- 最小可行产品
- 示范
- 实验
- 概念证明
在上述任何一种情况下，转向生产就绪产品通常需要从头开始重新编写软件，在这种情况下，DevOps 实践可以作为整体工作的一部分进行计划。
结论
正如您在本文中可能注意到的那样，DevOps 世界中最常出现的词是“自动化”。作为一名 DevOps 工程师，我的座右铭是：“如果你不能复制它，你就没有它。”
与传统开发相比，DevOps 通常需要更多的前期工作来建立自动化模式。在这个初始阶段之后，开发人员的生产力得到提高，运营团队所需的工作量大大减少。
或许，你也注意到了，我没有提到云。这是有意的，因为 DevOps 实践适用于云和本地环境。但是，对于基于云的工作负载，DevOps 实践对于当今的软件团队来说几乎是强制性的。这是因为手动配置和管理云资源很麻烦并且容易出现人为错误。云工程的许多方面也与 DevOps 实践有着内在的联系。
总之，可以公平地假设，除非您急于开发最小可行的产品，否则 DevOps 团队将允许您为您的开发人员和运营团队更有效地构建工作负载，并使两个团队都更快乐。请记住：“DevOps”是一种包含您的开发和运营团队的理念，因此“仅仅”引入 DevOps 团队是不够的。如果您在整个公司内实施必要的文化变革以使其（以及您的云环境）发挥作用，那将会必不可少的一部分。
主要分享低代码、微服务、容器化、SAAS、系统架构方面的的内容，希望大家点赞，评论，关注。