您好,欢迎来到LOVEBET爱博app!
LOVEBET爱博app
专注电气元件品牌销售服务
首页 > 爱博网站ApP
爱博网站ApP
全国服务热线
400-875-1500
销售热线:13720093566

扫一扫,添加销售经理

开发者强烈表示:“我们根本不想做运维!”

发布时间:2022-09-08 02:27:31
  • 产品介绍

  “谁创建,就由谁来负责运维”的要求让开发者们逐渐感到吃力,此外,运维团队也压力倍增。现在已经到了开发和运维再次分离的时候了吗?

  2000年代末,软件开始吞噬世界,DevOps与敏捷方法论随着云计算的兴起大行其道。作为“开发”和“运维”的组合,DevOps试图将先前负责构建和部署软件的两个独立团队聚集在一起。与此同时,软件工程师需要缩短用户反馈循环,提升生产环境下的更新频率,他们的这类需求也在无形中推动了开发和运维之间的结合。

  许多组织抓住了这个机会,将两方面的专家聚集在一起,尝试以前所未有的速度解决问题。但也有一些组织将Devops的兴起视为对开发人员负责运维任务的许可,并试图建立由全栈开发人员组成的超级团队。

  “在大多数情况下,开发人员不想处理运维问题。”《Devops for Dummies》作者、亚马逊网络服务社区参与负责人Emily Freeman在推特上写道。

  这条推特显然触动了全球软件开发者的神经,数百条同样抱有同样观点的开发人员的回复纷至沓来。

  “我是一名开发人员,我并不想处理运维问题。”快餐公司Chipotle的软件工程师Scott Pantall表示。

  SUSE的开发者布道者Andrew Gracey认为,开发和运维应该紧密合作,同时扮演不同的角色,团队之间的共鸣才是真正的重点。

  虽然将更多的运维和安全问题 左移到软件开发领域的做法具有显著优势,但它也有可能造成一个危险的瓶颈。

  “如果将开发人员拉到太多不同的领域,最终会自食其果。”Kubernetes存储专家Ondat的产品负责人James Brown说道。

  Harness的现场首席技术官Nick Durkin表示,人们现在开始逐渐意识到,电工和管道工确确实实是不同的职业。

  虽然企业软件开发人员的规模达到了历史新高,但大家对运维的关注度始终不高,即使运维的工作量正在不断地增加之中。

  正如Devops工程师、前系统管理员Mathew Duggan去年所说,“运维方依旧承担着之前职责,确保应用程序可用、受控、安全及合规,但是现在他们还需要额外负责构建和维护软件交付管道,保证开发人员在没有运维参与的情况下能够快速安全地发布代码。”

  这些不断扩大的责任会涉及到大规模的再培训工作,其中云工程和基础设施作为代码的技能变得至关重要。

  “在我看来,情况从未像现在这样惨淡过。运维团队的职责在不断增加,而管理层依旧对速度有着不切实际的期望,现已经完全不堪重负。”Duggan写道。

  戴尔技术资本的董事总经理Tyler Jewell在一份研究报告中说到:“要建立一个能够长期可持续发展的组织非常具有挑战性。随着系统复杂性和终端用户反馈的增加,人们很难准确预测某项变更可能对系统带来的影响。”

  情况可能并不像Duggan和其他人认为的那样毫无希望,但需要对工程团队及其职责做出重大调整。

  “转型的目的并不是要给开发者增加负担,而是让其在正确的时间获得正确的信息”,Harness公司的Durkin说,比起配置所有的东西,开发者最希望在正确的时间从系统中获得有效信息,以使运维、安全及基础设施团队能够正常工作。除非出现问题,否则开发人员无需关心运维工作。

  Walt Disney公司的前企业技术战略总监Nigel Simpson也希望公司能够认识到这个问题,并努力让开发人员摆脱“担忧机器应如何工作”的状态,回归到他们最擅长的构建软件上来。

  更重要的是,Devops是一个连续的过程,具体的实施会因组织而异。开发人员可以做一些运维工作,但并不意味着他们应该始终承担运维的压力。

  Gartner分析师Lydia Leong表示,开发人员对基础设施的控制并不是一个全有或全无的命题,这部分职责可以划分到整个程序生命周期中,只有这样才能从“谁构建,谁运维”中获益,而无需将开发者空降到一个他们并不熟悉的未知领域。

  正如Ondat的Brown所表态的,Kubernetes的容器编排正在成为开发和运维之间的分界线,关注这条分界线,能够让开发人员专注于自己的代码,并且让运维团队确保底层基础设施的优化与运行。“不要让我们的团队回到各自分离、互不交谈的状态。”Brown说。

  事实上,根据VMware的《2022年Kubernetes现状》报告,776 名受访者中有 54% 表示提高开发人员效率是采用Kubernetes的关键原因,此外有超过三分之一 (37%) 的受访者表示是为了提高运维人员效率 。

  Humanitec的创始人Kaspar von Grunberg在电子邮件中表示,“不要相信每个人都成为专家的谬论,在高效团队中,很少有Kubernetes方面的知名专家。”

  如果DevOps的时代真的走到了尽头,或者说其光彩已经开始褪色,那么接下来会发生什么呢?

  站点可靠性工程 (SRE)是 Google在遭遇与Devops相关的成长阵痛中诞生的,它已被证明是一种流行的解决方案。Google工程副总裁、SRE之父Ben Treynor坦言,“从根本上说,当你要求软件工程师设计一个运维功能时,就会发生这种情况(诞生SRE)。”

  以两家大型金融机构Vanguard和摩根士丹利为例,他们在向云原生实践过渡时发现难以平衡开发和运维之间的责任。此时,SRE就像开发团队和运维团队之间的过渡带,有助于公司建立信心,同时实现良好的开发速度和稳定的运营状态。

  然而,SRE也受到了一些批评。摩根士丹利的DevOps和企业技术架构负责人Trevor Brosnan说,建立SRE原则有时会被误解为要对运维团队的重塑。

  “这是一个需要解决的微妙问题,引入SRE确实让人们觉得我们正在分离运维团队。”Vanguard的站点可靠性工程师Christina Yakominn始终鼓励Vanguard的开发人员和运维人员分担安全责任,并确保拥有共享平台的团队承担全部的运维责任。

  内部开发人员平台已成为组织为开发人员提供所需工具的必要方式,也能通过配备适当的组织护栏隔离其他业务的影响,为开发人员提供更好的工作环境。

  内部开发人员平台通常由API、工具、服务、知识和支持组成,并由专门的专家团队或产品所有者对其进行维护。

  软件工程师兼Devops评论员Sid Palas在推特上写道,“DevOps已死,平台工程才是未来。开发人员不喜欢与基础设施打交道,而公司在成长过程中又需要控制自己的基础设施,只有平台工程才能使这二者统一共存。”

  软件咨询公司Thoughtworks的技术主管Brandon Byars表示,“平台工程团队的良好运作能够在消除开发人员摩擦的同时,让开发人员具备更高的灵活性。”

  任何组织若想在工程团队中实施Devops原则,都必须明白如何在软件开发和运维团队之间的保持平衡。正是这种微妙平衡的存在,使得云原生时代的复杂性越来越高。