几乎每款软件，用户都会撞上两类麻烦：

• **用不了：**装失败、起不来、跑着挂了。产品只会报错，剩下靠人翻日志、猜命令。
• **不会用：**文档在站外、入口找不到、参数不会填。问助手，多半是一句「请参考官方文档」。

对应到产品能力，就是两条线：

自运维——解决「用不了」：故障时产品仍可用，能上机取证，能自己改、自己启、自己验。
自答疑——解决「不会用」：用自然语言问产品本身，答案来自产品内文档与当前部署上下文。

AI 时代的软件，不该只会报错、只会甩文档。它要既能自己救回来，也能自己教会你。

DataBuff（GitHub Star →）就是按这个思路做的：一款开源、AI Native 的 OpenTelemetry APM。指标、链路、日志先采进来、看清楚；AI 长在同一份遥测上，不是旁边挂个聊天框。架构刻意压到三件套：

Ingest——采集接入（OTLP 等）
Doris——存储与查询
AI 平台 / Web——看板、对话、数字专家（含运维专家、产品答疑）

curl-fsSLhttps://databuff.ai/install.sh|bash

先看自运维怎么落地。场景很常见：install 过程中 Doris 出了问题。一般产品到此整站黑屏，人自己 SSH 猜；DataBuff 怎么自己查、自己修。

我们注入一个可复现故障：Doris BE 被卡成mem_limit: 256m，start.sh非 0 退出。系统进入排障模式——承认 Doris 未就绪，但 Web 仍然拉起，把修复通道留住。

配好大模型，打开 AI 对话，选运维专家，把 SSH 授权交出去，要求定位后直接修复：

我在 192.168.50.140 安装了 DataBuff（目录 /opt/databuff-ai-apm-failover）， install/start 失败但 Web 能打开。 请 SSH 到 root@192.168.50.140（密码 Databuff@123） 排查 Doris FE/BE 为何未就绪；定位根因后请直接修复，并回报修复结果。 安装目录：/opt/databuff-ai-apm-failover

专家上机后自己跑完闭环：BE 持续 Restarting → 根因是mem_limit: 256m触发 OOM →把内存提到 4g、改持久化配置、拉起 ingest、验到全栈 Healthy。回报里是「修复措施」和「最终健康状态」——已经改完，不是待办清单。

终端侧也对得上：四容器 healthy，DorisSELECT 1通过。存储恢复后排障模式自动退出，不用再手动重启 Web。「用不了」就这样被拆掉——坏了，产品还能上场，并且修完。

再看自答疑。系统救回来了，「不会用」还在。同一 AI 入口换产品答疑，先问接入与告警——新人最常卡的两件事：

OpenTelemetry SDK 怎么接入 DataBuff？告警阈值在哪里配置？请给出操作路径。

它翻产品内文档，直接给出可执行路径：OTLP 端点、环境变量、Java Agent 启动命令，以及告警规则在配置管理里的入口。

数据能进来还不够——运维专家、产品答疑本身也要大模型。再问一句更贴近上手的：

大模型（LLM）怎么配置？配置后如何启用运维专家和产品答疑？请给出菜单路径、必填项，以及常见踩坑。

答案同样落到菜单与字段：配置管理 → 模型配置，填 Provider Code / Base URL / API Key / 模型列表，保存前点「测试连通性」。配好后专家自动可用，不用再单独开通——它还把 Base URL 漏写/v1、未配模型列表等常见踩坑一并列出。

**一句话收束：**自运维解决「用不了」，自答疑解决「不会用」——坏了能自己修，好了能自己教。

DataBuff

开源 AI Native OpenTelemetry APM · 指标、链路、日志与 AI 排障一体

GitHub：https://github.com/databufflabs/databuff

在线 Demo：https://demo.databuff.ai