DevOps概述

1. 概述

在本文中，我们将了解 DevOps 原则和实践的基础知识。我们将看到为什么这在软件开发中是相关的和有帮助的。我们还将了解我们如何能够有意义地采用 DevOps 以及有哪些工具可以帮助我们完成这一旅程。

2. 历史背景

如果不稍微回顾一下历史，我们将无法欣赏 DevOps 的现状。软件开发的早期主要以我们所说的瀑布方法为特征。这实际上意味着软件是连续概念化、设计、开发、测试和分发的。

每一步都尽可能详细，因为回去的成本很高。这实际上意味着思想和行动之间的等待时间要长得多。然而，这并不是一个问题，因为技术格局的波动性要小得多，而且中断的范围也太广了。

有趣的是，这种模式并没有持续多久。随着技术发展的步伐发生变化，中断开始频繁发生，企业开始感受到压力。他们需要更快地测试新想法。这意味着业务的各个方面（包括软件）都将发生更快的变化。

这催生了一个全新的软件开发方法世界，这些方法在敏捷的保护伞下被松散地看到。敏捷宣言提出了一组要遵循的原则，以小增量和更快的反馈循环交付软件。在实践中有几种敏捷框架，如Scrum 和Kanban 。

3. 什么是DevOps？

我们已经看到，具有更快反馈的增量开发已成为当今软件交付的基石。但是我们如何实现呢？虽然传统的敏捷方法将我们带到了一个合理的点，但它仍然不理想。

敏捷方法在不断努力打破孤岛的过程中不断完善自己。

传统上，我们总是有不同的团队负责开发和交付软件。这些团队经常在各自的孤岛中运作。这有效地转化为一个更长的反馈周期，这不是我们想要的敏捷方法。

因此，不需要很多推理就可以理解，良好集成的跨职能敏捷团队更适合实现他们的目标。DevOps 是一种鼓励软件开发和运营团队之间的沟通、协作、集成和自动化的实践。这更好地使我们能够以更快的反馈实现增量开发。 下图解释了实践 DevOps 的可能工作流程：

虽然我们将在本教程后面详细介绍这些步骤，但让我们了解 DevOps 的一些关键原则：

• 以价值为中心的方法（由最终用户实现）
• 协作文化（具有有效的沟通、流程和工具）
• 流程自动化（以提高效率和减少错误）
• 可衡量的结果（衡量目标）
• 持续反馈（具有快速改进的趋势）

4.如何开始旅程？

虽然该理论简单明了且吸引人，但真正的挑战在于有意义地实践 DevOps。正如我们目前所收集到的，DevOps 主要是关于人，而不是团队。

共同目标、有效沟通和跨职能技能是此类团队的标志。由于这种变化的很大一部分是文化方面的，所以它通常是缓慢的，而且并非没有摩擦。

4.1. 动机

仅仅因为有一种流行的做法并不一定适合我们。我们需要了解我们进行任何转变的动机——如果我们正在向敏捷转变，则更是如此。通过定义我们想要实现的目标来着手是很有用的。

DevOps 在任何组织中的目标都取决于该组织的雄心、文化和成熟度。以下是一些更常见的 DevOps 目标：

• 为最终用户提供更好的体验
• 更快的上市时间
• 缩短平均恢复时间

4.2. 活动

请记住，DevOps 不是最终状态，而是为实现目标而持续改进的过程。因此，团队中的每个人都必须努力找出障碍并迅速消除它们。以下是一些可以帮助我们开始的活动：

• 清楚地了解当前的构思状态到生产周期
• 收集一些明显的瓶颈并使用指标做出事实决策
• 优先考虑那些在移除后会增加最大价值的瓶颈
• 定义迭代计划以递增方式为优先项目交付价值
• 遵循 Develop-Deploy-Measure 的短周期来实现目标

5. DevOps 实践

有几种做法可以遵循，但这个想法不应将任何一种作为黄金标准。我们应该在我们的状态和目标的背景下仔细检查每一种做法，然后做出明智的决定。然而，几乎所有的实践都倾向于尽可能地关注自动化流程。

5.1. 敏捷规划

敏捷规划是以短期增量定义工作的实践。虽然最终目标应该很明确，但没有必要预先定义和详细说明整个应用程序。这里的关键是根据工作可以交付的价值确定工作的优先级。

然后，它应该在一个简短但有效的增量迭代中被打破。

5.2. 基础架构即代码 (IaC)

这是通过机器可读的配置文件管理和供应基础设施的做法。我们还在版本控制系统中管理这些配置，就像我们管理我们的代码库一样。有许多特定领域的语言可用于以声明方式创建这些配置文件。

5.3. 测试自动化

传统上，软件测试通常是在孤岛中进行的手动工作。这与敏捷原则并没有很好地结合。因此，我们必须尝试在所有级别上自动化软件测试，例如单元测试、功能测试、安全测试和性能测试。

5.4. 持续集成 (CI)

持续集成是一种更频繁地将工作代码以小增量合并到共享存储库的做法。通常，在这个共享存储库上经常运行自动构建和检查，以尽快提醒我们任何代码中断。

5.5. 持续交付/部署 (CD)

持续交付是在软件通过所有检查后立即以小增量发布软件的做法。这通常与持续集成一起实践，并且可以受益于自动发布机制（称为持续部署）。

5.6. 持续监控

监控——也许是 DevOps 的中心——可以实现更快的反馈循环。确定正确的指标来监控软件的所有方面，包括基础设施，是至关重要的。拥有正确的指标，再加上实时有效的分析，可以帮助更快地识别和解决问题。此外，它直接用于敏捷规划。

此列表远未完成，并且在不断发展。实践 DevOps 的团队不断寻找更好的方法来实现他们的目标。其他一些值得一提的实践包括容器化、云原生开发和微服务等。

6. 交易工具

如果不谈论工具，关于 DevOps 的讨论是不完整的。这是过去几年爆发的一个领域。当我们读完本教程时，可能会有一个新工具出现！虽然这既诱人又让人不知所措，但有必要谨慎行事。

我们不应该把工具作为我们脑海中的第一件事来开始我们的 DevOps 之旅。在找到合适的工具之前，我们必须探索并确立我们的目标、人员（文化）和实践。清楚这一点，让我们看看我们可以使用哪些经过时间考验的工具。

6.1. 规划

正如我们所见，成熟的 DevOps 总是从敏捷规划开始。虽然目标很明确，但只需要为少数短迭代确定优先级和定义工作。来自这些早期迭代的反馈对于最终塑造未来的迭代和整个软件来说是无价的。这里的有效工具将帮助我们轻松地执行此过程。

**Jira 是 Atlassian 开发的顶级问题跟踪产品。**它有很多内置的敏捷规划和监控工具。在很大程度上，它是一种商业产品，我们可以在内部运行或用作托管应用程序。

6.2. 发展

敏捷背后的想法是更快地制作原型并寻求对实际软件的反馈。开发人员必须做出更改并更快地合并到软件的共享版本中。更重要的是团队成员之间的沟通要流畅和快速。

让我们看看这个领域中一些普遍存在的工具。

**Git 是一个分布式版本控制系统。**它相当流行，并且有许多托管服务提供 git 存储库和增值功能。最初由 Linus Torvalds 开发，它使软件开发人员之间的协作非常方便。

Confluence 是由 Atlassian 开发的协作工具。协作是任何敏捷团队成功的关键。协作的实际语义是非常有上下文的，但是一个可以无缝协作的工具仍然是无价的。Confluence 正好适合这个位置。而且，它与 Jira 集成得很好！

Slack 是 Slack Technologies 开发的即时通讯平台。正如我们所讨论的，敏捷团队应该能够协作和沟通，最好是实时进行。除了即时通讯之外，Slack 还提供了许多与单个用户或一组用户进行交流的方式——并且它与 Jira 和 GitHub 等其他工具集成得很好！

6.3. 一体化

应持续检查开发人员合并的更改是否合规。什么构成合规性是特定于团队和应用程序的。但是，通常将静态和动态代码分析以及功能和非功能指标测量视为合规性的组成部分。

让我们简要地看一下几个流行的集成工具。

**Jenkins 是一个引人注目的、开源的、免费的自动化服务器。**它已经在行业中存在多年，并且已经足够成熟，可以为广泛的自动化用例提供服务。它提供了一种定义自动化例程的声明方式，以及多种自动或手动触发它的方式。此外，它还有一组丰富的插件，可提供多种附加功能以创建强大的自动化管道。

**SonarQube 是 SonarSource 开发的开源持续检测平台。**SonarQube 为许多编程语言提供了一套丰富的静态分析规则。这有助于尽早检测代码异味。此外，SonarQube 提供了一个仪表板，可以集成其他指标，如代码覆盖率、代码复杂性等。而且，它与 Jenkins Server 配合得很好。

6.4. 部署

快速向软件交付更改和新功能很重要。一旦我们确定存储库中合并的更改符合我们的标准和政策，我们就应该能够快速将其交付给最终用户。这有助于我们收集反馈并更好地塑造软件。

这里有几个工具可以帮助我们将交付的某些方面自动化到我们实现持续部署的地步。

Docker 是一种流行的工具，可以快速将任何类型的应用程序容器化。它利用操作系统级虚拟化将软件隔离在称为容器的包中。容器化在更可靠的软件交付方面具有立竿见影的好处。Docker 容器通过明确定义的通道相互通信。此外，与虚拟机等其他隔离方式相比，这是非常轻量级的。

Chef / Puppet / Ansible 都是配置管理工具。众所周知，软件应用程序的实际运行实例是代码库构建及其配置的组合。虽然代码库构建通常在不同环境中是不可变的，但配置却不是。这就是我们需要一个配置管理工具来轻松快速地部署我们的应用程序的地方。这个领域有几种流行的工具，每种都有自己的怪癖，但 Chef、Puppet 和 Ansible 几乎涵盖了这些基础。

HashiCorp Terraform 可以帮助我们进行基础设施配置，自私有数据中心时代以来，这一直是一项繁琐且耗时的任务。但随着越来越多的人采用云，基础设施通常被视为一次性和可重复的结构。然而，这只有在我们拥有一个工具时才能实现，我们可以使用该工具以声明方式定义简单到复杂的基础设施，并通过单击按钮创建它。这听起来像是一个梦幻般的序列，但 Terraform 正在积极尝试弥合这一差距！

6.5. 监控

最后，能够观察部署并根据目标对其进行衡量是必不可少的。我们可以从系统和应用程序中收集大量指标。其中包括一些特定于我们的应用程序的业务指标。

这里的想法是能够几乎实时地收集、管理、存储和分析这些指标。这个领域有几种新产品，包括开源产品和商业产品。

Elastic-Logstash-Kibana (ELK) 是三个开源项目的堆栈——Elasticsearch、Logstash 和 Kibana。Elasticsearch 是一个高度可扩展的搜索和分析引擎。Logstash 为我们提供了一个服务器端数据处理管道，能够使用来自各种来源的数据。最后，Kibana 帮助我们可视化这些数据。总之，这个堆栈可用于聚合来自所有应用程序的日志等数据，并实时分析它们。

Prometheus 是一个开源的系统监控和告警工具，最初由 SoundCloud 开发。它带有多维数据模型、灵活的查询语言，并且可以通过 HTTP 拉取时间序列数据。Grafana 是另一种开源分析和监控解决方案，可与多个数据库配合使用。Prometheus 和 Grafana 一起可以让我们实时处理我们的系统能够生成的几乎所有指标。

7. DevOps 扩展（或者它们真的是！）

我们已经看到，从根本上说，DevOp 是一种持续的努力，旨在消除障碍，以实现更快、基于迭代的基于价值的软件交付。现在，一个直接的结论是这里不可能有最终状态。

人们认识到的开发和运营团队之间的摩擦并不是唯一的摩擦。打破组织内部的孤岛以增加协作是中心思想。现在，人们很快开始意识到类似的摩擦存在于开发和测试团队之间，以及开发和安全团队之间。许多传统设置都有专门的安全和性能团队。

除非我们能够打破团队之间的几乎所有界限并帮助他们更有效地协作，否则 DevOps 的全部潜力将永远无法实现。这本质上意味着将测试、安全和性能等团队纳入其中。

混淆主要在于它的命名法。DevOps 让我们明白它主要是关于开发和运营团队。因此，随着时间的推移，出现了新的术语，包括其他团队。但在很大程度上，它只是更有效地实现了 DevOps！

7.1. 开发测试运营

DevOps 的基石是以小增量和更频繁地交付高质量软件。这里对质量的强调有很多方面。从某种意义上说，我们经常假设我们采用的 DevOps 实践将帮助我们实现这一目标。而且，我们之前讨论的许多实践也确实专注于始终确保高质量。

但是软件的功能测试范围更广。通常，我们倾向于在软件交付结束时保留高阶测试，如端到端测试。更重要的是，这通常是参与流程后期的独立团队的责任。这是事情开始偏离 DevOps 原则的地方。

我们更应该做的是从一开始就在所有级别上集成软件测试。从计划阶段开始，软件测试就应该被视为交付的一个组成部分。此外，同一个团队应该负责开发和测试软件。这就是众所周知的 DevTestOps 实践。这通常也称为连续测试和左移。

7.2. 开发安全运营

安全性是任何软件开发不可或缺的一部分，并且具有一定的复杂性。这通常意味着我们有一个单独的安全专家团队，当我们准备好交付产品时，我们就会与他们接触。他们在此阶段发现的漏洞修复起来可能代价高昂。这又一次与 DevOps 的原则产生了共鸣。

到这个时候，我们应该已经有了我们需要应用的解决方案，那就是我们应该在游戏早期引入安全问题和人员。我们应该激励团队在每个阶段都考虑安全问题。安全无疑是一个非常专业的领域，因此我们可能需要在团队中引入专家。但这里的想法是从一开始就考虑一些最佳实践。

随着我们的前进，有几种工具可以自动扫描大量漏洞。我们还可以将其插入我们的持续集成周期以获得快速反馈！现在，我们不能将所有内容都集成到持续集成中，因为我们必须保持它的轻量级，但总是可以单独运行其他定期扫描。