云原生和DevOps已成熟,时候让运维集体下岗?

2022-03-23 15:53:50cloudliangmin来源:cloudliangmin
史上最牛网导读: 明人不说暗话:在云原生和DevOps成熟的今天,运维作为一个岗位和团队已经完成了历史任务,应该退出舞台了。 没人招聘运维岗了 我不是说正在吭哧吭哧写脚本搬机器的运维同事们马上就会被补偿N+1护送出数据中心,但是确实,

明人不说暗话:在云原生和DevOps成熟的今天,运维作为一个岗位和团队已经完成了历史任务,应该退出舞台了。

 

没人招聘运维岗了

 

我不是说正在吭哧吭哧写脚本搬机器的运维同事们马上就会被补偿N+1护送出数据中心,但是确实,运维岗位的招聘越来越少了。以Scania为例,这家卡车制造商并不是Spotify那样的先进IT企业,但是他们的IT部门已经停止招聘Ops岗位了。扩展到Scania所在的瑞典斯德哥尔摩市,基本已经不再看到运维岗位的招聘了,而对DevOps岗位的需求激增。

 

那么,为什么呢?原因也很直白:传统专职运维团队的工作任务,在现代工具的帮助下,已经可以由开发团队更好更快更便宜的实施了。

 

发版本的运维被机器取代了

运维届老兵王津银先生在《运维自动化平台深度解码》讲述:“运维是有很多种场景的,但从业务的角度来说,核心的几种业务场景就那么几种,如:业务上线、业务下线、业务扩容、业务缩容、应用升级等五种”。

 

其中业务上线下线升级三个场景,不客气的说,一个持续部署管道就可以取代了。尤其有了Docker技术后,CI/CD变得非常容易。如果你不想管理Jenkins,gitlab甚至提供pipeline as a service。国内阿里云也有持续集成与交付解决方案。我身边的案例,K公司共有1000个微服务,每天部署一千余次,全部是由Dev团队触发cd pipeline完成,并不需要运维团队参与。实际上,这个公司根本没有运维团队。

 

而业务扩容和缩容(两者实际上是一个场景),通过云厂家提供的Auto Scaling服务,可以做到完全自动化,既不需要Ops,也不需要dev参与。上述K厂家的基础设施部门的员工,往往答不出“你们部门有多少台虚拟机”这个简单问题,原因就是他们重度依赖AWS Auto Scaling和Application Auto Scaling两个服务做自动扩缩容,以至于他们已经不太关注虚拟机数量,就像各位运维已经回答不出“你们部门有多少个进程”一样。

 

在工具如此成熟的今天,如果还有运维团队的价值建立在王先生描述的五个场景下,CIO可能需要对自己的组织架构做一个严肃的检讨:汽车都这么成熟了,我为什么会养这么多马夫在拉马车?

 

运维已经无力保障系统可靠性

上述引文中,王先生遗漏了一个更重要的场景:保障系统可靠性。

新版本发布并不是软件生命周期的终点,而只是持续迭代中的一个小环节。与发布版本同样重要的一个工作是保证软件能以满意的SLA对目标客户提供服务。

 

为了这个目标,谷歌特意创造了Site Reliability Engineer这个岗位<此处请自行脑补Site Reliability Engineering, The Site Reliability Workbook和Building Secure & Reliable Systems三本SRE圣经的图片>。很多聪明的运维工程师,自己缝一个SRE的帽子戴上,出门都神气很多了。

 

但是在微服务流行的今天,SRE也力不从心了。原因有三:

  1. 微服务数量巨大,设置专职SRE成本巨大。一个SRE能理解25个服务的话,5000个微服务需要200 * 3(三班倒)总计600个SRE, 这个成本不是一般的大。有些不太遵守劳动法规的公司,自然就在人头上动脑筋,于是我们就经常看到运维岗位的招聘广告里有“吃苦耐劳,积极完成领导交代的其他工作任务”之类的奇葩需求。
  2. SRE对服务的了解有限。在快速迭代的今天,50%以上的故障是软件bug造成的,而SRE由于不参与应用服务的开发,对软件bug天然的缺乏敏感度,这就导致SRE很难快速处理大部分故障。实际上,在《The Site Reliability Workbook》的一个案例中,SRE们忙活了20多个小时,交接了三个SRE团队,怀疑了七八个方向,最终却还是dev团队找到并且修复了自己的bug。
  3. 另外,由于SRE不参与开发,而Dev不对可靠性负责,两个团队天然有目标冲突。我们经常看到的是,Dev写的日志和业务指标基本是摆设,该有的没有,不该有的一大堆,其根本原因就是:Dev在可观测性上拉稀,并不影响自己的生活之类,SRE会来擦屁股,而倒霉的SRE擦了屁股也还是无法影响Dev拉下一场稀。
  4.  

对于如何解决这两个问题,业界观点比较一致,就是让Dev承担起Ops的责任,称DevOps。让Dev对SLO负责,会驱动他们在设计和编码阶段投资于可维护性,降低后期维护成本。这表现在几个方面:

  1. 开发者会更积极的拆分巨型单体应用。
  2. 开发者会更多的建设可观测性:提升日志的信噪比,更主动的输出业务层指标,以及开启分布式追踪。
  3. 开发者会更多管理上下游依赖,避免非关键依赖妨碍关键流程。
  4. 开发者会更精准的建设监控系统,比如引入Monitor as code提升监控质量。
  5.  

实施上述动作之后,再结合成熟的可观测性平台,Dev一般就可以兼任Ops工作了。这个模式下,不论是发版本的速度,还是平均故障恢复时间(MTTR),都能得到显著的提升。

有兴趣的朋友可以去翻阅《Accelerate: The Science of Lean Software and DevOps》和Google每年发布的《DORA's State of DevOps report》,可以看到更系统的阐释。

 

运维的其他工作任务也消失了

我手头有一本赵旻先生的《IT基础架构系统运维实践》,算是比较权威的运维工具书,我们逐一打开运维还有什么工作内容:

一部分是数据中心,硬件的管理和维护(第二,三,五,六,十二章),毫无疑问,已经被公有云厂家彻底替代了。对于非云厂家的IT公司,此类知识不过是屠龙之技。所以,此处不需要运维了。

一部分是建设包括域名解析之类的基本IaaS服务(第七,八,九,十,十一章)。现在都2021年了,显然选用云厂家的成熟服务,成本更低,稳定性更好。所以,此处不需要运维了。

一部分是最佳实践(第四章网络规划和第13章信息安全),这本就不是工作内容,在云时代,应该是Infrastructure架构师做决策,而开发工程师予以实施。所以,此处不需要运维了。

最后一部分是性能调优。这其中硬件调优工作已经转移到了云厂家,而留存的软件调优,显然dev更在行。所以,此处不需要运维了。

综上所述,没有哪个地方需要专职运维了。

 

在运维圈子,一直流传一个半开玩笑的笑话:运维的一部分功能就是替开发团队背锅。对CIO来说,这其实是一个组织架构上的失败。为了避免这种甲团队犯错打乙团队板子的错置,取消运维团队,显然是一个釜底抽薪的办法。

 

革自己的命和被别人革命

现在是2021年,DevOps已经发展出很成熟的最佳实践,云服务也得到了广泛的应用,云原生这个大框架并没有给专职运维团队留下位置。

 

我的朋友老王顶着一个运维总监的头衔,使用他的云原生王四条,在过去几年,把自己的运维团队彻底干没了,把自己干成了一个光杆司令。我问他为什么?他说“历史潮流浩浩荡荡,顺之者昌逆之者亡,与其别人来革我的命,不如我自己先下手”。现在的四条·王,已经脱下了背锅侠的外壳,快快乐乐的戴上了Infrastructure Architect的帽子。

 

而按另外一个朋友李老板的说法,“决定CIO裁不裁掉运维团队的,不是运维团队,也不是CIO,而是市场上的竞争对手。”

手机互联网第一神卡:100多款APP应用免流的流量卡,免费送上门,优惠活动中~~~咨询客服专员!!!

咨询客服专员

抢沙发坐
  • 全部评论(0
    快来抢占沙发

抖音快手 热门资源 Site 最牛网 娱乐大家 超级最牛 世界之最 最排行榜 最牛发明 吉尼斯最 中国十大 世界十大 最奇葩事 最牛视图 流量套餐

免费领取,点我 -- 热门手机app免流量抖音、快手 、腾讯、B站、王者吃鸡 →手机靓号,点我 豹子号、顺子号、情侣号、老板号、生日号、车牌号、心水号、吉祥号
Copyright © 2008-2021 ;史上最牛,每日牛谈资讯.
内容,广告,资源,产品,合作QQ:569400131
粤ICP备13064609号-2