DSH出来也有一段时间了，它的设计理念非常好，一切皆插件！所以，我认为用它来扩展AIOps能力也是非常合适的。

在传统企业运维体系中，监控、日志、发布、配置管理等系统已经比较完善。

例如：

Prometheus负责指标采集；Elasticsearch/Loki负责日志检索；CMDB记录服务拓扑；Kubernetes负责服务运行；Jenkins/GitLab记录发布过程。

但这些系统解决的是：“数据在哪里？”

而不是：“为什么发生故障？”

实际故障排查过程中，运维工程师往往需要：

查看监控趋势；搜索异常日志；查询最近发布；对比配置变化；综合判断根因；执行修复操作。

这个过程高度依赖经验。

因此，AIOps的下一阶段并不是重新建设一个监控平台，而是让AI Agent成为连接各种运维系统的智能决策层。

今天这篇文章，主要是跟大家分享一下我的一个思路：基于DSH的插件扩展机制，实现一个轻量级 AIOps Agent，让大模型具备：

查询监控数据；分析日志；关联变更记录；自动推理故障原因；生成处理建议。

01 | 整体设计思路

整个系统分为三层。

第一层：DSH Agent智能层

这是智能体的大脑。

负责：

接收用户请求；判断任务目标；制定分析流程；调用插件工具。

例如：

用户输入：

分析订单服务延迟升高原因

DSH会规划：

Step1:查询订单服务指标Step2:搜索异常日志Step3:查询最近发布Step4:综合分析根因Step5:生成处理建议

第二层：AIOps能力插件层

这是我们开发的部分。

不负责采集数据。而是把已有系统能力封装成Agent可以理解的工具。

例如：

1）Metric Plugin

连接Prometheus，给DSH提供一个“查询监控数据的入口”。

简单来说：当AI需要了解某个服务是否异常时，它可以通过这个插件主动去询问监控系统。

例如：AI发现：“订单服务响应时间增加”

于是它可以进一步查询：

最近10分钟接口延迟变化；当前错误率；CPU和内存是否异常；数据库连接是否达到上限。

最终，AI不再依赖人工截图，而是可以直接获得实时运行状态。

2）Log Plugin

连接ELK/Loki，让DSH拥有一个“查看日志的能力”。

AI发现接口错误率升高后，可以主动：

查询该服务最近的错误日志；找出异常关键词；判断错误发生时间；将日志信息和监控变化关联起来。

简单理解：Metric Plugin告诉AI“哪里不正常”，Log Plugin帮助AI理解“为什么不正常”。

3. Change Plugin

它可以连接：

发布平台；Git提交记录；Kubernetes事件；配置管理系统。

当AI分析故障时，可以进一步判断：

例如：

10:00 服务正常10:30 发布新版本10:35 延迟开始升高10:40 大量数据库连接失败

那么AI就能够推断：故障很可能与最近一次发布有关。

4. Action Plugin

完成故障分析后，下一步就是处理问题。

例如：AI判断，当前版本发布导致服务异常。

那么它可以进一步调用Action Plugin：

查看服务状态；重启服务；扩容实例；回滚版本。

不过在真实生产环境中，一般不会让AI直接执行危险操作。

更合理的方式是：

第一阶段：AI生成处理建议。例如：建议回滚order-service到上一版本。第二阶段：人工确认。第三阶段：AI执行自动化操作。

第三层：运维基础设施层

就是企业内部已有的监控、日志、配置和变更、执行平台等，这个就不细说了。

02 | 实现流程

整个开发流程建议分为三个阶段。

Step 1：运行DSH环境

第一步不是写代码。

而是：先把DSH本身跑起来。

这个就不用多做阐述了，根据官方文档搭建即可。

Step 2：开发AIOps插件

确认DSH运行后，再增加业务能力。

目录：

dsh-aiops-plugin├── manifest.yaml├── skills│   └── incident-analysis.md├── tools│  └── metric_tool.py│  └── change_tool.py   └── workflow.yaml

其中：

1）Skill

描述Agent如何处理故障。

例如：

当收到故障请求：1. 先查询指标2. 再分析日志3. 检查最近变化4. 形成根因分析报告

2）Tool

提供实际能力。

例如：

def query_metric(service):    return prometheus.query(service)

DSH负责：什么时候调用。

插件负责：调用后返回什么。

Step 3：配置任务触发机制，实现AIOps诊断闭环

完成 DSH 环境部署和 AIOps 插件扩展后，还需要定义智能体如何被触发，以及如何组织一次完整的故障分析流程。

可以采用用户对话作为任务入口：

用户输入

“分析订单服务响应变慢原因”

DSH Agent 根据预先配置的 AIOps 诊断 Skill 判断当前任务属于故障分析场景。然后会按照故障排查逻辑自主调用已经注册的能力插件。

例如：

首先调用 Metric Plugin 查询服务运行指标，确认是否存在延迟升高、错误率增加等异常；如果发现指标异常，则进一步调用 Log Plugin 查询相关错误日志；如果需要判断是否由人为变更导致，则调用 Change Plugin 获取近期发布和配置修改记录。

在这个过程中，不需要额外编写固定的故障排查流程代码。

DSH Agent Loop 会根据当前获得的信息不断进行

“分析—调用工具—获取结果—再次分析”

的循环，直到收集到足够证据。

最终，Agent 将多个数据源的信息进行关联分析，并输出结构化诊断结果，包括故障现象、关键证据、可能原因以及处理建议。

在实际生产环境中，用户对话只是其中一种触发方式，还可以进一步接入 Alertmanager 告警或者定时巡检任务或工单系统，实现故障事件自动触发 AIOps 诊断流程。

03 | 最终架构