本文来自字节跳动网络基础设施团队，作者包括 Haopei Wang、Anubhavnidhi Abhashkumar 等人。

他们提出了 NetAssistant——一个面向数据中心网络诊断的任务导向型对话系统（通俗点说，一个聊天机器人），接受用户用自然语言提出的网络问题，自动执行诊断工作流并给出结论。这个系统在字节的生产网络中已经运行了三年多，每天被调用上百次，拦截了 50%–90% 的网络 oncall 请求。

该研究已发表于 NSDI 2024。

论文链接：https://www.usenix.org/conference/nsdi24/presentation/wang-haopei

问题从哪来：网络 oncall 到底有多累

数据中心网络一旦出问题，受影响的业务团队会向网络工程师发起 oncall——「我的服务连不上数据库了，是不是网络的问题？」这类问题看起来简单，但网络工程师要回答它，得翻一堆监控看板、查日志、核对配置，再综合判断。

团队先做了一件很多人没做过的事：把过去积累的约 7000 条 oncall 记录做了系统分析。从问题类型看，42% 是网络咨询（「机房网络有没有问题？」），31% 是配置请求，12% 是主机网络故障。从目标对象看，63% 的查询集中在主机层面——物理机、虚拟机、IP 对、子网、集群。

但用户提问的质量并不高。问题往往很模糊——有人问「圣克拉拉网络有问题吗」，但正式的可用区名其实是 US-WEST-1；有人直接扔一句「Redis 卡了」，你根本不知道他指的是哪台机器、哪个维度。

网络工程师那边也不轻松。团队统计了一个数据中心（约 14000 台交换机）单月的 syslog 数据：交换机异常总量超过 1.18 亿条，平均每天 400 万条。再加上每天 12TB 的流量监控数据、65GB 的连通性数据、35GB 的交换机日志——要从这堆数据里找到和用户问题相关的那一丁点信息，这就是 oncall 又慢又累的根本原因。

换句话说，网络用户提不出精准的问题，网络工程师面对的是一片数据的汪洋。两者之间的鸿沟，目前靠人的经验和体力在填补。

核心思路：三层抽象，把工程师的经验变成可执行的流程

NetAssistant 的设计出发点很清晰：用自然语言理解（NLU）接住用户的问题，把网络工程师的诊断经验转化为可自动执行的工作流，再用高效的数据检索支撑整个流程。整个系统分三层，从上到下依次是对话层、工作流层、数据层。

对话层：两套词汇表 + 两代分类器

对话层（Dialogue Engine）负责理解用户的自然语言输入，提取「意图」和「槽位」。比如用户问「圣克拉拉机房网络有没有问题」，系统要理解意图是「检查机房网络状态」，槽位是「可用区 = US-WEST-1」。

这里有个有意思的设计。团队建了两套词汇表：一套是数据中心网络规范中的正式命名（Specification Naming Set），另一套是日常口语表达（Oral Naming Set），两套之间做多对多映射。「圣克拉拉」和「US West」都能映射到 US-WEST-1，反过来 US-WEST-1 和 US-WEST-2 都在圣克拉拉。这样不管用户怎么说，系统都能定位到正确的实体。

意图分类经历了两代技术方案。第一代是词级 CNN 分类器，离线训练。后来团队升级到了 LLM 方案——用 few-shot prompting 让大模型做多选题。因为系统已经有 100 多个意图，全塞进 prompt 太长，所以先用向量嵌入从候选中筛出约 10 个，再让 LLM 做最终判断。

工作流层：让工程师自己编排诊断逻辑

工作流层（Workflow Engine）是系统最有特色的部分。核心理念很朴素：网络工程师最懂怎么诊断，那就让他们把诊断经验写下来，系统自动转成可执行的流程。

具体来说，网络工程师通过可视化界面编排「故障排查指南」（TSG, Troubleshooting Guide）。一个 TSG 由多个「原子函数」组成——每个原子函数封装一种针对特定网络实体的诊断逻辑，比如检查某条链路的 sFlow 数据是否利用率过高，或者检查某台交换机的 syslog 有没有 BGP 抖动。原子函数的输出决定 TSG 的状态转移，像一个状态机。

以交换机可达性检查为例。TSG 先获取交换机元数据，然后依次检查连通性监控数据、交换机 syslog、硬件状态，任何一步发现异常就输出诊断结论。所有检查通过则标记为健康。

TSG 可以动态更新——不同厂商的交换机可以用不同版本的检查流程，网络架构变了就调整对应的 TSG。这意味着诊断逻辑不是写死在代码里的，而是像配置文件一样灵活可维护。

数据层：预计算告警，用空间换时间

数据层（Data Engine）解决的是性能瓶颈。直接在对话时实时查询海量监控数据根本不现实——光 sFlow 每天就产生 12TB 数据。

团队的方案是「主动预警」：对大数据量的监控源，部署常驻的流式任务（基于 Kafka），周期性地检测异常并生成告警。当工作流需要查询这些数据时，直接读预计算的告警结果，而不是从头分析原始数据。

这是一个合理的权衡——牺牲一点时效性（告警不是实时的，而是分钟级周期检测），换取数量级的响应延迟降低。优化后，大多数常用工作流的执行时间控制在 5-10 秒。对于一个对话系统来说，勉强够用，但也已经接近用户的忍耐极限。

跑了三年，效果如何

NetAssistant 从 2020 年 4 月上线，到论文写作时已经运行了三年多。团队从使用量、准确性和 oncall 减负三个维度做了评估。

日均 100-200 次调用，周末明显减少

以 2023 年 7-8 月为例，日均使用量在 100-200 次。有意思的是，周末使用量明显低于工作日——因为周末禁止大的变更操作，网络相对稳定。两个月内共有 476 个独立用户，主要是 SRE、基础设施工程师和网络工程师。大规模故障发生时，使用量会激增到 20-50 次。

拦截 50%–90% 的 oncall，节省 20%–25% 处理时间

这是最核心的指标。团队定义了「oncall 拦截率」——用户使用 NetAssistant 后不再发起人工 oncall 的比例。结果显示，系统能拦截 50%–90% 的日常 oncall。大部分被拦截的场景是用户得到「网络状态正常」的回复后，就不需要再找人了。

即使 oncall 没被完全拦截，NetAssistant 的诊断结果也能帮网络工程师节省 20%–25% 的处理时间。本来要花在翻看板上的时间省下来了，工程师可以更专注于问题修复和用户沟通。

误报率约 10%，漏报率接近 0

团队跟踪了半年的误报率和漏报率。误报率（把非网络问题诊断为网络问题）在 8%–12% 之间波动，主要来自采样监控数据的噪声和交换机高负载时的误判。漏报率基本在 0%–1.25%。

对于误报，团队采取了分层策略：严重且影响范围大的问题才给出「不健康」结论，小问题只标记为「警告」。漏报基本只在监控覆盖不到的地方发生，每次漏报后都会快速补上盲区——比如有一次交换机管理口没挂但 loopback 口挂了，告警晚了 2 小时，事后就更新了对应的 TSG 检查逻辑。

几个一线经验

团队分享了三年运维中积累的几条经验，值得拿出来讲。

能不能主动发现问题、提前通知用户？ 答案是「部分可以」。只有高优先级的告警会触发主动通知，因为网络异常事件实在太多了，全部推送只会淹没所有人。监控覆盖率和数据质量受限于老旧设备型号和厂商支持，资源预算也不允许所有工作流都跑在主动模式。

用户也在被「教育」。 团队观察到，使用 NetAssistant 一段时间后，用户提问变得越来越精准和简洁——他们学到了更多网络知识，和工程师的沟通效率也明显提高。这是一个良性循环：工具越好用 → 用户越会用 → 反馈越精准 → 工具进一步优化。

LLM 的局限。 团队尝试过用 LLM 直接回答网络诊断问题，发现它擅长处理静态知识（「我们的 QoS 系统是怎么工作的」），但在理解诊断逻辑、处理实时监控数据方面还很吃力。所以在这个项目中，LLM 只负责意图理解，诊断逻辑仍然依赖预定义的工作流。这是一个清醒的判断——2024 年初 LLM 的能力边界在这里，拿它做擅长的事就好。

总结

NetAssistant 展示了一个务实的工程思路：不追求用 LLM 解决一切，而是把大模型擅长的事（自然语言理解）交给大模型，把需要专业知识的诊断逻辑交给网络工程师编码成工作流，把性能问题用预计算告警来解决。

三层架构的设计（对话层→工作流层→数据层）让每层各司其职，也方便独立迭代。三年多的部署经验证明，这种方案在大规模数据中心网络中是可行的——不是完美方案，但足够实用。未来如果能用 LLM 自动从自然语言和过往工单中生成工作流，让工作流根据反馈自我调整，那才是真正的自动化。但在那之前，NetAssistant 这种「人 + 系统」的协作模式，可能才是大规模生产环境中最现实的选择。