什么是 DevOps？我为什么要关注它？

DevOps 的定义最棒的地方在于：它有太多不同的版本可供选择。关于这个行业最新热门词汇，已经有很多文章、书籍和课程进行了探讨。围绕它还涌现出了网站、会议，甚至整个公司。

我们拥有思想领袖、实践者和试图跟上这股浪潮的人，但我们唯一缺乏的是对它究竟是什么的清晰定义。本文应该能让你对此有更清晰的了解。

这是解释 DevOps 实践系列文章的第一篇，我们将从宏观层面开始，逐步深入探讨。

那么，DevOps 到底是什么？   

DevOps 不是软件，也不仅仅是一种方法论，而是一种文化。它无法购买或下载，但可以学习。大多数定义都以运维和开发必须协同工作为出发点，并辅以自动化。但它的内涵远不止于此。

DevOps 不是：

• 仅仅是将一切自动化。
• 迁移到容器/微服务架构
• 持续集成

关于这一点有很多误解和迷思。你可能会听到这样的说法：

“加入一些 Kubernetes，这样我们就可以实现 DevOps 了！”

你不能仅仅部署容器、一些自动化工具和持续集成/持续交付（CI/CD）就说“我们现在就是DevOps了”。这些东西确实能实现DevOps，但DevOps更重要的是人，而不是技术。

“现在开发人员也兼任运维人员，反之亦然。”

虽然这没错，但通常被夸大了。这些群体之间的重叠比以前更多了，但角色仍然划分得很清晰。仅仅告诉工程师们现在必须自己配置机器，并不算是真正采用了DevOps。

DevOps 就是像大公司那样每小时发布一次产品。

虽然这可能是一个目标，但这只是DevOps文化整体目标的一小部分。每小时发布劣质代码并非进步。

DevOps 是：

一种思维模式和方法论：

• 促进沟通与协作
• 专注于快速IT交付
• 利用工具快速行动

DevOps 专注于利用反馈循环来缩短软件开发生命周期 (SDLC)，从而以更快的速度开发功能和修复错误。

DevOps 的一个重要方面是专注于更小、更频繁的版本发布。过去，我们发布新版本的软件可能需要数月甚至数年，而现在，我们只需几天甚至几小时就能完成。

我将重点介绍批量大小和在制品的概念，因为它们对这个过程非常重要。

DevOps 的总体目标是在不让工程师过度劳累的情况下提高速度和质量。

DevOps 的主要原则

DevOps 的主要原则在DevOps 的三种方式中得到了清晰的阐述。

方法一：系统思考

第一种方法是系统思维。它不关注快速的IT部门或快速的开发团队，而是将两者视为一个整体系统。他们的目标是以最快的速度将想法转化为实际功能。这就是你的价值流。其背后的理念很简单：一旦确定需要开发某个功能，开发人员就负责创建，IT部门则以最快的速度进行部署。   

自动化在这里发挥着重要作用，因为它能让你以最快的速度将代码推送到系统中。

成功后，你提交的代码会自动快速高效地推送、测试并集成到客户系统中。

方法二：放大反馈回路

第二种方法与建立反馈循环有关。开发人员将代码推送给运维团队，运维团队则提供关于该软件的反馈。然后，开发人员根据这些反馈修改或改进软件。如此循环往复。

以下是一些IT反馈示例：

• 速度
• 功能
• 测试结果

方法三：持续实验和学习的文化

第三种方法建立在现有反馈循环的基础上，并创建更多自我强化的反馈循环。它鼓励在短周期迭代中不断进行实验，从错误中吸取教训，并从改进中获益。   

实验环节至关重要。DevOps 是一个学习过程，它需要你尽快提出想法、付诸实践并从中学习。六个月的发布周期根本无法做到这一点，如果把时间浪费在软件迁移上，也无法实现这一点。

DevOps 创造了一种学习文化，这种文化以小而高效的工作负载为基础，并利用自动化将人们从繁重的工作中解放出来，让他们从事更有意义的工作。

那么，让我们来分析一些问题，看看我们为什么要费心采用 DevOps。

DevOps解决了哪些问题？

我从事IT和开发工作近20年了。更准确地说，我“还记得IT曾经是成本中心”的时候已经“入行”了。我还记得大约在2011年第一次听到“DevOps”这个词。我一位热情洋溢的技术朋友开始滔滔不绝地讲述IT运维和开发人员如何将职责合并，以及这将如何改变世界。

我的第一反应是“太棒了！我喜欢IT运维，而且我本身就是个开发人员。现在我居然可以配置机器了？简直完美！” 我可不是在讽刺，即使离开IT行业多年，我仍然对它充满热情。能以开发人员的身份参与IT相关工作，这个想法对我来说极具吸引力。这意味着我个人几乎没有抵触情绪，这或许也是我如此努力争取的原因。

我现在对DevOps的理解比以前更深入了，但我仍然觉得自己算不上专家。它本身就是一个不断发展变化的领域。不过，我确实看到很多变化都直接源于DevOps思维的采纳。

DevOps 的最大目标之一就是消除瓶颈

开发过程中一直存在瓶颈，而且将来也永远会存在。瓶颈可能出在人身上，可能出在技术上，也可能出在官僚作风上。DevOps 文化力求尽可能地减少所有瓶颈。

1. 释放节奏

你听过这句话多少次？

我们必须等到版本发布后才能专注于此。

由于批量生产规模庞大且需要大量人工部署，每次软件发布都是一件大事。团队已经仔细对缺陷和功能进行了分类，并决定了哪些内容将包含在下一个版本中。其他所有工作都暂时搁置。

除非在你开发新软件的六个月期间出现什么关键问题，否则一切都没问题。安全性和合规性问题就是其中之一。如果存在重大的安全漏洞，你必须立即编写补丁并修复它，而不是几个月以后。所以，作为一名优秀的工程师，你会想办法暂时把它集成到软件中。

随着这类问题越来越多，你眼睁睁地看着截止日期一再推迟，同时还要忙着进行紧急修复和实施，并将这些修复程序整合到新软件中。

DevOps 解决这个问题的方法是：让软件发布不再像以前那样引人注目。我们不再为了软件部署而给团队带披萨和蛋糕了。软件发布每周、每天甚至每小时都在发生。

通过将工作分解成更小的部分并不断整合，您不再需要等待数月才能实施更改。

2. 过度劳累的工程师

这句话怎么样？

我们得等简把这件事处理好。这还需要一段时间，她现在有很多事情要忙。

如果你在这个行业工作超过一周，你肯定认识这种工程师。你也可能曾经是这种工程师。他们对某个特定领域或技术了如指掌，以至于完全将其视为己任。

他们聪明、积极进取，对项目的成功乃至整个公司的成功都至关重要。他们可能是基础设施工程师、开发人员，或者担任其他各种角色，充当软件的“把关人”。

这种瓶颈会给你的团队带来诸多问题。没有他们的参与，软件就无法快速迭代。更重要的是，他们工作过度，牺牲了与家人朋友相处的时间，并且长期处于压力之下。这会导致他们出现健康问题，甚至可能最终离开公司。

DevOps 如何解决这个问题：打破信息孤岛，将责任分配给更多团队成员；将工作分解成更小的任务，从而优化流程。这减轻了任何个人在推动工作流程方面的压力。

3. 非计划基础设施请求

我需要一台服务器，在我们拿到服务器之前，我们无法继续进行下去。

我职业生涯早期从事的是资产配置工作。以下是我的通常工作流程：

• 收集需求
• 设计服务器
• 订购零件（如果手头没有的话）。
• 组装机器
• 给它装上操作系统
• 配置软件
• 在架子上找个地方。
• 插上电源
• 为需要的人提供访问权限

我以前每天都要重复做这些事。别误会，我很喜欢这份工作，但我也很高兴现在我们不用再这么做了。这些工作很费时间，我记得以前可以同时操作大约5台机器，后来就开始出错，遗漏细节了。

去年，我获取服务器的过程与现在大不相同。

• 收集需求
• 启动 Jenkins，选择一个配置文件
• 必要时添加一些参数
• 点击按钮
• 获取服务器的 IP 地址

如果我需要登录 Azure 并在那里部署，流程也大同小异。

猜猜哪个耗时更长？现在虚拟化和云平台正在解决这个问题，但DevOps是其发展的重要驱动力。

DevOps 如何解决这个问题： DevOps 文化倡导一切自动化，包括服务器配置和容器部署。过去我们像给宠物起名字一样给服务器命名，现在我们像给牲畜编号一样给它们编号。它们应该是通用设计的实例，而不是特殊的个体。

4. 测试阶段速度减慢

修复程序还需要一到两周才能发布，目前还在测试阶段。

测试和质量保证曾经是一个糟糕透顶的过程。我记得开发过的软件好几个月都没正式发布。这部分是由于老式的瀑布式开发模式一次性发布大量软件，部分原因则是测试耗时过长。

这并非测试人员的错。我们一次性把一大堆软件塞给他们，还附带了一份长长的功能和修复bug清单……大概吧。迭代规模如此之大，以至于当测试人员发现bug时，我们已经在上面叠加了一大堆软件。所以，到那时，回归问题已经普遍存在了。

DevOps 如何解决这个问题：这里有两个关键的改变：

• 批次大小：较小的批次工作量意味着更低的风险，并且每次只需检查一个小型功能或缺陷。测试完成速度更快。

• 自动化：借助 DevOps，现在很多测试都实现了自动化，您可以编写代码、提交并观看它完成整个测试流程。然而，人工测试并没有过时，因为他们参与了测试自动化的构建，并在过程中进行抽查。

DevOps 让测试人员能够更高效地工作。

大局

DevOps可能会给你的组织带来巨大的文化变革。然而，在当今时代，它至关重要。

• 企业创新速度比以往任何时候都快。
• 技术准入门槛比以往任何时候都低。
• 你可以在不牺牲质量的前提下提高速度。

这就是大家都在谈论DevOps的原因。这也是为什么人们争相采用新技术的原因。

这是DevOps系列文章的第一篇，我将在此解释DevOps原则以及如何应用这些原则。我们将探讨一些用例和实践，帮助您作为开发人员、运维人员或经理，充分利用这场文化变革。

如果您想在此期间了解更多关于DevOps的信息，

• 阅读《DevOps手册》
• 了解一下Pluralsight 的 DevOps 课程路径
• 请在 Dev.To 上关注我，以便接收未来文章的通知。

注意：12 月我将举办一场题为“实现低风险发布”的网络研讨会，届时我将探讨如何运用 DevOps 原则来提升发布速度。如果您想参加，请在此注册！