AI 年度盘点与2025发展趋势展望,50+案例解析亮相AICon 了解详情
写点什么

“要什么 DevOps,我们开发者根本不想做运维!”

  • 2022-08-25
    北京
  • 本文字数:3677 字

    阅读完需:约 12 分钟

“要什么DevOps,我们开发者根本不想做运维!”

“谁构建、谁运行”的口号让开发者们倍感压力,但另一方面,运维团队的日子也不好过。那么,这场席卷全球的开发与运维融合浪潮会不会黯然退场?

 

根据外媒记者 Scott Carey 的观察,众多开发者纷纷表示“苦DevOps久矣”。我们将 Carey 记录的文章在不改变愿意的基础上进行了编译,以飨读者。本文谨代表作者个人观点,不代表 InfoQ 立场。面对争议问题,希望大家理智讨论。

 

“在大多数情况下,开发人员并不想处理运维问题。”亚马逊云科技社区参与负责人、《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 已死

 

如果 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

2022-08-25 14:5412639

评论 4 条评论

发布
用户头像
我们要做着运维的工作还没有devops用╮( ̄▽ ̄)╭
2022-08-31 12:25 · 浙江
回复
用户头像
我们开发做了一段时间devops,揽了一堆活不落好,慢慢又都推出去了
2022-08-30 09:12 · 辽宁
回复
用户头像
2022-08-28 14:47 · 浙江
回复
用户头像
天下大事分久必合,合久必分
2022-08-26 14:24 · 上海
回复
没有更多了
发现更多内容

JavaScript混淆工具选择与使用指南

达芬奇DaVinci Resolve Studio 18 for Mac 系统调色视频软件

iMac小白

数据安全之路:Databend 用户策略指南

Databend

工作中总结的30个常用Linux指令,实在记不住就别硬记了,看这篇就够了

快乐非自愿限量之名

Linux 运维 服务器

聚道云助力:易快报CDP无缝对接,登录同步一步到位!

聚道云软件连接器

案例分享

为什么Solana在区块链生态系统中脱颖而出

区块链软件开发推广运营

dapp开发 区块链开发 链游开发 NFT开发 公链开发

Golang DB连接池ErrBadConn的应用

三七互娱后端技术团队

golang MySQL

JMeter读取CSV文件实现参数化技术指南

霍格沃兹测试开发学社

中国超高清自有珠穆朗玛:双Vivid是什么?

脑极体

音视频

如何提升买家对独立站的信任感?提升转化率的技巧

技术冰糖葫芦

API 接口 API 文档

左手医生:医疗 AI 企业的云原生提效降本之路

阿里巴巴云原生

阿里云 容器 云原生

云原生最佳实践系列 4:基于 MSE 和 SAE 的微服务部署与压测

阿里巴巴云原生

阿里云 微服务 云原生

28+岗位!百度安全2025届实习生招聘火热进行中

百度安全

聊聊多模态大模型处理的思考

EquatorCoco

多模态 大模型

一文读懂兼顾隐私、高性能和可拓展的公链Partisia Blockchain

股市老人

JetBrains CLion 2023 for Mac 完美激活 好用的c语言软件

iMac小白

网站首屏优化 | 提升首屏的几个简单手段

观测云

性能优化 前端

掌握ADB:详解操作命令及完整用法指南

霍格沃兹测试开发学社

类似trello的局域网开源的软件

爱吃小舅的鱼

项目管理 项目管理工具 Trello

让 AI 帮你写代码,开发提效神器来了

阿里巴巴云原生

阿里云 AI 云原生

大模型落地实战指南:从选择到训练,深度解析显卡选型、模型训练技、模型选择巧及AI未来展望—打造AI应用新篇章

快乐非自愿限量之名

人工智能 AI大模型 大模型

【教程】JavaScript代码混淆及优化

雪奈椰子

浅谈开放词汇目标检测

inBuilder低代码平台

目标检测

深入了解 Docker Compose:简化容器化应用部署的利器

霍格沃兹测试开发学社

怎样让 API 快速且轻松地提取所有数据?

技术冰糖葫芦

API 接口 API 文档

小程序应用市场发展趋势分析

Onegun

小程序 小程序平台

【FAQ】HarmonyOS SDK 闭源开放能力 —Scan Kit

HarmonyOS SDK

HarmonyOS

无人不识又无人不迷糊的this

不在线第一只蜗牛

Java 前端 开发语言

移动应用开发工具及其影响

雪奈椰子

Partisia Blockchain:真正做到兼顾隐私、高性能和可拓展的公链

股市老人

“要什么DevOps,我们开发者根本不想做运维!”_文化 & 方法_Scott Carey_InfoQ精选文章