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 应用中实现运维的自动化。
