本文通過 AI Agent 技術(shù)實(shí)現(xiàn)數(shù)據(jù)庫異常的自動(dòng)發(fā)現(xiàn)、智能分析和快速修復(fù)，將故障處理時(shí)間從數(shù)小時(shí)縮短到分鐘級(jí)，異常誤報(bào)率降低 60-80%。

背景：三大核心痛點(diǎn)

隨著業(yè)務(wù)規(guī)模快速增長(zhǎng)，OPPO的數(shù)據(jù)庫規(guī)模已達(dá)到數(shù)十萬實(shí)例、千萬級(jí)庫表，涵蓋MySQL、PostgreSQL、MongoDB、ClickHouse、Redis、Milvus等多種數(shù)據(jù)庫類型。常見故障點(diǎn)：

圖1：數(shù)據(jù)庫常見故障點(diǎn)

分析發(fā)現(xiàn)：

• 80%的故障時(shí)間花在問題分析與根因定位
• 平均故障處理時(shí)長(zhǎng)195分鐘，70%為性能調(diào)優(yōu)問題

傳統(tǒng)的人工診斷模式面臨三大核心痛點(diǎn)：

AI智能診斷：三大核心優(yōu)勢(shì)

基于AI Agent構(gòu)建的智能診斷系統(tǒng)，相比傳統(tǒng)診斷具有三大核心優(yōu)勢(shì)

2.1 多模態(tài)融合診斷

傳統(tǒng)方式：孤立指標(biāo)檢查 + 人工經(jīng)驗(yàn)關(guān)聯(lián)

AI方式：同時(shí)處理數(shù)百個(gè)指標(biāo)，自動(dòng)發(fā)現(xiàn)隱式關(guān)聯(lián)，融合5種數(shù)據(jù)模態(tài):

1. 指標(biāo)時(shí)序數(shù)據(jù)（Prometheus/Grafana）
2. 文本日志（錯(cuò)誤日志、慢查詢?nèi)罩荆?/li>
3. 配置信息（my.cnf等）
4. SQL文本（查詢語句、執(zhí)行計(jì)劃）
5. 拓?fù)浣Y(jié)構(gòu)（主從關(guān)系、分片信息）

案例：

數(shù)據(jù)庫突然變慢：
指標(biāo)：QPS下降50%
日志：大量"Lock wait timeout"錯(cuò)誤
SQL：UPDATE執(zhí)行時(shí)間從10ms增加到5s
配置：innodb_lock_wait_timeout設(shè)置為50s（過長(zhǎng)）
拓?fù)洌篣PDATE在從庫執(zhí)行（錯(cuò)誤）
AI判斷：應(yīng)用錯(cuò)誤路由到從庫 → 從庫只讀阻塞 → 連接池耗盡 → QPS下降

價(jià)值：排查時(shí)間從數(shù)小時(shí)縮短到分鐘級(jí)

2.2 動(dòng)態(tài)自適應(yīng)診斷

傳統(tǒng)方式：閾值固定，無法區(qū)分“正常的高負(fù)載”與“異常的高負(fù)載”

AI方式：

1. 自動(dòng)識(shí)別業(yè)務(wù)流量變化：工作日 vs 周末、業(yè)務(wù)高峰期 vs 低峰期
2. 異常評(píng)分：使用綜合評(píng)分規(guī)則給出異常程度
3. 遷移學(xué)習(xí)：將A庫的診斷經(jīng)驗(yàn)遷移到B庫（同架構(gòu)、不同業(yè)務(wù)）

案例：

傳統(tǒng)：CPU 85% → 告警（可能是正常業(yè)務(wù)高峰）
AI： CPU 85% + 查詢模式異常 + 連接數(shù)突增 + 歷史同期對(duì)比→ 綜合評(píng)分0.92（高度異常）→ 告警

價(jià)值：異常誤報(bào)率降低60-80%

2.3 預(yù)測(cè)性診斷

傳統(tǒng)流程：?jiǎn)栴}發(fā)生 → 用戶投訴 → DBA介入 → 分析 → 解決（已造成影響）

AI能力：

1. 時(shí)序預(yù)測(cè)：預(yù)測(cè)未來1-24小時(shí)性能趨勢(shì)
2. 故障預(yù)測(cè)：磁盤空間、容量預(yù)警
3. 性能退化預(yù)警：提前發(fā)現(xiàn)索引效率下降

案例：

AI模型輸入：
- 磁盤空間增長(zhǎng)率（指數(shù)增長(zhǎng)趨勢(shì)）
- 表大小增長(zhǎng)率
- 歷史清理周期
AI輸出：
"預(yù)計(jì)3天后磁盤將滿，建議立即執(zhí)行歸檔操作"

價(jià)值：從"救火"到"防火"，故障從"已發(fā)生"提前到"即將發(fā)生"

技術(shù)架構(gòu)：ODC+知識(shí)庫+AI Agent

3.1 整體架構(gòu)

• 多數(shù)據(jù)庫類型：OLTP、文檔型、分析型、鍵值型、AI新業(yè)態(tài)型數(shù)據(jù)庫
• 多模數(shù)據(jù)管理平臺(tái)：OneMeta：各數(shù)據(jù)庫類型在系統(tǒng)變成“可理解、可治理、可查詢”統(tǒng)一數(shù)據(jù)資產(chǎn)；OneOps：提供DBaaS（數(shù)據(jù)庫即服務(wù)）的體驗(yàn)，所有運(yùn)維相關(guān)操作的控制平臺(tái)
• AI驅(qū)動(dòng)：構(gòu)建數(shù)據(jù)庫知識(shí)庫，融合專家經(jīng)驗(yàn)+AI Agent
• AI應(yīng)用：多種場(chǎng)景如開發(fā)提效、智能診斷、智能運(yùn)維自治

圖2：AI智能診斷系統(tǒng)整體架構(gòu)

多模數(shù)據(jù)管理平臺(tái)ODC(Open Database Develop Center)已經(jīng)完成并投入使用，不做過多說明。本文主要介紹智能診斷模塊的實(shí)現(xiàn)，開發(fā)提效和智能運(yùn)維模塊后續(xù)再做詳細(xì)介紹。

3.2 智能診斷核心組件

OneMetrics：統(tǒng)一監(jiān)控指標(biāo)輸入與異常監(jiān)測(cè)

• 運(yùn)行日志：慢日志、錯(cuò)誤日志、審計(jì)日志
• 性能指標(biāo)：CPU、內(nèi)存、IO、連接數(shù)等
• 操作日志：擴(kuò)縮容、主從切換、參數(shù)修改

診斷自治服務(wù)：專家經(jīng)驗(yàn) + AI Agent

• 異常識(shí)別：自動(dòng)識(shí)別CPU飆高、慢日志激增等
• 異常分析：AAS分析 + AI Agent智能診斷
• 異常定位：基于RAG的檢索增強(qiáng)生成

圖3：診斷自治服務(wù)流程圖

核心技術(shù)：專家經(jīng)驗(yàn)+RAG增強(qiáng)型AI

4.1 診斷演進(jìn)路徑

4.2 診斷流程：識(shí)別→分析→定位

圖4：智能診斷方案

4.2.1 異常識(shí)別

依賴數(shù)據(jù)采集時(shí)的監(jiān)測(cè)，自動(dòng)識(shí)別異常場(chǎng)景：

• CPU飆高
• 內(nèi)存異常
• 慢日志激增
• 錯(cuò)誤日志
• 主從切換
• 整庫整表刪除
• 其他異常場(chǎng)景

4.2.2 異常分析

專家經(jīng)驗(yàn)部分：

以AAS（平均活躍會(huì)話數(shù)）作為切入點(diǎn)：

• AAS數(shù)量變化趨勢(shì)反映數(shù)據(jù)庫實(shí)例負(fù)載變化
• 優(yōu)先處理AAS數(shù)量較多的會(huì)話狀態(tài)
• 快速初步定位根因

AI Agent部分：

將以下信息作為輸入，以Prompt形式發(fā)送給AI Agent：

• 異常信息
• 審計(jì)日志
• 慢日志
• 錯(cuò)誤日志
• AAS數(shù)據(jù)
• 操作日志
• 監(jiān)控指標(biāo)
• 特殊指標(biāo)

AI Agent進(jìn)行預(yù)設(shè)的分析流程進(jìn)行智能診斷分析，輸出診斷結(jié)果。

4.2.3 異常定位

技術(shù)方案：基于RAG（Retrieval-Augmented Generation，檢索增強(qiáng)生成）

圖5：基于RAG的異常定位技術(shù)架構(gòu)

RAG的優(yōu)勢(shì)：

? 結(jié)合通用知識(shí)庫和人工標(biāo)注結(jié)果

? 融入企業(yè)私有業(yè)務(wù)知識(shí)

? 顯著提升準(zhǔn)確性，減少AI幻覺

? 調(diào)用OneMeta API，增強(qiáng)診斷準(zhǔn)確性

反饋閉環(huán)：

用戶對(duì)診斷結(jié)果評(píng)價(jià)后：

• 將Prompt和用戶標(biāo)注結(jié)果輸入嵌入式模型
• 更新知識(shí)庫
• 持續(xù)優(yōu)化診斷效果

4.3 結(jié)果評(píng)估：雙重保障

AI評(píng)估

使用AI小模型對(duì)DB Agent輸出進(jìn)行評(píng)估：

人工評(píng)估

• 用戶評(píng)估：對(duì)診斷結(jié)果準(zhǔn)確性和采納與否進(jìn)行評(píng)估
• 專家評(píng)估：專家對(duì)結(jié)果的準(zhǔn)確性、相關(guān)性、安全性再次評(píng)估
• 知識(shí)庫更新：剔除badcase，存入優(yōu)質(zhì)案例，持續(xù)優(yōu)化

重要性：雖然評(píng)估成本較大，但這是提高DB Agent準(zhǔn)確率的"良方"，尤其在數(shù)據(jù)庫這種基礎(chǔ)高風(fēng)險(xiǎn)組件中尤為重要。

實(shí)戰(zhàn)案例：CPU飆高診斷

5.1 異常監(jiān)測(cè)

進(jìn)入性能診斷界面，發(fā)現(xiàn)CPU使用率在21:03:00-21:13:00突然飆高至85%，觸發(fā)智能診斷。

圖6：CPU使用率異常監(jiān)測(cè)界面

5.2 根因分析與定位

通過AAS（平均活躍會(huì)話數(shù)）分析發(fā)現(xiàn)：

• 數(shù)據(jù)庫Sending_data負(fù)載最大
• AAS數(shù)量變化趨勢(shì)與CPU飆高時(shí)間段完全吻合
• 業(yè)務(wù)Send數(shù)據(jù)量和MySQL的TPS增多，相互佐證

圖7：AAS分析圖

推斷：CPU飆高由數(shù)據(jù)庫查詢時(shí)Sending_data數(shù)據(jù)過多引起。通過SQL關(guān)聯(lián)分析，定位到導(dǎo)致CPU飆高的SQL指紋。

5.3 優(yōu)化建議

AI提供索引建議和SQL改寫建議，一鍵跳轉(zhuǎn)ODC數(shù)據(jù)變更界面。

圖8：SQL優(yōu)化建議界面

核心價(jià)值與展望

1. 核心成果

• 異常發(fā)現(xiàn)及時(shí)性：從被動(dòng)響應(yīng)到主動(dòng)預(yù)測(cè)
• 根因診斷高效性：從數(shù)小時(shí)縮短到分鐘級(jí)
• 異常告警準(zhǔn)確性：異常誤報(bào)降低60-80%

2. 技術(shù)亮點(diǎn)

• 多模態(tài)融合：融合指標(biāo)、日志、配置、SQL、拓?fù)涞榷嘣磾?shù)據(jù)
• RAG增強(qiáng)生成：結(jié)合知識(shí)庫和專家經(jīng)驗(yàn)，提升診斷準(zhǔn)確性
• 雙軌制保障：專家經(jīng)驗(yàn)+AI，保證穩(wěn)定性
• 反饋閉環(huán)：用戶和專家評(píng)估，持續(xù)優(yōu)化

3. 未來方向

• 持續(xù)優(yōu)化AI模型，提升診斷準(zhǔn)確率
• 擴(kuò)展更多數(shù)據(jù)庫類型支持
• 增強(qiáng)預(yù)測(cè)性診斷能力
• 完善自動(dòng)化修復(fù)能力

總結(jié)

數(shù)據(jù)庫智能診斷實(shí)現(xiàn)了資源監(jiān)控與SQL智能關(guān)聯(lián)，精準(zhǔn)鎖定異常根因，提供優(yōu)化方案，形成異常發(fā)現(xiàn)-診斷-修復(fù)閉環(huán)。

AI的診斷結(jié)果并非完全準(zhǔn)確，部分重要場(chǎng)景仍需要人為干預(yù)和引導(dǎo)。DB Agent的建設(shè)是一條持續(xù)且漫長(zhǎng)的道路，需要我們不斷優(yōu)化與改進(jìn)。