作者|云赵Devops是一种围绕开发团队和IT运维团队营造协作氛围的文化。自提出以来，业内一直存在拥护者和质疑者两种声音。一方面，在劳动力成本上升、市场竞争日趋激烈、用户需求变化频繁的背景下，DevOps形成了一系列的理念、实践和工具，为企业提升了产品和服务的交付效率另一方面，DevOps被很多人调侃为“系统集成”、“软件堆叠”，实际落地难度很大。甚至有人认为DevOps运动失败了。DevOps确实有助于加快软件交付。它为企业项目团队带来了高度敏捷、减少劳动力、高效的跨职能团队协作、持续创新和最小缺陷。该工具的危险性已大不如前。DevOps的初衷：打破部门壁垒谈起DevOps，还得从DevOps之父——PatrickDebois说起。2007年，Patrick参与了比利时政府机构的大型数据中心搬迁项目。在这个项目中，他分别负责测试和验证。这意味着他不仅有机会和开发团队（Dev）一起工作，还经常要和运维团队（Ops）一起工作。在开发团队，他需要适应敏捷交付的节奏，但在运维团队，他又要遵循传统模式，像救火员一样维护系统。两种工作氛围的来回切换让他非常沮丧：不同的工作方式和思维方式必然存在巨大差异，所以在两者之间工作充满了冲突。应用在实际生产中会遇到各种未知的疑难问题，很难及时处理。这促使运维等相关人员参与到软件开发生命周期的早期阶段。作为敏捷开发的拥护者，Patrick果断做出调整，试图打破开发和运维的部门壁垒。而他所进行的敏捷管理实践，就是DevOps开发的第一个雏形。DevOps概念的形成有两个关键时刻，PatrickDebois和AndrewClayShafer在多伦多敏捷大会上的会面，以及JohnAllspaw和PaulHammond在Velocity'09上的演讲。经过讨论，DevOps的准确定义是Development和Operations的结合，是一组流程、方法和系统的统称，用于促进开发、技术运维和质量保证（QA）之间的沟通、协作和整合。部门。当时的概念很简单：修复文化。要使“DevOps”成功，所有相关方都需要参与。十几年过去了，现在看来，虽然企业多了“DevOps工程师”的职位，但在DevOps大会上失去了这个初衷：大量的运维和运维人员参与，而开发人员参与较少。DevOps实施难之谜随着DevOps的火爆，很多公司采取了比较残酷的做法：合并Dev和Ops团队，或者将运维交给开发。这是概念上的错误。此外，在客观条件方面也缺乏土壤。尤其是在微服务盛行的今天，系统被分成几十个甚至上百个服务组件。如果没有敏捷的基础设施服务作为前提，做DevOps基本上就是一句空话。这也是近年来DevOps难以落地的两个主要原因。这是一个真实的例子。LeeBriggs是一位资深专家和企业家，拥有15年的云工程技术经验。他曾经谈过一段关于DevOps的迷茫经历：一位负责开发产品的总监级同事提到他的团队是“真正的Devops”，从来没有和Briggs谈过他们的运营需求，而Briggs甚至不知道他们是什么这样做，只是他们使用AWSECS部署应用程序。Briggs感到困惑：如果他们甚至都没有参与，公司的运营团队怎么可能是“真正的DevOps”？后来在和自己团队的开发人员交谈后，Briggs明白了整个过程背后的意义：公司的开发人员接管了整个应用生命周期，一次性处理，不需要运维的参与——他们用boto3并编写部署脚本发布新版本，并聘请了精通AWS和后端业务的“全栈工程师”。DevOps的初衷纯粹是为了让开发者的工作更轻松。初衷是为了减少甚至消除他们在部署、管理部署等基础设施生命周期中的各种繁琐操作和麻烦。但是现在，当别人说“真正的Devops”时，他们的意思是让开发人员接管运维的工作。开发和运维都已经到位。今天，我们使用的是当今运维人员所熟悉的久经考验的工具来提供给开发者，包括GitLabCI、Terraform（Terraform是一个IT基础设施自动化编排工具，可以使用代码来管理和维护IT资源），当然还有Kubernetes。它就像这样：“嘿，你应该试试我们的平台！我们已经修复了所有这些错误，它比原来的工具要好得多。”“谢谢，但我们不感兴趣。”“呃，为什么？它更可靠、更快，并且使用行业标准工具。”“是的，但我们对他们一无所知。我们还是比较熟悉自己的东西。“运维人员一直相信他们的方法是有效的：毕竟，运维人员知道如何在云上运行软件。但开发人员通常不会为此付费。布里格斯陈述了这段经历——”运维人员总是试图说服开发人员来。参加DevOps会议。简单地解释一下您构建的平台的作用以及它将如何帮助他们。我一直在与开发人员的对话中争论不休，拼命地试图将“DevOps”的心态带到整个公司，而团队对这种心态的回应是‘我们自己做，谢谢。’”Briggs终于意识到：DevOps这种改变文化的尝试失败了。状态：沦为运维工具最后，Briggs对2022年的DevOps做了如下总结：DevOps现在更多的是从运维的角度出发和维护，试图说服开发人员以Ops的方式做事。很容易看出原因，当今市场上几乎所有称为“DevOps”的工具都专注于Ops层。如果你浏览/r/devops，你会请参阅另一篇关于操作或工具的文章。如果您查看DevOps工程师的职位描述，它看起来与2013年的系统管理员角色非常相似，除了不是旧的服务器机架和堆栈，而是一些容器或云提供商管理。所以如果DevOps应该是关于改变整体文化，它不能被认为是一个成功的运动。这个运动的牛市可能会高兴地说：“我们正在努力！“但事实上，他们明白他们在运维方面仅局限于单方面的努力——而这显然与DevOps最初强调的‘一条双路’背道而驰。值得记住的是，在任何给定的情况下项目或组织，运维人员通常至少占1/5，试图说服每个开发人员以“运维”和“使用运维工具”的方式进行开发，最终将成为傻瓜的差事。问题归结为它，术语“DevOps”，可能已经有点过时了。如果有人现在向你推销DevOps，它可能太过时了。我们真正想看到的是DevOps人们在他们的想法中的思考方式日常角色发生了根本性的变化，我们往往忽略了以下两点：1.DevOps人的第一本质是关注运维，角色定位是帮助开发者向客户交付功能（或者帮助发展rs实现其他业务目标）2.在向开发人员提供产品和功能时，需要小心：找到一条阻力最小的路径是保持速度的关键，开发人员学习和维护所有操作是不可扩展或不可行的做法。回顾DevOps最初的思路，重点是消除开发人员和运维团队之间的摩擦：让运维人员不再盲目地对开发人员说“不”，让开发人员不不再强制push运维人员上线。这些想法和目标仍然是崇高的，企业今天仍然应该追求它们，但DevOps的世界到底是什么样子的呢？如果我们同意“DevOps”是一种将开发人员带入运维世界的尝试，并且同意这种尝试在很大程度上已经失败，那么现在我们需要一个新术语。Briggs提出了一个新术语：“SoftOps”。SoftOps：SoftOps，软件开发人员的运维，听起来有点老生常谈，但概念是全新的。SoftOps的理念是重点是让开发人员更好地工作。Ops不会告诉他们该做什么，而是会询问他们在运营方面想做什么，然后让他们尽可能轻松。该术语来自Briggs在Pulumi的经历，他通过不同的视角看世界：以开发人员为中心。SoftOps是一种将开发人员作为主要客户放在第一位的想法。构建面向开发人员的操作实践应该（理论上）让开发人员参与进来，这样他们就可以一起工作。也许，如果我们只关注这个目标，我们最终会解决DevOps在2009年试图解决的问题。在这种新理念下，“下载这个工具，阅读这个48页的手册页，并告诉你的PM你错过了sprint截止日期”命令与开发人员对话场景将永远消失；此外，“把它给我，我会为你做”开发人员完成所有操作工作的日子已经一去不复返了。写于今年最后的三月，AbsoluteReports发布了《全球DevOps平台市场2022调查报告》。报告预测，到2028年，全球DevOps平台市场规模将从2021年的67.376亿美元增长至263.70亿美元。看起来2022-2028的复合年增长率是20.7%。从这些数字可以看出，DevOps是提高企业技术可靠性、保障业务稳定增长的利器，全球企业对DevOps工具的需求越来越强烈。从DevOps文化的角度来看，DevOps正在演变为一种让开发者使用新的运维工具的运动。但这种运动无疑有“背离”的迹象，这也是DevOps难以落地的根本原因：文化的缺失。如果不能转变观念，即使把员工放在一起，也只会增加两个团队之间的争吵。也就是说，DevOps考验的不仅仅是企业的技术，更考验的是管理水平和企业文化。Briggs提出的“SoftOps”概念改变了“全开发、全运维”的现状，想要重新梳理开发和运维流程的规范，让开发者能够在早期就对系统部署给出优化建议运维阶段。虽然名词变了，但是SoftOps和DevOps的初衷是一样的：减少开发团队和运维团队之间的摩擦，而不是一方接管，拒绝沟通，甚至干脆成为一种新的工具.参考资料：https://leebriggs.co.uk/blog/2022/06/21/devops-is-a-failure更多精彩技术文章可在精选技术期刊中获取，下载链接：https://www.51cto.com/journalDetail/6.html
