从告警到清理30 分钟闭环人只点了一次确认—— 系列第 1 篇 ——2026 年 10 月目 录一、现场一条凌晨 3 点的告警二、告警从哪来30 秒一轮的值守三、把排障交给 AI完整对话实录四、AI 停下来的那一秒五、收尾让下次不用再爬起来一、现场一条凌晨 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、内存、磁盘、交换分区使用率和关键服务存活状态。默认阈值如下都可以在配置里改指标默认告警阈值说明CPU 使用率90%持续超阈值才告警偶发尖峰不误报内存使用率90%同上磁盘使用率85%本篇案例的触发点交换分区70%swap 用得深通常是内存吃紧的前兆服务存活进程消失即告警支持 web / db / k8s / OpenStack 等角色探针自动识别按角色挂载判定有两个防误报设计。一是状态机去抖同一台主机同一项指标从正常变异常只推送一次告警恢复时再推送一次「已恢复」不会每 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/shmAI根分区 92%。继续定位大目录 → run_command(du -x --max-depth2 /var | sort -rh | head -15)18G /var/lib/mysql14G /var/log3.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.gzAI查看错误日志尾部确认刷屏原因 → run_command(tail -30 /var/log/mysqld.log)连续数千行重复的 Aborted connection 报错此前数周一直在写到这里根因已经清楚MySQL 的错误日志既没配轮转又被连接异常反复刷屏一个月写出了 12G再加上几个几百兆的旧系统日志压缩包。AI 给出了处理建议并且把风险讲在前面AI建议分三步处理其中第 1 步对运行中的日志文件清空是安全的第 2 步删除旧轮转压缩包不可逆第 3 步涉及 MySQL binlog 建议单独评估1. 清空 /var/log/mysqld.logtruncate -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 运维助手发现问题监控告警喊人值守告警喊人同时已备好对话入口定位根因人肉 df / du 逐层翻AI 自主连续执行只读命令直接给出结论执行处理人手敲命令全靠经验把关AI 拟好命令与风险说明人工一次确认结果验证再敲一次 df 自己看AI 执行后自动回验并报告事后预防想起来的话才去配AI 主动建议轮转与巡检加固总耗时30~60 分钟全程清醒不到 30 分钟人的参与以秒计五、收尾让下次不用再爬起来清理完成后我追问了一句「以后怎么避免」AI 给出的方案包括为 mysqld.log 配置 logrotate 按天轮转并限制保留个数在 MySQL 侧排查 Aborted connection 的来源常见是应用连接池配置不当或网络闪断以及把磁盘巡检阈值对 /var 单独收紧。这类加固操作依然走「AI 拟方案、人确认」的节奏这里不展开。这一篇完整的链路是值守 30 秒一轮发现异常 → 横幅、报警音、邮件三路喊人 → AI 只读命令自主排障 → 高危操作一次确认 → 执行后自动回验 → 值守面板恢复推送。你会发现整个过程中 AI 扮演的是「值班工程师」而你是「签字的领导」——领导只需要在正确的时间做正确的决定。磁盘告警只是值守场景里最常见的一种。下一篇换一个更常见的现场白天业务网站突然 502 了——这次连告警都来不及等而且我们会用到另一个武器把报错截图直接丢给 AI。 
长河君 · 2026/10/9 2:52:25 · 阅读 1.2k 彭大帅的AI运维助手实战案例 1 · 凌晨 3 点的磁盘告警
从告警到清理30 分钟闭环人只点了一次确认—— 系列第 1 篇 ——2026 年 10 月目 录一、现场一条凌晨 3 点的告警二、告警从哪来30 秒一轮的值守三、把排障交给 AI完整对话实录四、AI 停下来的那一秒五、收尾让下次不用再爬起来一、现场一条凌晨 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、内存、磁盘、交换分区使用率和关键服务存活状态。默认阈值如下都可以在配置里改指标默认告警阈值说明CPU 使用率90%持续超阈值才告警偶发尖峰不误报内存使用率90%同上磁盘使用率85%本篇案例的触发点交换分区70%swap 用得深通常是内存吃紧的前兆服务存活进程消失即告警支持 web / db / k8s / OpenStack 等角色探针自动识别按角色挂载判定有两个防误报设计。一是状态机去抖同一台主机同一项指标从正常变异常只推送一次告警恢复时再推送一次「已恢复」不会每 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/shmAI根分区 92%。继续定位大目录 → run_command(du -x --max-depth2 /var | sort -rh | head -15)18G /var/lib/mysql14G /var/log3.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.gzAI查看错误日志尾部确认刷屏原因 → run_command(tail -30 /var/log/mysqld.log)连续数千行重复的 Aborted connection 报错此前数周一直在写到这里根因已经清楚MySQL 的错误日志既没配轮转又被连接异常反复刷屏一个月写出了 12G再加上几个几百兆的旧系统日志压缩包。AI 给出了处理建议并且把风险讲在前面AI建议分三步处理其中第 1 步对运行中的日志文件清空是安全的第 2 步删除旧轮转压缩包不可逆第 3 步涉及 MySQL binlog 建议单独评估1. 清空 /var/log/mysqld.logtruncate -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 运维助手发现问题监控告警喊人值守告警喊人同时已备好对话入口定位根因人肉 df / du 逐层翻AI 自主连续执行只读命令直接给出结论执行处理人手敲命令全靠经验把关AI 拟好命令与风险说明人工一次确认结果验证再敲一次 df 自己看AI 执行后自动回验并报告事后预防想起来的话才去配AI 主动建议轮转与巡检加固总耗时30~60 分钟全程清醒不到 30 分钟人的参与以秒计五、收尾让下次不用再爬起来清理完成后我追问了一句「以后怎么避免」AI 给出的方案包括为 mysqld.log 配置 logrotate 按天轮转并限制保留个数在 MySQL 侧排查 Aborted connection 的来源常见是应用连接池配置不当或网络闪断以及把磁盘巡检阈值对 /var 单独收紧。这类加固操作依然走「AI 拟方案、人确认」的节奏这里不展开。这一篇完整的链路是值守 30 秒一轮发现异常 → 横幅、报警音、邮件三路喊人 → AI 只读命令自主排障 → 高危操作一次确认 → 执行后自动回验 → 值守面板恢复推送。你会发现整个过程中 AI 扮演的是「值班工程师」而你是「签字的领导」——领导只需要在正确的时间做正确的决定。磁盘告警只是值守场景里最常见的一种。下一篇换一个更常见的现场白天业务网站突然 502 了——这次连告警都来不及等而且我们会用到另一个武器把报错截图直接丢给 AI。