“在大多数情况下，开发人员并不想处理运维问题。”亚马逊云科技社区参与负责人、《DevOps for Dummies》作者Emily Freeman在推特上坦言。
一石激起千层浪。Freeman 的观点引起了广泛共鸣，几百条抱有同样观点的开发人员纷纷留言回应。
“我就是个开发者，我不想处理运维问题。”快餐公司 Chipotle 软件工程师 Scott Pantall 直接表示。
“我确实更喜欢回到只需要掌握特定编程技巧的时候，而不是现在这样成为一个万事通，因为多个责任分散了我太多精力。这两者都是全职工作，而我只能各自投入一半的精力。”开发者 Mitchell Abbott 说道。
SUSE 开发人员布道师 Andrew Gracey 认为，开发人员和运维人员应该密切合作，同时各自扮演不同的角色，能够让团队成员相互理解的同理心才是 DevOps 的真正核心。
“强迫开发者身兼太多任务，最终只会搬起石头砸自己的脚。不同场景对应着不同的技能组合。”Kubernetes 存储技术提供商 Ondat 的产品负责人 James Brown 表示。
“人们慢慢意识到，电工和水管工确实不是同一个职位。”Harness 公司专项 CTO Nick Durkin 说道。
当然，也有开发者人认为，当自己全面负责代码、基础设施和监控时，通常会感到自己很有能力。“这就是全才和专家的区别吧。”
2000 年代后期，DevOps 与敏捷方法随着云计算的兴起而大行其道。作为将开发与运维合并起来的新理念，DevOps 希望打通这两支以往长期孤立的软件构建与部署力量，实现“1+1>2”的积极效应。与此同时，当时的软件工程师也恰好需要缩短用户反馈循环、提升生产环境下的更新推送频率，这也在无形中推进了开发与运维间的融合。
不少组织敏锐把握住了这个机会，将两方面的专家汇聚起来，试图以前所未有的速度解决种种常见问题。但也有一些组织把 DevOps 解读成了“让开发人员负责运维工作”，并据此描绘出一个白日梦般的超级概念——全栈开发人员。
但开发运维受到很多限制。网友“beall49”表示，“我厌倦了一切东西像是从钥匙孔里获取，它令人筋疲力尽。”
“有时，你会得到一台被公司严格锁定的开发机器（硬件加速设置已关闭并且没有密码无法使用，严格的操作系统安全策略禁止你从公司存储库以外的任何地方安装软件等），你不能甚至使用虚拟化，使用这台机器就是你进入公司网络的方式。”开发者“FloRup”补充道。
同时，随着企业软件开发者的总体规模达到历史新高，大家对运维侧的关注度却始终不高。更可怕的是，随着软件开发的增长，运维工作量实际上也始终在同步攀升。
正如 DevOps 工程师、前系统管理员Mathew Duggan去年的观点，虽然运维人员继续承担着之前的所有职责，确保应用程序可用、受控、安全和合规，但现在他们还得负责构建和维护软件交付管道，确保开发人员在无需运维介入的情况下，快速安全地发布代码。
要干的活越来越重、要上的再培训课程越来越多，特别是云工程和基础设施即代码技能，几乎成为当前运维从业者们的必修课。
“在我看来，情况已经恶化到了历史极点。运维团队的职责范围大幅增加，但管理层还是对速度提出不切实际的要求，整个体系已然不堪重负。”Duggan 写道。
事实上，压力带来的恶果正开始显现。
戴尔技术资本董事总经理 Tyler Jewell 在一份研究报告中提到，“要想建立一支能够长期、和谐保持这种稳定迭代水平的团队，其实是个巨大的挑战。随着系统复杂度的提升和最终用户反馈的增加，人们已经很难准确预测某项变更可能给系统造成的影响。”
当然，情况可能并没 Duggan 等人描绘的那么糟糕，但对工程团队及其职责做出重大调整确实非常必要。
“转型的目的不是要给开发人员增加负担，而是在正确的时间为开发者提供正确的信息。”Harness 公司的 Durkin 表示，“开发者最需要的不是额外的配置任务，而是在正确的时间能从系统中快速获取必要信息，这样就能支持运维、安全和基础设施团队的正常工作。除非出现问题，否则运维元素就不应该出现在开发者的视野当中。”
迪士尼公司前企业技术战略总监 Nigel Simpson 也希望公司能认识到这个问题，并努力让开发人员摆脱对底层基础设施的担忧，重新回到自己最擅长的软件构建上来。
更重要的是，DevOps 代表一个连续的统一体，其具体实施会因组织而异。现在的开发者能做一点运维，并不代表他们就该每天都承担运维压力。
Gartner 公司分析师Lydia Leong认为，开发人员对基础设施的控制，并不是“要么全做、要么彻底不做”的命题。企业可以把这部分职责划分到整个应用程序生命周期当中，只有这样“谁构建、谁运行”才能发挥积极作用，而不是把开发者空降到一个他们既不熟悉、也难以驾驭的陌生环境。
粗暴把基础设施和运维团队的问题抛给开发者，不会带来任何好处。 Leong 表示，更好的办法应该是放手让开发人员自行访问开发和测试环境，并为他们赋予将基础设施构建为生产代码模板的能力。这才是重点，而不是让他们全面负责生产。
在云计算领域，Kubernetes 容器编排正在成为开发与运维之间的边界。关注这条边界，就能让开发者集中于自己的代码，并让运维人员确保底层基础设施和管理的运行与优化。“但这种独立是以沟通和理解作为基础的，并不是以往那种孤岛式的各自为战。”Ondat 公司 Brown 说道。
事实上，根据 VMware 公司发布的《2022 年 Kubernetes 现状》报告，776 名受访者中，54%的人采用 Kubertnetes 的关键原因就是要提高开发者效率，另有超过三分之一（37%）的受访者称是为了提高运维人员的效率。
“千万别相信那种‘人人都能成为专家’的谬论。在高效团队中，其实很少会有所谓专门的 Kubernetes 专家。这些团队只是通过极高的抽象度着力缓和了每位成员的认知负担。”Humanitec 公司创始人Kaspar von Grunberg表示。
如果 DevOps 的时代真的走到了尽头，或者至少走过了辉煌时期、来到新的转折点，那接下来事情将如何发展呢？
站点可靠性工程（SRE）诞生自谷歌内部，当时搜索巨头遭遇到了 DevOps 希望解决的成长阵痛。现在来看，这个职位确实能有效平衡开发与运维间的矛盾。谷歌工程副总裁、SRE 之父 Ben Treynor 曾经坦言，“从本质上讲，如果要求软件工程师设计一项运维功能，那结果就是 SRE。”
以 Vanguard 和摩根士丹利两家大型金融机构为例，他们在向着云原生实践过渡时，就发现越来越难以平衡开发和运维两端的职责。而 SRE 就像是缓冲层，把它铺在集中运维团队和各开发者团队之间，就能帮助各方建立信心，感受到既保持良好开发速度、又获得稳定运营状态的可能性。
有开发者现身说法道，“我们有 SRE，他们为我们构建了很好的工具并维护应用程序的基础设施。我们仍然自己做几乎所有的日常部署和运维工作，但是 SRE / 基础设施团队已经做得很好了，我们只需要担心会发生什么而不必担心要如何做。”
然而，SRE 也受到过不少批评。摩根士丹利的 DevOps 和企业技术架构负责人 Trevor Brosnan 就提到，建立 SRE 原则“有时会被误读为要对运维团队进行大洗牌。”
“这是个需要解决的微妙问题。引入 SRE 确实会让人有种正在再次剥离运维团队的感觉。”但事实并非如此，Vanguard 站点可靠性工程师 Christina Yakomin 就一直在鼓励公司的开发者和运维人员分担安全责任，并把运营需求整体交由共享平台团队承担。
如今，不少企业开始尝试建立内部开发者平台或者平台工程部门，这样既能给开发人员提供必要工具，也能通过适当的组织护栏隔开其他事务对开发和运维造成的影响。
内部开发者平台往往由大量 API、工具、服务、知识和支持所构成，目的是为开发人员提供代码生产部署所必需的一切助力。至于平台本身，则由公司专门的专家团队或所有者负责维护。
软件工程师兼 DevOps 评论员 Sid Palas 在推特上写道，“DevOps 已死，平台工程才是未来。开发者不想跟基础设施打交道，企业在发展过程中又需要控制自己的基础设施。只有平台工程，能将这两个相互矛盾的命题统一起来。”
“平台工程部门的实际表现确实不错，能够在消除开发流程摩擦的同时，赋予开发者充分的灵活性。”软件咨询公司 Thoughtworks 的技术主管 Brandon Byars 表示，“一旦把这些工作硬塞给缺乏专业知识和工具支持的开发者，情况就会迅速恶化。”
因此面对新的历史阶段，要想在工程团队中贯彻 DevOps 原则，组织首先需要了解怎样在软件开发与运维团队间寻求平衡。正是因为这一微妙平衡点的存在，才让云原生时代的系统复杂性越来越高。
原文链接：
https://www.infoworld.com/article/3669477/devs-don-t-want-to-do-ops.html
关注微信
