上周客户现场又遇到一次凌晨告警。MySQL 实例 OOM，Zabbix 第一时间把告警推过来了，没问题。问题是告警来了之后，值班同学花了 40 分钟才定位到是 innodb_buffer_pool_size 配得太大，物理内存扛不住。
40 分钟。其中 35 分钟在搜资料、翻文档、试错。真正敲对命令就 5 分钟的事。
这事儿我琢磨了好几天。Zabbix 的告警能力没得说，CPU 爆了、磁盘满了、数据库 OOM 了，它都能第一时间告诉你。但告警来了之后呢？知识是散的。Oracle AWR 报告怎么读、MySQL 慢查询怎么定位、金仓的 work_mem 怎么调，这些知识散落在官方文档、博客、群里截图、个人笔记里。遇到问题现搜现试，效率低，踩坑多。
BIC-QA 干的事就是把数据库领域的知识收拢起来，做成一个可以对话问答的知识库。我最近用 AtomCode 做了一个 Zabbix 插件，把 BIC-QA 嵌进了 Zabbix 面板。这篇文章记录一下这个插件的设计思路和实现过程。
01. 痛点在哪
先说清楚为什么要做这个插件。
我整理了一下客户现场遇到告警后的典型处理流程，大概是这样的：
| 步骤 | 动作 | 耗时占比 |
|---|---|---|
| 1 | 登录 Zabbix 看告警 | 5% |
| 2 | 打开浏览器搜关键词 | 20% |
| 3 | 翻几篇质量参差不齐的博客 | 25% |
| 4 | 照着敲命令，可能敲错 | 10% |
| 5 | 发现不适用当前版本，再搜 | 25% |
| 6 | 终于定位到根因 | 15% |
看明白了吗？真正花在"解决问题"上的时间只有 15%。剩下的 85% 都耗在"找知识"上。。。。。。
这就是我们需要一个 Zabbix 插件的原因。告警发生的那一刻，就是最需要知识的时候。如果运维同学在 Zabbix 面板看到告警，顺手就能问 BIC-QA 拿到分析思路和处置命令，这个闭环就非常短，效率就上来了。
02. 插件长什么样
装好之后，Zabbix 左侧菜单栏的 Monitoring 下面会多出一个入口，叫 “BIC-QA 智能分析”。点进去是一个三 Tab 的页面。
第一个 Tab 是对话。底部输入框打字，点发送或者按 Ctrl+Enter，回答会以聊天气泡的形式弹出来。比如你输入"Oracle AWR 报告里 DB Time 很高怎么分析"，它会返回一段结构化的分析建议，从 AAS 计算到 DB Time 构成拆解，专业且可直接操作。
第二个 Tab 是告警分析，这是重头戏。把 Zabbix 告警文本粘进去，点分析根因，插件会自动给告警文本套上一个结构化的提问模板，调用 BIC-QA 返回四段式的根因分析：
- 现象解读：告警到底在说什么
- 根因排序：按可能性从高到低列出候选根因
- 定位命令/SQL：可以直接复制粘贴执行的排查命令
- 处置建议：短期怎么止血，长期怎么根治
第三个 Tab 是配置。就两个字段，API 地址（默认已填好）和 API Key。填完点保存，整个插件就能用了。Key 在打码显示，不会裸奔在页面上。
API KEY 哪里获取？点击阅读原文 https://www.bic-qa.com/pages/popup.html?inviteCode=VQ672G7B 注册即可。现在新户注册可获赠 1 亿 Token，每天签到还可获 1000 万 Token。
03. 告警列表一键 AI 分析
周末听了一场关于 Zabbix 的分享，还有幸和周松老师面基并合影。这个特性是我从分享中得到的启发。
以前你得手动把告警文本复制粘贴到告警分析 Tab，虽然也不难，但多了一步复制粘贴的动作。现在我在 Zabbix 的 Problems 页面，每个告警行旁边注入了一个 🤖 AI 按钮。点一下，告警信息自动填入对话框，BIC-QA 自动开始分析。
验证结果让我比较满意。我用了 Playwright 做端到端测试，模拟真实用户操作：登录 Zabbix → 打开 Problems 页面 → 点击 🤖 AI 按钮 → 检查是否跳转到 BIC-QA 分析页面 → 等待分析结果返回。
实测数据是这样的：
| 验证项 | 结果 |
|---|---|
| AI 按钮注入到真实告警行 | 成功，3 个告警行各注入 1 个按钮 |
| 日期分隔行不注入按钮 | 成功，2 个 row-disabled 行无按钮 |
| 点击 AI 按钮跳转 bicqa.main | 成功，URL 参数正确传递 |
| 告警文本自动预填 | 成功，预填文本 87 字符 |
| BIC-QA 自动触发根因分析 | 成功，返回 3183 字符的分析结果 |
从点击按钮到看到分析结果，整个过程不到 10 秒。考虑到 BIC-QA 的知识库覆盖了 Oracle、MySQL、金仓、PostgreSQL、SQL Server 这些主流数据库，这个响应速度我觉得是可以接受的。
下面是实测截图。 Problems 页面同时显示两个 MySQL 告警，MySQL OOM 和 MySQL 死锁，每行右侧都注入了 🤖 AI 按钮：
点击死锁告警行的 🤖 AI 按钮，自动跳转到 BIC-QA 智能分析页面，告警文本已预填，根因分析自动触发并返回结果：
04. 从手动搜索到一键分析
让我们回顾一下告警处理方式的演进。
| 阶段 | 时间线 | 处理方式 | 平均定位耗时 |
|---|---|---|---|
| 1.0 | 2015 年前 | 翻纸质文档，问老员工 | 2-4 小时 |
| 2.0 | 2015-2020 | 搜索引擎 + 技术博客 | 30-60 分钟 |
| 3.0 | 2020-2026 | ChatGPT/通用 AI 辅助 | 15-30 分钟 |
| 4.0 | 2026 起 | 专业知识库嵌入监控面板 | 5-10 分钟 |
我们现在的方案处于 4.0 阶段。核心变化是知识不再散落在外部，而是直接嵌入到了告警发生的现场。
这个演进的背后有一个逻辑。告警处理的瓶颈从来不是工具不够多，而是知识与告警之间的距离太远。搜索引擎时代，这个距离是"打开浏览器 → 输入关键词 → 筛选结果"。通用 AI 时代，这个距离缩短为"打开 ChatGPT → 提问"。而我们的方案，把这个距离缩短为零，因为知识就在告警旁边，点一下就行。
05. 几种方案的对比
看看市面上几种告警处理方案的差异。
| 方案 | 知识来源 | 与告警的距离 | 个性化程度 | 维护成本 |
|---|---|---|---|---|
| 搜索引擎 | 互联网 | 远（需手动搜索） | 无 | 零 |
| 通用 AI 助手 | 通用大模型 | 中（需切换工具） | 低 | 零 |
| 企业内部知识库 | 内部文档 | 中（需登录系统） | 中 | 高 |
| BIC-QA + Zabbix 插件 | 数据库专业图谱 | 零（嵌入告警面板） | 高 | 低 |
几个关键差异点。
第一，知识的专业性。BIC-QA 的知识库不是通用大模型那种"什么都知道一点但都不深"的路子，它是专门针对数据库领域构建的知识图谱。你问它 Oracle AWR 报告怎么读，它能告诉你具体的计算公式和判断标准，而不是给你一段泛泛而谈的科普。
第二，与告警的距离。这是我最看重的一点。传统方案下，运维同学看到告警后要做一系列动作才能开始排查。而我们的插件把知识直接放到了告警旁边，点一下 🤖 AI 按钮就行。从看到告警到拿到分析结果，只需要两次点击。
第三，维护成本。BIC-QA 平台的知识库是持续维护更新的，你装好插件之后，每次提问拿到的都是最新的知识，不用自己做知识库的维护和更新。
06. 总结
总结三点。
第一，监控工具和知识库的融合是个必然趋势。Zabbix 告诉你哪里着火了，BIC-QA 告诉你怎么灭火，这个插件让你在同一个房间里同时拿到这两条信息。未来更多的监控工具会走这条路，把知识检索能力原生集成到告警流程里。
第二，专业领域的知识图谱比通用大模型更有价值。通用大模型什么都知道一点，但遇到数据库这种专业领域，深度不够。BIC-QA 这种专门针对数据库领域构建的知识图谱，在准确性和可操作性上都有明显优势。
第三，告警处理的下一个突破点是 AI 自动化处置。现在我们的插件做到了"告警来了，一键拿到根因分析和排查命令"，但这些命令还是需要人工去执行。下一步如果能把分析结果直接对接到 AI 自动化运维工具，实现"告警来了，自动定位根因，自动执行处置脚本"，那才是真正的无人值守。
最后，还有很多客户、甲方希望有一套成熟的私有化部署方案，或许，我们可以期待一下基于 Zabbix + BIC-QA 的 AI 智慧一体机。
如果你对这个话题感兴趣，或者在告警处理流程上有自己的实践，欢迎在评论区聊聊。
Have a nice day ~ ☕
公众号「少安事务所」，专注于数据 & AI 领域技术传播。
如果这篇文章为你带来了灵感或启发，请帮忙『点赞、转发、推荐』，感谢！ღ( ´･ᴗ･` )~
