多模态看图不是噱头是排障提速的实招—— 系列第 2 篇 ——2026 年 10 月目 录一、现场白天网站 502 了二、多模态把截图丢给 AI三、从截图到根因AI 的只读排查链四、修复与加固一次确认的重启五、复盘为什么看图不是噱头一、现场白天网站 502 了上一篇是凌晨的值守告警这一篇换成白天最常见的突发下午两点运营同事在群里喊「网站打不开了」。web01 是一台 Rocky Linux 9 虚拟机Nginx 反代后面的 PHP 应用平时稳得没存在感。这种场景有个特点你不是从告警开始的而是从一句模糊的转述开始的——「打不开」「一直转圈」「报了个错」。传统做法下你要么自己登服务器漫无目的翻日志要么让同事把报错截图发过来再对着截图猜是哪一层的毛病NginxPHP数据库防火墙502 这个词对运维人不陌生但对报障的人是黑话。这一篇要展示的核心能力是把报障同事的截图原样丢给 AI让它自己「看懂」这是哪一层的错误然后带着方向去排查——而不是让你当人肉翻译把截图转述成技术语言再喂给工具。二、多模态把截图丢给 AIAI 运维助手支持在对话里直接传图。Web GUI 里把图片拖进输入框或点上传按钮CLI 终端里用 /img 命令指定本地图片路径两者效果一样图片会被转成模型可读的格式和你的文字一起发给大模型。单张图片上限 5MB一次可以带多张。需要说明的是看图走的是你所配置的大模型的多模态能力——接 DeepSeek 这类纯文本模型时图片不参与理解换成通义千问、GLM、豆包等多模态模型或本地 Ollama 里的视觉模型即可软件本身对图片不做任何加工原图不出你的电脑本地模型或只进你选定的模型厂商云端模型。回到现场。我让同事把浏览器报错页截了图拖进对话框附一句话我[图片] 网站打不开了同事说一直转圈然后跳这个页面AI 看完图第一句话就把错误层定位了AI截图显示的是 Nginx 502 Bad Gateway。这个错误说明 Nginx 本身在运行但它后面的应用服务PHP-FPM没有响应——请求到了Nginx后端没人接。我先确认后端进程状态。注意这里发生了什么报障同事没有说一个技术词我没有做任何转述AI 从截图里读出了错误类型并且直接给出了排障方向。传统流程里「发截图 → 人看图 → 人翻译成术语 → 人登服务器」的四步被压缩成「发截图 → AI 登服务器」。三、从截图到根因AI 的只读排查链接下来的排查是 AI 自主完成的每一步都是只读命令无需确认一气呵成AI→ run_command(systemctl status php-fpm)php-fpm.service - The PHP FastCGI Process ManagerActive: inactive (dead) since 13:47:22AI后端进程确实不在了。看它是怎么退出的 →run_command(journalctl -u php-fpm --since 2 hours ago | tail -20)无正常 stop 记录AI→ run_command(dmesg -T | grep -i -E out of memory|killed process | tail -5)[五 09月27 13:47:21 2026] Out of memory: Killed process 11873(php-fpm) total-vm:9123456kB三条命令结论落地php-fpm 进程消失系统日志显示它是被内核的 OOM killer 干掉的——物理内存耗尽内核挑了占用最大的进程杀掉保命。这不是 php-fpm 自己崩了是这台小内存虚机扛不住请求高峰。AI 把根因和建议一起给了出来AI根因内存耗尽php-fpm 被 OOM killer 杀死不是配置写错。恢复systemctl restart php-fpm站点应立即恢复预防三选一或组合调低 php-fpm 的 pm.max_children、增加 swap、给这台虚机加内存。是否现在重启 php-fpm四、修复与加固一次确认的重启重启服务属于变更操作按分级管控弹确认框命令完整可见。点确认后AI→ run_command(systemctl restart php-fpm)已确认AI验证恢复 → run_command(curl -sI http://127.0.0.1 | head -3)HTTP/1.1 200 OKServer: nginxContent-Type: text/html; charsetUTF-8从同事报障到 200 OK全程不到十分钟。期间我做的动作转发一张截图、看一段分析、点一次确认。预防建议我也让 AI 直接落实了其中两条把 php-fpm 的 pm.max_children 调低并重启生效又是熟悉的确认框以及顺手确认了这台机器的值守状态——web01 早已被 scan_roles 识别为 web 角色主机PHP-FPM、Nginx 的进程探针都在下次再被 OOM 杀掉30 秒内横幅、报警音、邮件会一起来不用等同事在群里喊。至于加内存和加 swap前者要去虚拟化平台动配置后者是一条命令的事AI 同样给出了带确认的执行路径。整个事件里唯一需要「运维经验」的决策只有两个要不要现在重启以及预防方案选哪个——而这正是人该干的事。环节传统做法AI 运维助手理解报障看截图、翻译成技术问题AI 直接看图定位错误层排查路径凭经验挑命令逐个试AI 带着方向连续只读排查全程可见根因结论翻日志拼线索三条命令给出「OOM 杀进程」的确定结论执行修复人手敲重启命令AI 拟命令人一次确认恢复验证自己刷网页AI curl 回验 200 并报告事后加固常常不了了之AI 给出并落实预防清单五、复盘为什么看图不是噱头很多产品都有「传图」功能但运维场景里看图的价值经常被低估。运维信息的原始形态恰恰大量是图监控大盘截图、报错弹窗、管理界面状态页、同事随手拍的大屏。传统自动化工具要求你先把图翻译成文字或结构化数据而这个翻译过程既费时间又容易失真——报障的人说不清技术细节看图的人又不在现场。多模态把这个环节抹掉了。本篇案例里截图承担的是「零上下文冷启动」AI 不需要你描述现象现象本身就在图里。同样的能力换个场景依然成立——监控大盘里 CPU 曲线异常你截给 AI它结合数值帮你判断K8s Pod 排查时的 describe 输出太长截图发过去让它先扫一眼找重点都是同一个道理。这一篇的关键词是「白天突发 零上下文」没有值守告警铺路报障就是一句话加一张图。AI 先用眼睛看懂问题再用 SSH 读懂机器最后在变更前停下问你。看图、执行、刹车三件事连成一条完整的排障流水线。下一篇回到批量场景月底三十台服务器要巡检一次对话能不能巡完 
长河君 · 2026/10/9 2:52:25 · 阅读 1.2k 彭大帅的AI运维助手实战案例 2 · 网站 502，把报错截图丢给 AI
多模态看图不是噱头是排障提速的实招—— 系列第 2 篇 ——2026 年 10 月目 录一、现场白天网站 502 了二、多模态把截图丢给 AI三、从截图到根因AI 的只读排查链四、修复与加固一次确认的重启五、复盘为什么看图不是噱头一、现场白天网站 502 了上一篇是凌晨的值守告警这一篇换成白天最常见的突发下午两点运营同事在群里喊「网站打不开了」。web01 是一台 Rocky Linux 9 虚拟机Nginx 反代后面的 PHP 应用平时稳得没存在感。这种场景有个特点你不是从告警开始的而是从一句模糊的转述开始的——「打不开」「一直转圈」「报了个错」。传统做法下你要么自己登服务器漫无目的翻日志要么让同事把报错截图发过来再对着截图猜是哪一层的毛病NginxPHP数据库防火墙502 这个词对运维人不陌生但对报障的人是黑话。这一篇要展示的核心能力是把报障同事的截图原样丢给 AI让它自己「看懂」这是哪一层的错误然后带着方向去排查——而不是让你当人肉翻译把截图转述成技术语言再喂给工具。二、多模态把截图丢给 AIAI 运维助手支持在对话里直接传图。Web GUI 里把图片拖进输入框或点上传按钮CLI 终端里用 /img 命令指定本地图片路径两者效果一样图片会被转成模型可读的格式和你的文字一起发给大模型。单张图片上限 5MB一次可以带多张。需要说明的是看图走的是你所配置的大模型的多模态能力——接 DeepSeek 这类纯文本模型时图片不参与理解换成通义千问、GLM、豆包等多模态模型或本地 Ollama 里的视觉模型即可软件本身对图片不做任何加工原图不出你的电脑本地模型或只进你选定的模型厂商云端模型。回到现场。我让同事把浏览器报错页截了图拖进对话框附一句话我[图片] 网站打不开了同事说一直转圈然后跳这个页面AI 看完图第一句话就把错误层定位了AI截图显示的是 Nginx 502 Bad Gateway。这个错误说明 Nginx 本身在运行但它后面的应用服务PHP-FPM没有响应——请求到了Nginx后端没人接。我先确认后端进程状态。注意这里发生了什么报障同事没有说一个技术词我没有做任何转述AI 从截图里读出了错误类型并且直接给出了排障方向。传统流程里「发截图 → 人看图 → 人翻译成术语 → 人登服务器」的四步被压缩成「发截图 → AI 登服务器」。三、从截图到根因AI 的只读排查链接下来的排查是 AI 自主完成的每一步都是只读命令无需确认一气呵成AI→ run_command(systemctl status php-fpm)php-fpm.service - The PHP FastCGI Process ManagerActive: inactive (dead) since 13:47:22AI后端进程确实不在了。看它是怎么退出的 →run_command(journalctl -u php-fpm --since 2 hours ago | tail -20)无正常 stop 记录AI→ run_command(dmesg -T | grep -i -E out of memory|killed process | tail -5)[五 09月27 13:47:21 2026] Out of memory: Killed process 11873(php-fpm) total-vm:9123456kB三条命令结论落地php-fpm 进程消失系统日志显示它是被内核的 OOM killer 干掉的——物理内存耗尽内核挑了占用最大的进程杀掉保命。这不是 php-fpm 自己崩了是这台小内存虚机扛不住请求高峰。AI 把根因和建议一起给了出来AI根因内存耗尽php-fpm 被 OOM killer 杀死不是配置写错。恢复systemctl restart php-fpm站点应立即恢复预防三选一或组合调低 php-fpm 的 pm.max_children、增加 swap、给这台虚机加内存。是否现在重启 php-fpm四、修复与加固一次确认的重启重启服务属于变更操作按分级管控弹确认框命令完整可见。点确认后AI→ run_command(systemctl restart php-fpm)已确认AI验证恢复 → run_command(curl -sI http://127.0.0.1 | head -3)HTTP/1.1 200 OKServer: nginxContent-Type: text/html; charsetUTF-8从同事报障到 200 OK全程不到十分钟。期间我做的动作转发一张截图、看一段分析、点一次确认。预防建议我也让 AI 直接落实了其中两条把 php-fpm 的 pm.max_children 调低并重启生效又是熟悉的确认框以及顺手确认了这台机器的值守状态——web01 早已被 scan_roles 识别为 web 角色主机PHP-FPM、Nginx 的进程探针都在下次再被 OOM 杀掉30 秒内横幅、报警音、邮件会一起来不用等同事在群里喊。至于加内存和加 swap前者要去虚拟化平台动配置后者是一条命令的事AI 同样给出了带确认的执行路径。整个事件里唯一需要「运维经验」的决策只有两个要不要现在重启以及预防方案选哪个——而这正是人该干的事。环节传统做法AI 运维助手理解报障看截图、翻译成技术问题AI 直接看图定位错误层排查路径凭经验挑命令逐个试AI 带着方向连续只读排查全程可见根因结论翻日志拼线索三条命令给出「OOM 杀进程」的确定结论执行修复人手敲重启命令AI 拟命令人一次确认恢复验证自己刷网页AI curl 回验 200 并报告事后加固常常不了了之AI 给出并落实预防清单五、复盘为什么看图不是噱头很多产品都有「传图」功能但运维场景里看图的价值经常被低估。运维信息的原始形态恰恰大量是图监控大盘截图、报错弹窗、管理界面状态页、同事随手拍的大屏。传统自动化工具要求你先把图翻译成文字或结构化数据而这个翻译过程既费时间又容易失真——报障的人说不清技术细节看图的人又不在现场。多模态把这个环节抹掉了。本篇案例里截图承担的是「零上下文冷启动」AI 不需要你描述现象现象本身就在图里。同样的能力换个场景依然成立——监控大盘里 CPU 曲线异常你截给 AI它结合数值帮你判断K8s Pod 排查时的 describe 输出太长截图发过去让它先扫一眼找重点都是同一个道理。这一篇的关键词是「白天突发 零上下文」没有值守告警铺路报障就是一句话加一张图。AI 先用眼睛看懂问题再用 SSH 读懂机器最后在变更前停下问你。看图、执行、刹车三件事连成一条完整的排障流水线。下一篇回到批量场景月底三十台服务器要巡检一次对话能不能巡完