1. 什么是 Ops 项目

我在之前的文章中介绍过一个常用的 Ops 工具。

Ops 的设计理念在于，运维工具的核心在于文本分发和脚本执行，实现了这两种能力就能够满足运维的功能诉求。

目前我主要的运维对象是 Host 主机、Kubernetes 集群，因此在 OpsObject 层实现了 Host 和 Cluster 对象，分别对应主机和 Kubernetes 集群。

在此之上，分别实现了面向主机的文件分发、脚本执行，以及面向 Kubernetes 集群的文件分发、脚本执行，也就是 Core 核心能力层。

得益于 Core 层的能力，我已经可以实现一些简单的运维功能，比如：批量添加 hosts，批量安装、变更 Prometheus 等。

2. Ops Server 和 UI 功能

在上面的架构中，我提供了三个入口，：opscli、opsserver、opscontroller。

由于之前工作需求已经完成了 opscli、opscontroller 两个组件，近期补齐了 opsserver 项目的部分功能和一个简单的 UI 界面。通过 helm charts 的方式，已经可以直接安装，详情参考 https://www.chenshaowen.com/ops/ 。

下面是一些功能截图:

• 查看托管的主机列表

Ops 会自动从主机上定时同步信息，比如: 主机名、CPU、内存、磁盘、系统信息等。

• 查看托管的集群

Ops 会自动从集群上定时同步信息，比如: 版本、节点数量、Pod 的状态、证书过期时间等。

• 查看 Task 对象

Task 是我定位的复用级对象，能够沉淀并共享运维能力，实现标准化操作。

通过 Task 指定具体的主机或者集群，设置变量值，创建 TaskRun 对象就能够实现运维任务的执行。另外，Task 也支持定时执行。

• 查看 TaskRun 对象

TaskRun 对象包含了任务的基本信息，包括: 任务名称、具体操作、执行结果等。

3. 下一步

目前 Server 端的迭代主要依赖于 Copilot 项目的诉求。

LLM 擅长分析并回答问题，得到一个解决方案或者一系列的 Command，但 LLM 并不能直接执行这些 Command。如上图，Ops Server 接下来的迭代的目标就是对接好 LLM ，让 LLM 能够读懂 Ops Server 的设计意图，在输出 Command 之后，能够直接转换为具有真实影响的 Action，让 LLM 具备真正的运维能力。

这种设计的意义在于:

• 不必在本地执行命令、配置凭证
• 支持批量的主机、集群操作
• 远程执行环境约束力更强，更加安全可审计
• 远端能够配置实现一些更加灵活、复杂的操作

简单点理解就是 Ops Server 会提供一种远端的运维能力，通过 API 对接到 LLM 应用中实现运维的自动化。