是时候让运维集体下岗了
明人不说暗话：在云原生和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》，可以看到更系统的阐释。
运维的其他工作任务也消失了
我手头有一本赵旻先生的《IT基础架构系统运维实践》，算是比较权威的运维工具书，我们逐一打开运维还有什么工作内容：
一部分是数据中心，硬件的管理和维护（第二，三，五，六，十二章），毫无疑问，已经被公有云厂家彻底替代了。对于非云厂家的IT公司，此类知识不过是屠龙之技。所以，此处不需要运维了。
一部分是建设包括域名解析之类的基本IaaS服务（第七，八，九，十，十一章）。现在都2021年了，显然选用云厂家的成熟服务，成本更低，稳定性更好。所以，此处不需要运维了。
一部分是最佳实践（第四章网络规划和第13章信息安全），这本就不是工作内容，在云时代，应该是Infrastructure架构师做决策，而开发工程师予以实施。所以，此处不需要运维了。
最后一部分是性能调优。这其中硬件调优工作已经转移到了云厂家，而留存的软件调优，显然dev更在行。所以，此处不需要运维了。
综上所述，没有哪个地方需要专职运维了。
在运维圈子，一直流传一个半开玩笑的笑话：运维的一部分功能就是替开发团队背锅。对CIO来说，这其实是一个组织架构上的失败。为了避免这种甲团队犯错打乙团队板子的错置，取消运维团队，显然是一个釜底抽薪的办法。
革自己的命和被别人革命
现在是2021年，DevOps已经发展出很成熟的最佳实践，云服务也得到了广泛的应用，云原生这个大框架并没有给专职运维团队留下位置。
我的朋友老王顶着一个运维总监的头衔，使用他的云原生王四条，在过去几年，把自己的运维团队彻底干没了，把自己干成了一个光杆司令。我问他为什么？他说“历史潮流浩浩荡荡，顺之者昌逆之者亡，与其别人来革我的命，不如我自己先下手”。现在的四条·王，已经脱下了背锅侠的外壳，快快乐乐的戴上了Infrastructure Architect的帽子。
而按另外一个朋友李老板的说法，“决定CIO裁不裁掉运维团队的，不是运维团队，也不是CIO，而是市场上的竞争对手。”