本文要点

DevOps的核心前提是让开发和运维能够协作，以加快两者的速度。

在开发和运维之间使用相同的工具栈可以让他们产生共鸣并共享相同的语言。

“运维”是一个内涵丰富的概念，组织在进行DevOps转换之前，需要从业务和技术的视角理解它的含义。

尽管容器是一项伟大的技术，但是它也拉大了团队之间的距离。

在DevOps转换时，忽略运维人员是取败之道。

在DevOps的初期，当我们在欧洲举办第一次devopsdays会议时，感觉社区的一部分主要来自有运维背景的人，他们所讨论的是如何减少停机时间、加速部署和提高平台的稳定性，从而提高他们的生活质量。

接下来我将回顾一下在过去的十年间DevOps的简要历史（其中有像战争那样的故事），包括它的成就和缺点。

创新者接受开发和运维的协作

在2009年，我们中的很多人都遇到过这样的情景：开发团队将不可用的制件抛出了墙外并希望运维人员能够解决它。我们疲于处理开发团队所造成的副作用，而忽略了他们将代码提交到版本控制后需要发生的事情。

与此同时，老旧的手工运维已经无法满足我们的扩展需求了。借助虚拟化，组织正在从数台物理服务器转变成数百个虚拟机。在早期的devopsdays会议上，我们讨论的话题包括基础设施即代码、构建自动化、监控和度量的改善以及如何发挥敏捷、开源和云的威力。

而另一方面，社区的另外一部分人是想要变得更快的开发人员，他们将运维人员视为瓶颈。他们需要更好的平台、更快的响应时间以及更便捷的可扩展性。

这两组人都意识到协作才是前进的方向。开发人员如果不提前与运维人员讨论他们的需求，那么就不会得到他们想要的平台。同时，运维人员如果不提前与开发人员讨论他们的需求的话，运维人员也不可能得到易于在生产环境运维的制件。因此，筒仓（silo）被焚毁，而桥梁搭建了起来，来自整个组织的具有不同技能的人员开始在跨功能的团队中协同工作。软件交付对每个人来说都变得更加连续和平滑。DevOps的时代已经到来。

早期的采用者改变了他们的工作方式

随后，人们开始关注那些成功的DevOps早期实践者，并且想知道我们为何不能像他们那样工作，我们为何不能更快地交付，我们为何不能构建更稳定的平台。

第一个“DevOps转换”开始出现。大型组织想要和那些“酷”孩子一样。有些人意识到敏捷和交付速度对他们的业务至关重要。而其他人则只想雇佣已经在“做DevOps”的酷孩子。

这些大型组织意识到他们需要演进，这就迈出了第一步。但是，改变是很困难的，而且很多宣称成功的“DevOps转换”并没有达到预期。对于在一线工作的团队来讲，并没有什么根本的改变。

每个组织都有自己的挑战和历史。要达到幸福的彼岸，他们所要选取的道路也是不同的。但是，直到今天，我依然看到很到组织都声称他们想要改变，而在他们的转变计划中并没有将运维人员包含进来。将运维人员从对话中排除出去的话，他们该怎样“做DevOps”呢？在他们的DevOps转换中，运维人员该处于什么位置呢？

我参与的第一个项目是帮助一个组织实现“更加DevOps”，这是一家150人组成的SaaS平台公司，他们在部署到生产环境并保持其技术栈启动和运行方面遇到了严重的问题。他们高速增长，失去了对基础设施和部署的控制。他们所面对的是一片混乱，每个人都在互相指责。在这个过程中，我们所做的第一件事就是向运维人员讲解基础设施即代码以及持续交付。我们知道，在后续的流程中，运维团队将负责支持开发人员，以实现业务应用的持续交付。

现在，因为运维人员理解了CI/CD的基础知识，并且开始使用与开发人员相同的工具，所以在对事情的理解方面，他们有了共识。运维人员更好地理解了需要交付什么内容：制件应该是什么样子的，在部署中要涉及到哪些阶段，以及开发人员选择的工具如何提供帮助。开发人员和运维人员之间的鸿沟消除了，至少大幅度缩小了。双方现在使用共同的语言，使用相同的工具，并且朝着建立（更好的）协作和理解的文化迈出了重要的一步。

早期大多数人所识别出的局限性

我目睹的下一个大规模转变并不包含运维人员。在该组织中，甚至没有明确从DevOps的视角来看，运维到底意味着什么。有些人编写代码，而另外一些人则从业务角度（比如，在目录中添加新的产品）“运维”该应用程序。对于他们来说，将具有这两种技能的人组合到一个团队中就是DevOps，但是仍然没有人负责高度技术化的运维领域。我花了18个月的时间，终于遇到了一位工程师，从技术角度来看，我认为他有资格成为运维人员。

这位拥有深厚运维知识的人“忙于”在生产环境救火，而且在这个大型组织的DevOps转换谈话中，并没有将他包含进来。他在不同的大楼中为不同的法人实体工作，尽管是集团中的一员，但是他还是因为缺少动力而决定离职了。然而，组织却依然声称要进行“DevOps”。

在这个案例中，我们采取的措施是让一定数量的专家退出，他们实际上是工作流程中的瓶颈（如果你读过《凤凰项目》一书的话，会明白这就是书中“Brent”的角色）。我们要求他们基于Scrum的方式构建基础设施即代码的新组件。我们甚至带着他们去了另外一座城市，这样他们就不会被老同事打扰了。几个月之后，他们重新回到之前的团队，但是现在他们有了全新的工作方式。即便是最老的Unix系统管理员也变成了敏捷的布道师，他们都宣传技术设施即代码的方式，而不是手动为生产环境打补丁。

后期的大多数人过于关注工具

我最近为一家大型的金融机构进行了培训。我被拉过来对他们的DevOps转换进行健康检查。我很快就听到很多DevOps教练都提到他们不允许和运维人员交谈。他们告诉我运维是由另外一家公司负责的，这家公司并没有参与DevOps的转换过程。

我询问了高层管理人员，但是他们回答说，对此无能为力，因为这是总部做出的不可逆转的决定，而总部位于另外一个国家。他们不完善的解决方案就是在中间构建一个“DevOps团队”，该团队没有任何运维和开发经验，甚至不能访问生产环境。这个新团队将为整个组织建立一个持续交付管道，从而允许开发团队一直部署到测试环境，运维人员会从这里开始接管并手动部署一切。

这种方式的最终结果就是一个无人使用的工具栈，因为它并不匹配开发人员的需求。另外，他们依然需要为运维人员创建手工工单（ticket）来部署自己的服务。很多人决定离开该组织，包括本地的高层管理人员，他们都明白无法实现真正的DevOps转换。

我从这些（以及其他的）转换中得到的教训就是，我们需要超越工具的范畴，要将每个人都真正包含进来。如果在转换过程中不将运维引入进来，那么将永远无法填补开发和运维之间的鸿沟，带来的后果只能是浪费时间并损耗人们的积极性。

“这能够在我的工具上运行，接下来就是运维的问题了”

围绕采用DevOps所产生的问题并不总是单纯的组织问题，通常还会有工具的问题。并非所有的工具都能带来相同的收益。

最近，我看到很多组织都在宣称他们在采用DevOps，因为他们实现了工具X。但是，仔细看一下的话，工具X通常会让开发人员更容易，但是付出的代价则是隐藏了运维的复杂性。在如何管理工具X的讨论中，内部的运维团队通常会排除在外，他们会再次变得无比沮丧。我们重新回到了“开发 VS 运维”的思维模式，开发团队（和管理团队）声称运维人员在阻碍他们。工具X对于他们来说可能非常简单，但是他们忽略了监控、安全性、备份、扩展、度量指标、网络和许多其他的非功能性需求，而这些都是需要运维团队解决的。

不幸的是，这种痛苦模式的工具数量正在不断增加。在这十年的DevOps中，我们已经从“这能够在我的机器上运行，接下来就是运维的问题了”变成了“这能够在我的工具上运行，接下来就是运维的问题了”。我将其称为Dev-oops，而不是DevOps，其他的人则将其称为云原生。

让运维人员使用和开发人员相同的工具集，并让他们使用相同的模式，这样能够为他们提供一种通用的语言，可以实现更好的相互理解。正确地使用工具是提升组织协作的坚实基础。不过，如果工具选择是在隔离的情况下做出的，并且由不同的团队独立操作，那么可能会在团队之间造成更大的隔阂。

结论

尽管有了很多进步，但许多组织中的DevOps仍然处于起步阶段。我们要将如何提高开发质量整理出来，并引入核心实践，如基于主干的开发（trunk-based development）、测试场景等。

DevOps的基本前提是在开发人员和运维人员之间进行协作，调整他们不同的技能集以快速且安全地交付和运行，但许多组织仍然经常忽略这一点。

所以，十年来我们一直在说每个人都应该被包括在内，在任何DevOps转换中，讨论和路线图不仅要包括开发人员，还要包括运维人员。遗憾的是，事实并非如此。

希望在下一个10年，我们能解决这个问题。

作者介绍

Kris Buytaert是一位资深的Linux和开源顾问。他是DevOps运动的发起者之一，目前在Inuits工作。他经常在各种国际会议上发表演讲，或组织国际会议，并在不同的书籍、论文和文章中撰写了关于该主题的内容。他大部分时间都致力于弥合开发人员和运维之间的鸿沟，他强烈关注高可用性、可伸缩性、虚拟化和大规模基础设施管理项目，试图建立能够扛得住10楼测试（指的是在基础设施中任选一台机器，将其从10楼扔下，能够在5-10分钟之内恢复基础设施的测试——译者注）的基础设施，也就是今天所谓的云，同时积极推动DevOps的理念。他的博客名为“一切都是该死的DNS问题”，可以通过这里访问。

原文链接：Did You Forget the Ops in DevOps?

创作场景

DevOps 10 年：你是不是忘了 DevOps 中的 Ops