什么是DevOps？它与软件开发中的其他想法和方法论有何关系？Linux Journal 副主编和资深软件开发人员 Bryan Lunduke 并不完全确定，因此他向一些专家请教，以帮助他更好地理解 DevOps 现象。

DevOps 这个词让我困惑。

我甚至不确定困惑是否足以表达我每次听到这个词时所感受到的痛苦——就在我大脑的中心。

并不是我不喜欢 DevOps；而是我真的不明白它到底是什么。让我来演示一下。以下是几分钟前维基百科上对 DevOps 的定义

DevOps 是一组软件开发实践，它结合了软件开发 (Dev) 和信息技术运营 (Ops)，以缩短系统开发生命周期，同时频繁交付功能、修复和更新，并与业务目标紧密结合。

我非常确定我仅仅通过复制和粘贴这句话就得了三个动脉瘤，但我仍然不知道 DevOps 到底是什么。也许我应该退后一步，介绍一下我的背景。

我的职业生涯始于 20 世纪 90 年代，当时我的第一份工作是软件测试工程师（这些人负责在软件发布之前找到软件中的错误，并告知程序员）。在随后的几年里，我的职位和职责逐渐演变，我尽可能地尝试了许多软件行业的职位头衔

• 自动化工程师：负责自动化软件测试的人员。
• 测试软件开发工程师：负责为测试人员制作工具的人员。
• 软件开发工程师：又名“编码员”，又名“程序员”。
• 开发主管：“嘿，你是一个优秀的程序员！你应该管理一些其他程序员，但仍然像以前一样编写代码，但是，别担心，我们不会给你大幅加薪！这会很棒！”
• 开发经理：像开发主管一样，但编程较少，管理较多。
• 工程总监：程序员经理的经理。
• 技术/工程副总裁：又名“负责做决策的大老板书呆子，当错过截止日期时第一个倒霉”。

在我担任各种花哨头衔的期间，我管理过的团队包括

• 系统运维：以前代表“系统操作员”，即运行和维护可访问网络系统的人员，但现在已被重新定义为“系统运营”，其定义非常混乱，似乎没有人能达成一致。
• 系统管理员：又名“系统管理员”，与系统运维类似，只是更新。
• 项目经理：负责记录项目需求，并帮助工程师、测试人员和团队中其他人员交付他们正在处理的任何内容。

所有这些都绕了很大弯子，只是想说，“我应该知道 DevOps 到底是什么意思。”

但我不知道。我真的，真的不知道。也许这是我大脑的缺陷。也许我只是来自计算机行业的不同时代，那时使用的词语和想法都不同。而且，显然，我并不孤单。如果你在 Google 上搜索“定义 DevOps”，你会得到超过 4300 万条结果。我点击了大约 4200 万条结果（尽管我通过 DuckDuckGo 进行了搜索），但仍然没有更接近理解这个术语的难以捉摸的含义。

幸运的是，我认识一些非常聪明的人，他们以某种方式从事 DevOps 工作。所以我向他们提出了一个简单的挑战

“向我解释 DevOps 的含义。如果不用任何流行语，可以加分。”

接下来是与四位“DevOps 专家”在几周内进行的精彩对话。为了让大家更容易理解，我从这些对话中提取了关键部分，并将它们编辑成一个半真实、半虚构的聊天，与一位 DevOps 专家进行对话，这位专家是他们四位的结合体。

我们叫他“Ted”吧。

注意：在接下来的内容中，会使用一些软件工程术语，有些读者可能不熟悉。当这种情况发生时，我已包含定义。

Lunduke：好的，Ted。什么是 DevOps？

Ted：维基百科将 DevOps 定义为“一组结合软件开发的软件开发实践”。

Lunduke：哇哦！得打断你一下。我已经读过维基百科的条目了。我读过文章和各种 DevOps 年度报告。我去参加过会议，看过演示文稿，幻灯片里充满了足以让我头晕目眩的流行语。用你自己的话告诉我。

Ted：幸运的是，DevOps 是一个简单的想法。将开发人员和运维人员整合在一起。

Lunduke：我假设我们不是在谈论公司内部传统的“运营”（供应链之类的东西）？首席运营官之类的？

Ted：不。更偏向系统运营。系统管理员的工作。

Lunduke：哦，好的。所以是开发人员与系统管理员一起工作？

Ted：还有 QA（测试人员）——每个参与软件开发生命周期的人员共同努力，以实现持续集成和更快的发布。

Lunduke：听起来像敏捷开发。另外，“持续集成”这个词说起来真让人痛苦——几乎和“增强企业协同”一样。

维基百科对敏捷软件开发的定义如下

敏捷软件开发是一种软件开发方法，在这种方法下，需求和解决方案通过自组织和跨职能团队及其客户/最终用户的协作努力而演变。它提倡适应性计划、进化式开发、早期交付和持续改进，并鼓励对变化做出快速和灵活的响应。

Ted：我知道，这是一个糟糕的术语，但这个想法仍然很好。至于像敏捷开发，有一些相似之处，但重点不同。敏捷开发更多的是让工程团队更容易、更快速地与项目经理和客户合作，而 DevOps 则是让工程团队与处理项目所需的所有 IT 基础设施（例如系统管理员）的人员紧密合作。

Lunduke：所以，我听到的意思是 DevOps 是一种说“系统管理员和工程师应该交谈”的方式。但这不可能是正确的。这是一个太简单（且显而易见）的想法，早在吉米·卡特总统之前就存在了（尽管并非总是付诸实践）。肯定还有更多内容；否则，就不会有专门针对 DevOps 的整个会议和公司。

Ted：围绕 DevOps 发展出了许多想法和最佳实践，以帮助团队取得成功，但这确实是基本思想。有时，为了更好地将开发与运维集成，两者会完全合并到同一时间和甚至相同的角色中。

Lunduke：这是一个如此简单的想法（并且在大多数计算机拥有 GUI 之前就已存在）。为什么需要一个新术语？当我经营自己的业务时，我同时戴着开发和系统管理员的帽子。从技术上讲，这让我成为 DevOps……事后看来？

Ted：是的。从技术上讲！但不要太在意这个术语。重要的是这个想法以及有助于促进它的最佳实践。简单地将其视为一组想法和工具，以帮助软件在开发和生产环境中正常运行。这也是一种确保工程师能够维护他们生成的代码的方式。

Lunduke：我觉得我的大脑中的一个电路正在被触发，因为我在这里寻找一些新的东西。从你描述的内容来看，DevOps 似乎是一个基本的想法（或一小组想法），它存在的时间比今天大多数工程师的生命还要长。也许如果你能给我一个 DevOps 式最佳实践的例子，那将有助于我理解这一点。

Ted：当然。一个明显的最佳实践是发布小的、增量的和频繁的更改。工程师、测试人员和管理员（或 DevOps 工程师）一起工作，快速发布微小的更改。这使得每次发布的风险和容易出错的可能性都降低了。并且它更快地将改进（即使是较小的改进）带给用户。

Lunduke：冒着让人恼火的风险（我知道，已经太晚了），这听起来完全像敏捷开发。每个参与生产的人都在同一个团队（或非常紧密地）工作，以便在快速的时间表上发布小的、迭代的更新。

Ted：除非它比敏捷开发更快——或者它可以更快。它肯定比瀑布模型更快。

维基百科对瀑布模型软件开发的定义如下

瀑布模型是将项目活动分解为线性顺序阶段，其中每个阶段都依赖于前一个阶段的可交付成果，并对应于任务的专业化。在软件开发中，它往往是迭代性和灵活性较低的方法之一，因为进度主要在一个方向（“向下”像瀑布一样）流经概念、启动、分析、设计、构建、测试、部署和维护阶段。

Lunduke：但从技术上讲，敏捷开发对你可以多频繁地发布没有任何限制。如果你愿意，你可以每天——甚至每小时——进行一次敏捷冲刺。

这是维基百科对冲刺的定义

冲刺（或迭代）是 Scrum（一种通常在敏捷开发中使用的框架）中开发的基本单元。冲刺是一项有时限的工作；也就是说，它被限制在特定的持续时间内。持续时间是为每个冲刺预先确定的，通常在一周到一个月之间，最常见的是两周。

Ted：敏捷开发与 DevOps 的争论将持续很长时间。幸运的是，DevOps 的核心思想是有益的。并且交流（在书籍和会议等中）的一系列最佳实践确实可以对工程团队有所帮助。

Lunduke：我的意思是，我想我明白了。它仍然听起来像敏捷开发（对我而言）。嘿，Ted，你能帮我个忙吗？

Ted：呵呵，当然，Lunduke。

Lunduke：你能以某种方式将 DevOps 与 Linux 联系起来吗？你知道，这篇文章是在 Linux Journal 上发表的。

Ted：嗯，我认识的大多数 DevOps 人员都运行 Linux——尤其是在服务器端。这算吗？

Lunduke：是的，是的，算。