怎样用 AI 运维

诞生背景

最近这些年，运维行业提出了不少概念，各种各样的“XX 运维”可以说是你方未唱罢我方已登场。然而，这些概念，都有一个共同点：专注于面向运维同学自身的工具和系统。

这些，其实都隐含了一个前提：DO 分离后，开发和运维都做好自己的事情，然后就可以老死不相往来了。哦，还有一个另类，DevOps。虽然这个概念，在运维行业炒得更火，但它的初衷，其实是开发抛开运维单干吧？只不过运维同学利用自己手握设备资源的优势，发起了一波反攻，在固有的部署和运营领域以外，趁势还染指了研发流程。天天忙着敲代码做需求的开发们，也得了便利，就偃旗息鼓了。

当然，以上只是戏言。但有一点是事实：DO 分离后，开发和运维之间，有了无形的隔阂。运维同学不熟悉研发环境，开发同学不熟悉运营系统。运维同学作为业务运营的主要责任方，运维岗位作为支撑岗位，而且是 7*24 小时支撑岗位，其职责要求能够随时随地支持业务——无论是开发同学的紧急需求，还是硬件设备的自身故障。

开发同学希望运维同学能第一时间响应需求，紧急故障需要运维同学第一时间处理。然而，运维同学也是普通人。工作时间，会有开会，培训，吃饭之类不处于随时待命状态的情况。非工作时间，各种琐事更是多种多样。

如何缓解这个矛盾呢？每天给 IDC 的机器上三炷香自然于事无补。正所谓求人不如求己，我们的幸福生活，需要我们自己来创造。我们专注于运维场景，借助于 AI 技术，开发了智能运维机器人，为的就是缓解这一矛盾。

登场亮相

什么是智能运维机器人？我们所开发的智能运维机器人，就是采用了人工智能技术的，预设场景定位于日常运维咨询和操作需求的，面向开发和运维两类人群的，依托于企业 IM 工具的客服机器人。

这个定义不怎么友好。眼见为实。这张截图，就是披着企业微信外衣的智能运维机器人：

简单来说，一方面，它是个智能客服机器人，能理解自然语言，能自动回答开发的咨询问题，能执行开发的操作需求。另一方面，它不是一个单纯的客服，它还是一个面向运维同学自己的移动运维平台。

智能运维机器人的这样设计，自然是针对运维场景的特殊性而来。运维场景最典型的特点有以下三条：

• 操作类需求。不同于一般客服，咨询需求的占比并没有排在第一位，反倒是操作类需求很可能占到三分之二。所以，定位于运维场景的机器人，不仅要“说到”，更要“做到”。

• 移动运维平台。日常运营中，运维同学会用到一些运营系统或工具。在公司使用自然没问题，一旦业务有问题时，需要在公司外使用，即使手头有电脑，也得花好几分钟 VPN 先连到公司内网。第一，时间上不划算，第二，半夜三更的，VPN 一次，折腾下来，说不定都就此睡意全消了。一个移动运维平台，对运维同学的工作生活平衡非常重要。

• 脚本开发。很多运维同学都有一定的开发能力。当然，有些运维同学的开发能力还很强。不过，对于不少运维同学来说，手机 APP 开发，门槛还是高了点。写写脚本就能完成的开发，才是他们想要的。

产品定位

不管依托于哪种企业 IM 工具，披着什么样的“外衣”，智能运维机器人本质上是一个开发自助平台，也是一个移动运维平台。

作为开发自助平台，一方面，它依托于企业 IM 工具，开发在使用前不需要额外安装配置。另一方面，通过自然语言处理技术，开发可以用聊天这种最自然的方式提出需求并得到解决。

这两个特点，可以说，对于开发而言，使用这个自助平台的门槛为零。设计大师唐纳德.诺曼说，好的设计，有两个重要特征，可视性（discoverability）和易通性（understanding）。简单来说，就是看了就知道怎么操作。对于这样一个也面向开发，而不只是运维自嗨的产品而言，零使用门槛的重要性怎么强调都不为过。

作为移动运维平台，用户鉴权和联通内网环境，企业 IM 工具已经内嵌了这两个功能；参数提取，操作识别以及界面交互，智能运维机器人帮你做好。运维同学只需要按照规定的格式实现一个异步的 HTTP 任务接口（一个任务发起，一个任务查询）就可以添加自定义的工具了。

开发工作基本就是简单的脚本。甚至后续我们会支持同步的 HTTP 任务接口。这一点切合运维工具定制化强，开发敏捷的特点。而且相比手机 APP 这个正统的移动运维平台，智能运维机器人的移动运维工具开发门槛低到大多数的运维同学都能够迈过去。

典型场景

说了那么多，来看看我们的智能运维机器人的典型应用场景。智能运维机器人的应用场景可以分为两类：

• 随时响应用户（主要是开发）的咨询和操作需求

• 非工作时间运行运维自己定制的工具直接处理问题或者提供辅助信息

下面的截图是几个实际使用案例。

场景一：随时随地响应用户咨询

场景二：随时随地响应用户操作需求

场景三：非工作时间手机处理告警

场景四：非工作时间获取自定义辅助信息

这几个使用案例只是抛砖引玉。比如，四个案例中，有两个都是和告警有关的。实际上，理论上来讲，告警处理的最高境界，应该是没有告警，其次是告警出来后自动处理。让告警发出来，就已经落入了下乘。

不过，一万年太久，只争朝夕。在更上乘更完整的解决方案出台前，先自己动手来个可以接受的妥协方案，未尝不是一件可取的事情。而且，运维工作中，会遇到很多阶段性的紧急需求。只要开发门槛足够低，工具化就是值得的。

有了上述的介绍内容，相信大家对于智能运维机器人是什么，能做些什么，已经有了一定的印象。接下来详细介绍智能运维机器人的技术方案。

技术方案

智能运维机器人是基于企业 IM 工具的，它和用户的交互界面，就是 IM 工具的会话窗口。我们定义会话有三种模式：

• 智能模式，这是默认的模式。智能模式下，会对用户输入的消息进行文本匹配，返回相应的匹配结果。

• 操作模式。操作模式不提供主动切换的入口，而是在智能模式下，当识别到用户的输入，是一种操作需求时，自动进入操作模式。而操作发起或取消后，又自动切换为默认的智能模式。

• 人工模式。人工模式是用户主动点击切换的。在人工模式下，用户所有输入直接透传给运维账号的值班人员。

以下是一条消息或一个事件的简单处理流程：

智能运维机器人流程

考虑到一些小细节，实际处理逻辑比这个更复杂。比如，怎么避免两个智能运维机器人账号相互“灌水”？怎么回应用户发送的纯表情？又比如一些体验问题。当 FAQ 库里找不到用户问题的回答时，我们会提供一个快捷菜单，列出一些常见的自助操作或文档。那么怎么设计快捷菜单的出现时机？

作为智能客服的变种，对话系统是智能运维机器人的核心。上述流程图中，只是简单地写了调用对话系统获取结果。实际上，调用对话系统后的返回，会有几种情况。具体如下图所示：

和对话系统的交互

上图其实透露了一点，我们的对话系统，技术选型并非是当前研究热点的生成式模型，而是基于检索的模型。这也是考虑到智能运维机器人的应用场景中，用户和智能运维机器人交互时，不是想找个人聊聊天放松一下，而是想得到一个权威解答。

所以，我们利用运维账号积累的用户高频问题和对应的标准化答案，构成了一个简单易编辑可扩展的知识库。对话系统的主要功能，就是把用户问题和知识库中的合适答案关联起来。下图就是对话系统的结构图。其中，多轮引擎和图谱引擎还在实现中。

对话系统结构示意

我们的这一套技术框架里，对于用户的问题，会使用建有高效索引的检索系统先召回部分高分的答案，再进行精确的匹配和排序。这种“粗排”和“精排”两步走的方案，是很多信息检索系统（包括推荐系统）的标准范式。添加一个“粗排”的步骤，可以排除大部分无关的候选集，大大减少需要精确排序的候选集。在知识库的知识条目数很大的时候，耗时能够指数级地减少。

“粗排”过后，我们就可以对召回的那部分候选的知识库问答对做“精排”了。这个过程中，我们用到了两大类的匹配模型。

一类是传统的文本匹配模型。 这些模型都没有用到深度学习，本质上就是判断用户问题和知识库中的问题（及部分答案信息）的相似度（两个文本串的相似）。根据匹配的语素单位分，可以基于字、基于词、基于 N-gram 的多粒度的匹配。在简单文本匹配方法里，有编辑距离和扎卡德系数等。在传统信息检索方法里，利用领域语料信息的检索方法，如 TFIDF，已经有更好平滑方法的 BM25。

另一类，就是神经网络分类模型。 简单来说，这个模型是这样的：

神经网络分类模型

图片比较抽象，接下来我们详细说明一下。

在搜索引擎这类文本检索的场景，查询往往是几个关键字，但是待查询的文档却很长，不用担心查询的关键字和待查询文本没有交集。但是在问答的场景中，用户问题和知识库中的问题，很大概率没有任何一个相同词，但是仍然表达一个意思。

所以，我们借助词向量技术，将任何语素单位（字、词）表示成一个低维空间的连续变量，这样可以构建一个字词之间的有效距离空间，进而更加精确地去匹配两个文本的语义距离，而不是字面上的距离。我们将词向量技术同我们的监督任务本身在一个端对端网络中进行训练。

这种方法也是当前文本表示和文本匹配技术的标准范式。先将字词等语素单位通过词向量矩阵映射成连续向量，然后利用 CNN/RNN 等神经网络去提取文本词向量之上的高阶特征，再通过这些特征去构建一个分类任务。

在智能运维机器人场景里，就是对用户问题和一个个知识库问题做 0/1 分类，1 表示这两个问题是同一个意思。由于词向量矩阵、CNN/RNN 参数以及特征做分类的权重矩阵都是一个网络图里面的参数，可以联合起来训练，这样就给了网络更大的灵活性。

与文本表示的场景不一样，文本匹配的场景更依赖于两个句子的交互信息。而一维匹配模型分别去建模两个句子，然后对表示求距离的方式并不能很好地建模两个句子的交互信息。我们选择用二维匹配模型，在一开始就构建两个句子的联合表示，对这个联合表示去求特征，以得到更好的结果。

此外除了词向量的信息，句子中其它特征也可以编码成向量作为 CNN/RNN 的特征。比如句子里面的字词位置信息、两个句子相互重叠的位置、词的词性信息等信息。同时在自然语言处理领域的 attention 机制也是文本匹配的关键信息，让句子对特定的字词更加敏感，这也是符合人类认知的习惯，通过最显著的部分来抓住信息的关键。

所有的传统文本匹配模型得到的分数，和神经网络分类模型得到最后的分数，用一个回归模型组合起来，得到用户问题和知识库问题的匹配度，最后把匹配度在指定阈值之上的知识库问题和它的答案返回给用户。

只是开始

在这个 AI 的东风吹得满世界人心躁动的时代，在这个人人谈 AI，处处见 AI 的时代，我们做智能运维机器人，确实有着蹭热点的嫌疑。我们也无意去澄清这个嫌疑。这么多人，这么多企业关注 AI，投身 AI，连国家也将其作为重大战略，不仅仅出于被 AI 取代，被时代抛弃的恐惧，更是因为无法拒绝 AI 给我们带来的无穷想象空间。

当我们出于降低用户使用门槛的需求而引入了自然语言处理技术后，发现原本单纯的运维客服账号，瞬间充满了可能性。腾讯织云智能运维机器人，只是 AI 在运维领域的小试牛刀。当越来越多的 AI 技术引入运维领域后，我们能憧憬，我们的征途，正驶向星辰大海吗？

本文转载自公众号云加社区（ID：QcloudCommunity）。

原文链接：

https://mp.weixin.qq.com/s/M_Yg2kJU-580W6RqTs-Z7Q