详解 Ops 智能运维机器人，故障处理又快又准！

作者|  阿里文娱高级开发工程师 见乔

责编 | 夕颜

出品 | CSDN（ID：CSDNnews）

 

背景

对优酷来说，核心业务全年需要有很高的业务可用率。对于故障处理则有 1-5-10 的目标， 即 1 分钟发现、5 分钟定位、10 分钟恢复。当前我们的技术架构越来越复杂，线上的一次请求， 可能会经过非常复杂的调用链路，当业务出现问题时，如何快速发现和止血，是当前系统运维 体系的核心点之一。

在稳定性建设这条路上，我们已经沉淀非常多的经验：监控预警、业务链路、变更查询、 日志查询分析……每一个故障排查手段都对应了可能不止一个运维平台。所以 PE 在故障处理 时所面临的问题，不是没有平台或工具，而是平台太多，想要在 5 分钟快速定位线上问题，非 常考验每个 PE 的能力。

随着人工智能在全球领域越来越热，ChatBot 作为应用场景之一，它的功能也日益强大。为 了让 PE 的运维方式更加智能，优酷应用架构团队，也借助钉钉机器人，在 ChatBot 领域展开了 运维领域的实践，为 PE 量身打造了一款智能运维机器人。

 

常用场景介绍

运维机器人通过聊天的方式，智能处理用户的输入，将运维结果快速反馈给用户。用户不 用关心众多运维平台和具体术语概念，只需要聚焦于运维对象和运维操作，机器人会帮助用户 去处理一些脏活、累活和重复性工作。另外，机器人天然具备秒级响应、一触即达的能力，以 及在移动端的优势，更是让每个 PE 都能随时随地通过手机进行运维，大大提高了故障响应能力。

运维机器人在优酷的具体使用场景：

 

1. 变更操作

1）实例重启：线上实例异常时，想快速重启应用服务，只需要在钉钉里告诉机器人想重启 哪个实例即可；

2）实例替换：线上实例异常时，如想直接替换新的实例（如替换容器），只需要在钉钉里 告诉机器人想替换哪个实例即可；

3）订阅应用发布：开发、测试同学，经常因为各种原因需要关心上下游某些应用的发布情 况，可以提前在钉钉群里告诉机器人想订阅哪个应用的发布情况，在该应用开始发布时，机器 人就会在钉群里通知，相关同学便能在第一时间判断此次发布的影响范围。

2. 应用查询

1）应用信息查询：想最快知道一个应用的相关信息？直接将应用名发送给机器人即可；2）Java Dump。

排查 Java 应用的线上问题时，经常需要 Dump 堆栈或堆内存信息来进行分析。直接告诉机 器人想 Dump 哪个实例上的应用即可快速 Dump。

3. 系统网络

1）IP 查询

无论是外网还是内网 IP，都可以发送给机器人进行查询。

 

             

（图：IP 查询）

 

2）域名查询 无论是内网还是公网域名，都可以发送给机器人快速查询相关信息。

              

（图：域名查询）

 

3）VIP 查询

通过机器人，快速查询 VIP 信息，及 VIP 下 RS 的信息。

 

1. 监控预警

1）系统监控图绘制 可以通过告诉机器人相关指标及时间，快速查看对应的监控指标图。

             

（图：监控图绘制）

 

2）异常诊断 底层对接了集团的日志分析平台，可以快速诊断应用是否存在异常日志。

 

技术实现方式

 

1. 消息收发 

在实现上，机器人主要是依赖了钉钉提供的群机器人功能来进行钉钉消息的收发。钉钉支持 Incoming 机器人和 Outgoing 机器人。在企业内部往往有很多自研后台系统，例如 CRM 系统、交易系统、监控报警系统等等，有时候大家想把这些自研系统的事件同步到钉钉的聊天群，通过钉钉的 Incoming 机器人，就可以快速实现这个功能。只需要在钉群里创建群 机器人，通过向群机器人的 webhook 来发送特定消息格式的请求即可实现。

而对于复杂的运维场景，仅仅通过 Incoming 机器人做消息推送还不够，所以我们用到了 Outgoing 机器人，根据具体的运维场景，来定制用户与机器人的交互。当用户@机器人时，钉 钉将用户发送的消息内容实时地发送到机器人服务上。

2. 请求处理流程

机器人服务会针对用户的输入，首先进行意图判断，如果用户是以自然语言的方式进行输 入，首先会通过 NLP 模块解析用户的意图，最终拆分成命令+参数的方式，识别出具体的可处 理组件，然后交给组件去处理业务逻辑（例如判断此次输入是进行服务器信息相关查询还是应 用信息相关查询），最后由组件根据自身逻辑调用底层的具体服务。

             

（图：技术架构）

 

请求处理的整体框架设计比较简单：通过统一的 Controller 进行消息接收，然后遍历每个 已加载的组件，首先询问该组件是否能处理该请求，如果可以处理，则交给该组件进行处理；

对于处理失败的组件，会再继续询问下一个组件。大致流程如下图：

             

（图：请求处理过程）

 

对于用户而言，用户不需要了解具体的运维相关概念，例如输入一个 IP 时，用户并不需要 关心这是一个公网 IP、内网 IP 又或者是一个 VIP，甚至用户不需要关心自己输入的字符串到底 代表什么，因为相应的判断都由各个组件自己决定。

 

3. 组件接口设计

接口设计上，每个组件都会实现 CommandFilter 和 Command 这两个接口，CommandFilter 主要是回答能否处理某个用户输入，Command 则是具体地处理某个输入：

              

（图：组件接口）

 

这样一来，机器人服务也非常利于拓展。对于新增的业务场景，只需要新增一个组件即可。

 

总结

机器人服务向下打通了十几个底层基础设施平台，同时提供了统一的交互方式给到真实用 户，解决了长期以来运维难、应急响应慢的痛点。当前在优酷，运维机器人已经成为日常工作、 故障应急必不可少的助手。

机器人在智能这块，后续还会持续加强能力。因为对用户屏蔽了一系列复杂的运维平台概 念，所以机器人提供的运维服务是否周到，最终还是取决于底层对接的运维平台是否足够全；而用户与机器人交互的体验是否贴心，意图识别是否准确，最终还是要看在 NLP 这块，机器人 服务对于用户自然语言输入的预处理能否更加精准。

【END】

更多精彩推荐

克隆一个 AI 替自己开会，爽吗？

为什么大厂都在用 GO 语言？读透 GO 语言的切片

☞饿了么交易系统 5 年演化史

☞北京四环堵车引发的智能交通大构想

☞从Ngin到Pandownload，程序员如何避免面向监狱编程？

从 Web 1.0到Web 3.0：详析这些年互联网的发展及未来方向

你点的每个“在看”，我都认真当成了喜欢