企业官网建设流程全解析

一、现场：一条凌晨 3 点的告警

先把现场交代清楚。db01 是我实验环境里的一台 CentOS 7.9 虚拟机，上面跑着一个 MySQL 8.0 实例，40G 系统盘。这台机器平时没什么存在感——直到某个凌晨，/var 目录悄悄涨到了 92%。

放在过去，这件事的标准剧本是这样的：手机短信或邮件把人吵醒，摸黑开电脑，SSH 登上服务器，df -h 看一眼——快满了；du 一层层翻——不知道哪层大；找到一堆日志，还得先想想哪些能删、删了服务会不会出事；删完再 df 验证，前前后后半个多小时，第二天顶着黑眼圈上班。中间任何一个 rm 敲错了路径，故事就直接变成事故。

这个剧本里的每一步其实都是重复劳动：看占用、找大文件、判断能不能删、删完验证。判断需要经验，但执行不需要灵魂。这一篇就讲：这件事交给 AI 运维助手之后，是什么样子。

二、告警从哪来：30 秒一轮的值守

传统监控（Zabbix、Prometheus 那一套）负责「发现问题」，但发现问题之后的排查还是人来做。AI 运维助手的值守监测把两件事连在了一起：它不只是喊你，还能陪你把问题处理完。

在 Web GUI 里点「一键值守」，助手开始对纳管的所有主机每 30 秒一轮巡检，采集 CPU、内存、磁盘、交换分区使用率和关键服务存活状态。默认阈值如下，都可以在配置里改：

判定有两个防误报设计。一是状态机去抖：同一台主机同一项指标，从正常变异常只推送一次告警，恢复时再推送一次「已恢复」，不会每 30 秒轰炸你一遍；偶发一次采集超时也不会立刻拉响警报。二是连接失败容忍：网络抖动连续失败若干轮才会把该主机监测标记为暂停，恢复后自动续上。

告警触发时走三路通知：Web 界面顶部弹红色横幅、电脑响起三连急促报警音、邮件通知异步发出（在「邮件通知」面板配好 SMTP 即可）。凌晨 3 点你不在电脑前，邮件就是最后防线。

# 邮件标题大概长这样：

[彭大帅的AI运维助手] db01 磁盘告警：/ 使用率 92%（阈值 85%）

要点值守是「喊人 + 排障」一体：收到告警后不需要自己再登服务器，直接在对话框里把现场丢给 AI，见下一章。

三、把排障交给 AI：完整对话实录

以下是那晚的真实对话（回显做了精简）。我在 Web GUI 的对话框里只说了一句话：

我：db01 磁盘告警了，帮我看看是什么占满了

AI 没有反问我「要用什么命令」，它自己拆解任务，先看整体占用：

AI：先查看整体磁盘占用 → run_command(df -h)

Filesystem Size Used Avail Use% Mounted on

/dev/mapper/centos-root 40G 35G 3.2G 92% /

tmpfs 3.9G 0 3.9G 0% /dev/shm

AI：根分区 92%。继续定位大目录 → run_command(du -x --max-depth=2 /var | sort -rh | head -15)

18G /var/lib/mysql

14G /var/log

3.1G /var/lib/docker

两分钟不到，嫌疑人已经圈定：/var/log 有 14G，对一个测试库来说明显异常。AI 继续往下钻：

AI：查看 /var/log 下最大的文件 → run_command(ls -lhS /var/log | head -10)

-rw-r----- 1 mysql mysql 12G Sep 27 03:12 mysqld.log

-rw-------. 1 root root 982M Aug 30 04:02 messages.4.gz

-rw-------. 1 root root 875M Aug 23 04:02 messages.5.gz

AI：查看错误日志尾部，确认刷屏原因 → run_command(tail -30 /var/log/mysqld.log)

（连续数千行重复的 Aborted connection 报错，此前数周一直在写）

到这里，根因已经清楚：MySQL 的错误日志既没配轮转，又被连接异常反复刷屏，一个月写出了 12G；再加上几个几百兆的旧系统日志压缩包。AI 给出了处理建议，并且把风险讲在前面：

AI：建议分三步处理，其中第 1 步对运行中的日志文件清空是安全的，

第 2 步删除旧轮转压缩包不可逆，第 3 步涉及 MySQL binlog 建议单独评估：

1. 清空 /var/log/mysqld.log（truncate -s 0，保留文件，MySQL 无需重启）

2. 删除 /var/log/messages.4.gz、messages.5.gz 两个旧压缩包

3. binlog：先查 SHOW BINARY LOGS 再决定 PURGE，本次先不动

我回复了决策：

我：按 1、2 执行，binlog 先不动

高危操作执行前，Web 界面弹出确认框，列出将要执行的完整命令。我点下确认，AI 执行并回验：

AI：执行清空与删除（已确认）→ run_command(truncate -s 0 /var/log/mysqld.log

&& rm /var/log/messages.4.gz /var/log/messages.5.gz)

AI：验证回收效果 → run_command(df -h /)

Filesystem Size Used Avail Use% Mounted on

/dev/mapper/centos-root 40G 18G 20G 47% /

92% 降到 47%，释放约 17G。几秒后值守面板上 db01 的红色告警条转绿，推送「磁盘已恢复」——去抖机制保证这件事只提醒一次，不会刷屏。从横幅弹出到恢复，全程不到 30 分钟，我做的事只有：看告警、说一句话、做一个决定。

四、AI 停下来的那一秒

复盘这次处理，最值得注意的不是 AI 多能干，而是它在哪里停了下来。整个流程里 AI 自主做了所有「读」的操作——df、du、ls、tail 都是只读命令，直接执行，一秒都没耽误；而到了删文件的「写」操作，它停下来弹了确认框，把完整命令摆在我面前，等我的决定。

这不是临场发挥，是内置的分级安全管控：只读命令直接放行；高危操作（写文件、改配置、重启服务、删除文件）必须人工确认；毁灭性操作（比如对关键路径的递归强制删除）直接拒绝执行，连确认的机会都不给。以删除为例，助手会解析 rm 命令的旗标和目标路径——rm -rf 且指向系统关键目录这类组合，命中毁灭性规则。

有人可能觉得「还要点确认」不够智能。恰恰相反，深夜排障场景里这一秒确认是整个设计的价值所在：AI 负责把信息备齐、把方案列好、把风险讲明，人负责最后的判断。能力越强的自动化，越需要清晰的刹车。AI 能干的是 80% 的重复劳动，剩下 20% 的决策权永远在你手里——这才是它敢让你睡觉的底气。

五、收尾：让下次不用再爬起来

清理完成后，我追问了一句「以后怎么避免」，AI 给出的方案包括：为 mysqld.log 配置 logrotate 按天轮转并限制保留个数；在 MySQL 侧排查 Aborted connection 的来源（常见是应用连接池配置不当或网络闪断）；以及把磁盘巡检阈值对 /var 单独收紧。这类加固操作依然走「AI 拟方案、人确认」的节奏，这里不展开。

这一篇完整的链路是：值守 30 秒一轮发现异常 → 横幅、报警音、邮件三路喊人 → AI 只读命令自主排障 → 高危操作一次确认 → 执行后自动回验 → 值守面板恢复推送。你会发现整个过程中 AI 扮演的是「值班工程师」，而你是「签字的领导」——领导只需要在正确的时间做正确的决定。

磁盘告警只是值守场景里最常见的一种。下一篇换一个更常见的现场：白天，业务网站突然 502 了——这次连告警都来不及等，而且我们会用到另一个武器：把报错截图直接丢给 AI。