大模型在IT运维领域的应用场景与实践

大模 型在IT运维领域的运用场景有很多，包括数字化运维助手、私有文档问答、脚本解读、数据注释、日志运维等等。 本文 将从 大模 型 在 日志 场 景 的应用方向 、 实践路径、 企 业真实案例 三 个方面进行展开分享 。

分享嘉宾｜饶琛琳 日志易产品VP

内容已做精简，如需获取专家完整版视频实录和课件，请扫码领取。

01

大模型在日志场景的应用方向

相信所有在关注大模型的人，脑子里印象深刻的都是微软刚刚接入大模型时，发布的一段 Copilot 的原型视频，在 windows 之上，什么都可以通过自然语言模型去实现，非常的激动人心，后来，谷歌云的安全产品也发了类似的产品demo。

大家看一下上述的效果截图，这是当时 demo 首页的一张截图。

我们看到他上面写了一段话，需要找到这周的一个事件，然后看到它在下面出现了专门的一个 DIV 框，这个框里面写的“ search summary”。

它根据提问生成的语句，实际上是查出来了大概 3 万多条日志。依靠人肉眼去看 3 万多条日志，是不可能看完的，这个时候可能会画个趋势图，或者找某几个特别关键的字段，然后看一下有没有特殊的，再进行下一步的定位。

现在多数的日志产品，都会利用一个比较简单的日志聚类算法，提取 log key，也就是日志模式。这 3 万多行提取完了以后，可能会变成 300 行模式，大概翻十几页就能翻完，勉强算是人眼能够看完的范畴，但是我们看到在谷歌云的演示中，它是直接用一段话告诉你这三万行日志发生了什么。

对多模态的运维基础模型而言，需要有一些日志的信息，例如做一些日志摘要。但是过往的日志摘要算法，都是这一行日志里代码写的固定文本。发生了什么事情，比如说端口 down 了，它会把“port”“ down” 两个关键词拿出来，它认为这是个摘要，但是谷歌云在大模型基础上做的东西是完全不一样的，整个描述里面提供了很多关于实体的信息，这在以前的摘要概念里面，可能是一个星号、参数位，是完全不一样的概念。

这个时候再看日志就不用再翻页了，它会明确告诉我说，现有 15 个用户，发生了什么事情，其中哪几个账号要特别关注从哪个 IP 上来的。接下来就看这个 IP 用户的行为就可以。这是非常好的且非常理想的情况。但是这么理想的事情，如果想直接去实现，还有很多阶段性的问题。

首先第一个就是 3 万多条日志，需要多长的数据才能放进去？

这不光是日志的问题，大模型里面大家都在说窗口的问题。最开始早一代的都是2k， 4K 就比较大了，百度“文心一言”最早只有1K，只让写 1000 个字，现在有稍微大一些的，比如说 Claude是100K，最大的像李开复的“Yi”号称是200K。我们曾经试了100K，把大概有 300 条的日志放进去，可以看到总结的还可以，甚至还可以再问一下某一个 IP 具体怎么样。

在这 300 条日志里面问的还行，但是还是有问题：这个窗口不可能无限大。很难想象如果有一个 LLM 可以支持无限大的一个窗口，这不太现实，但是日志是无限多的。

另外一个问题是现在百 k 级的窗口，真的就放百 k 级的文本进去， LLM 只是对头部的一部分和尾部的一部分问答效果比较好，中间大概从50%或者70%的召回效果是比较差的，很难保证用户关心的信息就在头部几条或者尾部几条。

那是不是可以用一些智能体代理的方式？

我们在 ChatGPT 上去做了一点尝试，写了常用的统计和tools，让它去使用。但是发现它对运维知识的理解要求，是比较高的，比如怎么判断哪个类型的日志应该带用什么样的工具。我们在 ChatGPT 上有一些场景看起来还算成功，但是更多场景看起来不太成功，通用模型要发挥到运维领域的知识理解高度，还是有领域上的偏差。

另外这种代理对 function call 能力要求也比较高，等于很多时候普通的模型，调用 API 根本不成功。因为我们也试过把自己的 API 手册，整理成 function call 的形式去做尝试。基本上开源模型多数都不太好去组合，包括新发布的ChatGLM3 ，宣称有function call 能力，但是实际测试下来和 ChatGPT 差的也是比较远。

还有一些可能，比如我们用分段选择的方式，把刚才前面提到的中间召回效果不好的日志分个 20 段，每一段分别做总结。

先明确地问一个问题，然后在分段的总结里面找到哪一段总结和问题相近，就可以快速地缩短日志的过程了。甚至包括说问题都不用自己来找，把之前模式聚类得到的一两百条的模式给到模型，让大模型想几个问题。这种方式存在的问题是，日志是有顺序的，怎么能保证分段不把顺序截开？怎么去分段？这是个通用难题，我们也一样可以期待，后续有没有什么好的办法总结下来。

直接用大模型做日志问答场景看起来是很好的，谷歌展现了非常好的一个场景，但是实际上还是有各种的压力。前面讲了技术上的门槛，另外在部署上也会有一些难点。

刚讲到在 Claude 上放了大概几百条的日志，可以做一些换算，处理大概 1000 条的 SSH 日志，8块 A100 同时处理应该是1600行，像刚才谷歌展示的至少也是3万行，所以这个东西理论可行，但是对算力要求也是巨大的，如果按照这种算力要求的话，私有部署投入的性价比就很难支撑了。

02

实践运用大模型的路径

总结下来，我们可以利用大模型，做更现实一点的事情，还是去生成和调用现有的分析工具，生成日志查询的语句，然后语句利用原有的日志搜索引擎的功能，去完成这些事情。

关于生成语句，这是个经典课题，而且像 SQL 是最多的，但我们在日志查询方面，一般用 SQL 的不多，更多用SPL，属于日志分析的专用的语言，它和 SQL 稍微有点差异，这差异会导致生成 SPL的任务会变得比 SQL 更难，主要难点是在日志分析。

第一，日志是非结构化的，所以没有预置好的表结构。而所有的 SQL 生成任务，都可以提前告知有哪几个表、每个表里面有什么字段、是什么类型。但是查日志的时候没有人提前知道里面的信息，不知道会有什么，所以需要在提问时，靠大模型判断哪些东西可能疑似是字段名称。

第二， SQL 是有国际标准的，但是 SPL 目前只是行业性的通用概念。大家都知道日志分析语言应该用SPL，然后用管道符把不同的命令一直往后接，但它只有这个概念是通用的，语法层面是没有标准的。各家的日志分析的SPL差别都很大。

第三，就是字段名称不统一，我们公司内置的一些标准字段名称，和 splunk 的 CIM、elastic 的 ECS 都不一样，所以说很难去通过一个通用大模型去完成这件事情。

举一个通用大模型的例子：左边是某通用大模型，前面已经写了很多语法介绍等等的提示信息，最后提问如果它明白上述语法介绍声明的话，现在尝试生成一个请求。然后生成请求的结果是，完全忽略了我上面所有的提示，认为我要生成一个表格，就给我了一个虚拟的统计表格。

另外一种方式，把整个检索参考的语法结构，包括一些示例给到ChatGPT，发现返回的语句是对的，但是GPT说这是splunk的 parse 指令。而这个知识是个错误的回答，因为 parse指令是日志易的叫法，在 splunk 里面它是叫 rex 指令。

由此发现大语言模型，在预训练阶段获取的知识，后期通过提示工程是比较难去覆盖掉的，有很多似是而非的东西，可能我们和别人的语法差异仅有格式上的区别，但这种细节的干扰，通过提示工程不能很好的解决。

所以选择去做新的微调训练，微调训练首先要做的就是怎么去筹备数据。

训练数据筹备1：内外网数据搜集

我们通过内外网的数据收集，包括自己的指令说明、内部的知识库积累、收集GitHub 上常见的日志关键字和es /Splunk/kusto 的安全分析规则，再加上专家的人工投入。

训练数据筹备2：问答类数据增强

问答类的数据增强，也是学习 Alpaca 的self_instruct 的方式扩展，以及大量的人工复核，大概有 10% 到 15% 的数据太差，直接删掉。

训练数据筹备3：丰富提问方式

另外我们还换了一种方式，就是反向解读。因为 SPL 是管道符传递，从前到后一个个命令往后拼的，所以解读起来比较容易，可以从前到后的一字一段的往下翻译，它基本就能解读出这段查询语句是要干嘛。用一些能力比较强的开源模型去反向解读，它就可以生成一些比较好的提问的方式。

扩展提问方式的原因是靠人手动编写，专家的数量是有限的，所以人的提问方式慢慢会变少，可能最后问题全部一样的语气，一样的结构，不利于 LLM 训练，所以需要生成一些不一样的问题和问法。虽然问的东西最终是一样的，但要换不同的语气，换不同的提问方式，这是可以通过模型去完成的。

训练数据筹备4：加入其他产品知识

虽然目标只是生成SPL，但是生成 SPL 涉及到很多日志内部的内置字段，或者基础的功能的关系，所以需要把产品文档转换成纯文本之后，利用LLM 反向从文档里面生成提问，这也是可信的一个办法。

在落地产品的时候，关于字段名称如果比较模糊和能直接能给出字段名称的差别比较大，在产品迭代的时候就可以锚定到搜索页，从搜索页去获取到产品自身的数据集、字段、列表等即时知识，可以在实际向服务器端提交的时候，可以把这些即时性的知识带上，就不用大语言模型去拆你提问里的名称，只需要在一个列表里让它选就行了,同时做好敏感数据拦截等等，避免个人隐私的泄露。

03

大模型在金融企业应用案例

以金融行业为例，一般业务系统比较多，通常有200-600百个业务系统，运维一般是业务日志。

每个开发商在日志里使用的标识符不会完全一模一样，没有人提问的时候记得住 600 个业务系统的代号叫什么，这是第一个问题。

第二个问题是业务系统比较复杂，会有非常多的返回码，有时可能有上千个。但是运维人员一般只对最常用的十几个比较熟悉，其他的大概只记得中文的含义，但不可能记得返回码。而且返回码可能很长，就算找到了返回码，但返回码并不代表着业务系统的全部东西，有时在同一个返回码上面可能还有不同的返回的消息。

如果没有大模型的话，人是怎么去完成这件事情呢？

第一靠自己过往比较丰富的经验，见得多了记录了一些，第二就是有故障去翻手册，找到后再过滤，然后在搜索框里写，如果返回的信息不对，需要再打开手册查找，这是个往返的过程。

以上的情景，通过ChatSPL 可以把字典表通过场景字典的方式直接定义进来。当你选择所属应用的时候，可以把它对应的各种关键字，直接注入到用户实际搜索的提示词里面。

比如上图的示例，定位定义了一个错误关键字，主机上的错误关键字可能是这 4 个，我现在只需要问一下它的统计情况，它实际生成的语句就会把具体这四个以 OR 的形式给它拼进来。这是一个简单的情况，实际上情况可能很复杂。

为什么我们选择了比较简单的支点设计，而不是用向量数据库的召回？

因为我们觉得在故障定位的过程中，是很争分夺秒的事情，如果用向量数据库召回，首先需要调好召回的方案，需要花一定的功夫。另外我们总结该场景是相对简单易行的，可以找最痛的点，然后以最快的方式减少查找业务错误类的用时。

同时对于业务线运维，可以直接通过提问完成分析，出现问题不再需要找对应维护平台的高级工程师们，高级工程师们的工作时间就被释放出来，可以投入到一些高阶能力的建设，去完善新的工具平台类的建设。

未来大模型在日志场景，也将会不断迭代，包括查询结果的可视化，当查询生成的足够好，还可以直接提交执行，甚至返回的数据也可以直接去让LLM 去推荐使用可视化的形式，以及查询到的日志，可以再做解读，甚至推选可选的提问。

总体来说，我觉得大模型的运用场景还有很多，很期待开源大模型的继续成长。

04

专家对话：互动问答

以上就是本次的分享内容，如获取专家完整版视频实录和课件可扫码领取。

前微博系统架构师，有10余年互联网及IT运维经验，拥有多项日志分析及智能运维方向的发明专利，并参与信通院和电子标准院有关大数据、研发运营、智能运维、可观测性等多领域的行业标准编写。

著有《网站运维技术与实践》、《ChatGPT 速通手册》、《ELKstack权威指南》；

译有《Puppet 3 Cookbook》、《Learning Puppet 4》。