AIOPS自动化构建部署和回滚设计方案

本方案基于dify、jumpserver与jenkins构建AIOPS自动化体系，实现用户口语需求到自动化操作的全流程闭环，涵盖意图解析、任务执行、状态监控及结果反馈等核心环节，同时具备完善的重试机制与回滚能力，保障部署流程的稳定性与可靠性。

一、核心工作流

1.1 工作流总览

整个自动化流程以用户需求为起点，通过意图解析、Jenkins交互、状态监控、结果分析四个核心阶段实现闭环，具体流程如下：

1. 需求输入：用户通过口语形式提出构建、部署、回滚或拉取等需求；

2. 意图解析：借助DeepSeek-V3 CHAT模型解析用户需求，提取关键参数并构建标准JSON格式；

3. Jenkins交互：发起Jenkins连接请求，验证连通性后提交操作请求，获取任务ID；

4. 状态监控：通过任务ID循环查询任务执行状态，内置失败重试机制（失败时自动重试3次）；

5. 结果分析：由DeepSeek-V3 CHAT模型分析执行结果，区分任务类型给出针对性建议；

6. 反馈输出：向用户输出任务状态、服务执行列表及下一步操作建议。

1.2 关键分支逻辑

• 连通性判断：若Jenkins请求状态码为200，进入操作请求环节；否则触发重试机制，重试3次失败则直接反馈结果；

• 任务完成判断：通过查询任务状态接口返回的body内容判断，若包含"status":"SUCCESS"则退出循环，否则持续监控；

• 等待时间差异：拉取和发布操作因涉及多服务器组，需等待4-5分钟；回滚操作执行快速，仅需几秒至毫秒级，流程中已针对不同动作设置差异化等待策略。

二、关键设计模块

2.1 意图解析与提示词设计

提示词：

`把用户口语需求转成 JSON，只输出 5 个字段，其余默认 null。`

`规则：`

`- 出现“推包并构建”“全量”“完整” → action=full  `

`- 仅出现“构建”“部署” → action=deploy  `

`- 出现“回滚” → action=rollback  `

`- 出现“拉取” → action=pull  `

`services、kf_environments 从用户描述里提取数组；force_refresh 默认 true。  `

`输出格式：  `

`{"action":"full|deploy|rollback|pull","services":[…],"kf_environments":[…],"rollback_version":"vxx","force_refresh":true/false}`

`禁止解释，禁止 markdown

核心目标是将用户口语需求转化为标准化JSON格式，便于后续系统接口调用。JSON固定包含5个字段，未提及的字段默认设为null，具体转换规则如下：

JSON转换规则：

• action字段：含"推包并构建"“全量”“完整"时设为full；仅含"构建”"部署"时设为deploy；含"回滚"时设为rollback；含"拉取"时设为pull；

• services字段：从用户描述中提取服务名称，以数组形式存储；

• kf_environments字段：从用户描述中提取KF环境组信息，以数组形式存储；

• rollback_version字段：仅回滚动作时需填写，格式为"vxx"（如v1.0.1），非回滚动作默认null；

• force_refresh字段：默认设为true，如需关闭强制刷新可手动指定为false。

输出格式示例：

{
  "action":"full",
  "services":["online_customer_service"],
  "kf_environments":["test_env","prod_env"],
  "rollback_version":null,
  "force_refresh":true
}

2.2 参数解析设计

参数解析分为两个核心场景：一是从意图解析结果中提取执行参数，二是从Jenkins返回结果中提取任务ID，确保流程衔接顺畅。

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

参数类型	必选状态	数据类型	提取来源	提取规则/指令
action（动作）	是	String	意图解析JSON	匹配JSON中action字段值
services（服务）	是	Array[String]	意图解析JSON	匹配JSON中services字段数组
kf_envs（KF环境）	是	Array[String]	意图解析JSON	匹配JSON中kf_environments字段数组
roll_ver（回滚版本）	否	String	意图解析JSON	仅action为rollback时提取
task_id（任务ID）	是	String	Jenkins响应body	正则表达式：“task_id”:\s*“(?P<task_id>[\w-]+)”

2.3 HTTP请求设计

针对Jenkins的交互设计三类核心HTTP请求，分别实现连通性检测、操作执行、状态查询功能，确保每个环节的请求参数规范、可复用。

2.3.1 Jenkins连通性检测请求

核心作用是验证与Jenkins服务的网络连通性，为后续操作提供基础保障，若请求失败则直接终止流程并反馈。

• 请求方法：GET

• 请求URL：/dashboard/online-customer-status/

• 鉴权方式：无

• 响应判断：状态码为200表示连通成功，否则失败

2.3.2 Jenkins操作执行请求

根据意图解析结果提交构建、部署等操作请求，请求体参数与jumpserver后端接口兼容，支持并行执行模式。

• 请求方法：POST

• 请求URL：/dashboard/online-customer-deploy/

• 请求头：Content-Type: application/json

• 请求体（JSON）：

{
  "project": "online_customer",
  "action": "${意图解析结果.action}",
  "execution_mode": "parallel",
  "max_workers": 3,
  "services": "${意图解析结果.services}",
  "kf_environments": "${意图解析结果.kf_environments}",
  "rollback_type": "previous_version",
  "rollback_version": "${意图解析结果.rollback_version}",
  "force_refresh": true
}

2.3.3 任务状态查询请求

通过任务ID循环查询Jenkins任务执行状态，实现异步任务的实时监控，支撑后续结果分析环节。

• 请求方法：GET

• 请求URL：/core/dashboard/online-customer-task-status/?task_id=${提取的task_id}

• 请求头：Content-Type: application/json

• 查询频率：根据任务类型动态调整，回滚任务查询间隔短，拉取/发布任务查询间隔长

三、执行结果分析规范

任务执行完成后，需从三个维度输出分析结果，确保信息完整、建议具有针对性，输出内容需包含以下模块：

3.1 任务状态

明确整体执行状态及核心细节，包括流水线完成情况、拉包/部署成功数量等，示例如下：

整体状态: SUCCESS(成功)
详细信息: 完整流水线完成，拉包成功:1，部署成功:1

3.2 成功/失败服务列表

按服务类型分类展示执行结果，包含版本信息、耗时、分支、构建链接等关键数据，无失败服务时需明确标注。

3.3 下一步建议

根据任务状态和类型给出差异化建议：

• 成功场景：建议进行灰度验证，明确验证范围（服务+环境）及核心检查项（版本一致性、功能测试、监控指标）；

• 失败场景：建议执行回滚操作，同时提示失败原因排查方向；

• 特殊说明：若部署阶段显示"跳过"，需标注原因（目标环境已存在相同版本）及强制更新方案（清理环境或调整版本号）。

四、典型执行案例

4.1 需求场景

用户需求：“帮我把online_customer项目的re服务和test_env、prod_env KF组，自动推包至v1.0.0-beta版本，并自动构建”

4.2 执行结果分析

1. 任务状态整体状态: SUCCESS(成功)

2. 详细信息: 完整流水线完成，拉包成功:1，部署成功:1

3. 成功/失败服务列表拉包成功服务：re（版本: v1.0.0-beta）

4. 构建结果: SUCCESS，耗时: 8.6秒，分支: unknown，构建链接: 点击查看

5. 部署成功服务：re（版本: v1.0.0-beta）

6. 特殊说明：部分环境显示"跳过部署"（原因：所有环境均已部署该版本）

7. 失败服务：无

8. 下一步建议建议操作: 由于任务状态为成功且所有服务均部署完成，建议进行灰度验证。

9. 验证范围: re服务在test_env和prod_env环境中的运行状态。

10. 检查项: 版本一致性、功能测试、监控指标（如请求成功率、延迟等）。

11. 备注: 部署阶段显示为"跳过"，表明目标环境已存在相同版本。如需强制更新，需清理环境或调整版本号。

五、常见问题解答

5.1 为何回滚与拉取/发布的等待时间差异较大？

核心原因是操作复杂度不同：拉取和发布需涉及代码拉取、依赖安装、多服务器同步等环节，若服务器组数量多，整体耗时约4-5分钟；而回滚操作仅需调用历史版本快照，无需重新构建，因此耗时仅几秒至毫秒级，流程中已针对两种场景设置差异化等待策略。

5.2 任务失败后如何处理？

系统内置失败重试机制，所有Jenkins请求失败时会自动重试3次；若重试后仍失败，将输出明确的失败原因（如连通超时、参数错误等），建议优先排查网络连通性或意图解析结果的参数完整性，再重新发起请求。