裁员潮里唯一在招的人：能做运维、也能写平台的运维开发

互联网公司现在到底在裁什么人、招什么人？

裁的是纯开发。中台开发、业务开发、那些需求不饱和就闲着的人。

招的是运维出身，但能写代码的人。 不是写业务代码，是写运维自己的平台——定制开源组件、搭建自动化运维系统、建内部开发者门户。

为什么？

因为运维团队自己也面临减员。以前 5 个运维管 200 台机器，现在让你 2 个人管 500 台。纯手工运维的人撑不住，必须自己写工具替代自己。

这就是运维开发的本质：不是开发来学运维，是运维在自我进化。

传统运维为什么活不下去了？

传统运维的工作模式是「等」。等告警、等工单、等开发扔过来一个要部署的包。

这种模式下，运维的价值和人数成正比。机器多了加人，业务多了加人。加不起了就压榨存量——晚上睡不好，周末不敢关机。

问题的根源不是「运维不重要」，而是运维的工作方式没有杠杆效应。一次手动部署花 10 分钟，部署 100 次就要 1000 分钟，线性增长，没有边际成本递减。

开发之所以值钱，是因为代码有杠杆——写一次，跑无数次。运维之所以被裁，是因为没有杠杆——每次操作都要人亲自动手。

所以真正的出路不是让开发来干运维，是让运维学会造杠杆。

运维开发到底在干什么？

不是写 Spring Boot，不是写 React 页面。

是这三件事：

第一，定制开源组件。

Kubernetes 是开源的，Prometheus 是开源的，Grafana 是开源的。但开源的默认配置不是为你公司设计的。运维开发的工作是：读懂 K8s 调度器源码，改掉那个让你业务晚上 8 点卡顿的调度策略；给 Prometheus 写一个 exporter，把业务自定义指标暴露出来；把 Grafana 的告警模板改造成适合你业务链路的样子。

这不是开发能力的问题，是运维经验 × 开发能力的乘积。 你只有运维经验，你知道问题在哪但不知道怎么改源码。你只有开发能力，你不知道该改什么。

第二，搭建运维平台。

不是买一个成品。是国内大部分成品运维平台，落到具体业务场景里就是「80% 功能用不上，缺的 20% 没有」。运维开发要做的是用开源组件拼出自己的平台——GitOps 工作流、自服务部署门户、自动化故障处理。

字节跳动的运维中台就是这条路走通了的典型。他们自研了 ByteEye（监控）、BytePlan（容量规划）、ByteMesh（服务网格），每一个都是运维团队自己写出来的，不是找开发团队要的。

这些平台上线后，业务开发不需要知道底层是 K8s 还是物理机。他们只需要在平台上点一下部署，平台自动处理一切。

运维开发的价值不是你部署了多少服务，是你写的平台让多少人不需要找你。

第三，自动化重复劳动。

每周要做 20 次扩容缩容？写个自动扩缩脚本，CPU 超 70% 自动加机器。

每次发版要改 5 个配置文件？写个模板引擎，一键生成。

半夜被磁盘满的告警叫醒？写个定时清理任务，或者更高级——用 AI 预测什么时候会满，提前处理。

这些不是「开发能力」，是运维痛点的工程化解决。 你只有亲自被磁盘满的告警吵醒过三次，才知道自动清理脚本怎么写才能真正解决问题。

三种人，三种结局

现在运维领域其实分成了三种人：

第一种人的问题是没有杠杆。第二种人是行业真正稀缺的——他们有运维的判断力（知道 99% 的问题出在哪个环节），又有开发的能力（能把解决方案固化到代码里）。第三种人写代码很强，但写出来的平台「看起来很美，用起来不解决问题」——因为他们没被凌晨三点的告警叫醒过。

你之前说的「招运维和开发全栈的人」，准确的翻译是：招第二种人。 不是让开发跨界学运维，是让运维跨界学开发。

行业最好的样本：是那些你听过的名字

Google SRE 的起源。 2003 年，Google 一个叫 Ben Treynor 的人被要求「管管生产环境」。他是个软件工程师，不是运维。他不做手工运维，而是写了大量自动化代码。一年后，Google 生产环境的运维基本不需要人了。SRE 这个角色由此诞生——本质上是用软件工程方法解决运维问题。

国内字节的运维中台团队也走了这条路。他们的核心岗位叫「基础架构工程师」，招聘要求第一条不是「精通 Linux 命令」，是「有大型分布式系统开发经验」。

这不是在裁运维，是在重构运维——从劳动密集型变成技术密集型。

最后一句

裁员裁掉的是「能做但谁都能做」的人。抢着招的是「能做而且只有少数人能做」的人。

纯运维是前者——你走了，换个人培训一周也能上线。运维开发是后者——你写的自动化脚本、你定制的 K8s 调度策略、你搭的内部平台，是你走了以后团队三个月才能接手的资产。

你不是在保工作，你是在把自己变成不可替代的基础设施。