DevOps这个术语已经存在了很多年。大小公司都将DevOps概念用于不同目的，例如，以提高软件质量。在此博客文章中，我们定义了DevOps，介绍了它的优缺点，重点介绍了一些概念并了解它们如何影响整个组织。
什么是DevOps？
从较高的层次来看，DevOps被理解为公司在技术，组织和文化上的转变，以更有效，可靠和安全地运行软件。根据第一个定义，我们可以看到DevOps不仅仅是“使用工具X”或“移动到云”。DevOps首先了解到，不再将开发（Dev），运营（Ops）和质量保证（QA）视为孤立的学科。取而代之的是，他们在协作团队中以共同的流程和责任聚在一起。DevOps通过多种技术实现了这一目标。在“实施”部分，我们介绍了其中一些概念。
好处
应用DevOps的好处包括：
- 通过提高效率节省成本。
- 更快的软件迭代周期，从开发到投入生产，更新所需的时间更少。
- 运行软件时具有更高的安全性，可靠性和容错性。
- 组织中不同利益相关者（包括非技术人员）之间的牢固联系。
- 启用更多由数据驱动的决策。
让我们看看通过应用DevOps想法如何实现这些好处：
如何实现DevOps
自动化和持续集成（CI）持续交付（CD）
自动化是DevOps工程驱动部分的关键方面。借助自动化，我们的目标是通过经过自动化且易于理解的操作流程来发送软件，以尽可能减少对人为操作的需求，从而减少人为错误的可能性。这些自动化操作可以构建您的软件，运行单元测试，将其与现有系统集成，运行系统测试，部署它并提供每个步骤的反馈。我们在此描述的内容通常称为持续集成（CI）和持续交付（CD）。采用CI / CD可以以一种低风险和低成本的方式来解决“工程师笔记本电脑上运行的软件”与“在生产服务器上安全可靠地运行的软件”之间的鸿沟。
CI/CD通常绑定到一个平台，在该平台上运行自动化操作，例如Gitlab。该平台接受应通过管道传递的软件，在通常被抽象化的服务器上执行自动化操作，并向工程团队提供反馈。这些动作可以高度定制，并以不同的方式捆绑在一起。例如，一个动作仅编译源代码，并将构建工件提供给后续动作。另一动作可以负责运行测试套件，另一动作可以部署软件。可以为不同类型的软件定义此类操作：可以将网站自动部署到服务器，或者可以使您的客户使用桌面应用程序，而无需人工干预。
除了CI / CD可用于各种软件外，还有其他优点可供考虑：
- 团队很好地理解和维护了CI / CD管道：可以灵活地更新，扩展管道中运行的操作，等等。在这里，作为代码的基础架构可以成为一个强大的概念。
- 在标准化环境中运行：工具和配置之间的版本冲突或依赖项不匹配只需要在构建管道时修复一次。管道正常工作后，由于底层服务器及其软件版本未更改，它将继续工作。跨不同工程师的操作系统，工具，工具版本之间不再存在冲突。管道是高度可复制的。在这里，容器化可能会改变游戏规则。
- 反馈：操作有时会失败，例如因为未通过单元测试。CI / CD平台通常允许使用不同的报告机制：向某人发送电子邮件，在存储库概述页面上更新项目状态，阻止后续操作或取消其他管道。
下一部分将介绍更多受益于自动化的DevOps概念。
多种环境
通过将软件部署到不同的环境，可以扩展CI / CD。这些部署可以在管道中定义的单个操作中进行。除了运行面向用户软件的生产环境之外，还可以定义将软件部署到的暂存和测试环境。例如，工程团队可以使用测试环境来进行同行评审和验证软件更改。一旦团队同意新软件，就可以将其部署到暂存环境中。暂存环境的通常目的是尽可能地模仿生产环境。可以在登台环境中运行进一步的测试，以确保该软件可供实际用户使用。最终，软件达到生产就绪状态并部署到生产环境中。
不同的环境不仅实现了运行软件的不同语义和置信度（例如，如前一段所述），而且还充当了整个组织中软件的共识视图。多环境部署使您的软件及其质量更易于理解。这是因为在运行软件时，尤其是在接近生产环境的基础结构上运行软件时获得了见识。通常，运行软件可以提供有关性能，可靠性，安全性，生产就绪性和整体质量的更多见解。可以在不同的软件质量阶段（例如，运行软件的不同环境）咨询不同的团队，例如安全专家或专门的质量保证团队（如果您的组织遵循此做法）。此外，非技术人员可以使用环境，
最终，集成多个环境可以进行质量检查，并简化不同团队之间的互动。
提前失败
无论在构建软件的组织中工作如何顺利，都会发生错误，并且错误代价很高。错误的成本可以预测为修复错误所需的人力，因生气的客户而导致的声誉损失以及通常对业务造成的负面影响。由于我们无法完全避免错误，因此存在减少错误发生频率和影响的概念。“及早失效”是这些概念之一。
基本思想是尽早在开发过程中捕获软件中的错误和其他缺陷。开发软件时，单元测试，编译器错误和同行评审将计入用于检测和修复缺陷的早期廉价机制。理想情况下，单元测试可以告诉开发人员该软件不正确，或者第二双眼睛可以看到在代码检查期间潜在的性能问题。在这两种情况下，都不会浪费很多时间和精力，并且可以轻松修复该缺陷。但是，其他错误可能会通过这些初始检查得以实现，并进入测试或登台环境。还应该使用其他类型的测试和质量检查来检查软件质量。最坏的情况是，该错误将超过所有检查的期限，并已投入生产。错误在那里影响更大，需要许多利益相关者付出更多的努力，例如
为了节省成本，应及早执行廉价检查，例如在自动化管道中运行测试套件。这将节省成本，因为稍后在过程中发现的缺陷会导致更高的成本。因此，尽早失败会提高成本效率。
回滚
DevOps还可以帮助快速响应更改。如上一节所述，一个突然变化的例子是一个错误，该错误在生产环境中被发现。回滚（例如作为手动触发的管道）可以及时恢复生产服务的良好功能。当错误是一个很难解决的错误并且需要数小时才能确定和修复时，这很有用。这些小时降低的客户体验，甚至停机时间，使付费客户不满意。需要一种更快的机制，该机制可最大程度地减少故障系统与已恢复系统之间的差距。回滚可能是恢复系统状态的快速有效方法，而不会使客户遭受太多公司失败。
政策规定
DevOps概念对整个组织的安全性和权限管理构成了挑战。策略可以帮助制定运营过程中的授权和规则。例如，可能需要实现以下安全要求：
- 生产中的部署或回滚不应由权限明确的一组人员触发。
- CI / CD管道中的某些动作应始终运行，而其他动作应手动触发或仅在特定条件下运行。
- 开发人员可能需要与专门的质量检查团队稍有不同的权限来执行其日常工作。
- 人类和机器用户可以具有不同的功能，但应始终为其分配最少的特权。
CI / CD提供商或云供应商提供的身份验证和授权工具可以帮助根据您的组织需求设计此类策略。
可观察性
随着软件的运行以及用户与您的应用程序的交互，错误率，性能统计信息，资源使用情况等洞察力可以帮助您识别瓶颈，缓解未来的问题并通过数据推动业务决策。建立两种不同形式的可观察性的方法有两种：
- 日志记录：软件输出的文本形式的事件，用于通知应用程序的状态和运行状况。不同类型的日志消息（例如，指示错误事件的严重性）可以帮助在中央位置聚集和显示日志消息，工程团队可以在该位置将其用于调试目的。
- 指标：有关应用程序本身未生成的正在运行的软件的信息。例如，运行软件的底层计算机的CPU或内存使用情况，网络统计信息，HTTP错误率等。与日志记录一样，度量标准可以帮助发现瓶颈并在对其产生业务影响之前缓解它们。可视化汇总指标数据可促进技术团队和非技术团队之间的沟通，并利用数据驱动的决策。指标仪表板可以加强团队之间软件的共享所有权。
日志记录和指标可以帮助定义目标，并使开发团队与质量检查团队保持一致。
缺点
到目前为止，我们仅研究了DevOps的优势和特点。通过评论采用DevOps概念的可能的负面影响和弊端，让我们简要介绍一下硬币的另一面。
- 对DevOps的投资可能是巨大的，因为它是整个公司范围内，跨学科，跨团队的转型，不仅需要技术实施工作，还需要对人员进行培训，重组和调整团队。
- 这与第一点是一致的，但值得强调：由于人为因素，对组织的文化影响可能具有挑战性。尽管可以合理地很好地估计和实施新的自动化机制，但是跟踪变更人们的通信方式，主人翁感，适应新流程的进度可能很困难，并且可能不会提高效率，DevOps承诺这是短期的。由于DevOps的巨大影响，这是一项长期投资。
- DevOps的技术骨干，例如CI / CD管道，云供应商，授权和身份验证的集成，可能会通过与新参与者签订新合同和许可而增加费用。但是，通过现代DevOps工具中开源的优势，例如通过使用Kubernetes，可以避免供应商锁定。
结论
在此博客文章中，我们探讨了DevOps的定义，并提出了一些DevOps概念和用例。此外，我们评估了利弊。采用DevOps是对开发，测试和运行软件的低摩擦和自动化方式的投资。技术改进（例如自动化）以及不同学科团队之间增强的协作最终可以长期提高组织的效率。
但是，DevOps不仅代表技术上的努力，而且还影响着整个公司，例如，团队之间如何沟通，问题如何解决以及团队对什么负责。找到正确的平衡并为团队选择最佳的概念和工具是一个挑战。我们可以帮助您确定和解决组织中的DevOps转换。
