自然语言处理在 AIOps 中的应用

GOPS上海站

作者简介：管正雄，阿里巴巴高级算法工程师

今天分享的内容分为三块，第一块介绍一下 NLP 是什么和运维的交集是什么，第二是 NLP 在大数据运维的实践，最后是一点思考。

一、NLP 与运维的交集

首先大家想一下在运维这一块，我们要处理最多的数据。运维这一块目前处理比较多的大概是三类数据，告警、日志、工单，随着这些的信息量越来越复杂，告警一般是告警项，然后有一些内容。日志相对来说有一些结构化的东西。工单来说信息最丰富的。信息量越大，文本复杂度也越大，对于我们处理起来也有一些困难。

不知道大家有没有一些情形，比如说睡觉的时候突然手机响起来了，拿起来一看一百条告警短信。对于系统越来越复杂，每个模块都会出现告警，这样的话出现异常的时候，很多模块上下游同时都会发生告警，短时间内是没有办法处理这么多告警的。

第二块是日志，比如我们想更高效地分析日志，这个时候我们希望提取出一些日志模板，对着日志模板进行分析。简单一点的还好，复杂一点的东西模板提取还是有困难的。

还有就是知识库，有时候会遇到答非所问的问题。所以像这些文本内容，其实在NLP，都可以用NLP的一些算法来解决。

NLP 已经出现在生活的方方面面，像淘宝的机器人，去问他比如说东西要退货什么的，他会回答你。还有像翻译之类的，也是 NLP 的实践。包括像语音助手等等，都是 NLP 及其相关的落地案例。

NLP 是一门交叉学科，计算机科学、语言学、人工智能的交叉学科，他的发展主要伴随三个阶段。最开始是一个规则系统，只能满足最基础的。到第二个阶段统计阶段，我们可以把一些词比如说ABC经常出现，可以把统计规律学习出来。第三个阶段深度学习阶段，我们依靠神经网络这样一个强大理论能力，还有强大的算力，我们就可以把海量的语调输入进去，学习到高层的语义知识。

NLP 应用简单列举了一下，主要分成两个。一个是自然语言理解，比如说像意图识别等等，如果我问淘宝的机器人我想送什么什么东西，这个时候它就识别你的意图。另一个分支是自然语言生成，比如我可以生成一些对话，你跟机器人沟通时候就不觉得对面是一个机器人，而是一个客服，你们可以沟通起来。

前面也提到了一些在运维中处理文本信息的脱敏，再简单介绍了一下NLP。总结一下在运维适合用 NLP 解决的场景有哪些特点？

首先是需要语言文本相关的问题，是通用性，因为我们算法解决问题的时候不是一个特定的case，他解决的是一类case。同时我们需要有充足的领域知识，比如我们需要搞一个 NLP 模型解决一个问题，比如说模型是一些有监督问题的时候，就需要业务同学帮我们一起做个打标，这里就要把他的经验输入到模型当中，所以我们需要有充足的领域知识支撑的。

最后有足量的数据支撑，因为我们的模型无论是训练还是验证、迭代，都是要一定量的数据去支撑的。具体的量级这里不举例，因为不同的场景、不同的任务，量级都是不同的。

参考以上场景的特点，我们在运维领域比如稳定性、成本、效率三块，主要列举了一些可以落地的案例。比如像日志异常检测，通过对于日志模式的监控找到系统的异常。比如更新定位，更新定位过程当中可能需要一些日志的信息，这里可以用到 NLP 相关的一些算法来对日志进行提取，这个时候就可以辅助更新定位。还有变更风险监测等等。在效率这块，我们列举了一些场景，像告警聚类，我放到了聚类分析里面。还有一些像知识推荐，推荐一些类似问题的工单等等。最后就是 ChatOps。

二、NLP 在大数据运维运维的实践

接下来讲讲在大数据运维的实践。今天主要讲一下背后的管控平台，就是飞天大数据管控平台（Apsra Big Data Manaager）。

我们可以看到我们的大数据产品都在上面。这一块是智能运维平台里面关于NLP的算法服务，整块就是算法服务，他分123，我们先看下面第一块预处理模块。因为我是算法服务模块，所以我提供的都是通用的算法能力，所以在第一层预处理模块，我会对数据进行清洗。比如说像分词等等，再包括对于日志模板提取的一些方式。还有聚类算法服务，这一块我们提供给用户可选择的算法，用户可以根据算法场景对于我们的算法进行配置，这样就可以实现对他们业务的算法，我们提供的是通用的算法能力。知识推荐也是一样。

接下来讲几个具体案例。首先第一个比如我们在用大数据平台的时候，如果我遇到报错的时候，我拿着原始的错误日志，我想找解决方案，这个时候应该怎么做？比如我去找文档，我在文档里面找，结果有些时候遇到我们的版本迭代非常快，第一个文档没有及时更新，第二个查文档的时候并不能很好解决问题。这个时候我们怎么做？就找SRE。同时很多人问SRE的时候，可能效率也不是很高。所以我们就希望把这两个的优点结合在一起。文档有什么优点？很快，非常快。SRE答疑有什么特点？专业。我希望非常快的得到一个专业的解决方案。

我们先看这一块，首先我们把大量的原始日志通过聚类分析聚类成日志模式，我们这里称聚类以后的日志模板，我们叫做日志模式。这个时候往往是成千上万的日志，聚类完以后大概只有一两百条模式，这个时候SRE就会接入，和我们的日志模式进行打标，打标一次就可以解决非常多的同类问题，我们这样就构建了一个日志模式打标库。

比如用户拿着一个原始报告日志去聚类分析，然后日志模式打标，再进行匹配。如果有时候 SRE 打标的过程中没有进行打标，或者出现新问题的时候怎么办？这个时候用户可以选择人工，这个时候人工再给用户进行答疑。

我们是把这个放到钉钉里面，我们在群里@机器人，你可以看到左边我们在群里@机器人，然后贴上原始日志，这个时候机器人就会返回，如果说匹配到一个就会返回这一类的解决方案。这是第一种情况。第二种情况如果没有匹配到，它就会提一些类似的问题，然后再那里找人工。

其实每个下面都会有这样一个选项，“该回答是否能够满足您的需求”，这个就是评价体系，因为我们需要一个评价体系去评价日志答疑的效能。到底效果好不好，提升在哪里。

所以我们抽取了两个指标，第一个是答疑准确率，就是用户问的问题跟推荐给他的问题是不是同一个，如果是的话那这个推荐是准确的。第二个提问转工单数，比如说机器人可以给用户一个答案，用户不满意又提了一个工单，说明我匹配是正确的，但是打标的方案可能需要更新了，这个时候我们就抽取了提问转工单数。如果说这个问题一直出现，同时打标的结果一直没有奏效，这个时候我们就会知道，让 SRE 去更新一下。

接下来看第二个案例，日志模式异常检测。首先我们把大量的日志称之为日志流量，日志流量分为两块，一个是背景流量，一个是异常流量。异常流量往往是排查问题的关键信息。看左边这个图，蓝色的是背景流量，红色的是异常流量。人工排查的时候，这个其实非常耗时的。第二个比如说我们系统现在做的越来越庞大，同时有一些模块我们想监控，往往会发现比如说这个模块异常，他对应的日志报错可能会飙升。

我们来看第一块，用户选择关注日志模式，这一块比如说同样的，我们也是拿这些原始数据经过聚类生成日志模式，这个时候 SRE 需要介入，比如说系统某一些模块的异常，他有一些特定的日志模式发生变化，SRE 要做的就是把这样的日志模式挑出来，挑出来以后就重点关注这样几个模式。

场景二比如说实时大量的海量日志开始流入了，首先经过我们的聚类分析模块，我们的聚类分析模块会把海量的日志聚类成日志模板，这个时候我们就会对聚类以后的日志模式，重点关注的几个。比如说一条条日志模式的曲线，如果我重点关注有飙升，我会进行多维度的统计分析，你这个飙升是怎么样增加的，这个要靠业务的经验来给予。飙升以后我们会生成工单，再通知用户比如说你这个日志模式发生变化了，你赶紧去排查。

我们来看一下实际的情况，左边这个图是某类模式的技术，随着时间突然在某个阶段飙升了，因为这个模式是我们关注的模式，所以说他会立刻生成工单。这个时候工单会有上下文信息，同时第二个就是统计纬度，这个增加了数量多少还是增加了种类，他要关心哪一类问题都会把工单贴出。这样的话用户接到工单的时候，就会非常快的排查问题。

评价日志模式异常检测的能力。首先第一个异常检测准确率，比如我的日志模式突增突降等等，这一块我是否检测对了。第二我异常检测对的，这个日志模式确定增加了，没有问题。但是这个日志模式增加以后却不是我们关注的模块发生异常，也就是说日志模式增加，跟我们的模块没有强关联，这跟我们之前分析的不同，我们后面就知道了日志模式要重新去配，重新去关注。

接下来看第三个case，比如我们的公有云或者专有云，他会有一些驻场，系统会出问题，这个时候驻场会把问题抄给二线运维，二线运维同学会去解决问题。解决问题的时候，他会发现一些问题，比如说二线运维同学有人可能这一块并不是很熟悉，或者是刚来没有多久，他遇到了一些问题并不是之前遇到过的。所以他有两种情况，一种翻一翻答疑手册，第二个就是手册文档这些通用的问题更新慢、覆盖不全等等。第二就是我们有一个历史工单库，包括问题描述、问题发生的情况、问题的解法，我们都会有一个描述。

这时候我们可以把现在发生的一些不知道怎么解的问题放到里面去找。但是找的过程当中会发生一些问题，比如说你输入了一个关键词，可能这个关键词包含了整体问题中的一角，其实就是很难描述清楚一个问题。

这个时候看一下我们做的业务流程图，这个时候我们用到了知识推进模块。

我们先看构建知识库。我们构建知识库，首先把历史工单数据库进行一些 NLP 处理，比如做一些特征提取等等，构建出了一个历史工单知识库。用户在填工单的时候，这个时候要有知识推荐模块，要有历史工单知识库在里面他能不能找到匹配的工单。如果能找到，我就会把历史工单知识库里面的内容推荐给用户作为一个参考。当然我们也会出现问题解不了，我们也提供了人工出口，让人解问题。但是这里要注意，人工处理以后我们这里也做了闭环，就是人解完以后，我们也会把这个记录下来，所以历史工单知识库是实时更新的。

来看一下应用案例，右边是推荐模块，左边就是工单内容，就是一些问题描述信息。首先我输入以后，右边就会有一个推荐，这是工单的名字，旁边是匹配度，我们是用文本相似性等等算出来的一些结果。右边是关联，比如说问题关联在一起的时候，如果你觉得非常类似我们可以关联，这几个工单会关联在一起，这样的话解决问题等等都会非常有体系化。

最终我们抽取两个指标来评价整体工单推荐系统。第一个是推荐准确率，比如说用户在接到推荐工单以后，有一个操作是或者否，如果点“是”的话就可以推荐。同时这个是用户的直接反馈，还有一个用户的间接反馈，间接反馈比如说我去推荐top3，我点进top3的这里，信息也会收集下来。

第二个指标是平均工单关闭时间，用来衡量工单的解决效能。比如说不同工单有不同的解法，对你平均解工单时间的减少，如果时间越少就证明方式越正确。

三、思考与展望

接下来说一下 NLP 落地时候的一些坑，还有一些未来的展望。首先说一下落地过程中牵扯到的业务闭环，其实最难的一块俗话说万事起头难，最难的一块是场景挖掘，这需要多方共同努力。

首先业务会疏理出一些他们的痛点，痛点再进一步抽象，痛点抽象成数学问题，然后我们找一些数学模型，可以解这样一个问题。再抽取一些业务数据，对于算法进行PUC的验证。验证完以后这个算法可以解目前的问题，这个时候我们再进行整体的产品化设计。设计完以后再研发交付等等。因为我们这一块做的算法是服务化的，所以最终提供给用户其实是算法服务，这一块我们会提供给用户服务化的东西，用户会根据他们的业务对服务化进行配置，最终落地使用。

到这里并没有结束，用户在使用的过程中前面我们提到了非常多的评价体系，这里我们就可以用评价体系来评价我们的模型哪里做的好，哪里做的不好，这里可以反作用于我们的第二步算法模型。比如说我们的穿插数是不是要再调节，再或者我们的算法模块是不是哪里需要再进一步更新，最终就形成了整体的闭环。闭环的目的就是不停地提升算法能力，使算法产生的业务价值不停的逐步的去进步，越来越大。

未来工作，这里谈一下NLP在未来工作中可以做的工作。首先第一个是进一步挖掘多纬数据的语义相关性，目前我们做的像观点聚合、工单推荐等等，只是一个纬度的关联，目前还没有把多维的数据整体打通，如果打通的话这个提效会更多。比如你的某个配置发生变更，导致了什么样的事件产生，最终再导致告警，如果能把多纬数据打通的话，这样用户在排查的时候可以把这几个关联起来看。

另外就是工单知识库，知识图谱的好处在于知识展示存储速度更快、展示纬度更丰富。

最后就是 DevOps 机器人，目前机器人做的一些事情比如说像日志答疑，他做的这些工作是方便我们去找更多的入口。但是对于一些复杂语言的理解，相对来说目前还没有做到更好。比如说我这个巡检场景，这个语言相对来说目前理解还比较困难，还需要优化。包括像上下文关系，后面还需要进一步去优化。

接下来介绍一下我们的团队，我们是阿里云计算平台事业部大数据基础工程技术，希望大家多和我交流，我们团队内部也在招聘，大家有什么信息可以联系我。

非常感谢！谢谢大家！