AIOps探索 | 如何用大模型构建高效运维知识及智能问答平台（1）

文章来源：公众号ID-布博士（擎创科技资深产品专家）

一、背景

好久没有分享AIOps相关干货了，最近大模型这么火，而且我们有客户已经基于大模型构建了知识及智能问答平台，需要在运维领域结合使用场景进行应用。为此，楼主从头到尾声梳理了一遍大模型在运维领域构建知识及智能问答平台的应用场景、技术实现，总结出来供大家一同探索，希望对大家理解和运用大模型有一定帮助~

二、平台对运维效率提升的重要性和挑战

提升运维效率对于任何组织都至关重要。在追求高效运维的过程中，一个关键步骤就是建立丰富的知识共享平台，它能够为团队成员提供一个共享经验、解决方案和最佳实践。通过知识共享，团队可以更快地解决问题并成长，提高企业内部运行运营的整体效率。

运维效率的提升很大一部分在于不同角色的运维人员在不同的场景（故障处置、IT服务工作台、应急分析及处置等）中对知识的快速应用。其对提升运维效率非常重要，同时也面临很多挑战。

1.重要性

（1）知识复用

同样的数据库故障，在不同的应用系统下事件管理员需要同样的分析过程和咨询原厂商的过程，难以在事件再次发生的情况下有效识别，并进行知识复用。

（2）专家经验工具化

专家在处理问题时，通常都具有很强的专业背景和经验，这些知识如何有效的工具化，使一线的值班人员在处理简单、重复的问题时，可以在不同的场景直接获得专家的经验知识，快速解决问题，降低成本，让专家专注在更高效地提升客户体验上。

（3）快速问题解决

运维知识及智能问答平台可以促进团队随时随地的知识使用和学习需求，使团队可以不断学习和改进运维流程和工具，最终快速问题解决，提高运维效率。

2.挑战

（1）知识有效利用

由于缺乏智能化手段（或成本高昂），老旧的知识库和自动问答系统只能作为存储和搜索数据库，难以有效利用存储在知识库中的知识。这也导致了对知识库的维护意愿不高。

（2）知识运用场景化

使用知识需要登录到知识库系统查询相关知识，而不是在不同的应用场景中。这导致了使用成本较高，例如在事件或应急场景下，是否能够在推送告警事件或应急场景时，同时推荐相关事件的知识或解决方案。

（3）知识反馈流程化

一旦知识进入系统，就很难发现其中的问题，因为无法有效利用。即使发现了问题，也需要经过冗长的流程和填写大量表单，这让大多数人望而却步。在场景化应用中，应该能够在使用流程的各个环节中遇到问题时进行实时且高效的反馈，润物细无声，而非刻意要去做某件事情。

三、基于大模型的平台建设解决方案

由于最近一年来大模型的智能化能力在知识及智能问答领域的突飞猛进，使得之前力不从心的知识及自动问答系统有了更好的技术手段可以满足人们的应用需求。

1.使用场景

（1）故障排除与问题解决

①告警处置方案知识化：当事件管理员在告警管理工作台处置告警时，其对告警的最终分析处置解决方案可以同步知识库做为故障处置的知识存储。

②告警产生知识推荐：当事件管理员在告警管理工作台看到新产生的告警时，大模型可以直接推送针对该告警可能的解决方案知识信息，加速分析及处置效率。

（2）应急场景

①应急手册：大型企业都会对一些重要的业务系统进行应急演练，并配置相应的应急手册，当出现故障时可以按应急预案进行操作，因此应急手册成为应急场景下的重要知识来源。

②应急知识推荐：在故障应急状态下，系统本身已经收集了应急的相关数据，这时可以根据应急状态下产生的告警信息由大模型分析之后，推荐应急操作预案、推荐针对单个告警的处置方案、甚至故障的成因也一并推送出来，这时可以辅助应急决策人员进行快速的应急处置和业务恢复。

（3）已知故障

①厂商手册：应用研发厂商、技术组件厂商（开源或商业）一般会准备一些快速的故障排查及处置手册，这些会成为运维领域知识的重要组成部分，大模型通过对故障关键字的匹配可以精确找到故障的解决方案。

②运维专家或SRE工程师对故障的总结：这两个重要的角色在日常运维的过程中针对发现和处置的故障进行总结之后，会形成已知故障场景库，当再次发到类似的故障之后，可以直接推送针对当前故障的分析方法、处置恢复方案，减少专家介入和排查的时间成本。

（4）运维管理规范

也是重要的知识内容，当出现应急或重大事件的场景下，一般运维人员会采用各种方法找捷径去恢复业务，但是捷径代表不可预知的风险，因此在故障场景下，不仅要让当前的处置事件的工程师获取处置事件的知识、建议，同样也要告诉到他针对这类事件的处置要遵守某种操作规范。

（5）工单处置结果

①工单处置结果知识化：来自工单系统的对某个工单的处置结果同样也可以做为知识的一部分，当处置完成之后这些信息会同步知识库。

②工单知识推荐：当某个工程师被分配工单之后，针对工单上所描述之故障的推荐知识也会随之提供出来。

（6）IT服务台

①服务台客户服务知识化：日常服务台响应和回答用户或客户的问题，是最好的一问一答格式，可以经过审核和优化之后的标准答案做为知识库存储起来。

②服务台客户服务知识推荐：不论是来自电话语音还是文字的客户沟通问题，都实时转译为文字通过大模型从知识库中匹配最佳的答案提供客服人员或智能问答机器人进行快速的回复。

2.运维知识体系构建

（1）针对运维知识体系的构建，我们分成三个重要的组成部分：

①运维知识供献场景层：蓝色的部分，为运维领域的一些主要场景，其在进行业务开展的过程中会产生大量的知识，这些知识需要通过某种标准化的手段（自动的、模板化的）进入到传统知识管理层，对这些知识进行分门别类的管理。

②传统知识管理层：橙色的部分，知识构建和管理的过程同老旧的知识管理没有什么分别，可以用一些老版的管理工具，如wiki、conflunce甚至wordpress这种工具都可以很好地管理起来，在这里不再详述。

③基于大模型的知识库层：灰色的部分，这是同传统的知识体系应用不太一样的地方，传统上的应用会定时将这些知识存储到ES类的系统中以方便进行全文检索，然后提供算法对检索的内容进行排序，而基于大模型的知识检索和知识问答则需要将知识库中的信息转换为纯文本信息，然后再对文本进行分割（分割知识块），然后通过特定的算法将文本向量化之后存储在向量数据库中。（这个过程在互联网上大家可以找到非常多的内容来详细了解，在此不再详细描述）

（2）针对知识的创建主要分为两类：

①手工知识创建：该过程可以让运维人员自行登录知识库系统并建立知识。

②基于场景化的知识创建：在运维的不同场景中结合场景来自动化创建相应的知识，如事件处理完成之后，对事件的总结性回顾的内容可以日终批量同步到知识库系统中，包括问题、问题描述及日志、问题产生的原因、解决方案这四个关键字段内容。

3.运维知识体系应用

在收集了知识信息之后，剩下的部分就是知识的应用了，在“使用场景说明”章节中，已经详细介绍了在运维领域可能的使用场景，集成工作无非就是api嵌入到使用场景中，结合业务流程来进行使用，通过大模型的核心能力基于对应场景上下文信息，提供知识，满足场景使用需求。

以告警工作台为例，说明一下大模型场景下整个系统交互的处理流程：

首先，事件管理员在告警工作台看到了一条告警，对于这条告警自己也没有遇到过，这时当他打开这条告警进行分析时，系统会自动根据告警内容抛出一个“查询/提问”，如：针对下方这条告警系统要能够自动归纳出这是“CPU使用率异常”问题。

【次要告警（xx数据中心）】应用监控平台[APM]，by10xxxxx，Linux服务器1分钟CPU负载高(实例:CPU）,当前值:1.25,阈值:1 - 9999999，发生时间:09/17/2020 18:38:25 【详细信息:Cpu Number:8; 1 Min Load Average:9.99; D Process Number:0】【生产地址:*.168.1.*；所属资源池:暂无,序列号:210xxxxxxxxx0218】

1.针对查询/提问的内容“cpu使用率异常”进行有效性检验，一般验证查询或提问的内容是否为空。

2.针对查询/提问的内容进行向量化转换（大模型通用的一种实现方案将文本或知识进行向量化存储，同时查询也会先向量化，具体可以通过google了解一下技术细节）。

3.通过向量化之后，需要到向量数据库进行查询跟该向量结果相似的内容，注意这一步一般是本地的算法工程来完成，找到跟该内容相似的所有内容，而不是将整个库提供给大模型，大模型是在此基础上进行推理。

4.在基于向量的知识库中查询之后，会将满足条件的相似内容提交给大模型处理。

5.在正式发送给大模型之前，需要Prompt处理，其实是让大模型进行角色扮演的指令，如针对上面一条告警生成的prompt建议如下：

你现在是一名运维领域的专家，主要处理一些重要的告警。请根据告警的问题“CPU使用率异常”，帮助推荐给出问题出现的大致原因和解决方案。

6.这时调用大模型的接口对该prompt进行处理，注意在这里大模型可以是openAI提供的也可以是国内不同的企业所开发的大模型，由大模型针对查询的问题和相似的内容做出推理判断。

7.针对大模型判断的结果输出给告警工作台，如下图所示：

4.系统集成边界

针对已有自动问答系统和知识库的企业用户，可以参照上图为系统集成边界，参照如上方式可以最大限度的保障企业下面所述已有的资产：

①核心的推理引擎：采用openAI或其它的大模型来增强智能问答或知识检索系统的效果。

②向量化知识库：传统的知识信息存储在关系数据库或ES这类系统中，而基于大模型的应用，则需要将其存放到向量数据库中，因此需要从传统知识库中同步相关的知识进向量化知识库，而对知道的管理过程，则保持不同。

③知识管理：知识管理过程，知道的采集、审核、保存，如果企业已有现成的系统，则可以不必替换。只是需要将信息同步到向量化知识库中。

④智能问答系统：老旧的智能问答系统一般已经完成了同部分使用场景的结合，这时不必对该系统进行全部替换，只是替换其核心的大模型推理引擎即可，如上图中利用openAI的部分，增强其知识的推理能力。

⑤用户提问：即使用场景的部分，需要将其提供的方式参照大模型的Promp标准进行提问即可。

注意：为了未来对大模型进行效果微调，在系统设计时，要记录相应的调用日志，或在业务流程中对大模型回馈的结果进行评价，这样可以做为人工标注的数据，可以优化模型。

本期分享到这里暂告一段落了，下期我们一起看看如何构建知识库，构建的知识库如何在事件管理中应用，感兴趣的朋友可以关注一下~

擎创科技，Gartner连续推荐的AIOps领域标杆供应商。公司专注于通过提升企业客户对运维数据的洞见能力，为运维降本增效，充分体现科技运维对业务运营的影响力。

行业龙头客户的共同选择

了解更多运维干货与行业前沿动态

可以右上角一键关注

我们是深耕智能运维领域近十年的

连续多年获Gartner推荐的AIOps标杆供应商

下期我们不见不散~