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可以通过将软件部署到不同的环境来扩展。这些部署可以在你的管道中定义的个别行动中发生。除了运行面向用户的软件的生产环境，还可以定义软件部署到的暂存和测试环境。例如，一个测试环境可以被工程团队用来进行同行评审和验证软件的变化。一旦团队同意了新的软件，它就可以被部署到一个暂存环境。暂存环境的一个通常目的是尽可能地模仿生产环境。进一步的测试可以在暂存环境中运行，以确保软件可以被真正的用户使用。最后，软件达到生产准备状态，并被部署到生产环境中。这样的生产部署可以采用逐步推出的方式进行设计，即金丝雀部署。
不同的环境不仅实现了不同的语义和运行软件的置信度，例如上一段所描述的，而且还作为整个组织中对软件的一致看法。多环境部署使你的软件和其质量更容易理解。这是因为在运行软件时，特别是在接近生产环境的基础设施上，可以获得深入的了解。一般来说，运行软件可以对性能、可靠性、安全性、生产准备程度和整体质量有更多的了解。不同的团队，如安全专家或专门的QA团队（如果你的组织遵循这种做法），可以在不同的软件质量阶段，即软件运行的不同环境中进行咨询。此外，非技术人员也可以使用环境，例如，用于演示的专门环境。
最终，整合多种环境可以使QA结构化，并使不同团队之间的互动更加顺畅。
尽早失败
无论在一个构建软件的组织中事情做得有多好，错误都会发生，而且错误的代价很高。错误的代价可以推算出为修复错误而投入的人力，由于愤怒的客户而造成的声誉损失，以及一般的负面业务影响。既然我们不能完全避免错误，就有一些概念可以减少错误的频率和影响。 "早期失败 "就是这些概念之一。
其基本思想是在开发过程中尽可能早地捕捉软件中的错误和其他缺陷。在开发软件时，单元测试、编译器错误和同行评审都算作早期廉价的检测和修复缺陷的机制。理想的情况是，一个单元测试告诉开发人员软件不正确，或者，第二双眼睛在代码审查中发现了一个潜在的性能问题。在这两种情况下，不会损失太多的时间和精力，而且缺陷可以很容易地被修复。然而，其他的错误可能会通过这些初步检查，并在测试或暂存环境中着陆。其他类型的测试和QA应该到位，以检查软件的质量。最坏的情况是，这个bug在所有的检查中都没有被发现，而是进入了生产环境。在这种情况下，错误的影响要大得多，需要许多利益相关者付出更多的努力，例如，工程团队的错误修复和对客户的道歉。
为了节约成本，应该尽早执行廉价的检查，如在自动化管道中运行测试套件。这将节省成本，因为在过程中后期发现的缺陷会导致更高的成本。因此，早期失败会增加成本效率。
回滚
DevOps还可以帮助对变化做出快速反应。突发变化的一个例子是在生产环境中发现了一个错误，如上一节所述。回滚，例如作为手动触发的管道，可以及时恢复生产服务的良好运作。当bug是一个硬伤，需要几个小时来识别和修复时，这可能很有用。这些小时的客户体验下降，甚至是停机，使付费客户不高兴。希望有一个更快的机制，使故障系统和恢复后的系统之间的差距最小化。回滚可以是一种快速有效的恢复系统状态的方法，而不需要让客户过多地暴露在公司的故障中。
政策
DevOps概念给安全和权限管理带来了挑战，因为这些管理跨越了整个组织。策略可以帮助在运营期间制定授权和规则。例如，可能需要实施以下安全要求。
- 生产中的部署或回滚不应该由任何人触发，而应该由一组定义明确的权威人士触发。
- CI/CD管道中的一些操作应始终运行，而其他操作则打算手动触发或仅在某些条件下运行。
- 开发人员可能需要与专门的QA团队略有不同的权限来执行他们的日常工作。
- 人类和机器用户可以有不同的能力，但应该总是分配给他们最少的权限。
CI/CD供应商或云供应商提供的认证和授权工具可以帮助根据你的组织需求设计这种政策。
可观察性
随着软件的运行和用户与你的应用程序的互动，诸如错误率、性能统计、资源使用等洞察力可以帮助识别瓶颈，缓解未来的问题，并通过数据驱动业务决策。存在两种主要方式来建立不同形式的可观察性。
- 记录。软件输出的文本形式的事件，以告知应用程序的状态和健康。不同类型的日志信息，例如表明错误事件的严重性，可以帮助在一个中心位置聚集和显示日志信息，在那里它可以被工程团队用于调试目的。
- 度量。关于运行中的软件的信息，不是由应用程序本身产生的。例如，运行软件的底层机器的CPU或内存使用率，网络统计，HTTP错误率等。与日志记录一样，指标可以帮助发现瓶颈，并在其产生业务影响之前加以缓解。将汇总的指标数据可视化，有利于技术和非技术团队之间的沟通，并利用数据驱动的决策。度量仪表板可以加强各团队对软件的共享所有权。
例如，日志和指标可以帮助定义目标，并使开发团队与QA团队保持一致。
劣势
到目前为止，我们只看了DevOps的好处和特点。让我们简单看看硬币的另一面，评论一下采用DevOps概念可能带来的负面影响和缺点。
-
对DevOps的投资可能是巨大的，因为它是一个全公司的、多学科的、多团队的转型，不仅需要技术实施的努力，还需要人员培训、重组和调整团队。
-
这与第一点相辅相成，但值得强调的是。由于人为因素，对你的组织的文化影响可能是具有挑战性的。虽然一个新的自动化机制可以被合理地估计和实施，但跟踪改变人们的沟通方式、所有权的感觉、与新流程保持一致的进展是很困难的，而且可能导致没有获得效率，而DevOps承诺的效率是短期的。由于DevOps的高影响力，它是一项长期投资。
-
DevOps的技术骨干，如CI/CD管道、云供应商、授权和认证的整合，可能会通过与新的参与者签订新的合同和许可证而导致费用增加。然而，通过开源在现代DevOps工具中的主导地位，例如通过使用Kubernetes，可以避免厂商锁定。
总结
在这篇博文中，我们探讨了DevOps的定义，并介绍了几个DevOps概念和使用案例。此外，我们还评估了好处和坏处。采用DevOps是对开发、测试和运行软件的低摩擦和自动化方式的一种投资。技术上的改进，例如自动化，以及不同学科的团队之间的合作增加，最终提高了企业的长期效率。
然而，DevOps不仅代表了技术上的努力，也影响了整个公司，例如，团队之间如何沟通，问题如何解决，以及团队觉得自己的责任是什么。为你的团队找到正确的平衡并选择最好的概念和工具是一个挑战。我们可以帮助你识别和解决你的组织中的DevOps转型问题。
