AIOps 的第一步
后台看到有些同学在留言：做 AIOps 我们应该怎么开始？今天我们就聊聊这个。
数百家企业的 DevOps 运维系统落地经验告诉我们：先做标准化，再谈智能化。
要让 AI Agent 替你干活，得让它们先读得懂你的环境。
所以我们的 Agentic Ops 产品思路上来不是直接让你做故障根因分析、成本分析这些高级的能力，而是先辅助大家做好标准化建设，打好基座，画出你们生产环境的一个拓扑图。
这个基座就是我们的语义网络。
构建好语义网络以后，AI Agent就可以顺着这个图回答这两个问题了：
- 环境里有什么？
- 它们之间怎么连接？
变更/故障影响评估、故障快速定位，全都站在这两个答案上的。
过去为了维护这个网的准确性，我们需要人工配置大量的映射规则，在 LLM 时代可以通过 Agent 的方式来去解决这个问题。
就像人类一样的，LLM 能规模化读懂异构的配置文件、理解半结构化的文本、非结构化的日志，还能把它们和运行时的连接实况互相印证。同样是回答"环境里有什么、怎么连"，出现了一条比维护一大堆映射规则更轻、更准、不需要专人养护的路。
这篇文章讲三件事：
-
为什么 AI Agent 开始参与运维之前，必须先读懂企业的真实环境？
-
Ontox 如何从应用配置和运行状态中提取环境事实，并通过证据、置信度和人工确认，把它们组织成一张可信的环境地图？
-
企业需要做哪些准备，多久能够完成第一次摸底，以及最终会拿到一份怎样的环境报告？
一、AI Agent 工作之前，必须先读懂环境
AI Agent 要参与变更、排障和日常运维，首先要回答两个基础问题：
环境里有什么？它们之间怎么连接？
这两个答案决定了后续所有推理的质量。环境理解得准，Agent 才能评估一次变更会影响哪些系统、从一个异常节点追踪可能的上下游；环境理解得不准，后面的推理越复杂，结果反而越容易偏离现实。
但企业通常并不缺少环境数据。
云平台记录了主机、网络和存储资源，Kubernetes 保存了工作负载和编排信息，CMDB 管理着配置项、模型和责任信息，监控系统采集运行指标，应用配置则声明了数据库、消息队列和下游服务。
真正的困难是：这些信息分散在不同系统里，使用不同的格式，描述的也是环境的不同侧面。
一台机器上运行着哪些进程，可以通过系统命令获取；但这些进程共同组成了什么业务系统，未必能从机器属性里直接得到。
一个服务正在连接哪个 IP 和端口，可以从运行状态中观察；但这个目标是数据库、缓存还是另一个业务服务，为什么会产生这条连接，还需要结合应用配置和业务信息才能判断。
因此，AI Agent 需要的不能只是一份资源清单，而应该是一张包含实体、关系、业务语义和证据来源的环境地图。
环境真相来自两个侧面
Ontox 主要从两个侧面理解环境。
第一个侧面是应用声明自己准备做什么。
数据库连接串、Nginx 转发规则、消息队列地址、注册中心配置和服务启动参数，都可能包含应用的依赖信息。这些信息分散在 YAML、JSON、properties、INI、启动脚本等不同格式中，过去通常需要工程师逐份阅读，或者针对不同技术栈编写解析规则。
LLM 可以读取这些异构配置，从中识别服务名称、连接目标、环境标识和引用关系，把不同格式表达的信息转换成统一的依赖线索。
配置的价值在于，它记录的是应用的意图。即使某个低频任务在采集期间没有执行，或者某个备用连接尚未被触发，只要依赖明确写在配置里，就仍然有机会被发现。
第二个侧面是系统运行时实际发生了什么。
Ontox 会采集当前的进程、监听端口和网络连接、应用访问日志，用来观察服务当时正在与哪些目标通信。运行连接可以帮助验证配置中的声明，也可以发现配置文件中没有直接出现的实际通信。
两类证据放在一起，可以得到更完整的视角：
-
配置里声明了，运行时也观察到了，这条依赖有两个来源相互印证；
-
配置里声明了，但采集时没有观察到连接，它可能是低频、备用或者已经失效的依赖，需要保留来源并进一步判断；
-
运行时观察到了，但配置里没有找到对应声明，则需要继续结合进程、端口、注册信息和资源身份确认目标。
这里也需要说明边界。
Ontox 当前采集的是连接快照，不是持续保存全部流量。持续运行的 eBPF 或 Trace 可以更完整地捕获短连接和实际调用，但通常需要额外部署观测组件、申请运行权限，并建设相应的数据处理链路。
Ontox 选择的是更轻的起步方式：通过企业已有的管理通道读取配置和运行状态，不要求用户先部署完整的持续观测基础设施。配置可以补充一部分未出现在连接快照中的低频依赖，但如果一条调用既没有配置证据，又只在两次采集之间短暂发生，当前方案仍然可能遗漏。
这不是对全部历史流量的完整记录，而是一次面向环境理解的摸底：在较低接入门槛下，尽可能还原当前系统、资源和依赖关系，并保留每个结论的证据来源。
如果企业已经建设了 CMDB，其中的资源、模型和责任信息可以成为环境理解的重要输入；如果还没有完整的 CMDB，也可以从现有的 SSH、Kubernetes 和云管理通道开始，建立第一份面向 AI Agent 的环境地图。
业务视角：图是围绕"系统"建的，不是围绕机器
还有一个视角必须说清楚：这张图，是围绕什么建的？
运维的本质，是保障业务的可用性。故障发生时，我们需要回答的问题是「订单系统挂了影响什么」，而不是「某台机器挂了影响什么」。
Ontox 按业务单元建模。3 个互相构成主从或集群关系的 Redis 部署实例，被识别为 1 个缓存系统，再上溯到环境、到业务岛。归并靠的是集群、注册身份这类证据，不是靠跑的是同一个软件。同一套订单系统在 prod、qa、dev 三套环境，用一条链路串起来，一次查询就能拿到全部拓扑。
效果是：你在平台上看到的，是一张业务地图，不是一张资源清单。
二、怎么用上
怎么用上：门槛有多低
到这里，道理都讲通了。但读者心里真正的顾虑是：用起来，是不是要先搭一套语义网络、先建模型、先配一堆采集规则？中小企业哪有这个人。
Ontox 的回答是：不需要。
第一，接入用你本来就有的命令通道。 走 SSH、K8s、阿里云、AWS、腾讯云、火山引擎这些运维本来就在用的管理通道，不需要改造或者迁移你现有工具链，不改应用一行代码。
第二，不需要先会建图。 Ontox 把过去优维积累的运维语义网络建模方式直接内置到产品里面。用户不需要先学会设计 CI 类型。你要做的只是提供接入方式。
第三，节奏是：接入 5 分钟，20 分钟可出报告。 一次摸底，先出系统边界（业务地图），每个系统再深度扫描他们的服务以及依赖关系。
第四，连接器已覆盖场景。 SSH、Ansible、K8s、阿里云、腾讯云、火山引擎这些主流通道都已经支持，开箱即用。如果你的环境里有还没覆盖到的连接器类型，欢迎通过官网联系我们，我们会优先评估支持计划。
实操：一次真实的摸底报告
这次摸底产出的环境地图，也正是变更影响、故障定位这类 Agent 推理时依赖的环境输入。
跑一次摸底报告（Discovery Report），你会依次看到：
第一步，看到业务聚类。 分散在不同机器上的实例，被归并成一个个业务系统，边界是识别加人工确认出来的，不是规则猜出来的。
上面这张截图，就是一次真实摸底后的报告首页。它显示的是系统边界识别结果：哪些机器被归到了一起、形成了什么业务系统、哪些机器跑着什么服务等。
第二步，深扫出依赖图。 每个系统深扫，产出服务依赖、中间件、存储绑定。每一条依赖都带来源：来自配置、来自连接、来自注册中心、来自人工确认。
连接器的具体配置过程，本文不展开，那是另一篇文章的完整教程我们是怎么让 AI Agent 安全进入运维生产环境的。想深入了解安全围栏的，可以回顾 Ontox 的发布文章，那里讲了完整的安全体系，本文不重复。
结尾
去体验一次摸底报告吧，5 分钟接入，20 分钟拿到你的第一份环境答卷。
如果你的环境要上 AI，但还不知道第一步从哪开始，可以在后台留言或私信，申请一次 30 分钟的 AI 运维适配诊断。我们拿你的真实环境走一遍，告诉你适配方案和切入顺序。
现在注册 Ontox，限时免费试用，注册即送 2000 积分。这个量级足够接管一个小规模集群，摸底报告、RCA 排障这些核心场景都能跑，产品核心能力都能过一遍。立即体验 Ontox。
