KingbaseES 的卢智能运维体架构深度拆解

数据库运维这种事吧，我干了很多年了，最大的感受是啥呢？其实就是靠人肉。对，就是你得熬。熬出来的那个经验才值钱。KingbaseES 这边搞了个叫的卢的东西。其实想法也不复杂。就是把 DBA 那些年攒下来的那套东西给弄成一种结构化的知识图谱。再加上 NL2SQL、NL2Action 这两个引擎。然后呢，你就不用啥都得自己敲命令了，用大白话说就行。下面我把我了解到的一些情况整理了一下。不是什么官方定论，大家看着玩就行。

引言

先扯几句闲的吧。

数据库运维这个岗位，其实很吃经验的。真的是吃经验的。你出去面一个 DBA，三年跟十年的差距在哪里呢？基本上就是人家碰到过的故障种类多不多。

我见过的最厉害的 DBA，看几个指标曲线，直接就告诉你，嗯，某某表缺个索引，建了就好。你问他怎么知道的。他说以前碰到过。就这样。那他脑子里头得有多少这种模式呢？我估摸着没有几千个也有一千多个吧。什么指标组合对应什么问题，什么操作治什么症状。就是套路，一通百通的那种。

但是这个模式，说实话，问题挺大的。

经验不可复制：上面说的那种老法师，你让他带徒弟的话，两年都未必带得出来。东西在他脑子里，你又挖不出来。
响应有时间差：7×24 小时高可用，其实也就是个口号。靠人守吗？凌晨三点出故障，你在被窝里收到电话，人都没清醒。
规模有上限：一个人顾多少实例合适呢？我跟你们讲，四五十个差不多了。再多的话就不是运维了，是救火，天天灭火。

然后呢，信通院不是有个报告嘛，2024 年的。里面说 65% 的企业因为数据库性能出问题了导致业务停过。一年光故障处理就要烧掉 300 多个小时。IDC 那边也说，70% 的运维人力耗在巡检这种没啥技术含量的事情上了。

所以金仓的想法就是什么呢？你能不能让数据库自己学会诊断，自己修？把人的经验给它灌进去。的卢就是这么个东西。

一、DAAS 四级演进模型

金仓给这个东西起了个名字，叫 DAAS（Database Autonomy as a Service，数据库自治即服务）。挺长的一个缩写。他们把运维分成了四个档吧。

层级	名称	核心特征	人参与度
L1	被动响应	人工监控 + 脚本工具，故障后处理	100%
L2	主动预防	指标关联分析，提前预警，人工确认后执行	60%
L3	智能辅助	AI 生成诊断报告和优化建议，人工审批后自动执行	30%
L4	自治闭环	检测---诊断---决策---执行---验证全自动闭环	<10%

现在企业大概在什么水平呢。多数在 L1 到 L2 中间，上不上下不下的。的卢这东西要干的事，说白了就是使劲把人往 L3、L4 拽。

那你说 L3 到 L4 中间差的是啥呢？这个问题我一开始也不明白。后来看了架构才反应过来。它不光是个算法升级的事。它是一个完整的"感知---知识---决策---执行"闭环。你四个环，缺一个，它就不是自治系统，最多是个长得好看的监控。真的，就这点区别。

二、三位一体智能架构

2.1 架构全景

#mermaid-svg-ZI0iqc9mexfGNNc0{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;fill:#333;}@keyframes edge-animation-frame{from{stroke-dashoffset:0;}}@keyframes dash{to{stroke-dashoffset:0;}}#mermaid-svg-ZI0iqc9mexfGNNc0 .edge-animation-slow{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 50s linear infinite;stroke-linecap:round;}#mermaid-svg-ZI0iqc9mexfGNNc0 .edge-animation-fast{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 20s linear infinite;stroke-linecap:round;}#mermaid-svg-ZI0iqc9mexfGNNc0 .error-icon{fill:#552222;}#mermaid-svg-ZI0iqc9mexfGNNc0 .error-text{fill:#552222;stroke:#552222;}#mermaid-svg-ZI0iqc9mexfGNNc0 .edge-thickness-normal{stroke-width:1px;}#mermaid-svg-ZI0iqc9mexfGNNc0 .edge-thickness-thick{stroke-width:3.5px;}#mermaid-svg-ZI0iqc9mexfGNNc0 .edge-pattern-solid{stroke-dasharray:0;}#mermaid-svg-ZI0iqc9mexfGNNc0 .edge-thickness-invisible{stroke-width:0;fill:none;}#mermaid-svg-ZI0iqc9mexfGNNc0 .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-svg-ZI0iqc9mexfGNNc0 .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-svg-ZI0iqc9mexfGNNc0 .marker{fill:#333333;stroke:#333333;}#mermaid-svg-ZI0iqc9mexfGNNc0 .marker.cross{stroke:#333333;}#mermaid-svg-ZI0iqc9mexfGNNc0 svg{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;}#mermaid-svg-ZI0iqc9mexfGNNc0 p{margin:0;}#mermaid-svg-ZI0iqc9mexfGNNc0 .label{font-family:"trebuchet ms",verdana,arial,sans-serif;color:#333;}#mermaid-svg-ZI0iqc9mexfGNNc0 .cluster-label text{fill:#333;}#mermaid-svg-ZI0iqc9mexfGNNc0 .cluster-label span{color:#333;}#mermaid-svg-ZI0iqc9mexfGNNc0 .cluster-label span p{background-color:transparent;}#mermaid-svg-ZI0iqc9mexfGNNc0 .label text,#mermaid-svg-ZI0iqc9mexfGNNc0 span{fill:#333;color:#333;}#mermaid-svg-ZI0iqc9mexfGNNc0 .node rect,#mermaid-svg-ZI0iqc9mexfGNNc0 .node circle,#mermaid-svg-ZI0iqc9mexfGNNc0 .node ellipse,#mermaid-svg-ZI0iqc9mexfGNNc0 .node polygon,#mermaid-svg-ZI0iqc9mexfGNNc0 .node path{fill:#ECECFF;stroke:#9370DB;stroke-width:1px;}#mermaid-svg-ZI0iqc9mexfGNNc0 .rough-node .label text,#mermaid-svg-ZI0iqc9mexfGNNc0 .node .label text,#mermaid-svg-ZI0iqc9mexfGNNc0 .image-shape .label,#mermaid-svg-ZI0iqc9mexfGNNc0 .icon-shape .label{text-anchor:middle;}#mermaid-svg-ZI0iqc9mexfGNNc0 .node .katex path{fill:#000;stroke:#000;stroke-width:1px;}#mermaid-svg-ZI0iqc9mexfGNNc0 .rough-node .label,#mermaid-svg-ZI0iqc9mexfGNNc0 .node .label,#mermaid-svg-ZI0iqc9mexfGNNc0 .image-shape .label,#mermaid-svg-ZI0iqc9mexfGNNc0 .icon-shape .label{text-align:center;}#mermaid-svg-ZI0iqc9mexfGNNc0 .node.clickable{cursor:pointer;}#mermaid-svg-ZI0iqc9mexfGNNc0 .root .anchor path{fill:#333333!important;stroke-width:0;stroke:#333333;}#mermaid-svg-ZI0iqc9mexfGNNc0 .arrowheadPath{fill:#333333;}#mermaid-svg-ZI0iqc9mexfGNNc0 .edgePath .path{stroke:#333333;stroke-width:2.0px;}#mermaid-svg-ZI0iqc9mexfGNNc0 .flowchart-link{stroke:#333333;fill:none;}#mermaid-svg-ZI0iqc9mexfGNNc0 .edgeLabel{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-ZI0iqc9mexfGNNc0 .edgeLabel p{background-color:rgba(232,232,232, 0.8);}#mermaid-svg-ZI0iqc9mexfGNNc0 .edgeLabel rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-ZI0iqc9mexfGNNc0 .labelBkg{background-color:rgba(232, 232, 232, 0.5);}#mermaid-svg-ZI0iqc9mexfGNNc0 .cluster rect{fill:#ffffde;stroke:#aaaa33;stroke-width:1px;}#mermaid-svg-ZI0iqc9mexfGNNc0 .cluster text{fill:#333;}#mermaid-svg-ZI0iqc9mexfGNNc0 .cluster span{color:#333;}#mermaid-svg-ZI0iqc9mexfGNNc0 div.mermaidTooltip{position:absolute;text-align:center;max-width:200px;padding:2px;font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:12px;background:hsl(80, 100%, 96.2745098039%);border:1px solid #aaaa33;border-radius:2px;pointer-events:none;z-index:100;}#mermaid-svg-ZI0iqc9mexfGNNc0 .flowchartTitleText{text-anchor:middle;font-size:18px;fill:#333;}#mermaid-svg-ZI0iqc9mexfGNNc0 rect.text{fill:none;stroke-width:0;}#mermaid-svg-ZI0iqc9mexfGNNc0 .icon-shape,#mermaid-svg-ZI0iqc9mexfGNNc0 .image-shape{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-ZI0iqc9mexfGNNc0 .icon-shape p,#mermaid-svg-ZI0iqc9mexfGNNc0 .image-shape p{background-color:rgba(232,232,232, 0.8);padding:2px;}#mermaid-svg-ZI0iqc9mexfGNNc0 .icon-shape .label rect,#mermaid-svg-ZI0iqc9mexfGNNc0 .image-shape .label rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-ZI0iqc9mexfGNNc0 .label-icon{display:inline-block;height:1em;overflow:visible;vertical-align:-0.125em;}#mermaid-svg-ZI0iqc9mexfGNNc0 .node .label-icon path{fill:currentColor;stroke:revert;stroke-width:revert;}#mermaid-svg-ZI0iqc9mexfGNNc0 :root{--mermaid-font-family:"trebuchet ms",verdana,arial,sans-serif;} 实时指标流
审批→灰度→回滚
执行结果验证
执行层 · 闭环自治
自动索引推荐
参数动态调优
主备切换
告警处置闭环
智能决策层 · 的卢智能体
专家知识图谱

2000+ 故障模式
根因推理引擎
LSTM 负载预测模型
NL2SQL + NL2Action

自然语言交互引擎
感知层 · 全栈可观测
轻量级 Agent

1秒级采样
12 类指标维度

CPU/IO/锁/SQL/会话...
赤兔加速引擎

百万并发·亚毫秒响应

你看上面这个图，三层。感知的那层负责采数据。中间那层管分析跟做决策。执行层就真的上手去改配置、加索引那些。然后改完之后的结果呢？再送回感知层，成一个圈。一圈一圈地转，越转越好。不是跑一次就完事了。

2.2 感知层与关联建模

以前监控怎么做的你们都知道吧。每个指标绑个阈值，飙上去就叫。告警风暴这事，搞运维的应该都经历过吧？半夜手机哔哔哔哔哔哔，几十条上百条。看都看不过来，最后你全部静音，反而把真正要命的给漏了。

金仓这个感知层不太一样。我注意到它有几个地方做得比较有意思。

关联建模替代阈值堆叠

它不去盯单个指标。它看的是那种好几个指标同时不对劲的复合型异常。

复制代码

异常模式：性能劣化前兆
触发条件：
  CPU使用率 5分钟内上升 > 30%
  AND 锁等待线程数 > 50
  AND 慢查询并发量同步上升
  AND 缓冲区命中率下降 > 15%

你拿这个跟"CPU > 80% 就告警"比一下。差别在哪儿呢？单独 CPU 高了不一定是真问题。可能就那么一阵，一会就下去了。但是你 CPU 高了，锁等待也在涨，缓冲命中率在掉，慢查询也在往上跑，这几个同时来的话，那板上钉钉是有问题了。这种搞法能把告警数量压掉 82%。原来 100 条告警，值得看的一共就 18 条。舒服。

执行计划级深度采集

sql 复制代码

-- KES V9 开启自动执行计划捕获
ALTER SYSTEM SET log_min_duration_statement = '1s';
ALTER SYSTEM SET track_io_timing = ON;
ALTER SYSTEM SET enable_auto_explain = ON;

这几个开关拨上去之后，慢 SQL 就不光是给你记"这条 SQL 跑了多久"了。它把执行计划也给捞下来。是全表扫啊还是走索引啊，JOIN 走的啥策略啊，CBO 估了多少行实际又扫出来多少行啊。这些东西吧，人去看的话，一条一条看，太累了。但是机器拿去当根因分析的原料，那真是好使。

赤兔加速引擎保障监控低开销

还有个事。监控自己采集指标也是要费资源的对吧。你并发一百万的时候，监控 Agent 把 CPU 给吃了一大块，那不是搞笑吗。赤兔这个加速引擎呢，是走内存级数据管道加上向量化处理。压下来监控开销在生产负载 2% 以内，响应延迟也是亚毫秒级别的。这块我觉得做得还算到位。

2.3 专家知识图谱

好，接下来说知识图谱。这个东西，我个人感觉是整个架构里面最难啃的一块骨头。真的难。你说别的，采集啊、执行啊，好歹有现成的路子可以参考。知识图谱这个事，你得一个一个故障去梳理，一点都偷不了懒。

金仓找了挺多行业客户一块儿做。最后攒出来 2000 多个典型故障场景。每个场景结构化成了四条东西。症状长啥样，可能是什么原因，用什么诊断 SQL 去确认，确认了之后怎么修。就是下面这个样子。

yaml 复制代码

fault_pattern:
  id: "LOCK_WAIT_STORM_001"
  name: "锁等待风暴"
  severity: "critical"

  symptoms:
    - metric: "lock_wait_count"
      condition: "> 100/s"
      duration: "持续30秒以上"
    - metric: "active_sessions"
      condition: "> max_connections * 0.8"
    - metric: "tps"
      condition: "下降超过50%"

  possible_causes:
    - cause: "长事务未提交导致阻塞链"
      probability: 0.65
      diagnostic_sql: |
        SELECT pid, state, query, xact_start,
               EXTRACT(EPOCH FROM (now() - xact_start)) AS tx_duration
        FROM sys_stat_activity
        WHERE state IN ('idle in transaction', 'active')
        ORDER BY tx_duration DESC
        LIMIT 10;

    - cause: "缺失索引导致全表扫描行级锁"
      probability: 0.25
      diagnostic_sql: |
        SELECT relname, seq_scan, seq_tup_read
        FROM sys_stat_user_tables
        WHERE seq_scan > 1000
        ORDER BY seq_tup_read DESC;

    - cause: "应用连接池配置不当导致连接泄漏"
      probability: 0.10

  recommended_actions:
    - action: "终止阻塞源头长事务"
      command: "SELECT sys_terminate_backend({pid});"
      require_approval: true
    - action: "创建缺失索引"
      command: "CREATE INDEX CONCURRENTLY idx_{table}_{col} ON {table}({col});"
      require_approval: true
    - action: "调整连接池最大连接数"
      parameter: "max_connections"
      suggested_value: "原值 * 1.5"

然后这些图谱条目跟实时指标是绑在一起的。不是静态甩在那里不管的。感知层一旦抓到 lock_wait_count > 100/s 这种情况，立马就去图谱里找匹配的条目。匹配上了跑诊断 SQL。根据返回结果锁到具体原因，然后推修复动作。

整个链条从异常冒头到出修复建议，90 秒。说真的，比好多 DBA 半夜被叫起来，人还没清醒去处理要快。

2.4 NL2SQL 与 NL2Action 双引擎

的卢跟人交互这块，底下其实是两套东西。

NL2SQL 引擎做的是什么呢？就是你问，它翻成 SQL：

复制代码

用户输入："最近一周哪些表的增长量最大？"

的卢生成：
SELECT relname,
       pg_size_pretty(pg_total_relation_size(relid)) AS current_size,
       pg_size_pretty(pg_total_relation_size(relid) -
           COALESCE(prev_size, 0)) AS growth
FROM (
    SELECT c.relname, c.relid,
           pg_total_relation_size(c.relid) AS current_size,
           s.prev_size
    FROM sys_class c
    LEFT JOIN size_history s ON s.relname = c.relname
    WHERE c.relkind = 'r'
) t
ORDER BY (pg_total_relation_size(relid) - COALESCE(prev_size, 0)) DESC
LIMIT 10;

NL2Action 引擎更进一步。你说的一个需求它能给拆成一长串动作链：

复制代码

用户输入："昨天下单接口变慢了，帮我分析一下原因"

的卢执行链：
1. [查询] 定位昨天下单相关SQL
   → SELECT sql_text, calls, total_time, mean_time
     FROM sys_stat_statements
     WHERE query ILIKE '%order%'
     AND day = CURRENT_DATE - 1;

2. [分析] 获取Top慢SQL执行计划
   → EXPLAIN ANALYZE SELECT * FROM orders WHERE create_time > ...;

3. [诊断] 匹配知识图谱
   → 发现 orders 表 seq_scan = 15243，缺失时间索引

4. [建议] 生成修复方案
   → CREATE INDEX idx_orders_create_time ON orders(create_time);
   → 预估提升：查询耗时从 2.3s 降至 0.08s

5. [执行]（需审批）
   → 用户确认后，CREATE INDEX CONCURRENTLY ...
   → 执行后验证：重新采样响应时间，确认改善

然后还有一个细节。多轮对话上下文记忆。就是说你追着往下问，它不会忘了前面聊到了哪儿。整个分析链条是连着的。这点我觉得挺好的。有些工具就是问一句忘一句，烦得很。

三、KEMCC 统一管控平台

3.1 规模化运维核心矛盾

10 个实例的时候，你拿 Excel 记都行。100 个呢，得用脚本了。1000 个呢？嗯，到了这个量级复杂度不是 10 倍 100 倍的事，是指数往上飙。每个实例自己一套配置、告警、备份、基线，靠人的话？那纯属开玩笑。

KEMCC（Kingbase Enterprise Management & Control Center）这个东西呢，一块面板把所有实例给你装了。单平台能纳 10,000 个以上的分布式数据库节点。反正够用了。

3.2 核心能力矩阵

能力域	具体功能	自动化程度
部署管理	一键安装、批量升级、补丁分发	全自动
性能监控	多维仪表盘、实时指标、历史趋势	自动采集
告警管理	智能告警收敛、分级路由、通知策略	AI 辅助
参数调优	负载感知、动态调整、灰度生效	AI 建议→审批执行
备份恢复	定时备份、增量同步、一键恢复	全自动
SQL 诊断	慢SQL分析、执行计划对比、改写建议	AI 自动分析
安全审计	操作留痕、权限审查、合规报告	全自动

3.3 效能对比实测

有个案例，省级政务云，管着 300 多个实例。迁移前后数据比了一下。

人工搞的时候呢，也就是迁移前：

步骤	耗时	操作人
收到业务方反馈	5min	值班人员
登录数据库查慢SQL日志	8min	DBA
逐条分析执行计划	15min	DBA
排查锁等待和会话状态	10min	DBA
定位根因（缺索引）	5min	DBA
编写并验证修复SQL	4min	DBA
合计	47min	2人参与

用的卢之后，也就是迁移后：

步骤	耗时	操作人
系统自动检测到慢SQL异常	3s	的卢
匹配知识图谱，执行诊断SQL	12s	的卢
生成根因分析报告	8s	的卢
推荐索引创建方案	5s	的卢
DBA 审批确认	60s	DBA（1人）
自动执行 + 验证	2s	的卢
合计	90s	1人审批

47 分钟对 90 秒，怎么算都是 31 倍。而且人力从两个人变成一个人，只做审批。分析跟执行的活全没了。诊断准确率 94.6%，我觉得对于一个自动化系统来说，已经能看了。

四、自适应参数调优机制

4.1 传统调优困境

数据库参数，挑着点讲吧。shared_buffers，work_mem，effective_cache_size，wal_buffers，maintenance_work_mem......几百个。而且这些参数不是各管各的。它们是联动的，你调一个往往会牵到一串别的。

老派做法就是静态模板。OLTP 一套、OLAP 一套，写死了，改不动。但是真实场景是这样的吗？白天高并发小交易，晚上批量大报表，大促的时候流量直接往上蹿十倍。你这套参数定死了的话，到晚上就不好使，到促销就炸。没法用。

4.2 三步动态调优

负载画像

先让 LSTM 神经网络翻过去七天的负载数据。让它自己学会你的系统平时长啥样：

python 复制代码

model = LSTMWorkloadClassifier(
    input_features=['tps', 'qps', 'io_wait', 'cpu_usage',
                    'cache_hit_ratio', 'active_sessions'],
    window_size=60,  # 60分钟窗口
    pattern_classes=['oltp_burst', 'olap_batch', 'mixed', 'idle']
)

current_pattern = model.predict(latest_60min_metrics)
# 输出：{'pattern': 'oltp_burst', 'confidence': 0.92}

参数推荐

认出来当前是啥负载模式之后呢，再去根据硬件跟数据量推一套参数给你。

sql 复制代码

ALTER SYSTEM SET kingbase_ai_tuning_mode = 'auto';
ALTER SYSTEM SET kingbase_ai_tuning_interval = 60;
-- 系统每小时自动评估并应用优化后的参数组合

它会去算参数之间的联动。比如说你把 work_mem 往上拉，单条查询确实能用更多内存了，写的临时文件也少了。但是你要知道，work_mem 是 per-operation 的，不是 per-session 的。一条复杂查询能用好多倍。你 max_connections 不跟着评估的话，总内存超的概率很大。调优引擎会把这些都算进去。

灰度生效与效果验证

参数不一把梭全量推。它有一套灰度流程。

复制代码

1. 在测试实例上应用新参数
2. 回放近期真实负载，对比性能指标
3. 性能提升 > 5%：推送到生产实例
4. 性能下降或无改善：回滚，记录负样本
5. 生产实例灰度：先调整 10% 连接使用新参数
6. 持续监控 30 分钟，指标达标后全量生效

有个电商大促的时候实测，开了 AI 调优。数据库整体性能提了 30% 多，全程没人碰，完全自动的。

五、闭环自愈与安全护栏

5.1 自愈链路

觉察到不对了之后，系统就走下面这套流程。

复制代码

检测 → 诊断 → 决策 → 审批 → 执行 → 验证 → 归档
 ↑                                    │
 └──────────────反馈循环──────────────┘

每一步具体干了些啥，我列了个表吧。

环节	动作	示例
检测	感知层发现指标异常	I/O 延迟从 2ms 升至 45ms
诊断	匹配知识图谱，执行诊断SQL	定位到某表全表扫描导致大量磁盘读
决策	AI 生成修复方案	建议创建复合索引
审批	人工确认（可配置自动跳过）	DBA 确认索引方案安全
执行	自动应用变更	`CREATE INDEX CONCURRENTLY ...`
验证	重新采样指标，确认改善	I/O 延迟回落至 3ms
归档	记录故障 + 修复方案到知识图谱	下次类似场景自动匹配

5.2 三级风控策略

自动操作的风险是分级管的。分三档。

yaml 复制代码

auto_action_policy:
  low_risk:          # 索引推荐、统计信息更新
    auto_execute: true
    notify: "事后通知"

  medium_risk:       # 参数调整、连接池缩容
    auto_execute: false
    require_approval: "DBA 确认"
    rollback_window: "30分钟内可自动回滚"

  high_risk:         # 主备切换、数据迁移
    auto_execute: false
    require_approval: "架构师 + DBA 双签"
    rollback_window: "需人工评估后回滚"
    maintenance_window: "仅允许维护窗口执行"

说穿了就是。低风险的事你让它自己跑，出了事也不会死人的那种。中等风险的必须有 DBA 点个头。高风险的，双签，而且只能在维护窗口搞。边界的线是人来画的，AI 不管拍板，只管建议。

六、行业实践与数据验证

6.1 能源行业 186 站点统一管控

有个新能源集团，下面 186 个站点，每个站都有一套库。原来呢，每个站平均分到 0.5 个 DBA。对，半个，还不是全职的。出了故障要等 4 个钟头才有人处理。

KEMCC 加上的卢怼上去的数据：

指标	迁移前	迁移后	变化
实例纳管数	186	186	-
DBA 人数	12	4	-67%
故障响应时间	4h	12min	-95%
MTTR（平均恢复时间）	45min	12min	-73%
日常巡检耗时	4人·天/周	<1人·天/周	-75%
年度 TCO	¥1,200万	¥460万	-62%

还有个事挺神的。的卢自己在后台分析 186 个站点的负载数据，提前 36 个钟头就发现某个站点磁盘 I/O 有不正常的往上窜的趋势。自动弹了个扩容建议，DBA 看了一眼就批了。这要是没人盯着，再过两天那站点大概率就挂了。所以有时候 AI 预测的价值不是省多少人力，是你能提前躲开一个坑。

6.2 金融行业渐进式放权路径

金融行业嘛，你也不能怪他们保守。钱的事，不敢赌。所以的卢在金融落地是慢慢来的。四步走。

复制代码

阶段一（3个月）：仅开启监控和诊断，不执行自动化操作
  → DBA 用的卢诊断报告替代手动排查，建立信任

阶段二（3个月）：开启低风险操作自动执行（统计信息更新、索引重建）
  → 验证自动化操作的安全性和效果

阶段三（6个月）：开启中风险操作审批执行（参数调优、连接池调整）
  → DBA 审批，系统执行，逐步放权

阶段四（持续）：高风险操作仍需双签，90% 日常运维已无人干预
  → DBA 角色从操作者转变为策略制定者

一年下来，从完全不信任到 90% 自动化，靠的就是这个节奏吧。

七、能力边界与局限性

讲实话，的卢也不是万能的。有些地方还是要说清楚。免得期望搞得太高。

知识图谱覆盖率决定诊断准确率

覆盖到的场景，94.6% 的诊断准确率。没覆盖到的呢？比如你的业务特有的死锁模式，或者那种极少见的存储引擎 bug。还是得人上去排查。知识图谱这东西是个长期工程，得一直喂养。做完就扔那里肯定不行。

自愈能力有安全边界

的卢不会用破坏性手段去修。比如说数据不一致了，它报警，等你来，不会自己上手改数据。改数据这种事牵扯太多业务层面的判断了。AI 替你拍板不合适。

AI 调优需要数据积累期

刚上的新系统，前两到四周最难受。负载数据不够，模型没怎么见过你的场景。它推的参数可能还不如你手工调的。这个学习期跑不掉。

DBA 角色转型而非消亡

到最后，DBA 不是没事干了。是以前花在巡检、看日志、翻慢 SQL 上的 90% 的时间被省掉了。剩下那 10% 的复杂决策，架构、容量、治理这些，还是得人来。所以不是失业，是转岗。

结语

随便聊一下感受吧。

数据库运维这个行当，现在正在从"人扛着，工具搭把手"，慢慢变成"AI 扛主要的部分，人在旁边看着"。的卢跑出来的数据。告警压缩 82%、根因定位 90 秒、性能自动提升 30%、诊断准确 94.6%。放以前都是不敢想的。现在确实做到了。

但是要全面铺开的话，不是光靠技术就行的。知识图谱要持续扩充，不同行业的安全策略得定制，DBA 自己也得适应角色的变化。技术只是事情的一半。另一半是靠人、靠流程、靠时间积累的信任。

金仓在"AI for DB"这条路上做的这些事，我觉得起码算是给国产数据库趟出了一条道。不是光嘴上说说，确实是有东西跑起来的。