最近看到一组比较有意思的产品测试内容。

网深科技正在准备推出一款新的 AI 智能运维平台：观枢 GAIOP（Guanshu AI-driven Operations Platform）。

如果只是普通的“AI + 监控平台”，其实现在已经不新鲜了。很多厂商都在做类似的事情：在监控系统上套一个大模型问答入口，让用户可以用自然语言查询指标、解释告警、生成报告。

但这次值得关注的点在于，GAIOP 接的不是单纯的主机指标，也不只是日志，而是网深科技原有的 NetInside NAPM 全流量分析能力。

也就是说，它的思路不是让 AI 只看 CPU、内存、磁盘、日志，而是让 AI 尝试理解真实网络流量里的访问过程。

这件事如果做成，对 AIOps 方向其实挺有参考价值。

---

01｜为什么我觉得这个方向值得看？

传统监控平台最大的问题，不是没有数据，而是数据之间割裂。

很多企业现在都有一堆系统：

• 主机监控

• 网络监控

• 日志平台

• APM

• 数据库监控

• 安全告警

• 可视化大屏

• 工单系统

但真出问题的时候，还是经常要靠人拉群分析。

比如业务系统突然变慢。

主机监控看起来正常。
网络设备没有明显异常。
数据库没有立刻发现慢 SQL。
日志里只有一堆结果型报错。
APM 也许能看到某个接口慢，但不一定能还原整个访问链路。

最后就是典型场景：

业务说慢，研发说代码没问题，网络说链路没问题，数据库说 SQL 没问题，安全说策略没拦截。

问题不在于没有监控，而在于这些数据很难拼成完整的访问过程。

而全流量分析的价值恰好在这里。

它关注的是网络里真实发生过的通信：

• 谁访问了谁？

• 什么时候访问？

• 请求是否成功？

• 响应耗时多少？

• TCP 有没有重传？

• 连接有没有失败？

• 应用接口是否异常？

• 页面加载慢在哪里？

• 服务调用链路中哪一段异常？

这些信息不是传统资源指标能完整回答的。

所以如果 AI 能基于全流量分析结果进行推理，它就不只是一个“监控问答机器人”，而可能变成一个真正的运维分析助手。

---

02｜GAIOP 的关键点：不是简单套壳大模型

从目前看到的信息来看，观枢 GAIOP 的定位大概是：

基于网络流量观测与大模型推理的智能运维平台。

它要连接的核心能力包括：

• 全流量观测

• NAPM 网络应用性能分析

• 大模型推理

• AI Agent

• 自动化执行

• 报告生成

• 运维知识库

这和普通“ChatGPT 接监控系统”的区别在于：

普通 AI 问答更多是在已有指标、告警、文档上做解释。

而 GAIOP 的底层如果接的是 NAPM，就意味着 AI 可以围绕真实业务访问过程做分析。

这就很关键。

因为在运维排障里，真正有价值的不是“某个指标超过阈值”，而是：

这个异常为什么发生？
发生在哪一段？
影响了哪些业务？
有没有报文和会话证据？
应该怎么处理？

这才是根因分析真正要解决的问题。

---

03｜从测试画面看，AI 已经能直接查询 NAPM

从目前测试画面来看，GAIOP 已经可以通过自然语言查询 NAPM 数据。

用户可以直接问：

你现在都可以做哪些工作？

AI 会返回当前支持的能力清单。

【图1｜AI 直接返回能力清单（一）】

【图2｜AI 直接返回能力清单（二）】

继续追问：

详细介绍一下 NAPM 查询能力。

AI 会继续展开说明，介绍可以查询的对象、指标和分析维度。

【图3｜NAPM 查询能力说明（一）】

【图4｜NAPM 查询能力说明（二）】

【图5｜NAPM 智能查询结果示例】

从内容上看，GAIOP 已经可以识别多类 NAPM 查询对象，例如：

查询对象	示例
业务组	BusinessGroup
Web 应用	WebApplication
应用	DefinedApp
IP 地址	IPAddress
会话	IPConversation
页面族	PageFamily
接口	Interface
子网	Prefix24

这说明它不是简单地做一个固定 FAQ，而是已经开始把自然语言映射到 NAPM 的数据对象和查询能力上。

这点对实际运维很重要。

因为很多 NAPM / APM / 流量分析系统能力很强，但学习成本也高。用户需要知道去哪个菜单、查哪个对象、选哪个时间范围、看哪个指标。

如果 AI 能把这些操作封装成自然语言交互，运维人员的使用门槛会下降很多。

比如未来可能直接问：

昨天访问最慢的业务是什么？
最近一小时哪个 IP 连接失败最多？
帮我看一下 ERP 系统有没有异常。
最近一周 TCP 重传率有没有升高？
这个接口响应慢是网络问题还是服务端问题？

这类问题如果能直接打到 NAPM 数据上，价值就不只是“方便查询”，而是改变了运维系统的交互方式。

---

04｜真正有意思的是：AI 不只是查数据，而是知道该怎么分析

很多所谓 AI 运维产品，目前还停留在“你问什么，我答什么”的阶段。

但真实运维不是这样的。

真实运维里，用户经常不知道应该怎么问。

比如业务方只会说：

系统慢了，帮我看看。

但系统要知道下一步应该怎么分析。

是先看响应时间？
还是看连接失败率？
是看客户端侧？
还是看服务端处理时间？
是看 TCP 重传？
还是看应用接口耗时？
是看某一个业务？
还是看 TopN 异常对象？

从目前能力设计看，GAIOP 已经开始支持一些分析模式：

1. TopN 分析

比如：

昨天流量最高的 10 个 IP 是哪些？

这类分析适合快速定位高流量、高访问量、高异常量对象。

2. 趋势分析

比如：

最近一周 TCP 重传率变化趋势如何？

这类分析适合判断问题是偶发、持续还是逐渐恶化。

3. 对比分析

比如：

对比 ERP 和 OA 系统的响应时间。

这类分析适合判断多个业务之间的性能差异。

4. 多协议分析

比如：

这个 IP 都在使用哪些协议？

这类分析适合排查主机通信行为、应用访问行为和异常连接。

5. 下钻分析

比如：

找出最慢的业务，然后继续分析原因。

这类能力最接近真实排障过程。

也就是说，GAIOP 的目标并不是只做一个查询入口，而是让 AI 能够理解分析路径。

这个方向如果能做深，就会从“AI 问答”进入“AI 运维分析”。

---

05｜真正的看点：AI 根因分析

我觉得 GAIOP 这类产品真正值得关注的，不是自然语言查询，而是 AI 根因分析。

因为查询只是入口，根因分析才是运维系统的核心价值。

根据目前架构思路，GAIOP 会融合多类数据：

• NAPM 性能数据

• 告警数据

• CMDB 数据

• 运维知识库

• AI 推理引擎

在这个基础上，系统可以自动完成：

• 故障诊断

• 影响分析

• 根因候选生成

• 运维建议生成

• 自动执行

这里有一个关键点：根因分析不能只靠大模型本身。

大模型可以负责理解问题、规划分析步骤、生成解释和建议，但它必须有真实数据作为依据。

否则就会变成一本正经地胡说。

所以 GAIOP 的关键，不在于“用了大模型”，而在于它把大模型放在了 NAPM 全流量分析底座上。

流量数据可以提供真实证据：

• 某个时间段是否有连接失败

• TCP 是否发生大量重传

• 服务端响应是否异常

• 某个接口是否耗时过高

• 客户端到服务端链路是否存在异常

• 请求和响应过程是否完整

AI 基于这些数据做推理，才有可能输出可信的诊断结论。

这比单纯让 AI 解释一条告警要有价值得多。

---

06｜AI Agent 会不会成为运维闭环的关键？

GAIOP 里还有一个值得注意的方向：AI Agent。

如果 AI 只是负责分析，那它还是一个辅助工具。

但如果它进一步接入脚本执行、网络设备操作、系统管理操作和自动化任务，就有可能形成更完整的运维闭环。

大致链路可能是：

1. NAPM 发现异常

2. GAIOP 接收告警或用户问题

3. AI 调用流量分析能力

4. AI 判断异常类型和影响范围

5. AI 生成根因候选和处置建议

6. 必要时调用自动化脚本或外部系统

7. 生成故障分析报告或复盘报告

当然，这里会涉及权限、安全、审批、回滚、审计等问题，不可能简单地让 AI 随便操作生产环境。

但方向是明确的：

AI 运维不能只停留在“会说”，最后一定会走向“会查、会判断、会执行、会复盘”。

这也是 AI Agent 在运维场景里真正有价值的地方。

---

07｜自动生成报告可能是最先落地的能力

相比自动处置，自动生成报告反而是更容易落地、也更容易被企业接受的能力。

从企业微信联调测试场景来看，用户可以直接说：

把上面内容生成报告。

系统就可以自动生成 Word 文档。

【图6｜通过企业微信对话生成运维报告】

这件事看起来不如根因分析“高级”，但在实际运维工作里很实用。

因为运维团队真的经常要写报告：

• 巡检报告

• 故障分析报告

• 周报

• 月报

• 复盘报告

• 客户汇报材料

• 管理层汇总报告

很多报告本质上是重复劳动：

整理数据、截图、描述异常、分析趋势、总结结论、提出建议。

如果 AI 能直接基于 NAPM 数据、告警数据和分析结果生成 Word / PDF 报告，那会明显提升效率。

未来正式版本预计会支持：

• PDF 报告

• Word 报告

• 巡检报告

• 周报、月报

• 故障分析报告

• 管理驾驶舱报告

这类能力很可能比“全自动修故障”更早成为企业客户愿意使用的 AI 运维功能。

---

08｜GAIOP 和普通 AIOps 的区别在哪里？

我理解，GAIOP 最大的差异不是“用了 AI”，而是它的 AI 数据底座不一样。

普通 AIOps 常见底座是：

• 指标

• 日志

• 告警

• 事件

• 工单

• 知识库

这些数据有价值，但很多是结果型数据。

比如某个指标高了，某条日志报错了，某个告警触发了。

但全流量数据更接近过程型数据。

它记录的是一次访问从客户端到服务端的真实通信过程。

这就决定了它在排障时能提供不同维度的证据。

举个例子。

如果一个系统慢了，日志可能只告诉你接口超时。

指标可能只告诉你响应时间升高。

但流量分析可能进一步告诉你：

• TCP 建连是否正常

• 请求是否成功发送

• 服务端是否及时响应

• 响应时间主要花在哪一段

• 是否存在重传、丢包、连接失败

• 哪些客户端、服务端、接口受影响最大

如果 AI 能结合这些数据推理，分析结果就会更接近真实问题现场。

这也是“全流量 + AI”相比“日志指标 + AI”更值得关注的地方。

---

09｜这个方向可能会改变运维系统的使用方式

过去的运维系统更像工具箱。

每个功能都很强，但前提是用户知道怎么用。

你要知道：

• 去哪里查业务

• 去哪里查会话

• 去哪里看接口

• 去哪里看重传

• 去哪里导出报表

• 哪些指标要组合判断

• 哪些现象可能对应哪些根因

这对经验要求很高。

而 AI 智能运维的趋势，是让系统从“工具箱”变成“分析助手”。

未来可能是：

用户提出问题，AI 理解意图；
AI 自动选择查询对象和分析方法；
系统调用 NAPM、告警、CMDB、知识库等数据；
AI 汇总分析结果；
最后输出结论、证据和建议。

也就是说，用户不一定要知道每个按钮在哪里，但系统要知道如何完成分析路径。

这可能是 AIOps 下一阶段真正的产品形态变化。

---

10｜目前值得期待的能力

从目前内测与规划信息来看，观枢 GAIOP 已经具备或正在建设的能力包括：

• 自然语言查询

• NAPM 智能分析

• 告警解读

• 数据包分析

• 自动报告生成

• 企业微信集成

下一阶段规划还包括：

• AI 巡检

• AI 根因分析

• 运维知识图谱

• 自学习运维模型

• 自动化运维闭环

如果这些能力能逐步落地，GAIOP 可能不是单纯的监控增强工具，而是一个面向网络和应用性能分析场景的 AI 运维平台。

---

结语：AI 运维真正要看的不是“会不会聊天”，而是“能不能读懂现场”

现在很多产品都在讲 AI 运维。

但真正有价值的 AI 运维，不应该只是一个聊天框。

它要能读懂现场。

而在网络和应用性能领域，最真实的现场之一就是流量。

日志可能缺失，指标可能抽象，告警可能只是结果，但流量记录了真实发生过的访问过程。

所以我觉得 GAIOP 这个方向最值得关注的地方，是它把 AI 放在了全流量分析底座上。

当 AI 开始理解真实业务流量，它能做的就不只是解释告警，而是可能参与到故障定位、根因分析、影响评估、报告生成，甚至自动化处置之中。

运维人不一定会因为 AI 失业。

但可以确定的是，未来那些重复查询、截图整理、初步分析、报告撰写的工作，确实会被 AI 大幅重构。

而真正有经验的运维人员，可能会从“操作工具的人”，变成“管理 AI 运维流程的人”。

这才是 AI 智能运维真正值得关注的变化。