出品 | csdn云原生
(资料图片仅供参考)
声明：本文最初由scott carey在infoworld网站上发表。csdn将文章翻译成中文，分享给大家，转载请注明来源。
“谁创建，就由谁来负责运维”的要求让开发者们逐渐感到吃力，此外，运维团队也压力倍增。现在已经到了开发和运维再次分离的时候了吗？
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相关的成长阵阵痛中诞生的，它已被证明是一种流行的ag真人官方网的解决方案。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原则，都必须明白如何在软件开发和运维团队之间的保持平衡。正是这种微妙平衡的存在，使得云原生时代的复杂性越来越高。
想要csdn微信公众号以及博客文章署名发布 博客导流吗？想要参与到专家技术分享的一手整理过程中并获得相应权益吗？
关注【csdn云原生】公众号并回复关键词“志愿者”了解详情，你有机会获得图书，定制周边等礼物、年度志愿者证书及勋章发放、和专家近距离技术交流的机会.....
我们期待你的加入~
关键词：