我们是怎么让 AI Agent 安全进入运维生产环境的

OntoxOps

266人浏览 · 2026-07-30 12:22:52

OntoxOps · 2026-07-30 12:22:52 发布

凌晨三点的古法运维

凌晨告警响了，服务 api-service 的 P99 延迟从 45ms 飙到 2.3s。

SRE 在收到告警后打开笔记本：

电脑连上 VPN 和跳板机，凭自己印象跳到这个告警服务的虚拟机，ps aux | grep api，netstat -tlnp，tail -f /var/log/nginx/error.log。顺着调用链每个服务去确认进程是否还活着、端口是否正常监听、有没有正在刷的错误日志、它依赖了哪些服务。
切到阿里云控制台，看 ECS 监控、安全组规则等确认机器本身的 CPU/内存/带宽是否打满或安全组有没有被人改过导致流量中断。
还要去 Prometheus 查对应时间段的 JVM 指标和连接数以排除应用层面的资源泄漏或下游依赖瓶颈。
如果怀疑是变更引起的，还需要打开 GitLab 翻最近的 PR 和部署记录。
最后去群里问一句 “刚才谁动了什么？”，以排除人工操作、手动改配置、临时脚本这些东西不在任何工具的记录里。

在这里插入图片描述

故障分析的证据散落在各个工具角落，得自己拼：五六个工具、七八次上下文切换、三十分钟过去了。

这就是还在坚持古法运维的工程师日常。

过去大家在尝试用 AI 解决这个问题。如果仔细看，大多数产品走了两条路。

第一条路：全栈替换式。 “你要用我的AI 平台，那就把监控、告警、CMDB全切换到我这儿。” 这样做的好处是数据格式可以从头开始约束统一给到AI直接用。但是企业抛弃原有运维团队建设且在稳定运行的 Prometheus、Zabbix、Grafana、Elasticsearch 等工具，重新迁移的成本谁来承担？谁来保证工具迁移过程的业务可用性？

第二条路：对话外挂式。 不替换工具，在现有工具上套一层 Chat UI，然后 Agent 通过 API 去查。这条路的优势是轻量且不改现有架构。但 AI 拿到的是每次查询返回的独立结果：Prometheus 返回一段 JSON，K8s 返回一段 YAML，阿里云返回一段 XML。这就导致了 AI 缺少对环境的整体认知，跨工具推理时的上下文断裂， 根因最终还是得人肉去拼。
在这里插入图片描述
归根结底，是"数据归属关系"这个东西没有被打通。 第一条路的解法是把数据全搬进来统一管理，代价太大；第二条路压根没碰这个问题。

如今的大模型已经具备足够强大的推理大脑。它缺少的其实是一双能触达生产环境的手脚。只要像对待一位真实的运维同事那样，赋予它合规的操作权限，它就能像人类专家一样，自主规划排查路径，把散落的孤岛信息自动串联成一条完整的证据链。

因此与其他 AIOps 产品不同，我们 Ontox 正式发布：新一代企业级 Agentic Ops 运维平台的设计理念是对你现有的工作流完全无侵入，因为迁移这些工具链的成本太高而且没有必要。

Ontox 连接器做的事：让 Agent 替运维人员"伸手够数据"

在排障的过程中，SRE 表面上在操作五个工具，实际在串一条调查链：

从告警出发
查服务的部署位置
查机器的运行状态
查关联数据库的连接数
查最近的变更记录
把线索串起来形成判断

Ontox 的连接器想做的其实是同一件事，区别在于现在走这条调查链的是 Agent。

在这里插入图片描述

连接器替 Agent 解决的是一个很具体的问题：Agent 有推理能力，但没手没脚。 它想查一台机器的进程列表，但进不去公司的跳板机。它想拉一段 Prometheus 指标，但不知道 Prometheus 的地址。它想翻最近的 GitLab PR，但没有 GitLab 的 token。

连接器就是 Agent 的手和脚。你接好之后，Agent 的调查路径变成这样：

SSH 连接器 → 上去看进程、查连接数、拉错误日志
K8s 连接器 → 查 Pod 状态、看最近部署历史、拉容器日志
Prometheus 连接器 → 拉对应时间段的 JVM 指标、数据库连接数趋势
云连接器 → 查 ECS 规格、安全组规则、RDS 实例状态
GitLab 连接器 → 翻最近两小时的 PR 和变更记录

Agent 不会去替代工具，Agent 只是获得了操作它们的能力。 连接器给 Agent 配了一双可以伸入生产环境的手，让它能像运维工程师一样打开这些工具的界面、把分散在各处的证据收集回来。

故障场景下 Agent 利用连接器可以给你什么

但这里有一个很容易被忽略的问题：SRE 收到一份排查报告，凭什么信它？

“数据库连接数过高，建议调大 max_connections。”

语气很笃定，但 SRE 心里一定会追着问几个问题：这个结论是从哪来的？刚才看了哪些指标？怎么排除了其他可能性？跟最近那次变更有没有关系？

排查报告的信任度不取决于结论有多笃定，取决于证据链是否完整。比如症状、关联、变更、历史、被排除的方向，缺了任何一环，SRE 都不敢直接动手改配置。

那 Ontox 在这个场景下是如何做的呢？

Ontox 的连接器跑完一圈之后，Agent 会把采回来的数据整理成了一份排查报告：

在这里插入图片描述

当前症状（Prometheus 连接器）：api-service 从 03:12 开始 P99 延迟从 45ms 飙到 2.3s，用户下单成功率下降了 16%
影响面：通过语义网络的调用关系图，Agent 找到了关联的订单服务和支付服务——inventory-api 正常，但 payment-api 也出现了延迟。
部署路径：通过语义网络的调用关系图，部署架构也是直接可见——服务 api-service（当前版本 v2.3）运行在 172.30.0.41 上，机器是云虚拟机 i-0abc123
依赖检查：关联的 RDS mysql-prod-02 连接数从 47 飙到 389
最近变更：GitLab 连接器直接可查到 2 小时前有人 mysql-prod-02 的 max_connections 从 100 调到 200
历史参考：语义网络知识库上次类似的连接数异常定位为 order-api 连接池 idle timeout 配置过长导致连接泄漏
建议动作：先看 mysql-prod-02 的慢查询日志，确认是连接泄漏还是正常业务高峰

Agent 通过连接器自动采、自动关联、自动翻译出来的，中间没有一条数据是人工整理的。SRE 只需对 Agent 说一句"api-service 慢了"，剩下的证据链串联和修复方案的事 Agent 它自己走完了。

伸手的前提：为什么敢让 Ontox 进生产环境

聊到这肯定会想：Ontox 怎么进的机器？SSH 密钥给谁了？它会不会乱下命令？

整个链路的设计原则是三件事：密钥不出本地环境、操作默认只读、执行分级审批。

在这里插入图片描述

真正伸手的是跑在跳板机上的 Ontox Daemon，一个轻量可执行文件，零外部依赖。SSH 密钥、K8s 集群凭证、云账号 RAM Role，全在本地机器上加密存着。Daemon 主动向外发起一条出站加密长连接，环境不需要开放任何入站端口。只读操作自动放行，高风险操作必须在执行前等审批，每一次操作都记录在审计日志里。

Ontox 做的是替人动手，不是给智能体开了免审批权限。

关于安全护栏的三层防线（AST 语法审查、策略引擎分级处置、Daemon 硬编码黑名单）以及完整的三方信任分离设计，详见《Ontox 正式发布》一文。

五、Agent 的手能伸到哪些地方

在这里插入图片描述

目前 Ontox 连接器覆盖的范围：

主机和 VM（SSH 连接器）：Agent 能 SSH 上去看进程、查配置、拉日志，自动发现操作系统信息、监听端口、定时任务。排障时这是最直接的现场取证手段：服务慢了？先上机器看 CPU、内存、连接数、错误日志。
K8s 集群（K8s 连接器）：Agent 能进集群看 Pod 状态、查部署历史、拉容器日志、获取 Workload 环境变量。排障时用来回答"服务跑在哪、最近是不是有人部署过、Pod 有没有重启"。
公有云（AWS / 阿里云 / 腾讯云 / 火山引擎）：是目前用得最多的一类连接器。接好之后 Agent 能在云主机上执行命令、拉取文件、查询云资源。排障时一整条链路走通：先上云主机执行 top 看实时负载、cat 关键进程的错误日志，如果日志量大可以直接拉回完整文件做分析，同时顺手查同一时间段 RDS 的连接数有没有异常飙高、安全组规则有没有被人动过。不需要 SSH 密钥，也不需要开放入站端口，Agent 通过云平台自己的命令通道就能进机器。
监控系统（Prometheus、Zabbix 等）：Agent 排障时能直接拉对应时间段的指标历史。不仅支持公网 Prometheus，通过 Daemon 也能连接部署在内网的 Prometheus、Zabbix 等监控系统。内网监控数据不需要暴露到公网，Agent 通过出站隧道就能拉到。
代码和配置（GitLab、GitHub 等）：Agent 能翻最近的 PR、变更记录、部署历史。排障时用来回答"故障时间窗口内有没有人改过东西"。同样，部署在内网的 GitLab 通过 Daemon 也能接进来。
自动化工具（Ansible、Teleport）：Agent 能对接已有的运维自动化资产，把现有的 Ansible Playbook 和堡垒机体系复用起来，不是推倒重建。

这些连接器的真正价值在协同。单独看每个都是查询工具，串在一起，告警 → 指标 → 拓扑 → 机器 → 变更，一条证据链贯通。五类连接器各贡献一类证据，Agent 交叉验证后形成结论。

每一类连接器接上去之后，Agent 自动获得了一个新的"调查能力"。而且这些能力是叠加的：接的越多，Agent 跨工具关联证据的能力越强。只接 SSH，Agent 能巡检机器；再接上 Prometheus，排障时就能把指标异常和机器现场关联起来；再接上 GitLab，就能判断是不是变更引起的。证据链一层一层加厚，Agent 的结论越来越不需要猜。

Ontox 的连接器在持续迭代中，会逐步支持更多基础设施和工具类型。如果有特别想接入的系统，比如某个监控平台、日志系统、CI/CD 工具，欢迎在评论区或加入交流群告诉我们，我们会优先排期支持。

连接器的权限边界：个人私有与团队共享的严格隔离

聊到这可能会想：我在机器上配的 SSH 私钥，团队其他成员和 Agent 对话时可以直接用吗？

不能。 Ontox 把连接器分成了两类，从创建那一刻就决定了谁能用。

在这里插入图片描述

个人连接器 绑定的是你个人的身份标识。比如你个人的 SSH 密钥、GitHub Token、云账号 AK/SK 在接入 Ontox 创建连接器的时候设置为"个人"连接器，那这些凭证就只跟你绑定。别人在聊天里让 Agent 排查故障时，Agent 根本看不到你的个人连接器。你的密钥就是你的，别人碰不了。

团队连接器 绑的是你在 Ontox 的组织工作区。比如 K8s 集群的 ServiceAccount、公用的 Prometheus 地址、跳板机的共享账号这些，在接入的时候连接器类型选"团队"，这样整个组织的团队成员都能用。Agent 做排障时自动就能拿到团队连接器的数据，不需要每个人各接一遍。

个人连接器做身份识别和权限控制，团队连接器做能力共享。不管是哪种连接器，Agent 的每一次操作都带着操作人的身份落审计日志。你用个人 SSH 上机器查进程，审计日志记的是你；同事通过团队 Prometheus 查指标，审计日志记的是同事。区别只在于，个人连接器的凭证只有你自己能用，没人能顶着你的身份进你的机器。

实操：3 台 VM + 1 个 K8s 集群从零接入全记录

说这么多，接一个连接器到底要多久？我拿一个真实环境跑了一遍。

我的环境：3 台 Linux 虚拟机（172.30.0.41/42/43，跑着 Nginx + Nacos + MySQL + Redis 的微服务栈），1 个 K8s 集群。

初识：Agent 能做什么？

我没上来就动手，而是先在对话里问 Agent：“我刚接触 Ontox，你能帮我做什么？”
在这里插入图片描述

Agent 梳理了核心能力（故障排查与根因分析、基础设施发现与管理、连接基础设施、变更与事件管理、成本优化），然后主动问我"你的基础设施是什么样的？"

我告诉 Agent 我有 3 台 Linux 虚拟机和一个 K8s 集群。Agent 据此给出了两套接入方案。

轻量化部署：能不能只装一个 Daemon？

Agent 先给出了常规的部署脚本。但我提了一个需求。

在这里插入图片描述

“能不能只在其中一台 VM 上装一个 Daemon，让它通过 SSH 去连另外两台？三台 VM 只需要一个 Daemon。”

Agent 确认可行，调整了架构方案：VM1 作为主节点安装 Ontox Daemon，VM2 和 VM3 由 VM1 作为跳板通过 SSH 代理访问，K8s 集群单独部署一个 Daemon。

关键细节：不用每台机器都装 Daemon。一台 Daemon 当跳板，剩下的机器走 SSH 代理接进来即可。机器多了也一样，不需要一台一台去装。按生产环境、测试环境、办公网这些隔离域，每个域找一台跳板机装上 Daemon，这个域里的机器就全通了。维护量就是这几台跳板机上的 Daemon，不是几百上千台机器各装一个。