一、 网络运维工作

网络运维工作是一个专业性很强和种类非常多的工作。从网络最初的规划设计到网络建设交付再到网络日常的配置变更，状态巡检，故障处理都是网络运维的工作范畴。过去，网络规模比较小的时候，以上工作都是通过人工完成。随着网络规模的逐步增大，每个网工需要运维的设备数量从几十台增长到几万台，完全靠人工无法完成这项运维工作。

二、 自动化运维系统

现在有自动化运维系统可以帮助运维，网工可以利用自动化系统实现网络批量的自动化运维。以设置配置的变更为例，过去需要人工登录到每台设备上，一条一条敲命令才能完成对设备配置的变更；现在借助自动化变更工具可以从变更配置生成到批量配置下发全自动完成。随着网络不断演进，自动化运维系统的工具种类不断增加。

比如，监控工具，过去可能只有简单的连通性探测；现在随着探测技术的发展和设备硬件的更新，现在在线网已经部署了十几种监控工具。所有的监控工具最终的用户都是网工。网工需要熟练地运用工具才能保证网络安全可靠地运行。面对大量的运维工作时，虽然有自动化工具的辅助，但是也一定有这样的幻想，如果有很多助手帮助处理复杂的运维工作，只需要对助手监督和决策，网工的运维工作就变得很简单。大模型的出现就让每个网工都有运维助手的愿望的实现变得越来越真实。

三、 LLM的优势

为什么大模型能够帮助网工实现每个网工都具有运维助手的愿望呢？大模型主要具有以下三点优势。首先，大模型具备逐步推理能力。大模型可以理解自然语言，可以把对问题分析步骤以提示词的方式输入给大模型，大模型可以根据输入的提示一步步完成推理。

其次，大模型具备学习和进化能力。所有预训练大模型都具备一定的公共领域的知识，对于某些专业领域的知识有所欠缺，但是可以通过微调补充大模型对于专业领域知识的欠缺。最后是大模型具备泛化能力。大模型对输入的数据格式要求比较宽松，可以输入结构化，半结构化，非结构化数据给大模型。大模型即使面对从没有遇到过的数据也可以做出相对判断和输出，是否能够借助大模型帮助网工完成运维的工作。

四、 故障定位过程

团队选择了一个网络运维中常见的场景——故障定位，验证大模型是否真的可以辅助网工完成运维。现有基于自动化方式如何完成一次故障定位。建构系统每时每刻都在采集和探测网络的各项性能指标和设备上的异常数据，电控工具会把收集到的指标压缩到一个人可以阅读的量级，一旦某些监控指标超过告警阈值就会给网工推送告警，提醒网工去处理。网工收到告警后登录到各个监控工具上，查看每个监控工具输出了哪些结果，做出一个综合的分析，分析出哪台故障设备，再处理这台设备上的故障。大模型在这个流程中如何帮助网工提升运维效率。

五、 LLM辅助定位

假设现在已经有了大模型助手，收到告警后，大模型第一时间替网工登录到监控工具上，分析监控工具上输出的告警，做出综合判断，输出一个结论告诉网工是哪台设备上出现了故障，出现故障的原因是什么。网工只需要判断大模型给出的结论是否正确，省去了人工定位的时间。团队先按照以上流程做出了第一版大模型辅助助手，简单直接地把监控工具的告警塞给大模型，向大模型提问哪一台设备出现了故障，效果离预期相差很远。大模型会告诉故障设备，但是人工定位发现是错的。

事情没有想象得简单，团队对流程进行复盘。解决以上问题有三个挑战。第一个是大模型对上下文长度的限制。让大模型定位故障的时候会把所有可疑的设备的告警信息汇总，丢给大模型。这时很容易超过使用模型的上下文长度限制，使用的是千问1.5的开源大模型，限制的上下文长度只有32K。一旦设备数量多、告警数量大就很容易超过上下文长度，一旦超过上下文长度，大模型就会丢弃一些输入的信息，很容易导致定位的结果错误。

其次，对定位的准确率要求很高，定位时间短。定位不准需要人工重新定位，失去了减少网工定位工作量的意义，如果定位时间长不如人工定位，没有实际价值。为了解决上述的三个挑战，团队重新制定了如下三个解决方案。首先是为了解决输入上下文长度的问题。先分析了给大模型的输入，把所有设备的告警信息汇总。每台设备的每一类告警都不会超过上下文长度的限制，汇总后才会超过限制。

团队就考虑对告警信息进行多轮信息摘要。先对每一台设备的每一类告警让大模型进行一次告警信息摘要，经过一轮摘要之后，数据量在很大程度上被压缩。针对一台设备的所有告警让大模型做单设备的故障场景分析，经过两轮的信息压缩，一台设备上的告警信息被压缩到很小的长度，这时再把所有的可疑设备汇总到一起，让大模型做综合判断就不会超过模型对上下文限制。告警信息是比较专业的信息，所有预训练的大模型是不识别告警的，是监控工具输出的告警，所有的内容都是自己输出的。

为了让大模型能够准确识别和明白告警的含义，需要对开源大模型进行微调，所以还收集到了很多历史告警，人工做了一些打标，对数据摘要阶段使用的模型进行了微调，保证能够准确对告警数据做摘要，不会丢弃关键的告警信息。为了提升整个推理过程的准确性和可解释性，还对大模型提示词做了优化。优化大概分了三个方式：

先对大模型定一个人设——故障处理的专家，网工每天定位的SOP转化成大模型推理的提示词，辅助大模型应该如何定位故障，最后还会在提示词中给一些案例，告诉大模型历史上有哪些故障应该如何定位。整套方案的完整的处理流程如图内容。

先使用自动化的方法，将所有的监控工具输出的告警按设备维度聚类，聚类之后把每台设备的告警丢给大模型做并行的告警数据摘要，这一步的摘要可以加上监控工具告警分类维度做并行，这轮数据摘要之后，继续交给大模型做告警场景分析并行，两轮并行之后很大程度减少整个故障定位推理的时长。最后，把所有设备的告警信息再交给千问72B相对参数规模较大的模型做整个故障设备的打分和解释。

做打分时因为直接问大模型哪台设备是故障设备回答可能不准确，打分会给出相对合理的排名。整套流程结束之后可以得到以下故障定位的结果。这是一个例子，设备A的可疑程度是45%，设备B的可疑程度是28%，设备C的可疑程度是27%。为什么设备A的可疑程度最高，是因为设备A存在软硬件异常的告警。根据大模型输出的结果，网工自行判断是否采纳输出的结论，如果大模型定位结果是准确的，网工就省去了人工定位的工作时间。

这套定位结果在实际应用中的效果如何，团队在向往中部署了两个大模型，一个是微调后数据摘要模型一个是千问72B大模型。经过半年多的运行，单个故障定位耗时小于1.5分钟，显著优于人工定位时长。对于单设备故障定位的准确率大于80%。这个准确率对于网工来说是比较值得信任的准确率，可以优先选择相信大模型输出的结果，直接处理故障设备。后续团队会在这个场景深耕，不断缩短定位时长，提升定位的准确率。还有一些更加复杂的故障场景，比如多设备故障、区域类故障，会继续提升大模型的推理能力，让其能够覆盖更多的故障场景。

六、 未来展望

故障定位只是网络运维当中的一环，网络运维还有很多工作都需要大模型优化和提升。比如通过大模型搭建智能答疑机器人帮助网工处理日常的用户提问；意图驱动网络可以通过大模型将网工的意图转化网工想要对设备配置的修改的命令或者对现有的自动化系统的工具的调用。后面会构建网络领域的专属大模型的方式让AI赋能到整个自动化运维中，让每个运维场景都有属于自己的AI助手。