是时候让运维集体下岗了-CSDN博客

本文链接：https://blog.csdn.net/Python_0011/article/details/140096255

明人不说暗话：在云原生和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也力不从心了。原因有三：

微服务数量巨大，设置专职SRE成本巨大。一个SRE能理解25个服务的话，5000个微服务需要200 * 3（三班倒）总计600个SRE，这个成本不是一般的大。有些不太遵守劳动法规的公司，自然就在人头上动脑筋，于是我们就经常看到运维岗位的招聘广告里有“吃苦耐劳，积极完成领导交代的其他工作任务”之类的奇葩需求。

SRE对服务的了解有限。在快速迭代的今天，50%以上的故障是软件bug造成的，而SRE由于不参与应用服务的开发，对软件bug天然的缺乏敏感度，这就导致SRE很难快速处理大部分故障。实际上，在《The Site Reliability Workbook》的一个案例中，SRE们忙活了20多个小时，交接了三个SRE团队，怀疑了七八个方向，最终却还是dev团队找到并且修复了自己的bug。

另外，由于SRE不参与开发，而Dev不对可靠性负责，两个团队天然有目标冲突。我们经常看到的是，Dev写的日志和业务指标基本是摆设，该有的没有，不该有的一大堆，其根本原因就是：Dev在可观测性上拉稀，并不影响自己的生活之类，SRE会来擦屁股，而倒霉的SRE擦了屁股也还是无法影响Dev拉下一场稀。

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

开发者会更积极的拆分巨型单体应用。

开发者会更多的建设可观测性：提升日志的信噪比，更主动的输出业务层指标，以及开启分布式追踪。

开发者会更多管理上下游依赖，避免非关键依赖妨碍关键流程。

开发者会更精准的建设监控系统，比如引入Monitor as code提升监控质量。

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

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