Devops - 全景

问题

假设 Ahmed 在一家公司工作，这家公司的成功取决于比竞争对手更快地向在线客户提供新颖且令人兴奋的产品。现在 Ahmed 是一名开发人员，他负责为新产品、新功能、错误修复和产品安全更新编写代码。不幸的是，Ahmed 需要等待数周才能将他的工作部署到生产环境。这种延迟增加了保持竞争力的压力，因为一些竞争对手能够更快地部署新产品和新功能。此外，这种延迟使得开发人员很难同时管理待部署到生产环境的代码以及他负责开发的下一个功能。

当 Ahmed 的代码部署到生产环境时，偶尔会出现一些未预见的错误和问题。这通常是因为 Ahmed 只专注于在开发环境中编写代码，而开发环境与生产环境并不完全相同。

现在 Operations 团队开始发挥作用，Zunair 加入了 Operations 团队，他负责生产服务器 99.9% 的正常运行时间。随着公司开发的产品数量不断增加，Zunair 很难维护所有服务器。因为他用来管理所有服务器的工具并不是非常高效。这给 Zunair 将新代码迁移到生产环境带来了挑战。一旦新代码部署完成，他就需要负责监控这个新更改在生产环境中出现的所有问题和错误。Zunair 必须在生产环境中的每个构建上执行所有冒烟测试。

有时，也会出现以下情况，团队需要管理四种不同的环境，例如

1. Dev
2. QA
3. UAT
4. 生产

质量保证工程师必须在不同环境中对应用程序执行各种冒烟测试。这需要整个团队花费大量时间和精力。有时，发货中会出现很多问题，QA 需要通过在环境中运行这些发货来识别所有类型的问题。假设 QA 环境在运行该发货时出现问题，那么 QA 会将问题报告给开发团队，然后开发人员必须付出新的努力来解决该问题。当开发人员确信一切正常后，它将在 QA 环境中运行，并在 QA 环境中通过冒烟测试后。质量工程师在 UAT（用户验收测试）环境中运行该发货，如果一切正常，则将其部署到生产环境，否则问题将反馈给开发团队。

这就是团队花费大量时间和精力的地方。

时间消耗

从上面的例子中，我们可以得出将事物部署到生产环境需要花费多少时间。在软件开发中，跟踪 bug 始终非常重要。越早跟踪产品中的 bug，花费的时间就越少。我们在开发过程中跟踪代码中的 bug 是最省时的情况。

现在假设有 bug 的代码进入 QA 环境，QA 或测试工程师发现代码中的 bug 并将其报告给开发人员。在这种情况下，比第一种情况花费的时间要多。

现在假设测试工程师没有发现代码中的 bug，并且 bug 进入了生产环境。客户报告了错误和应用程序的奇怪行为。然后，客户将问题反馈给产品团队。在这种情况下，将花费团队大量的时间和精力。

什么是 DevOps？

所以，DevOps 出现以解决上述所有问题。DevOps 本身并不是任何软件工具的名称。它基本上是一种文化。它是工作的一种心态。互联网上有很多关于 DevOps 的定义。但我只想引用 2 个清晰的定义。

DevOps 是人员、流程和产品的结合，以实现向最终用户持续交付价值。

(Donovan Brown)

DevOps 集成了开发人员和运营团队，通过自动化基础设施、自动化工作流和持续衡量应用程序性能来提高协作和生产力。

如果您逐字阅读这两个定义，那么事情就会自动变得清晰。DevOps 帮助开发人员和运营团队使产品更加成熟。我们一直在寻找解决方案和策略，以如何快速将我们的产品交付给客户。

为了提高效率，工程师开始关注 **自动化**，因为只有自动化才能实现自动化，并且可以节省大量的人力成本和时间。

传统与现代方法论

您可能已经注意到，在我们的行业中，许多组织正在朝着敏捷的工作方式发展。这意味着我们在过去几十年中所采用的瀑布式方法正在逐渐消失。我们正处于一次重大的范式转变中；我们正在从工程思维方式向制造思维方式转变，以实现软件交付。

软件工程中的传统与现代方法论

传统	现代
瀑布模型	敏捷模型
用于需求、开发、测试和运营的不同团队或组织单位	多学科团队，所有学科共同协作完成一小部分交付
业务与 IT 之间明确分离（需求/供应）	业务、开发和运营在一个团队中
每年发布软件 2 或 3 次	每天发布多次
预算/成本驱动	价值流驱动

那么，在继续前进之前，我们首先讨论这些差异。在软件行业，传统的方式是我们一次性收集所有需求，然后遵循完整的 SDLC。敏捷的方式是迭代和增量方法发挥作用。这就是为什么在敏捷中，需求经常变化，并且总是欢迎变更。在敏捷中，最优先的是满足客户。

在传统方法中，有需求工程师、开发团队、测试团队等不同的团队。在现代软件开发方法中，客户直接与开发人员联系，以减少沟通差距，并根据客户的真实和实际需求制作产品。

在传统方法中，收集需求的业务团队与负责提供产品的 IT 团队之间存在明确的分离。在现代方法中，所有这些事情都集中在一个地方。

在经典且古老的传统方法中，只有 2 或 3 次软件发布成功，但在现代方法中，我们每天可以发布多次功能。

因此，我们所有人都需要遵循敏捷方法论并尝试跳出固有思维来加快进程，这一点非常重要。

敏捷与 DevOps

大多数时候，人们会感到困惑，甚至认为 DevOps 是新事物。有时，他们甚至对敏捷和 DevOps 之间的区别感到困惑。

实际上，正如我已经提到的，DevOps 并不是新事物。如果我们阅读敏捷宣言，我们可以从中了解敏捷和 DevOps 的理念。

“我们最优先的是通过尽早、持续交付有价值的软件来满足客户。” **(敏捷宣言)**

因此，从宣言可以得出结论，当敏捷运动开始时；他们已经明确声明了有价值软件的持续交付。而持续交付就是关于创建可重复、可靠的流程，以便快速向客户交付有价值的软件。并且为了实现持续交付，我们需要 **自动化** 几乎所有事情。

但是敏捷和 DevOps 仍然是两个不同的东西。敏捷基本上弥补了业务/需求工程师和开发人员之间的差距。

图片：Guru99

而 DevOps 弥补了软件开发人员和 IT 运营团队之间的差距。

图片：Guru99

DevOps 剧本

在敏捷中，有预定义的流程，如 Scrum 和 XP，用于在组织中实施敏捷。同样，对于 DevOps，虽然还没有非常成熟，但以下是最常见的流程。

人员/流程/时间

在此流程中，我们识别负责工作职能的人员组，然后定义这些人执行的流程，然后指定工具。这可能对您来说很明显，但有时工程师和技术经理会反过来操作，先购买工具。

持续部署

这是以非常小的批次频繁地编写代码、测试和发布软件的实践，以提高质量。

**持续集成** 是自动构建、单元测试整个应用程序的实践，理想情况下，这发生在每次源代码签入时。**持续交付** 是将所有更改部署到生产环境并对代码执行自动和集成测试的实践。**持续部署** 是自动部署到生产环境的实践。

大多数时候，以上三个术语都用于相同的概念。它们之间没有太大区别。如果我们深入研究持续交付，您将看到更大的图景。

借助源代码控制，在我们签入代码后，代码将在管道中构建，并且所有相关的单元测试都会随该构建一起运行。如果所有测试都通过并且代码验证 OK，那么它将打包完整的构建，然后形成构件。稍后我将解释构件。

最佳实践

在构建时，有一些重要的注意事项需要我们注意。

1. 构建应在 5 分钟内完成

   构建花费的时间越长，人们自然等待的时间就越长，直到他们拥有大量更改的批次，这会增加您的在制品。

2. 始终提交小型更改
3. 不要让构建失败

   如果测试用例失败或代码无法编译，那么构建将失败，并且不要让构建失败。如果构建失败，您将阻止交付。停止所有会议和所有团队任务，直到构建修复为止。

4. 不要允许奇怪的测试

   您可能经历过有人编写的代码有时有效有时无效。所以代码有问题。不要写这样的测试。

一旦您规划好了您的 CD 管道，请始终跟踪更改。并问自己两个问题。

1. 您能否跟踪整个系统的更改？（周期）
2. 您的更改能从开发转移到生产的速度有多快？（周期时间）

所以我们应该有指标，代码从开发到生产需要多长时间才能流动。这一点也很重要，因为如果您阅读 DevOps 的定义，DevOps 工程师的职责也是衡量应用程序的指标和性能。并尝试改进它。

精益管理

精益制造或精益生产，通常简称为“精益”，是一种在不牺牲系统生产力的情况下，最大限度地减少生产系统浪费的系统方法。日本人在提高生产力方面非常进步。精益技术最初是由 **丰田生产公司** 引入的。精益的主要目的是提高生产力，缩短时间，并减少产品浪费。

让我们讨论一下丰田生产公司为提高生产力而遵循的一些技术。

安灯卡

这是精益制造原则。在这种技术中，在丰田生产公司，如果一名员工在生产中发现任何类型的错误或浪费，他会尝试消除该错误。如果这种浪费有可能转移到产品中，他/她就会拉动安灯卡。拉动安灯卡后，整个生产停止，然后所有工厂都试图消除这种可能对公司声誉造成严重损害的严重问题。

根据丰田金融公司的数据，拉动安灯卡后公司损失 100 万美元。但如果这种浪费或错误进入生产和产品，那么公司可能会损失数亿美元。这就是为什么安灯卡技术对于确保产品质量非常重要。

无责事后复盘

系统总是在持续的失败后成熟。如果您想使事物更具生产力和强大，那么面对失败是必要的。因为失败帮助我们学到更多，做得更多。人没有错，而是流程错了。在精益管理中，最佳实践之一是，如果系统中发生任何由于某人造成的失败，而不是责备他并让他沮丧，而是让整个团队对事件进行无责事后复盘。他们记录发生的一切以及如何发生，然后所有团队都从中学习。这就是他们互相尊重并使团队环境变得更好的方式。

持续改进（Kaizen）

在这种技术中，团队主要专注于不同类型的实验和学习。他们互相分享想法和问题。他们积极参与对他们来说有效和无效的事情。这就是他们通过学习和尝试新事物来掌握技能的方式。

精益管理严格遵循丰田生产系统，但现在也正在软件行业中实施。如果您想了解如何实施精益技术；这里有一本详细的书供您参考（Lean Software Development (Agile Toolkit)）。

蓝/绿部署

如果您阅读过不同类型的部署模型，那么其中一种方式是蓝/绿部署模型。

实际上，在我们的现实生活中，不同的团队在同一个产品上工作。这是现代时代，一天内会发生不同的提交批次，或者我说不同的软件版本发布。那么，要跟踪哪些更改会影响我们的整个系统将非常困难。所以有了蓝/绿模型。

在该模型中，我们有两种类型的服务器。1 是实时服务器（蓝色），第 2 个是暂存服务器（绿色）。最初，流量流向实时服务器，当我们想发布一批功能时，我们将这些新功能更改部署到我们的绿色服务器。

图片：蓝绿部署

然后，我们在绿色服务器上运行冒烟测试，以检查一切是否正常。当所有测试都通过后，我们将流量路由到我们的绿色服务器。当绿色服务器出现任何错误时，流量将路由回蓝色服务器。这就是我们更新应用程序服务器中更改的方式。

底层的持久层（数据库）在两个服务器后面是相同的。这就是蓝绿部署的工作方式，并帮助我们跟踪生产环境中的任何错误，并且我们可以轻松地回滚我们的更改。

混沌猴

正如我们已经知道的，DevOps 工程师的职责也是跟踪系统的性能并衡量系统的正常运行时间和停机时间指标。

**Netflix** 是一家媒体服务提供商，其整个系统基于现代技术。它使用 AWS（Amazon Web Services）云为我们的客户提供媒体服务。

那么您可能在想，混沌猴是什么？

图片：混沌猴 Quora

Netflix 工程师编写了用于影响生产服务器的脚本。这段代码是开源的，可以在 github 上找到。现在，当混沌猴影响服务器时，Netflix 工程师会与这种猴子灾难作斗争，并保持服务器正常运行。混沌猴会随机关闭服务器。这就是 Netflix 工程师如何测试系统免受意外中断和意外故障条件的影响。

正如我在本文前面提到的，如果我们想使系统成功，那么我们必须面对失败并与之斗争。如果我们不面对问题，那么成功的机会非常渺茫。人没有错，而是流程错了。所以我们必须使我们的流程强大。

自动化

正如我们已经讨论过的，DevOps 是快速向客户交付有价值产品的名称。如果我们想快速完成工作；那么我们必须自动化我们的流程。而这里，自动化就发挥了作用。

借助自动化，我们可以自动化事物。这里有一些自动化的例子

1. 基础设施即代码 (IaaC)
2. 自动化测试（单元测试）

基础设施即代码

IaaC 是一种技术，通过这种技术，我们可以以编程方式配置新资源，甚至可以维护和配置新资源。

如果您有任何云（Azure、AWS）的经验，当我们创建资源时，我们可以看到用于配置资源的 IaaC 模板。例如，Azure 有 **ARM**，AWS 有自己的。所以这些 JSON 模板用于配置新资源。这就是 IaaC 如何在我们的现实生活中提供帮助。

当我们使用 DevOps 时，我们需要在不同时间点使用服务器，并且您可能有经验，当我们使用新服务器并部署应用程序时。大多数时候，我们的应用程序会失败，因为我们新获取的服务器配置不同。如果服务器数量很少，例如 2 或 3 台，我们可以手动配置它们，但假设您正在开发企业级应用程序，并且我们需要一次性配置数百甚至数千台服务器。所以我们唯一的选择是使用 **IaaC** 方法在几分钟内配置所有服务器。

**Cheff、Puppet、Ansible** 是 IaaC 自动化的例子，它们主要用于配置管理。我们将在接下来的系列文章中探讨所有这些工具。

自动化测试

因此，自动化测试就是单元测试的另一个名称。当我们遵循 DevOps 编码实践时，我们必须编写单元测试。我们提交带有正确单元测试用例的代码。然后在 DevOps 管道中，我们的测试运行并生成构建。这就是我们如何自动测试我们的应用程序，应对各种场景。我们可以编写单元测试，也可以编写我们应用程序的行为驱动测试。

这就是自动化在 DevOps 中的作用。

CI 工具链

如果我们讨论 DevOps 的开源工具，市面上有许多工具。不同的组织正在使用不同的工具，甚至一些组织编写了自己的工具来实现不同类型的操作。

如果我们谈论仪表板或 **面板**，我们可以在其中管理项目的冲刺和待办事项列表，那么我们有最佳选择 **JIRA** 和 **Trello**。如果我们谈论运行测试和构建我们的软件产品，那么我们将拥有 **Jenkins** 这个市场上的最佳选择，它非常有名且流行。如果我们谈论版本控制系统，那么 **Github** 没有竞争对手，它用于维护公共存储库；如果我们想维护本地源代码控制，那么我们有 **GitLab** 和 **BitBucket** 的选择。如果我们想部署功能产品，那么我们有 **XebiaLabs Deploy** 和 **Octopus Deploy** 的选择。

还有许多我还没有提到的工具。所有这些工具都很棒。

Azure DevOps

Azure DevOps 是微软提供的一种 SaaS（软件即服务）服务。以上所有功能，如看板、测试、版本控制、部署和软件产品的构件制作。我们都可以用 Azure DevOps 来完成。Azure DevOps 是所有这些功能的集合。

**Azure DevOps Boards**，您可以在其中协作完成创建软件产品所需的工作。看板专注于提供一个协作环境，该环境适合根据敏捷和 DevOps 工作方式工作的团队的需求。

**Azure DevOps Repos** 用于源代码控制。在这里，我们有两个选项可以使用 **Git** 和 **TFVC**。我们可以将所有更改提交并跟踪到 Repos。

**Azure DevOps Pipelines** 为我们提供了一种为任何平台和低级语言执行 CI 构建的方式。它提供了一个 Web 界面，我们可以在其中创建作业来为您的软件创建生产构件。

有两种类型的管道。

1. **构建管道**：用于构建软件产品。
2. **部署管道**：用于将软件部署到任何目标平台（GCP、AWS、Azure）

**Azure DevOps Test Plans** 为您提供了一种将测试完全集成到您的敏捷方式中的方法。我们可以跟踪测试的需求。我们可以针对来自部署管道的特定部署运行探索性测试。

**Azure DevOps Artifacts** 就像软件的版本。您可以升级具有由管道构建的最新版本的构件，如果您发现任何缺陷，那么您可以轻松将其回滚到之前安装的构件。这就是 **DevOps Artifacts** 的魅力。

构件的另一个优势是，假设您在软件中使用了某个节点包，而这个节点包存在某种 bug，影响了我们的一些产品功能。所以如果我们从构件中删除该包，下次当我们再次安装它时，构件会自动处理这个问题，并下载并安装我们之前安装的节点包的先前版本。这就是 **DevOps Artifacts** 的美丽之处。

注意

Azure DevOps 最美妙之处在于，我们可以使用 Azure DevOps 来维护我们的产品，甚至可以在任何平台上部署我们的应用程序（如 Azure、AWS、GCP、IBM 等）。这完全取决于客户的选择。如果我们只需要 DevOps 工具套件中的少数工具，那么您也可以只使用特定的工具，并且只需按使用量付费。

结论

DevOps 团队试图自动化一切，从新代码的测试到基础设施的配置。在 DevOps 实践中，我们以小块代码的形式编写软件，而不是一次性上线所有功能。在传统方法中，我们编写大量代码并花费数月时间进行测试。编写小块代码可以提高部署频率并缩短部署新代码的时间。它还使我们能够通过迭代过程来监控和衡量，以每天改进代码和运营。我们不需要手动配置软件和硬件资源，而是可以使用 DevOps 工具在几分钟内配置我们的系统。这就是我们如何为公司节省大量团队时间。借助 DevOps，我们主要专注于业务，而不是做所有事情。

DevOps 是一种新的哲学，可以帮助软件组织更快地创新，并更能响应业务需求。它促进开发人员和运营之间的协作，从而提高软件质量并加快软件发布速度。

历史

• 2019 年 4 月 9 日：初始版本