AI帮我写了个巡检工具第一台服务器就查出三个定时炸弹

AI帮我写了个巡检工具
第一台服务器就查出三个定时炸弹

运维群里有个奇怪的现象。

大家嘴上说"巡检很重要"，实际操作中，多半是登上去敲个 top，看一眼 df -h，然后截图发群里，就算交差了。

查仔细太费时间，所以大家多半懒得查。一台服务器从头到尾过一遍，系统信息、CPU、内存、磁盘、网络、进程、日志、安全、硬件、中间件、备份、告警，十几个模块挨个跑下来，半个多小时就没了。批量巡检？几十台服务器跑一圈，一下午就交代了。

所以大部分运维人的真实状态是：服务器跑得好好的，就不去碰它。等到它跑不好了，再冲上去救火。

我们也是这么过来的。直到有一天，我们决定用AI帮自己写一个巡检工具。

01）起因：一个比赛催生的工具

我们参加了一个AI比赛，想做个能展示AI在运维场景中实际价值的项目。想来想去，巡检是最合适的切入点：高频、刚需、重复劳动多，完美适合自动化。

第一版很快出来了。14个基础模块，从系统信息到资源告警，覆盖了运维巡检的常规项目。SSH连上去，一条条命令执行，结果收集回来，生成结构化报告。用paramiko做SSH连接，用Python写巡检逻辑，用AI生成诊断SQL，整个流程跑通了。

然后就越写越上头。

加了Java宕机分析模块。jps检测进程，jmap看堆内存对象TOP20，jstat采样GC统计，jstack抓线程快照做死锁检测，还能扫hs_err_pid日志找JVM crash记录。一个模块把Java应用最常见的问题全收进来了。

又加了数据库深度诊断。先做了MySQL的23项深度检查，连接使用率、缓冲池命中率、大表TOP10、慢查询配置、安全审计、主从复制状态、InnoDB引擎状态，一条龙走完。后来觉得不够，又加了数据库健康诊断、安全审计、锁分析、备份调度、SQL审核，一共6个数据库模块，还把PostgreSQL和Oracle也支持了。

19个模块，3000多行Python代码。全量巡检一键跑完，SSH凭证就能跑系统巡检，加上数据库凭证还能跑深度诊断。批量模式支持inventory.json配置服务器清单，多台并发，生成HTML汇总报告。

写完的那一刻，我们觉得这东西已经是个艺术品了。

02）第一刀：vms66上的三个定时炸弹

然后我们拿vms66试了一刀。

vms66是我们的生产服务器，跑着蓝凌EKP系统，MySQL数据库，Java应用。平时运行挺稳定的，没出过什么大问题。我们对它挺有信心。

巡检结果出来的时候，我们出了一身冷汗。

MySQL连接使用率飙到了八成以上。max_connections设的是151，实际连接数已经超过120。这意味着高峰期再来几个连接，数据库就会直接拒绝新连接，业务系统报错。我们完全不知道。

innodb_buffer_pool_size只有128M。这台服务器的内存是16G，MySQL的缓冲池只给了128M。等于MySQL每次查数据都要去磁盘读，缓冲池命中率不到九成。一台16G内存的服务器，MySQL跑得跟1G内存似的。

binlog永不过期。expire_logs_days设的是0，意味着binlog会一直累积，永远不会自动清理。这台服务器已经跑了好几年，binlog文件占了好几个G的磁盘空间，而且还在持续增长。迟早有一天磁盘被撑爆。

三个定时炸弹，安安静静地躺在那里。服务器表面上运行正常，实际上每个问题都随时可能引爆。

我们一直觉得自己是个还不错的运维。那一刻才意识到，"感觉没问题"和"真的没问题"之间，隔着一整套系统化的巡检。

03）更崩溃的发现：工具自己也有问题

更让人崩溃的是，这次巡检跑了20多分钟。

20多分钟。我们花了那么大精力写的工具，跑一台服务器要20多分钟。这效率，跟手动巡检有什么区别？

我们把日志翻出来，一个个模块排查。

find全盘扫描大文件，

find / -xdev -type f -size +100M

，扫的是整个根文件系统。在有大量文件的生产服务器上，这一条命令就能跑好几分钟。每个Java进程3次jstat采样，间隔1秒，多进程累计下来又是好几十秒。数据库模块23条SQL，每条都通过独立的SSH通道执行，每次都要建连接、发命令、收结果、断连接，网络往返开销巨大。日志扫描没有maxdepth限制，没有timeout保护，遇到深层目录就卡在那里慢慢爬。

19个模块串行执行，每个模块排队等前一个完成。即使模块之间互不依赖，也得老老实实按顺序来。总耗时等于各模块耗时之和，没有任何并行优化。

这就像去超市买东西，明明可以一只手拿酱油一只手拿醋，非要先拿完酱油走到酱油区，再走回醋区拿醋。

04）两轮优化：从20分钟到1分钟

这一次要优化的，是巡检速度。

第一轮，命令级别。

find全盘扫描限定到几个常驻目录，/var /opt /data /home /tmp，加maxdepth 6层限制，加timeout 20秒超时保护。一条命令从几分钟变成几秒。

jstat从每进程3次采样减到1次快照。1秒出结果，够用了。数据库模块的23条SQL合并成一个shell脚本，单次SSH调用全部执行完。一次连接搞定，不用反复建断。日志扫描加maxdepth 5层，加timeout 30秒，遇到深层目录直接跳过，遇到大日志文件快速搜完就走。

iostat从2次采样减到1次。mysql连接加--connect-timeout=10，连不上就快速失败，不傻等。

一轮下来，从20多分钟压到3到6分钟。效果不错，但还不够。

第二轮，架构级别。

19个模块从串行改成并发。ThreadPoolExecutor，默认5线程，每个模块在独立线程里跑。每个线程创建独立的SSH连接，避免多线程共用一个连接的竞争问题。单个模块有独立超时，超时后自动跳过，标记为"跳过"，不会拖累整个巡检进程。

想回退到串行模式也行，加个参数--module-workers 1就回去了。向后兼容。

又一轮下来，从3到6分钟压到1到2分钟。

两轮优化，总耗时从20多分钟降到1到2分钟，提升超过九成。

阶段	耗时	优化手段
原始版本	20+ 分钟	串行执行，全盘扫描
第一轮优化	3-6 分钟	命令级别：限定目录、合并SQL、减少采样
第二轮优化	1-2 分钟	架构级别：5线程并发，独立超时
累计提升	90%+	两轮叠加

05）顿悟：工具的速度决定使用频率

优化完之后，我们突然想通了一件事。

巡检工具最基本的功能是发现问题。但它真正的价值藏在另一个地方：让你敢于频繁地跑。

20分钟跑一次巡检，你一个月跑一次都觉得费劲。2分钟跑一次，你每天跑一次都不心疼。频率上去了，问题暴露的窗口期就短了，从"出了事再查"变成"还没出事就发现了"。

工具的速度，决定了你使用它的频率。你使用它的频率，决定了系统的健康度。

这个道理，以前也懂，但没有切肤之痛。vms66上的三个定时炸弹，就是"懂道理但没有工具"的代价。如果早点有这个工具，早点跑一次，那些问题在萌芽阶段就被揪出来了。

MySQL连接堆积，从100到120可能花了几个月。从120到151可能只需要一次突发流量。我们有几个月的时间窗口去发现它，但没工具，所以没发现。buffer_pool只有128M，这个问题从服务器部署那天起就存在。跑了好几年，每一天都在浪费内存，每一天都在让MySQL做不必要的磁盘IO。binlog永不过期，这个问题每天都在恶化，磁盘空间每天都在缩水。

三个问题，任何一个都足以在某一天引发故障。它们安安静静地等在那里，等着一个触发条件。

06）AI在巡检里到底起了什么作用

参加AI大讲堂比赛的时候，有人问我们：AI在巡检里到底起了什么作用？

我们的回答是：AI让我们看得更清楚。

MySQL的buffer_pool应该设多大，binlog该保留几天，连接数该调到多少，这些都是运维经验决定的。AI做的事情是，帮我们把这套巡检逻辑变成了一个可以一键执行的工具，帮我们把19个模块的3000多行代码写了出来，帮我们把MySQL、PostgreSQL、Oracle三库的诊断SQL都整理好了。

你本来就知道buffer_pool很重要，但以前没有工具帮你一键查出来，你就懒得查。现在2分钟跑完，你自然就愿意看了。

AI写的代码，每一行我们都自己读懂了。巡检工具是跑在生产环境上的，出了问题AI不会替你背锅。代码是你自己提交的，部署是你自己执行的，报告是你自己看的。AI只是帮你写得更快，帮你覆盖得更全，帮你把那些你懒得手写但确实该有的检查项都补上了。

技术浪潮一波接一波，最后留下来的，是那些既会用工具，又知道自己该在什么时候踩刹车的人。巡检工具有边界，它只是让你从"盲人摸象"变成"拿着手电筒摸象"。手电筒能照亮的范围有限，但至少让你看清了象的哪条腿有问题。

至于我们，现在每天早上到公司的第一件事，就是跑一遍巡检。2分钟，一杯咖啡还没凉，19个模块的报告就出来了。心里有底了，再开始一天的工作。

这种感觉，比"感觉没问题"踏实多了。

速查清单

01）巡检的核心价值是频率，能2分钟跑完的工具比20分钟跑完的工具强十倍

02）"服务器跑得好好的"是最危险的一句话，没查过不代表没问题

03）MySQL的innodb_buffer_pool_size至少给到物理内存的五到七成，128M是偷懒配置

04）binlog必须设过期时间，expire_logs_days设0等于让磁盘慢性自杀

05）连接使用率超过七成就该扩容了，等到八成再动手高峰期已经来不及

06）工具优化先砍最耗时的命令，再改架构上并发，不要一开始就搞多线程

07）单个模块超时自动跳过比让整个巡检挂起强，完成比完美重要

08）AI写的代码要自己读懂每一行，巡检工具跑在生产环境，出了事你自己负责

— END —