运维没被云原生淘汰，反倒转身成了SRE，这变化真让人懵圈

运维没被云原生淘汰,反倒转身成了SRE，这变化真让人懵圈

记得以前提起运维,大家脑子里蹦出来的画面可能就是：蹲在机房插网线、搬服务器、半夜被报警电话叫醒去重启服务，整天干些“修电脑”和“救火”的活儿，那时候，运维工程师的核心技能可能就是熟悉各种硬件、会写脚本、能熬夜，可云计算一来，尤其是“云原生”这词儿火遍大江南北之后，好多人都觉得，服务器都看不见摸不着了，一切都由云厂商管了，运维这岗位是不是快要消失了？结果呢，现实来了个大转弯，运维不仅没消失，还换了个更时髦、甚至更重要的头衔——SRE（站点可靠性工程师），这弯转得有点急，确实让不少圈里圈外的人懵圈。

这变化到底是怎么发生的呢？得从云原生说起，云原生不是简单地把应用搬到云上，而是一套全新的玩法，它提倡用微服务把大应用拆成一个个小部件，用容器把这些小部件打包，用Kubernetes这样的工具自动编排管理，再搞什么持续集成、持续部署，这样一来，系统的复杂程度是指数级上升，以前可能就管几台大机器，现在动辄管理成百上千个四处跑的小容器，变化的速度也飞快，一天部署几十次都是家常便饭，这种环境下，传统“手工作坊”式的运维，靠人盯着、手动操作，完全跟不上节奏了。

（参考《云原生时代下的运维转型》一文中指出，云原生架构的动态、弹性和分布式特性，对系统的可观测性、自动化管理和故障自愈能力提出了前所未有的要求。）

这时候,谷歌公司早年提出来的SRE理念，正好撞到了枪口上，成了解决问题的“良药”，SRE不是什么全新的工种，它本质上就是软件工程师和传统运维思想的结合体，它的目标非常明确：保证大规模软件系统的可靠性，SRE工程师干的事，和传统运维有本质区别，他们不再满足于当“救火队员”，而是致力于“防火”，他们用写代码的方式来解决运维问题，把重复性的人工操作全部变成自动化脚本和工具，他们最核心的工作之一，就是定义和监控服务的SLO（服务水平目标），比如要求系统99.95%的时间可用，然后围绕这个目标，设计监控、制定应急流程、平衡新功能发布与系统稳定性的关系。

（参考谷歌《站点可靠性工程》一书及国内技术社区的解读，SRE的核心是将运维任务工程化，通过软件工程方法系统性保障可靠性。）

运维转身成SRE,不是名字好听，而是工作内涵发生了巨变，以前的运维，更像是系统的“保姆”和“修理工”，被动响应，现在的SRE，是系统的“设计师”和“医生”，主动参与系统架构设计，用工程化的手段预防问题，他们需要懂开发，能写高质量的代码来自动化一切；需要懂架构，理解微服务之间的复杂调用；需要懂数据，通过分析海量监控指标来洞察系统健康；甚至还需要懂一些产品思维，在稳定性和开发速度之间做出明智的权衡。

这让很多老运维感到压力山大,过去熟悉的命令和脚本不够用了，得去学Go、Python，得理解Kubernetes的原理，得掌握一堆可观测性工具，这感觉就像开了半辈子手动挡卡车，突然被要求去开全自动的航天飞机，仪表盘都不一样了，能不懵吗？但这也是大势所趋，云原生环境里，不稳定因素更多，故障传播更快，没有这种工程化、自动化和数据驱动的能力，根本没法保障业务的稳定运行。

（参考多位一线互联网公司SRE的分享，他们普遍认为，转型最大的挑战是从“操作型”思维转向“开发型”和“产品型”思维。）

那是不是所有运维都变成了SRE呢？也不是，更准确地说，是运维工作的“重心”和“高端岗位”向SRE演进，基础的服务器维护、网络保障等工作依然存在，但价值上限不高，而能够承担SRE职责的工程师，成为了保障现代云原生系统生命线的关键角色，他们站在开发与运维的交叉点，用软件工程的方法解决了云原生时代最大的难题——如何在快速变化中保持稳定。

云原生淘汰的不是运维,而是那些不愿改变、只靠手工操作的运维方式，它逼着运维人员跳出舒适区，去掌握更全面的技能，从被动支撑转向主动赋能，这个转身虽然让人懵圈，充满了挑战，但也打开了更广阔的职业天花板，运维不是没了，而是进化成了更强大的形态，成了那个在云原生世界里，为系统稳定性保驾护航的“关键先生”，这变化，乍看突兀，细想却是技术演进下的必然。