我劝你别急着学AI运维,先把这三个基本功练好

最近运维圈有个怪现象。

群里每天都有人在转发AI运维的课程，朋友圈刷屏各种「AIOps实战营」，连脉脉上都全是「运维不学AI就等着被淘汰」的帖子。

我理解这种焦虑，我自己也焦虑过。

但焦虑归焦虑，我最近接触了好几个转型期的运维同行，发现一个很危险的信号：他们的基本功反而退步了。

一个干了五年的DBA，连慢查询都懒得自己分析了，直接扔给AI问。一个管着十几台服务器的系统管理员，排查网络问题第一步居然是问ChatGPT。

这让我很不安。

我们聊聊这个事。

为什么我说「别急着学」

先说结论，我绝对支持运维学AI，我自己也在用AI写脚本、做巡检、写报告，效率提升很明显。

但问题在于，很多人把顺序搞反了。

把AI当成学习起点，当成弥补基本功不足的捷径。

这个思路很危险。

打个比方，你连加减法都算不利索，直接拿计算器去考数学，刚开始确实能混过去，题目简单的时候你和学霸得分一样。等到题目复杂了，需要你判断用哪个公式、走哪条思路的时候，你就彻底懵了。

AI就是那个计算器，基本功就是加减法。

运维圈有个公开讨论，InfoQ去年专门做了一期直播，标题叫「LLM for AIOps：是泡沫还是银弹」。阿里云的运维总监、云杉网络的总裁坐在一起，核心争论点就是：大模型在运维领域的应用，到底是被过度炒作，还是真能解决问题。

注意，是行业大佬们在争论这个事，说明现在下结论还太早。

你在行业方向都不确定的时候，把所有精力砸进去，忽略基本功，这不叫转型，这叫赌博。

第一个基本功：Linux排查能力

这是地基中的地基。

你用AI写了一个监控脚本，跑了几天没问题，你觉得很省事。然后有一天，线上服务突然变慢，AI给你的回答是「建议检查CPU和内存」。

废话，谁都知道要检查。

但真正值钱的运维，是在这个基础上快速缩小范围，判断到底是IO wait还是CPU steal，是磁盘慢了还是网卡打满了，是容器limit设小了还是cgroup的cpu shares被占完了。

这些东西AI能给你一个排查清单，但判断还得你自己来做。

因为每个生产环境都不一样，你的架构、你的业务特征、你的历史包袱，只有你自己清楚。

我之前遇到过一次MySQL连接堆积的问题，14个连接全部卡死。AI给我的方案很通用，重启、调参数、检查连接池。但真正的问题是binlog配置导致日志永不过期，磁盘写满，MySQL响应变慢，连接池被耗尽。

这种链路排查，需要你对Linux系统调用、文件系统、进程调度都有感觉，靠AI给不出这个判断。

我的建议很简单：熟练掌握top、vmstat、iostat、sar、strace这几个命令的输出含义，能看懂/proc下面的关键文件，知道怎么用tcpdump抓包分析。

这些基本功练好了，AI才能真正帮上忙。

第二个基本功：数据库调优

数据库是运维的深水区，也是AI最难啃的骨头。

现在很多运维遇到数据库问题，第一反应是问AI：「帮我优化一下这个SQL」。

AI确实能改一些明显的语法问题，加个索引、改个JOIN顺序。但数据库调优真正难的部分，AI够不着。

第一，执行计划分析。MySQL的EXPLAIN你看得懂吗，type列从system到ALL分别代表什么，Extra里的Using temporary和Using filesort意味着什么，为什么有时候加了索引反而更慢。

第二，锁和事务。线上出现死锁，你能不能快速定位是哪两个事务在争抢哪个资源，能不能判断是业务逻辑问题还是索引设计问题。

第三，参数调优。innodb_buffer_pool_size该设多大，AI说的「建议设为物理内存的七成」只是一个起点。你要考虑这台机器上还跑着什么，业务高峰期的数据量有多大，读写比例是多少。

我见过一个真实的案例，一台生产环境的MySQL，innodb_buffer_pool_size只有8MB。这台机器内存有64G，但数据库跑了好几年没人管过参数。AI查不出来这个问题，因为AI看到的是SQL层面的东西，它看不到你的配置文件。

数据库调优需要手感，需要踩过坑，需要被线上事故教育过才能长记性。这些东西你跳不过去。

第三个基本功：监控告警体系

这个可能是最容易被忽视的。

很多人觉得监控就是装个Prometheus加个Grafana，模板一套就完事了。但一个真正能用的监控告警体系，里面的学问比你想的多得多。

告警阈值怎么设。设高了漏报，设低了告警风暴，每天几百条告警邮件没人看。我见过一个团队，监控面板做得很漂亮，但线上挂了半小时才发现，因为告警全被静默了。

监控指标怎么选。CPU、内存、磁盘这种基础指标谁都会看，但你的业务需要关注的指标是什么。比如一个订单系统，订单成功率、支付耗时、库存同步延迟，这些业务指标才是关键时刻救命的东西。

告警分级怎么做。哪些需要立刻打电话叫人起来处理，哪些可以等到第二天上班再看。我见过凌晨三点因为一个非核心服务的CPU波动把整个运维团队叫起来的事，后来大家的手机都设了勿扰模式，真正的故障来了反而没人接电话。

这些都需要你懂业务、懂系统、还得有实战经验踩过坑。

AI可以帮你写告警规则，但哪个告警重要、哪个可以忽略，它判断不了，因为它不了解你的业务上下文。

AI是放大器，基本功是地基

回到开头的问题。

我支持学AI运维，但我反对本末倒置。

腾讯云开发者社区今年发布的数据，2026年四成运维岗位需要与AI协同工作。这意味着AI确实在改变运维行业，但注意这个表述，是「协同」，是「辅助」，是让运维更高效，同时也在提高运维的门槛。

AIOps搞了好几年了，业界还在争论它是泡沫还是银弹。你在地基都没打稳的时候去追这个风口，风险太大了。

AI是放大器，它放大你的能力。基本功扎实的运维用AI，如虎添翼。基本功薄弱的运维用AI，只是掩盖了问题，等真正出事的时候，AI救不了你。

技术浪潮一波接一波，OpenStack来过，Kubernetes来过，现在AI来了。每一波浪潮都有人说「不学就淘汰」，但最后留下来的，永远是那些基本功扎实、同时愿意拥抱新工具的人。

先把地基打好，上面的楼才盖得稳。

速查清单：

01）AI能提升效率，但替代不了你的判断力

02）Linux排查是所有运维的地基，跳不过去

03）数据库调优需要手感，需要踩坑积累

04）监控告警的核心是业务理解，技术只是手段

05）行业方向还不确定的时候，别把鸡蛋全放一个篮子

06）AI给出的排查方案要自己验证，别盲信

07）基本功好的运维用AI是如虎添翼，反之是饮鸩止渴

08）技术浪潮永远在变，但系统底层原理很少变

— END —