出品 | 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相关的成长阵阵痛中诞生的，它已被证明是一种流行的解决方案。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云原生】公众号并回复关键词“志愿者”了解详情，你有机会获得图书，定制周边等礼物、年度志愿者证书及勋章发放、和专家近距离技术交流的机会.....
我们期待你的加入~
关键词：
营业执照公示信息