运维开发的崛起，不是趋势，是三道压力的应激反应

2026 年互联网行业有一个明显的招聘转向：纯运维在消失，纯开发在收缩，运维开发在涨。

运维开发不是 DevOps 换个名字。DevOps 是一个文化概念——让开发和运维协作。运维开发是一个岗位定义——运维出身、写代码为生、写的不是业务代码而是运维平台和开源组件定制。

这个岗位的崛起，不是谁的战略部署，是三道压力同时挤压的结果。

第一道压力：中台解体后，基础设施能力下沉

阿里 2023 年「1+6+N」改革，字节 2021 年 BU 化，本质都是把集中式中台拆回业务线。

中台被拆之后，出现了一个真空：以前业务线找中台要存储、要消息队列、要服务治理能力。现在中台没了，这些能力谁来给？

答案不是「业务开发自己搞」。业务开发的主线是迭代需求，不可能同时维护一套 K8s 集群。于是，下沉到业务线的基础设施能力，实际上落在了嵌入业务线的运维开发身上。 他们不是中台，但他们在业务线内部扮演了「小中台」的角色。

这意味着：运维开发的工作量反而比中台时代更大了。中台时代有统一团队维护统一组件，现在每个业务线要自己维护一套。表面上裁了中台省了钱，实际上每个业务线都在重复造轮子。

从公司整体账来看，成本可能没降，只是从「中台预算」变成了「各业务线的运维开发工资」。

第二道压力：开源组件的定制成本在上升

Kubernetes、Prometheus、Grafana、Enovy——这些都是开源的，但不是拿来就能用的。

一个真实的例子：某中型互联网公司用了开源的 HPA（水平自动扩缩容），默认策略是基于 CPU。但它的业务特征是每天晚上 8 点流量洪峰，CPU 飙到 90% 只需要 30 秒。HPA 的默认冷却时间是 5 分钟——扩容还没生效，服务已经挂了。

这个问题有两种解法：要么招一个懂 K8s 源码的人改调度策略，要么买商业版。商业版一年几十万，招一个运维开发年薪也是几十万。

公司选了运维开发。不是因为他便宜，是因为他修了 HPA 还能顺便把日志采集链路优化了、把 CI/CD 和 Jira 打通了。边际价值在延伸。

开源组件的普及没有消灭运维，反而创造了新的运维需求——从「会用」变成了「会改」。 这个「会改」的能力，纯运维没有，纯开发也没有。

第三道压力：AI 在替代人，但不是替代你想的那种人

2026 年 AI 运维工具的能力已经不再是「报警」了。

Datadog 的 AI 能预测磁盘满的时间点。PagerDuty 的 AI 能自动归类告警、推荐处理人。K8sGPT 能分析集群故障并给出修复建议。

这意味着：「会看日志、会重启服务、会手动部署」的人，确实在被 AI 替代。 一个初级运维能做的事，AI 大多能做了。

但 AI 替代不了什么？替代不了一个运维开发写出适配自己业务场景的自动化系统。AI 能帮你写一个通用的 K8s 调度策略，但它不知道你们公司每天晚上 8 点有大促流量，不知道你们的核心交易链路不能被驱逐。

AI 加剧了运维领域的两极分化：底层纯操作岗位加速消失，顶层能做架构级自动化的人加速被需要。

三股力量拧在一起的结果

这三股力量搅在一起，就是你现在看到的：运维开发不是公司主动想培养的岗位，是这三股力量把传统运维逼到墙角后，不得不进化出来的形态。

进化成功的人，薪资涨了。没进化的，被 AI 或者更便宜的人替代了。

但这个岗位也有天花板

说完了好的，看看另一面。

运维开发的核心价值是「运维经验 × 开发能力」。但运维经验是有时效性的。 你今天精通 K8s 1.30 的调度策略，三年后 K8s 可能已经不是主流了。

纯开发的护城河是抽象能力——数据结构、算法、系统设计，这些东西可以横跨技术栈。运维开发的护城河是具体技术栈的深度经验——这个东西过期就过期了。

运维开发的高薪可能是暂时的溢价，不是永久的定价。

而且运维开发在组织里有一个尴尬的位置：既不是业务核心（不直接产生营收），又不是基础设施核心（不掌握底层架构决策权）。经济下行时，业务线裁人第一个看的就是「离营收最远的人」。

最后一句

运维开发的崛起不是趋势，是三道压力挤出来的应激反应。中台解体向下漏、开源组件深度定制门槛抬高、AI 替代初级操作向上顶——三股力量在同一个点上汇聚成了这个岗位。

你会写平台、会改源码，公司当然抢着要。但你要清楚，你今天值钱不是因为「运维开发」这四个字，是因为三股力量正好在那个时间点撞在了一起。

风口停了，你还值不值钱，看你是在追风口，还是在造翅膀。