运维工程师正在消失？不，是“只会写自动化脚本”的运维在消失

上周和旧同事吃饭，他所在的“基础设施平台组”刚被合并进研发中心。他们组过去一年上了三套新系统：一套配置管理数据库、一套发布流水线、外加定制的监控看板。结果呢？故障率没降，反而因为工具之间互相踢皮球，每次出问题都要拉四个群的人对线。他说了一句让我印象很深的话：“我们现在不是在运维服务器，是在运维运维工具本身。”

很多人讲运维的未来是平台工程，是让开发自助服务。这个方向本身没错，但我看到的现实是：太多团队把“造平台”当成逃避“扛责任”的遮羞布。工具越堆越多，真正懂业务链路的人越来越少。2021年我们处理过一起支付网关超时事故，最后定位到是某个底层网络设备的老化——但这台设备居然没有任何监控，因为它的厂商太老了，新的采集器根本不支持。当时有几千条自动化告警刷屏，没一条指向真实原因。那一刻我意识到，我们最擅长的不是解决问题，而是让问题看起来像被解决。

另一个被严重低估的东西，是 on-call 经验。现在招聘要求里动不动就是“精通 Kubernetes，熟练掌握 Terraform”，却没人问你“有没有在凌晨三点被人打电话叫醒，然后靠着一知半解的链路图硬扛过去”。我在2019年经历过一次大规模缓存雪崩，那套系统没有优雅降级，没有熔断配置——当时唯一的办法就是手工改 nginx upstream 列表，把流量导到备用集群。那个晚上我敲了两个小时命令，每个命令都带着对业务代码的血腥理解。事后复盘，写不出任何自动化脚本能替代那种“慌但手不抖”的能力。

更讽刺的是，我们一边喊着“少人化运维”，一边又在制造新的重复劳动。我之前统计过自己团队一周的工作记录：平均每个人要手动处理 4.3 个工单，其中 60% 是“权限申请”或“配置变更”，而这些本可以靠一个简单的自助页面解决。但没人愿意做这个页面，因为做它不写进晋升材料。大家宁可去研究怎么把 Grafana 面板调得更漂亮，也不愿删掉那些已经没人看的废弃告警。告警规则从最初的 86 条涨到 1300 多条，真正有效的不超过 5%。我们管这个叫“防御性监控”，其实不过是玻璃心焦虑的数字化呈现。

说点更反常识的：我认为运维的终极价值不是保障系统稳定，而是敢于把不重要的东西删掉。很多系统之所以脆弱，不是因为缺这个缺那个，而是因为历史包袱太重。我刚接手现在这套业务时，有一个模块只有 0.2% 的调用量，却跑在核心链路里，每次发布都要跟着全量回归。我花了两周时间跟研发撕，最终把它从主流程中摘除。摘除那天,整个上线流程从 40 分钟缩短到 18 分钟。这才是运维该做的事——不是给每条腿都穿上防弹衣，而是截掉已经坏死的肢干。

所以，那些说“运维已死”的人，大概率是没见过真正靠谱的运维长什么样。靠谱的运维懂得拒绝花哨的工具，懂得保护自己的睡眠时间，也懂得在故障手册里写一句“如果你不确定，先别动”。我见过最好的 runbook，不是什么智能编排，而是第一行写着“关闭所有变更审批，然后通知值班经理”——这句话救过我们一次，因为当时真正的故障源头就是那个审批系统本身。这件事让我彻底明白：运维的技术含量，不在于你掌握多少种数据库的恢复方式，而在于你能在多短的时间里分清楚哪些规则是保护，哪些规则是枷锁。

如果你问我未来两年运维应该学什么，我的回答不是 eBPF、不是服务网格，而是：学会拒绝。拒绝那些不带来可观测性的监控，拒绝那些没有故障演练的自动化，拒绝那些只会让页面更好看的平台。多花时间跟业务方聊天，搞明白用户的支付失败是发生在你机房的路由器上，还是发生在对方手机的信号塔下。运维的核心从来不是技术栈——而是你对“不确定性”的接受程度和处置手感。这种手感，任何 AI 都教不会。

最后说个真实数字：过去三年，我所在团队把告警数量压掉了 78%，但 MTTR（平均修复时间）反而缩短了 31%。原因很简单——我们减少了噪音，人就能在真正出事时听见自己的心跳声。那是唯一比系统监控更准的仪器。