1. 传统交互模式下的数据库运维
作为一名与数据库打交道的开发人员,当你需要定位问题时,你可能需要:
- 查看 ob 实例、租户、节点、代理等几十、上百项监控指标,观察是否存在异常:
- 进入 ob 的「诊断」模块,进一步的通过排查 Top SQL、Slow SQL、可疑 SQL、高危 SQL 来定位到可能的问题
- 很多时候你需要进一步进入到数据库内部,去执行一些 sql 进一步定位,这个时候你可能需要配合去 ob 官网查阅一些资料。
- 定位到异常问题后,你需要基于问题去 ob 官网的文档进行查询解决方案。
整个过程是繁琐且耗时的,当你维护的 ob 实例很多时,这一过程就更加麻烦。
回顾上面的一整套交互过程,我们可以看到一些问题(局限性):
- obcloud 管控台的 UI 界面,是面向所有用户的一个“通用性”的交互方案。为了让更多人可以更快的理解使用,它的信息架构、筛选默认项都是符合逻辑性的。举例来说,你的控制台的操作路径总是:
-
选择 ob 实例 → 选择租户 → 查看监控 → 切换监控指标 → 查看租户诊断 → 筛选诊断信息
-
选择 ob 实例 → 选择租户 → 选择 unit → 查看 unit 监控 → 切换监控指标
…
即使我们在交互上做了一些“快捷路径”,它也总是基于上述最易于理解的逻辑操作的,你总是要进行大量的点击、浏览行为,从“大而全”的信息中,筛选定位到你所需要的信息,而每次去重复上述的操作路径,可以认为总是低效甚至无效的。
- 在官网查文档则可以看作是另一个重复的交互过程,直接的查阅不可能直接命中你想要的答案,你总是需要多次浏览、阅读文档,才能找到可能有效的方案尝试。
2. 前端视角下 ai 带来的变化和挑战
在 ai 时代下,人们碰到问题的第一反应不再是“百度一下”,而是“问问 deepseak”,这是一个很大的变化,因为 ai 更高效,它可以理解你的问题的意图,并基于你的意图整合出更符合你意图的答案给你,它在大部分场景下是更高效的,消除了很多无效的交互过程。
3. ai 时代的人机交互
真正重要的是数据,一切的图形界面都是为了让人更好的理解数据,结合 ai,我们可以让大模型来代替图形界面来帮助我们理解数据。
before:
after:
mcp 是 function call 的一种标准协议形式,主要用处是把用户的意图(action),转化为可被执行的 function,obcloud mcp 提供了两类可被大模型执行的 function:
- 获取 ob 实例信息:如:list_tenants(获取某实例租户列表信息)、diagnostics(获取某个租户的相关指标信息已诊断)。
- 连接数据库并执行 sql(被大模型转为 sql 的自然语言)。
基于上述两种能力,我们可以重构数据库运维的工作流。
一些效果截图展示:
实例信息获取
诊断
修改系统配置
SQL 可视化
基于大模型 &MCP 协议,我们实现了一套全新的数据库运维工作流。它很自然的实现了“千人千面”的效果。
你每天的数据库运维内容只需要 chat 的形式和大模型“聊天”就可以了,它甚至可以自动帮你生成数据报表
(取决于 mcp 客户端的能力)。
OBCloud MCP 已经上传至 Github:mcp-oceanbase/src/obcloud_mcp_server at main · oceanbase/mcp-oceanbase · GitHub
可以在 Github 上了解更多 OBCloud MCP 的使用细节。