夜雨聆风这两天我继续往平台里加了一项新能力：智能运维助手。
它的目标不是替代运维人员操作，也不是自动修改备份系统，而是让运维人员可以用自然语言查询备份运行情况。
简单说，就是把原来需要翻页面、查报表、看日志的动作，变成一句话提问。
当前版本主要面向 DBackup3 使用场景，通过备份系统 API 数据做运维增强，不改变原有备份链路。
一、现场痛点：数据有了，但理解成本还是高
在备份运维现场，很多问题并不复杂，但查起来很耗时间。
比如：
今天失败作业主要集中在哪些客户端？ 最近一周容量趋势怎么样？ 哪些作业连续失败？ 当前有哪些容量风险和告警？ 最近谁执行过高风险操作？ 本平台创建的作业当前运行状态如何？
这些信息平台里都有，但如果每次都要切换多个页面、筛选表格、查看明细，仍然会消耗不少时间。
所以我希望在备份视界里加一个入口：让运维人员直接问问题，平台负责整理上下文，再交给模型解释。
二、智能运维助手能问什么
这次新增的智能运维助手，是一个只读会话入口。
目前支持围绕这些方向提问：
今日备份概况 失败作业分析 连续失败作业 容量趋势 容量风险 告警摘要 本平台创建作业状态 近期审计事件
页面里也提供了一些快捷问题，例如：
最近一周容量趋势怎么样？ 最近一周有哪些作业一直失败？ 最近失败作业主要集中在哪里？ 当前容量风险和告警有哪些？
运维人员可以点选快捷问题，也可以直接输入自己想问的内容。
三、它不是“自动执行”，而是“辅助分析”
这一点我特意做了边界设计。
智能运维助手只做只读查询和分析，不支持：
创建作业 启动作业 删除记录 导入 CSV 修改模板 修改配置 新建用户 修改许可证
如果用户在会话里要求执行这些动作，后端会拦截并返回只读说明，不会调用任何写接口。
四、模型接入：支持多种大模型接口
智能运维助手支持在配置中心中接入模型 API。
当前支持：
DeepSeek OpenAI 通义千问 / 阿里云百炼 Kimi / Moonshot 智谱 GLM 自定义 OpenAI 兼容接口
可以配置：
API 地址 模型名称 API Key 接口超时 每类最多发送记录数 是否启用助手 是否保存会话历史
API Key 只在后端保存，前端只显示是否已配置和掩码，不回显明文。
五、上下文不是乱发，而是先做权限和脱敏
智能助手在回答问题前，会先由后端收集平台只读上下文。
上下文来源包括备份运行、失败作业、容量、告警、审计等数据。
这里我做了几层控制：
按当前登录用户权限收集数据 按许可证范围控制功能入口 敏感字段先脱敏 API Key 不下发到前端 默认不保存完整只读上下文 配置、测试、提问、历史查看和删除都写入审计事件
也就是说，AI 能看到什么，不是前端随便拼，也不是用户随便越权查，而是经过后端统一控制。
这对运维平台很重要。
六、AI 会话历史：问题和回答可以追溯
这次还新增了 AI 会话历史能力。
每一轮对话都会按 conversationId 归档，后续可以：
查看历史会话 搜索问题、回答和模型 分页浏览 打开历史会话 删除会话
会话历史保存：
用户问题 助手回答 模型来源 回答来源 上下文分段 上下文错误摘要 请求 ID 客户端 IP 创建时间
不同角色的可见范围也不一样：
管理员可以查看和删除全部会话。 审计员可以查看全部会话，但不能删除。 普通具备助手权限的用户只能查看和删除自己的会话。
七、AI 在这里真正做了什么
这次智能助手不是简单接一个聊天框。
它背后包括：
模型配置管理 连接测试 只读上下文收集 敏感字段脱敏 写操作拦截 权限校验 许可证控制 会话历史存储 审计记录 右下角全局浮窗 集成中心完整页面
AI 在开发过程中也继续参与了代码生成、接口设计、页面实现和文档整理。
但产品设计上，我更关心的是：它能不能真正减少运维人员查数据的时间。
结语
智能运维助手，是备份视界从“可视化平台”向“可对话平台”迈出的一步。
它不替代运维人员判断，也不自动执行高风险操作。
它做的是把平台已有的运行数据、失败作业、容量风险、告警和审计信息整理成上下文，让运维人员可以直接提问、快速理解。
我的目标很简单：
让备份运维从翻页面查数据，逐步走向用自然语言问问题。
说明：文中提到的相关产品名称及标识归其权利人所有。备份视界为基于项目实践开发的运维观测增强工具，用于说明多备份域观测、自动报表、智能分析和运维管理场景；除非另有说明，不代表原厂官方立场、授权或背书。
