DevOps竟然是在远离Ops？

DevOps竟然是在远离Ops？ - 极道

DevOps 意味着 Dev 和 Ops 的协作，但他们从等式中删除了 Ops

如今，我们很难定义 DevOps，因为它最初解决的问题早已不复存在。

对于最近的一些公司来说，这个问题实际上从未存在过！他们所做的一切都是正确的，但相反，软件工程领域发展如此之快，以至于工具和云工程填补了空白。

开发和运营孤岛
早在 2008 年，当Patrick Dubois第一次想到 DevOps 时，他正在研究项目管理刚刚从瀑布式转向敏捷的环境中开发和运营之间的无效协作。

当时的运营团队管理着从网络、服务器、虚拟机、操作系统到软件更新的一切。这些技术包含了很多手动操作运维。

管理服务器和软件版本并不简单，需要大量的专业知识。会阻止快速可靠地交付新软件版本的东西。

云，筒仓消失的第一个迹象
AWS 诞生于 2006 年，是第一大云提供商。DevOps 于 2008 年被创造出来，并不是要解决云管理问题，而是要解决本地基础设施运营之间的真正孤岛。

这就是 DevOps 定义混乱的根源。

软件工程领域的两大转变几乎同时开始。

谈到云计算，我们使用三种主要模型：软件即服务 (SaaS)、平台即服务 (PaaS) 和基础架构即服务 (IaaS)。
所以 OPS（系统管理）几乎消失了。这就好像原来被 DevOps 之父们认定的文化问题不复存在了。每种模型都对底层基础设施提供不同的控制、灵活性和管理级别，很少有公司会维护本地基础设施。

因此，当 DevOps 运动试图解决 Dev 和 Ops 之间的“孤岛”问题时，云基础设施已经通过使 Ops 过时而逐渐淡化部分问题。

没有运维，没有筒仓
DevOps 的关键动机是“左移”和“你构建它，你运行它”，这只会导致将 Ops 任务转移到 Devs。

云通过提供 IaaS 模型减少了对系统管理员 (Ops) 的需求，减少了开发人员自行管理和部署应用程序的工作量。

运维人员通过提供简化软件集成和部署的工具来为开发人员提供支持，从而减少运维团队维护基础架构所需的繁重工作。结果，我们最终陷入了不需要系统管理 (Ops) 的境地。但是，我们需要有人来维护这些“简化软件集成和部署的工具”。

这个新出现的角色还没有名字。

DevOps 重新定义了自己
DevOps 从来都与工具无关；这是关于文化的。这个想法是软件工程也可以变得更加“精益”并且可以及时完成软件交付。DevOps 最初的问题可能早已不复存在，但它催生了软件工程中最重要的思想：持续交付。

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

DevOps 是关键的流行语，很容易衍生成：DevSecOps、FinOps、GitOps、MlOps 等。

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

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

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