彭大帅的AI运维助手实战案例 5 · 新接手的服务器，先让 AI 摸底

从零文档陌生机器到资产档案再加一套自动值守—— 系列第 5 篇 ——2026 年 10 月目 录一、现场没有文档的祖传服务器二、对话式摸底从零到资产档案三、角色识别候选与确认的两段式四、从摸底到值守档案落地成探针五、收尾接手环境的正确姿势一、现场没有文档的祖传服务器运维生涯里总有那么几次接手一批「祖传」服务器。交接会上前同事说「都在上面跑着呢应该没什么要改的」然后你拿到几行 IP 和密码文档是没有的。每台机器跑着什么服务、谁在依赖它、定时任务里藏着什么、上一次重启是什么朝代——一概不知。这种机器最危险的地方不是它会坏而是你不敢动不知道里面有什么任何变更都是在黑暗里伸手。传统摸底的做法是登上去一通翻ps -ef 看进程、systemctl 看服务、ss 看端口、crontab 看定时任务、history 看前任敲过什么翻完在脑子里拼出这台机器的画像。一台机器半小时十台就是一天而且拼出来的画像全在脑子里人走了就没了。这一篇演示把摸底交给 AI让它翻完之后直接给你一份书面档案并且顺手把这台机器纳入自动值守。二、对话式摸底从零到资产档案先在 Web GUI 里把机器加进主机清单界面表单填名称、IP、账号密码或者直接对 AI 说「帮我加一台主机」它自己调 add_host。然后开始摸底我刚接手一台机器 web-legacy没有任何文档帮我摸个底系统版本、跑了哪些服务、监听哪些端口、定时任务、资源水位最后告诉我这台机器是干嘛的AI 开始逐层翻全程只读命令连续执行不反问AI→ run_command(cat /etc/os-release | head -2; uname -r; uptime)Rocky Linux 8.10内核 4.18已连续运行 247 天AI→ run_command(systemctl list-units --typeservice \--staterunning --no-pager | grep -v systemd | head -15)nginx、mysqld、redis、crond、rsyslog、tuned、chronydAI→ run_command(ss -tlnp | awk NR1 {print $4,$6} | sort -u)0.0.0.0:80/443nginx、0.0.0.0:3306mysqld、127.0.0.1:6379redisAI→ run_command(crontab -l; ls /etc/cron.d/ 2/dev/null)每天 02:00 执行 /opt/scripts/backup_db.sh数据库备份到 /backup四轮命令下来画像已经成形这是一台 Web 数据库 缓存三合一的混部机器。AI 再补两刀资源水位然后把角色识别也跑了AI→ run_command(df -h /; free -m)磁盘 61%内存 5.8G / 7.6G76%AI→ scan_roles(hostweb-legacy)候选角色webnginx 指纹命中、dbmysqld 指纹命中确认后写回监测配置值守将自动挂载 web / db 角色探针。三、角色识别候选与确认的两段式scan_roles 的结果值得单独说一段因为它的设计很克制默认只给「候选角色」不写任何配置。指纹命中了 web 和 dbAI 会先汇报给你看——「这台像 web db确认吗」你说确认它才把角色写回监测配置。为什么多此一步因为指纹可能误报测试残留的 nginx 容器、装了没用的 MySQL都可能让指纹命中。如果探测结果自动生效值守就会给这台机器挂上不存在的角色探针之后天天误报「服务没了」。候选 → 人工确认 → 写回一步不多、一步不少。确认环节还有个细节如果 AI 之前误判过某台机器的角色比如把残留容器当成了 web 服务你可以在确认时直接指出「web 是误报」它会用 exclude 参数把误报角色剔除后再写回并且是覆盖式写回——历史误写也会被清干净保证每台机器只挂真实角色的探针。我确认就是 web dbAI→ scan_roles(hostweb-legacy) # 这次带「确认写回」已写回web-legacy 的角色为 web、db值守监测已重载web / db 角色探针生效。四、从摸底到值守档案落地成探针角色写回后摸底的成果自动转化为值守能力这台机器的监测不再只是通用的 CPU / 内存 / 磁盘阈值还挂上了 web 探针检查 Nginx 进程与本机 HTTP 响应和 db 探针检查 MySQL 进程与端口。以后 nginx 挂了或 3306 不监听值守 30 秒内就会喊人不需要等用户报障。AI 最后交付的书面档案长这样对话里直接输出AIweb-legacy 资产档案系统Rocky Linux 8.10已运行 247 天未重启角色Web(Nginx 80/443) DB(MySQL 3306) Redis(6379, 仅本机)定时任务每日 02:00 数据库备份 → /backup资源磁盘 61% / 内存 76%风险点1. 三合一混部且内存 76%业务高峰有 OOM 风险参考上上篇502 案例php-fpm 就是被 OOM 杀的2. 备份落在 /backup 分区请核对保留策略是否会把盘写满3. 247 天未重启内核与安全补丁状态建议单独评估。值守已纳入web/db 探针生效建议观察一周内存水位。接手一台陌生机器的完整动作到此闭环加主机 → AI 摸底 → 角色确认 → 自动值守 → 书面档案。档案本身是对话记录随时可回看、可导出交接文档从此是「跑出来的」而不是「编出来的」。环节传统做法AI 运维助手信息采集人肉逐条敲命令翻输出AI 连续只读探测全程可见角色判断凭经验从进程猜指纹探测给候选人工确认档案产出凭记忆事后补文档对话即档案可直接导出风险识别想到哪看到哪AI 按水位与配置主动列风险后续保障记着手工盯确认后自动挂角色探针值守十台机器成本一整天且画像在人脑里一小时档案落在系统里五、收尾接手环境的正确姿势这一篇最舒服的地方在于它不需要出故障也能体现价值。前三篇都是「出了事找 AI」这一篇是「没事的时候让 AI 把家底盘清」。运维工作的很大一部分恰恰是这种「不知道的风险管理」——你知道那些祖传机器里一定藏着问题只是不知道藏在哪。摸底的价值链路是递进的盘点清楚 → 才敢变更 → 才能值守。角色识别把「这台机器是干嘛的」从人的记忆变成系统的配置值守探针才有依据可挂书面档案把画像从人脑搬进记录交接才不至于重来一遍。下一篇换个战场离开服务器机房走进网络设备的黑框框——交换机端口排查与配置下发。