世界快看：一条推特触动开发者神经：我们不想做运维！

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

  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云原生】公众号并回复关键词“志愿者”了解详情，你有机会获得图书，定制周边等礼物、年度志愿者证书及勋章发放、和专家近距离技术交流的机会.....

  北京市海淀区上地南路中博大厦8、9层 业务合作QQ：905 144 107