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 的使用细节。
