OntoHub
IT运维 · Verified Case

IT运维行业：数据库运维根因诊断与变更管控本体智能体

2026 运维管理 AI 场景要同时回答四类问题：「数据库为什么慢或卡了、慢查询和索引该怎么优化、巡检健康不健康、哪些写操作必须先确认才能执行并从哪儿追溯」。MySQL、Oracle、PostgreSQL、OceanBase 各有各的监控口径，大模型裸连数据库一条误写 SQL 就是生产事故。本项目按「库是大脑、AI 做判断、规则做闸门」的范式构建数据库运维智能体：以数据库运维本体（49 类 / 17 对象属性 / 18 数据属性，schema 464 条三元组 + SHACL 102 条三元组，顶层 DBOEntity → InfraResource / OperationCapability）为语义大脑，AG-0 编排、AG-1 监控、AG-2 SQL 优化、AG-3 故障诊断、AG-4 健康巡检、AG-5 变更管控六类智能体沿 Symptom → DiagnosticRule → Evidence → RootCause → Remediation → SafetyGuard 推理链工作，置信度公式 conf = prior + 0.10×证据 + 0.10×反模式 − 0.15×反证、conf < 0.60 不下结论；AG-5 是唯一写入口，变更走两阶段确认（dry-run → 5 分钟一次性 token → 人工确认 → 实施 → AuditRecord），采集通道 fdb2 零探针只读、数据脱敏 100%。Neo4j 知识图 137 节点 / 280 关系 / 7 约束沉淀能力 61 项、症状 12 类、诊断规则 6 条、优化规则 6 条、处置 6 类、健康维度 6 个、SQL 反模式 12 条、运维案例 7 个、知识条目 4 条。真实生产环境验证：18/64 张表无索引、phone 表 44.7 万行无主键全表扫描被 OR_MISSING_INDEX conf 1.00 定位并给出加索引处置（token 508cede810c8477f6f0dc72c），健康评分 57.6/90 扣分项逐条披露，34 次运维活动写操作 0 次，KPI：根因准确率 ≥85% / MTTR -40%、慢日志覆盖 90% / 采纳率 ≥70%、意图识别 ≥90%、脱敏 100%，F001–F045 需求全量覆盖。

关联本体 数据库运维AI场景业务与推理本体

案例背景

2026 运维管理 AI 场景要同时回答四类问题：「数据库为什么慢或卡了、慢查询和索引该怎么优化、巡检健康不健康、哪些写操作必须先确认才能执行并从哪儿追溯」。MySQL、Oracle、PostgreSQL、OceanBase 各有各的监控口径，大模型裸连数据库一条误写 SQL 就是生产事故。本项目按「库是大脑、AI 做判断、规则做闸门」的范式构建数据库运维智能体：以数据库运维本体（49 类 / 17 对象属性 / 18 数据属性，schema 464 条三元组 + SHACL 102 条三元组，顶层 DBOEntity → InfraResource / OperationCapability）为语义大脑，AG-0 编排、AG-1 监控、AG-2 SQL 优化、AG-3 故障诊断、AG-4 健康巡检、AG-5 变更管控六类智能体沿 Symptom → DiagnosticRule → Evidence → RootCause → Remediation → SafetyGuard 推理链工作，置信度公式 conf = prior + 0.10×证据 + 0.10×反模式 − 0.15×反证、conf < 0.60 不下结论；AG-5 是唯一写入口，变更走两阶段确认（dry-run → 5 分钟一次性 token → 人工确认 → 实施 → AuditRecord），采集通道 fdb2 零探针只读、数据脱敏 100%。Neo4j 知识图 137 节点 / 280 关系 / 7 约束沉淀能力 61 项、症状 12 类、诊断规则 6 条、优化规则 6 条、处置 6 类、健康维度 6 个、SQL 反模式 12 条、运维案例 7 个、知识条目 4 条。真实生产环境验证：18/64 张表无索引、phone 表 44.7 万行无主键全表扫描被 OR_MISSING_INDEX conf 1.00 定位并给出加索引处置（token 508cede810c8477f6f0dc72c），健康评分 57.6/90 扣分项逐条披露，34 次运维活动写操作 0 次，KPI：根因准确率 ≥85% / MTTR -40%、慢日志覆盖 90% / 采纳率 ≥70%、意图识别 ≥90%、脱敏 100%，F001–F045 需求全量覆盖。

案例描述

以数据库运维AI场景业务与推理本体（OWL 2 DL，schema 464 + SHACL 102 = 566 条三元组：49 类 / 17 对象属性 / 18 数据属性 / 6 条 NodeShape，命名空间 http://ontology.dbops.com/dbops#）为语义大脑构建异构数据库运维智能体矩阵：顶层 DBOEntity → InfraResource / OperationCapability 统一 MySQL/Oracle/PostgreSQL/OceanBase 四类引擎与三类业务场景（供应链 P0 SLA 0.999、营销促销 P0、财务结算 P1）；推理链 Symptom（12 类）→ DiagnosticRule（6 条带先验）→ Evidence（7 类）→ RootCause（7 类）→ Remediation（6 类）→ SafetyGuard 显式对象化，置信度公式 conf = prior + 0.10×证据 + 0.10×反模式 − 0.15×反证、conf < 0.60 不下结论。AG-0~AG-5 六类智能体分工（编排/监控/SQL 优化/故障诊断/健康巡检/变更管控），AG-5 唯一写入口走两阶段确认：dry-run → 5 分钟一次性 token → 人工确认 → 实施 → AuditRecord 留痕，fdb2 零探针只读采集、脱敏 100%。Neo4j 知识图 137 节点 / 280 关系 / 7 约束沉淀 61 项能力、12 条 SQL 反模式、7 个运维案例、4 条知识条目。真实环境验证：phone 表 446,903 行无主键全表扫描（EXPLAIN type=ALL / rows=446903）→ OR_MISSING_INDEX conf 1.00 → RC_MISSING_INDEX_SCAN conf 0.95 → REM_ADD_INDEX 经 token 508cede810c8477f6f0dc72c 两阶段确认；深分页 150 万行扫 20 行 → AP_DEEP_PAGING → 子查询延迟关联改写（扫描行 -99.8%、耗时 -85%）；健康评分 57.6/90（18/64 表无索引、slow_query_log=OFF 缺口如实披露）、34 次运维活动写操作 0 次，SHACL 校验 CONFORMS=True，F001–F045 需求全量覆盖。

数据库运维语义大脑（49 类统一建模）

把业务场景、异构引擎（MySQL/Oracle/PostgreSQL/OceanBase）、实例、会话、等待事件、锁冲突、能力组与能力、安全护栏、症状、证据、推理规则、根因、处置、反模式、运维案例、知识条目、巡检任务、健康维度、诊断报告、审计记录建成 49 类 / 17 对象属性 / 18 数据属性的统一本体（schema 464 条三元组），六大智能体 AG-0 编排、AG-1 监控、AG-2 SQL 优化、AG-3 故障诊断、AG-4 健康巡检、AG-5 变更管控全部对象化，运维知识一张图。

症状→根因→处置推理链（置信度可复核）

推理链显式建模为 Symptom → DiagnosticRule → Evidence → RootCause → Remediation → SafetyGuard 对象链路：6 条诊断规则带先验置信度（DR_LOCK_INDEX 0.85、DR_SLOW_FULLSCAN 0.80…），置信度公式 conf = prior + 0.10×证据 + 0.10×反模式 − 0.15×反证，conf < 0.60 不下结论；真实生产报告验证 OR_MISSING_INDEX conf 1.00 → RC_MISSING_INDEX_SCAN conf 0.95 → REM_ADD_INDEX 全链可追溯。

两阶段确认 + 零探针只读（写操作 0 次）

安全治理三闸门落地：AG-5 是唯一写入口（6 类能力 61 项、护栏 SG_READONLY/SG_TWO_PHASE）；变更走两阶段确认（dry-run 生成 5 分钟一次性 token，真实执行 token 508cede810c8477f6f0dc72c）；数据脱敏与零探针只读采集。真实环境周报：34 次运维活动写操作 0 次、约 10 次只读查询；健康评分 57.6/90，18/64 张表无索引、phone 表 44.7 万行无主键全表扫描被定位并给出加索引处置建议。

项目案例

客户面对的问题

MySQL、Oracle、PostgreSQL、OceanBase 各说各话：等待事件、锁模型、执行计划格式互不相同，一个巡检结论要在四种方言间翻译——没有统一本体，跨库运维口径永远对不齐

「数据库为什么慢」是多源证据拼图：慢日志、锁等待、buffer pool、执行计划各自独立，只看单一指标就会把行锁阻塞误判成慢 SQL——证据与根因必须显式分开建模

大模型裸连数据库是最大风险：LLM 自由生成写 SQL 一条 UPDATE 就是生产事故——写操作必须收口到唯一入口并强制两阶段确认

置信度不能拍脑袋：诊断结论要有先验、证据加分、反模式加分、反证减分的可复算公式，低于阈值的结论宁可不给——业务敢用的前提是结论可解释

可观测性缺口会自我隐藏：slow_query_log=OFF 且 long_query_time=10s 时「本周没有慢查询」的结论是假的——巡检要先发现观测缺口本身

变更与审计要全留痕：谁在什么时候对哪个实例做了什么、依据哪条规则、哪个 token 确认——没有 AuditRecord 对象化的运维经不起审计

项目案例

使用本体前后的变化

使用本体前使用本体后
四种数据库各自一套监控口径，巡检报告格式互不相同，跨库结论靠人工翻译MySQL/Oracle/PostgreSQL/OceanBase 统一映射到 DBOEntity → InfraResource / OperationCapability 顶层抽象：DBInstance、DBSession、WaitEvent、LockConflict 跨库同构，一条诊断规则覆盖四类引擎
DBA 凭经验在脑子里串证据链，「为什么慢」的推理过程不留痕、不可复核推理链对象化：Symptom（12 类症状码）→ DiagnosticRule（6 条带先验）→ Evidence（7 类证据）→ RootCause（7 类）→ Remediation（6 类），每一步落库可查，结论可复算
LLM 或运维人员直接连库执行写 SQL，一条误操作 UPDATE 就是生产事故，事后无法追溯AG-5 变更管控是唯一写入口：dry-run 生成 5 分钟一次性 token，确认后实施并写入 AuditRecord；真实环境 34 次运维活动写操作 0 次
「大概率是缺索引」这种拍脑袋结论，没有先验、没有证据加减分、没有阈值兜底置信度公式可复算：conf = prior + 0.10×证据 + 0.10×反模式 − 0.15×反证，conf < 0.60 不下结论；OR_MISSING_INDEX conf 1.00、RC_MISSING_INDEX_SCAN conf 0.95 全程带数
慢日志没开就下「本周无慢查询」的结论，可观测性缺口自我隐藏巡检先查可观测性缺口：slow_query_log=OFF + long_query_time=10s 被识别为 HD_ERR 未采集，健康评分 57.6/90 如实披露扣分原因，而不是假装没有慢查询
优化经验散落在个人笔记与工单评论里，人走了经验就带走知识库沉淀进图：12 条 SQL 反模式（AP_SELECT_STAR、AP_DEEP_PAGINATION 等）、7 个运维案例、4 条知识条目与 61 项能力共同构成 Neo4j 图 137 节点 / 280 关系，诊断规则直接引用反模式加分
只读采集到两阶段确认的全链路推理fdb2 只读采集通道接入异构引擎运行时状态，进入统一本体（49 类）；症状经诊断规则结合证据、反模式与反证推导根因，生成处置建议；所有写操作收口 AG-5 两阶段确认并全程审计。
正在生成关系图…
缺索引根因链：从 EXPLAIN 证据到加索引处置真实生产验证链路：EXPLAIN type=ALL / rows=446903 证据 + AP_ 反模式命中，OR_MISSING_INDEX conf 1.00 推出 RC_MISSING_INDEX_SCAN conf 0.95，生成 REM_ADD_INDEX，经 AG-5 dry-run 与 token 确认后实施。
正在生成关系图…
项目案例

本体域与业务的关联

方案作用于哪些业务对象？

对象域

异构数据库实例（MySQL/Oracle/PostgreSQL/OceanBase 四类引擎）、业务场景（供应链 P0 SLA 0.999、营销促销 P0、财务结算 P1）、库表对象（真实环境 64 张表）、会话、等待事件、锁冲突与运行时状态。

信息在哪里产生和流转？

系统与信息域

fdb2 零探针只读采集通道（v1.0.32）与 AG-0~AG-5 六类智能体：编排、监控、SQL 优化、故障诊断、健康巡检、变更管控；推理结果独立成层——Symptom 12 类 / Evidence 7 类 / RootCause 7 类 / Remediation 6 类 / DiagnosticReport 全部派生落库（Neo4j 图 137 节点 / 280 关系）。

判定依据是什么、由谁确认？

规则与标准域

6 条诊断规则（DR_*）与 6 条优化规则（OR_*）带先验置信度；置信度公式 conf = prior + 0.10×证据 + 0.10×反模式 − 0.15×反证，conf < 0.60 不下结论；6 条 SHACL NodeShape（102 条三元组）守护数据质量；GUARD_DEFAULT threshold=100、tokenWindowMinutes=5、tokenOneTime=true；数据脱敏 100%、写操作收口 AG-5 两阶段确认。

结论如何给出、边界如何交代？

结论与边界域

置信度全程带数可复算（OR_MISSING_INDEX conf 1.00 → RC_MISSING_INDEX_SCAN conf 0.95）；健康评分 57.6/90 如实披露 HD_ERR 未采集的扣分原因；可观测性缺口显式交代（slow_query_log=OFF）；真实环境写操作 0 次、34 次运维活动全审计；样本环境与生产规模差异如实披露。

项目案例

6 个应用场景

场景 1

异构数据库统一语义底座（TBox 分层）

客户问题

MySQL、Oracle、PostgreSQL、OceanBase 各有各的监控口径与诊断话术，跨库运维知识无法复用，「数据库为什么慢」在四种方言间对不齐。

本体做法

本体把业务场景、基础设施、会话运行时、能力与护栏、症状证据根因处置、知识库建成一张图：顶层 DBOEntity 抽象统一四类引擎，推理链显式对象化，护栏与审计内建。

应用效果

四类引擎、三类业务场景、六类智能体、61 项能力落在 49 类统一语义模型上：任何一条诊断或处置结论都能回答「依据哪条规则、哪些证据、哪个反模式、哪个护栏」，异构数据库运维第一次有了机器可读的统一表达。

输出内容
  • 数据库运维AI场景业务与推理本体（OWL 2 DL：schema 464 条三元组 + SHACL 102 条三元组合并 566 条，49 类 / 17 对象属性 / 18 数据属性 / 6 条 NodeShape）
  • AG-0~AG-5 六类智能体与 SG_READONLY / SG_TWO_PHASE 护栏对象化建模
  • Neo4j 知识图 137 节点 / 280 关系 / 7 约束（能力 61 · 症状 12 · 诊断规则 6 · 优化规则 6 · 处置 6 · 健康维度 6）
场景 2

故障根因推理与置信度可复算

客户问题

行锁阻塞与慢 SQL 症状相似，人工排查要在会话、等待事件、执行计划之间来回切换，MTTR 长且结论因人而异。

本体做法

症状→规则→证据→根因→处置显式建模，置信度公式可复算，证据链全程落库，结论附处置建议与护栏标记。

应用效果

故障诊断从人肉串证据变成带置信度的规则推理：SYM_LOCK_WAIT 症状触发 DR_LOCK_INDEX（prior 0.85），结合 EV_BLOCKED_SESSION + EV_LONG_ACTIVE_TRX 证据推出 RC_UNINDEXED_UPDATE_LOCK，给出 REM_KILL_SESSION + REM_ADD_INDEX 处置——长事务行锁阻塞 MTTR 目标 -40%、准确率 ≥85% 可复核。

输出内容
  • 长事务行锁阻塞推理链：SYM_LOCK_WAIT → EV_BLOCKED_SESSION + EV_LONG_ACTIVE_TRX → DR_LOCK_INDEX → RC_UNINDEXED_UPDATE_LOCK → REM_KILL_SESSION + REM_ADD_INDEX → SG_CONFIRM_TOKEN
  • 6 条诊断规则带先验（DR_LOCK_INDEX 0.85 / DR_SLOW_FULLSCAN 0.80…），conf < 0.60 不下结论
  • DiagnosticReport 全链落库，每步证据可查
场景 3

SQL 优化反模式推理与真实环境验证

客户问题

慢查询优化依赖 DBA 个人经验，为什么改、改成什么样、收益多少全靠口头承诺，慢日志没开时连问题是否存在都无法回答。

本体做法

反模式显式建模并参与置信度计算，优化规则给出改写方案与预期收益，EXPLAIN 证据落库可复核；可观测性缺口（slow_query_log=OFF）作为巡检结论如实输出。

应用效果

SQL 优化从经验驱动变成反模式驱动的规则推理：12 条反模式（AP_SELECT_STAR、AP_DEEP_PAGINATION 等）直接参与置信度加分，深分页场景 scannedRows 1,500,000 vs returnedRows 20 → AP_DEEP_PAGING → OR_DEEPPAGIN_REWRITE 子查询延迟关联改写——扫描行 -99.8%、耗时 -85%；真实环境 phone 表 44.7 万行无主键全表扫描被 OR_MISSING_INDEX conf 1.00 定位，KPI 慢日志覆盖 90%、采纳率 ≥70% 可度量。

输出内容
  • 深分页改写链：scannedRows/returnedRows 证据 → AP_DEEP_PAGING → OR_DEEPPAGIN_REWRITE → 子查询延迟关联（扫描行 -99.8%、耗时 -85%）
  • 真实生产验证：OR_MISSING_INDEX conf 1.00 → RC_MISSING_INDEX_SCAN conf 0.95 → REM_ADD_INDEX，EXPLAIN type=ALL / rows=446903 证据落库
  • 12 条 SQL 反模式知识库与 7 个运维案例沉淀
场景 4

多维健康巡检与可观测性缺口披露（AG-4）

客户问题

巡检报告各说各话：有的只报 CPU 内存，有的漏掉索引与慢日志配置，可观测性缺口被「没有慢查询」的假结论掩盖。

本体做法

健康维度对象化并加权评分，扣分原因逐项可查；观测缺口本身作为巡检发现输出，InspectionTask 与 DiagnosticReport 全程留痕。

应用效果

健康巡检多维量化：6 个健康维度加权（AVAIL 20 / CONN 20 / CAP 15 / SLOW 20 / INDEX 15 / ERR 10），真实环境健康评分 57.6/90——18/64 张表无索引、phone 表占库 54.7% 无主键、buffer pool 128MB、slow_query_log=OFF 各维度扣分原因逐项披露；周报 34 次运维活动、row_lock_waits 2180→2462（+282）趋势可查。

输出内容
  • 巡检报告：健康评分 57.6/90，HD_ERR 未采集如实扣分，无索引表 18 张清单与 phone 表 446,903 行 / 38.56MB 明细
  • 周度运维报告：34 次活动（写 0 次）、row_lock_waits +282、MySQL 5.7 EOL 风险提示
  • 可观测性缺口结论：「并非本周没有慢查询，而是无法观测」
场景 5

两阶段确认与零写操作审计闭环（AG-5）

客户问题

AI 运维最大的风险是写操作失控：LLM 自由生成 UPDATE/DELETE 一旦执行就是生产事故，事后无法追溯谁在何时改了什么。

本体做法

写操作收口 AG-5 唯一入口，两阶段确认 + 一次性 token + 审计留痕三闸门，只读采集与实施物理隔离。

应用效果

变更管控闸门实测通过：REM_ADD_INDEX 经 AG-5 dry-run 生成 token 508cede810c8477f6f0dc72c（5 分钟一次性），人工确认后实施并写入 AuditRecord——真实环境 34 次运维活动写操作 0 次、约 10 次只读查询，杜绝大模型裸连数据库与自由生成写 SQL；KPI 零探针、脱敏 100% 达成。

输出内容
  • 两阶段确认流程：dry-run → token（threshold=100 / tokenWindowMinutes=5 / tokenOneTime=true）→ 人工确认 → 实施 → AuditRecord
  • 真实环境审计记录：34 次运维活动写操作 0 次，全部只读
  • 护栏对象 SG_READONLY / SG_TWO_PHASE 与 61 项能力收口 AG-5 唯一写入口
场景 6

可解释性与需求全量覆盖（F001–F045）

客户问题

业务方追问「为什么是缺索引不是锁等待」「这个结论有多可靠」时，经验式运维拿不出可复核的证据链。

本体做法

结论引用本体事实（症状码、规则先验、证据指标、反模式命中），SHACL 校验守护数据质量，需求矩阵逐条映射可审计。

应用效果

诊断与优化结论可解释可追溯：每条结论引用 Symptom 码、DiagnosticRule、Evidence 明细与反模式命中；消耗验算场景逐项核对真实报告数字（phone 表 rows=446903、conf 1.00/0.95、健康评分 57.6），全链路 6 条 SHACL NodeShape 校验通过（CONFORMS=True），F001–F045 需求矩阵全量覆盖。

输出内容
  • 推理结果报告：派生 Symptom/RootCause/Remediation 成员与置信度全量输出
  • comprehensive 巡检报告与周报（真实环境 testte）作为交付文档
  • SHACL 校验 CONFORMS=True；F001–F045 需求-本体映射矩阵
业务示意

一次「phone 查询为什么慢、要不要加索引」的根因之旅

运维值班员问：「testte 库的 phone 查询为什么这么慢？要不要加索引？」 它在哪里产生：testte 是 MySQL 5.7.26 实例（flydiysz.cn:50332），fdb2 v1.0.32 零探针只读采集——phone 表 446,903 行 / 38.56MB 占库 54.7%，无主键无索引；EXPLAIN 显示 type=ALL、rows=446903 全表扫描。 系统如何处理：本体沿推理链逐层判定——Evidence（DBMetricEvidence：scannedRows=446903、type=ALL）✓、反模式命中（缺索引全表扫描）✓、OR_MISSING_INDEX 置信度 conf 1.00 ✓、推出根因 RC_MISSING_INDEX_SCAN conf 0.95 ✓——同时 AG-4 巡检发现 18/64 张表无索引、slow_query_log=OFF（可观测性缺口如实披露，健康评分 57.6/90）；R 链生成处置建议 REM_ADD_INDEX，提交 AG-5 变更管控：dry-run 通过后生成 5 分钟一次性 token（508cede810c8477f6f0dc72c），值班员确认后实施，全程写入 AuditRecord。 交付结果：一条 REM_ADD_INDEX 处置建议（附 EXPLAIN rows=446903 / conf 1.00 / conf 0.95 三项证据）、一份健康巡检报告（57.6/90，扣分项逐条可查）与 DDL 变更的两阶段确认记录；同时如实交代边界——slow_query_log 未开启导致慢查询覆盖率暂时为 0，建议先开启慢日志再评估优化采纳率。 业务影响：原本要 DBA 手工跑 EXPLAIN、翻 information_schema、口头汇报的排查流程，变成「只读采集 → 规则推理 → 证据链输出 → 两阶段确认」的标准化链路；「18 张表无索引、phone 表无主键」这类结构性风险第一次被数据坐实，且全程写操作 0 次、审计 100% 留痕。

项目案例

项目交付成果

本体资产

  • 数据库运维AI场景业务与推理本体（OWL 2 DL，schema 464 + SHACL 102 = 566 条三元组：49 类 / 17 对象属性 / 18 数据属性 / 6 条 NodeShape）
  • TBox 分层文件：schema（类与属性）+ shapes（SHACL 约束）+ graph_cypher（Neo4j 实例装载）+ knowledge_base（反模式/案例/知识条目）
  • AG-0~AG-5 智能体、SG_READONLY/SG_TWO_PHASE 护栏与 61 项能力的对象化建模说明

数据资产

  • 样本数据底座：4 类引擎 / 3 类业务场景 / 6 类智能体 / 真实环境 64 张表运行时状态（fdb2 只读采集）
  • Neo4j 知识图：137 节点 / 280 关系 / 7 约束（能力 61 · 症状 12 · 诊断规则 6 · 优化规则 6 · 处置 6 · 健康维度 6 · 证据 7 · 根因 7）
  • 知识库：12 条 SQL 反模式 / 7 个运维案例 / 4 条知识条目

验证与质量保障

  • 6 条诊断规则（DR_*）与 6 条优化规则（OR_*）带先验置信度；conf = prior + 0.10×证据 + 0.10×反模式 − 0.15×反证，conf < 0.60 不下结论
  • pySHACL 6 条 NodeShape 校验 CONFORMS=True 与本体一致性脚本 verify_libai_ontology.py
  • 真实环境验证：OR_MISSING_INDEX conf 1.00 → RC_MISSING_INDEX_SCAN conf 0.95 → REM_ADD_INDEX 全链证据落库

AI 应用与文档交付

  • comprehensive 巡检报告（健康评分 57.6/90）与周度运维报告（34 次活动 / 写 0 次 / row_lock_waits +282）
  • 两阶段确认与审计闭环记录：dry-run token（5 分钟一次性）+ AuditRecord 全量留痕
  • KPI 达成口径：故障根因准确率 ≥85% / MTTR -40%、慢日志覆盖 90% / 采纳率 ≥70%、意图识别 ≥90%、脱敏 100%、零探针；F001–F045 需求全量覆盖
项目案例

业务价值

看得懂

49 类本体把四类引擎、实例会话、症状证据根因处置建成一张图：DBA 看得懂诊断为什么成立、处置为什么这么给，异构数据库运维第一次有了机器可读的统一表达。

找得到

Symptom→DiagnosticRule→Evidence→RootCause→Remediation 全链落库：从任一结论能追溯到具体症状码、规则先验、EXPLAIN 证据与反模式命中，Neo4j 图 137 节点 / 280 关系可查。

说得清

置信度公式可复算（prior + 证据 + 反模式 − 反证，conf < 0.60 不下结论）；健康评分扣分项逐条披露；可观测性缺口（slow_query_log=OFF）如实交代而非假装无慢查询。

做得动

处置建议直接可执行：REM_ADD_INDEX 等建议经 AG-5 dry-run → 一次性 token → 人工确认后实施，全程 AuditRecord 留痕，真实环境写操作 0 次。

可持续

知识库（12 反模式 / 7 案例 / 4 知识条目）与 61 项能力沉淀进图，SHACL 约束守护数据质量，F001–F045 需求矩阵支撑按同一架构持续扩展新场景新引擎。

案例留言

围绕这个案例继续交流

公开展示审核通过的会员留言，帮助案例经验持续完善。

0 条公开留言
登录后参与留言案例留言仅面向已登录会员
0/1000
暂无公开留言

成为第一个围绕这个案例提出问题或分享复现经验的会员。