从交互和查阅两个方面来看,用户实际上花费了大量时间在这些重复的操作上,而日常运维工作往往也遵循类似的流程。尽管在实际工作中,遇到问题的概率相对较小,很多时候用户只是想检查当前运行的实例和数据库是否存在异常,但完成这样一套重复的操作仍会耗费大量时间。 前端视角下 AI 为运维带来的变化和挑战
随着人工智能技术的兴起,尤其是近一年来 AI 的广泛应用,人们在遇到问题时的反应发生了显著变化。以往,人们可能会首先通过搜索引擎查找答案,而现在,他们更倾向于直接向 AI 助手(如DeepSeek)提问。
这是因为 AI 能够更高效地理解用户意图,并基于该意图整合出更符合用户需求的答案,从而在大多数场景下消除许多无效的交互过程。例如,当用户询问“牛肉怎么做才好吃”时,AI 能够准确地提供答案,而如果通过搜索引擎查找,用户可能需要浏览多个标题,甚至将多个来源的信息拼凑在一起才能找到满意的答案。
那么,AI可以为传统运维带来哪些改变? AI替代传统GUI:OB Cloud MCP
在 AI 时代的人机交互中,数据才是核心要素。图形用户界面(GUI)的存在主要是为了帮助人们更好地理解数据。结合AI技术,我们可以利用大模型替代传统的图形界面,帮助用户理解数据。与上述 OB Cloud 的交互和查阅官网文档的过程相比,大模型可以取代中间的交互环节。
图中的MCP 是 Function call 的一种标准协议形式,主要用处是把用户的意图(action),转化为可被执行的 Function。
OB Cloud MCP 提供了两类可被大模型执行的 Function:
获取 OB 实例信息:如:list_tenants(获取某实例租户列表信息)、diagnostics(获取某个租户的相关指标信息已诊断)。
连接数据库并执行 sql(被大模型转为 sql 的自然语言)
整个流程可以概括为:在对话过程中,系统会尝试匹配是否命中 MCP。如果命中 MCP,系统会判断是否仅涉及资源状态信息查询。如果是,则查询相关信息并返回给大模型进行处理;如果不是,则基于 OB 文档和用户语义生成搜索词并查询。如果没有命中 MCP,则基于 OB 知识库文档给出回答,或者由底层大模型自行处理。以下是一些演示案例。 OB Cloud MCP 执行案例:实例信息获取、诊断
首先,用户尝试询问当前实例的状态。系统匹配到对应的 MCP 后,执行相关操作并列出实例信息和诊断结果。通过调用 OB Cloud 的 API,系统将数据传递给大模型进行处理。用户可以看到实例的诊断结果,包括SQL语句的执行情况、性能表现、慢查询情况以及资源使用情况等。从结果来看,资源使用情况较为健康,活跃用户和主要操作的数据库也一目了然。
OB Cloud MCP 执行案例:修改系统配置
另一个案例是修改系统配置。用户尝试开启数据库的日志监控,系统执行多次操作并启用circle审计。在启用 SQL 审计后,系统发现审计的百分比较低,于是尝试提高该值。在日常操作中,用户可能需要查阅OB文档才能执行此类操作。然而,日志监控和 SQL 审计并非强相关的名词对应关系,用户可能需要经过多轮查询才能掌握相关知识。