如今，我们很难定义 DevOps，因为它最初解决的问题早已消失。

对于一些新成立的公司来说，这个问题实际上从未存在过！他们做的一切都是正确的，但软件工程领域发展得太快了，工具和云工程填补了这一空白。

我们距离 DevOps 的最初时代及其旨在打破 Dev 和 Ops 之间孤岛的文化转变还很遥远。

开发和运营孤岛

2008 年，帕特里克·杜波依斯他首先想到了 DevOps，当时他正在研究项目管理刚刚从瀑布式转向敏捷的背景下开发和运营之间的低效协作。

当时的运营团队管理着从网络、服务器、虚拟机、操作系统到软件更新的一切。这实际上隐藏了很多手动操作。虽然不是所有操作都是手动的，但那是在 Puppet、Chef 和 Ansible 出现之前，甚至在 Terraform 出现之前。

管理服务器和软件发布并不是一件简单的事情，需要很多专业知识。这会妨碍快速、可靠地交付新软件版本。

云计算是孤岛消失的第一个迹象

AWS 成立于 2006 年，是第一家主要的云提供商。DevOps 诞生于 2008 年，其目的并非解决云管理问题，而是解决内部基础设施运营之间的真正孤岛问题。这是人们对 DevOps 感到困惑的根源。软件工程领域的两次重大转变大约在同一时间开始。

说到云计算，我们使用三种主要模型：软件即服务 (SaaS)、平台即服务 (PaaS) 和基础设施即服务 (IaaS)。由于我们一直在使用这些高级构造，OPS（系统管理）几乎已经消失。就好像 DevOps 之父发现的原始文化问题已不复存在。

每种模型都对底层基础设施提供了不同的控制、灵活性和管理级别，而且很少有公司会维护内部部署基础设施。

因此，虽然 DevOps 运动试图解决 Dev 和 Ops 之间的“孤岛”问题，但云基础设施已经通过淘汰 Ops而逐渐消除了部分问题。

无需操作，无需孤岛

DevOps 的关键理念是“左移”和“你构建它，你运行它”，这只能导致将 Ops 任务转移给 Devs。云通过提供 IaaS 模型减少了对系统管理员 (Ops) 的需求，降低了开发人员自己管理和部署应用程序的工作量。

我们可以换一种说法，让它听起来更好！Ops 通过提供工具来简化软件集成和部署，从而为开发人员提供支持，从而减少运营团队维护基础设施所需的繁重工作。结果，我们最终处于不需要系统管理 (Ops) 的境地。

但是，我们需要有人来维护这些“简化软件集成和部署的工具”。

这个新兴角色还没有名字，因为它是由前 Ops 带给你的，他们将其重新命名为“DevOps 人员”。我们称之为 DevOps 工程师。可能有人在某个时候这样称呼过，并且这个称呼一直沿用至今。

DevOps 重新定义自己

DevOps 从来不是关于工具的，而是关于文化的。其理念是软件工程也可以变得更加“精益”，软件交付可以及时完成。DevOps 最初的问题可能早已消失，但它催生了软件工程中最重要的理念：持续交付。

我一直支持那些声称 DevOps 不是一个角色或一个团队的人，如果你这样称呼它，那你就错了。后来，我意识到，事情要复杂得多。我们不合时宜地创造了一个角色，“维护工具以简化软件集成和部署的人”，但我们没有给它起名字。

想想看，如果一切都是云服务，你真的需要“维护工具以简化软件集成和部署的人”吗？完全托管？只需单击按钮即可完成？

这是大多数云提供商和许多 DevOps SaaS 产品（例如 GitLab）的梦想。事实并非如此简单。虽然理论上，事情本来可以很简单，Ops 任务可以自动化，服务可以完全管理等。但实际上，我们创造了一个怪物。

因此，大多数运营/基础设施团队（又名 Ops）面临的挑战是浏览无数工具和服务的地图，理解、部署并将这些工具连接到开发人员可以使用的连贯基础设施和工具中。

DevOps 坚持是那个关键的流行词，很容易衍生出：DevSecOps、FinOps、GitOps、MlOps 等。

但如果你注意到，残留的芳香总是 Ops。有趣的是，每种方法都旨在消除方程式中的 Ops。Ops 又名“登录系统并执行操作使其运行的人”。

总结

DevOps 最初想要解决的问题可能由于云基础设施的兴起而不再存在。然而，DevOps 催生了持续交付这一重要理念，并带来了软件工程的文化转变。

虽然“DevOps”这个术语可能一直是一个流行词，但它已经导致了 DevSecOps、FinOps 和 GitOps 等新方法的发展，所有这些方法的目的都是为了消除对传统 Ops 任务的需求。

最终，DevOps 和云基础设施的格局在不断发展，很难保持最新状态并选择正确的工具。具有讽刺意味的是，DevOps 最初意味着 Dev 和 Ops 之间的协作，但它已经转向将 Ops 排除在外。