《AIOps 在 360 的落地实践》分享实录

随着运维工作从规模和复杂度多方面的爆炸式增长，传统的运维手段已经无法满足如今系统运维管理的需求。AI 技术日趋成熟，智能运维（AIOps）应运而生，给运维行业带来了很多的变革和机会。如何将大数据和机器学习的方法引入运维的各个领域？如何快速落地 AIOps？本文作者在应用实践的基础上，系统的总结了 AIOps 的落地方案。下来就跟随作者一同探索吧。

1 简介

9 月 22 日，在北京 360 公司总部举办了【360 互联网技术训练营第 18 期——AIOps 落地实践探索】。本次会议共有四个议题，分别由两位内部讲师及两位外部讲师分享，第一个分享 AIOps 在 360 的落地实践——你也可以快速落地 AIOps 介绍了 360 的智能运维大框架和每个组件的替换建议等，旨在希望能让一些还没落地或者正准备落地的小公司也能开展 aiops，另一位内部讲师的分享议题是 360 基于 StackStorm 的 AI 运维平台故障自愈实践，主要是从一些常用的具体场景切入，期间加入预测、异常检测、关联分析等模型，然后针对检测结果做一些判断和自愈。

宜信

本次分享的第二个议题是由来自宜信的肖云朋讲师分享的基于知识图谱构建下一代智能 CMDB，知识图谱也有很多公司研究，在 AIOps 领域算是算法的补充,因为算法的本质还是通过大数据来分析和生成运维规则，而有些规则，在一些固定的场景，我们完全可以通过人工经验来直接生成，或者通过现有的 cmd 调用关系直接生成。比如 A 肯定会导致 B 发生，那就没必要再用大数据来找 A 与 B 的关系。如果把 AIOps 比成运维大脑的话，知识图谱算是根据你的运维经验，直接告诉大脑的一些固定知识，直接给你 3 岁智商，不需要你从 0 开始，什么都得学。一些运维经验直接无法生成规则的，可以交由大数据 AI 分析，慢慢替你学习找规律。

在 360 内部，尽管有成熟的 cmdb hulk 和 odin 等系统，有每天一线运维的经验积累，但这些都暂时没有通过知识图谱的形式把他生成经验库，这也是 360 内部接下来需要加强的地方。

日志易

本次分享的第三个议题是来自日志易，有着丰富运维经验的杜卫普分享的基于日志大数据的智能运维与安全实践，作为一个三方 Tob 公司，如果要接入一家公司的运维数据做智能分析，一般要集成 agent，用户考虑到服务端的安全性，会不太配合，所以 agent 自采集和 agent 抓包等，都比较难，一般都是从日志入手，所以日志易的切入点还是在大规模的三方日志，从最开始的 elk 到现在的自研等。然后 AI 的部分应该是体现在日志的一些关键词 nlp 分析，和生成的时序异常检测等。

360

了解了其他公司的一些 AIOps 切入点,接下来看看 360 自己的 AIOps 落地方案，从 18 年 3 月左右做智能运维落地和探索，我们也总结出了一套符合当前 360 现状的落地思路。

整体来说，随着公司的不断发展，不少业务进入了平台期，同时也涌现出了非常多的运维常见问题，例如：资源长期空闲，但没有及时回收；报警越来越多，但充满了误报漏报；报警杂多，但报警项之间没有关联等等，对于运维人员都是极大的挑战和折磨。

为了更好地解放运维，360 针对性的选择了三个通用的高频运维场景，然后借以 AI 分析在这些场景内做了分析和预测。例如，在资源回收场景，使用了分类和时序预测模型，在报警误报漏报，使用了时序异常检测，用更准的动态阈值来代替一刀切的阈值。在报警关联方面，使用了报警收敛和关联分析、根因分析等模型，给出了 topN 的可能原因，辅助运维做决策。

2 360 Aiops 落地实践

接下来简单的串讲一下。我们提到了我们的运维大数据 -> AI 中心 -> 报警自愈 -> 运维大屏。其实这个思路有一个拟人的对应关系，运维大数据即我们的监控系统类比我们的眼睛，AI 中心类比大脑，自愈类比手脚，运维大屏类比脸面。这样才是一个立体的架构。我们得看到问题存在的地方，发现问题，然后去 AI 分析问题，最后去执行自愈动作，解决问题，整体肯定是串联的。当然背后的工作做的再好，也得有一张好看的脸面，让别人能看到你的美，所以运维大屏作为我们的一个展示，也是非常必要的。接下来我们不看内涵先看脸。

运维大屏

这个图其实算是一个大聚合，这里面展示了有左边栏资源回收的成本数据，右边的效率提升数据，最下面的运维大数据，中间的骨干网络链路数据。其中骨干网的链路数据随着滚动条的拖动，可以实时生成预测数据。最顶端还有实时的 push 通道，如果有一些大规模报警过来，经过判断和分析后，确定是 AI 数据了，会实时的在大屏上显示影响范围，当然这一块屏还是数据维度的展示居多，脑洞大开一下，以后是否可以加上交互，比如装上摄像头，谁看大屏了，看了几次，看了多久，都可以统计，然后加上手势，可以切屏，局部放大等，甚至一些更酷炫的交互展示等。总之，展示是一个可玩性非常高的领域，即使我们是搞运维的，也希望大家不要局限思维，敢想敢玩，就能有新花样。

当然这么复杂的展示都是因为公司奇舞团的大力支持，一般情况下，一些开源的 3d 可视化框架也能做的很不错，例如 echarts 等，大家可以自行发掘。

体系架构

接下来看看可视化背后的体系架构，整体我们的体系就是 agent 采集，我们这里 agent 都是自研改造，根据需求可以采集任何我们想要的数据。比如这里的硬件、日志、进程、外网质量等数据，然后按需存到对应的方案中，然后统一集中治理，接着针对固定的时序数据，固定的场景去做 AI 分析，最后如果该场景需要自愈，可以触发命令系统执行自愈动作，最后聚合部分数据，做一个集中的大屏展示。

接着我们看看数据采集的整体框架。

这里我们整体的数据采集有 agent 自采，和三方数据。例如 syslog 通过 kafka 写入 es，硬件接口上报，写到 mongo，进程采集，接口上报，最后写入到 ha 的 infludb 里面。整体我们的资源数是 20 台 8 核 16G 的机器，我们的整体架构比较简单，就是采集，接口上报网关，网关算是一个比较重的组件，里面的数据处理和报警发送等都没单独拆出来，这么做其实是从运维和发布的角度考虑，整体来说还是单体应用和微服务的优劣区别，这里就不展开对比了，感兴趣的可以参考我以前写过的微服务拆分的文章。

我们本身是追求扛得住，易维护，代码复杂度低的原则。不会为了微服务而微服务。比如我们 agent 和网关的交互，没有使用 rpc 等，都是用的短链接，因为 rpc 在连接池维护，和连接状态管理方面有很多的注意的东西，但本质上解决的就是减少带宽传输，减少建连耗时等，但这些在我们的架构中不是很关注。在网关前面挡一层 nginx 也是为了方便日志分析。这样业务代码里就不需要加载一些框架和太多方便日志处理的代码。整体就是一个无状态的 web 服务，非常容易扩容和维护。

单点应用

我们这里由时序预测，时序异常检测，报警关联分析三个模型组成。时序预测用在了资源回收场景，时序异常检测用在了 vip 外网质量监控场景，关联分析用在了 io 报警关联等场景。其实当前 AI 落地 aiops，算法本身的准确度是一个方面，同时算法的场景选择也是非常重要的，一个算法落地的好与坏，与场景的选择，数据的工整性有着直接的关系。

这里以时序的异常检测为例子，500 个 vip，200 个 cdn ips，10 万链路 ping， 10 万报警阈值。

现在为了检测这 10 万链路的异常点，我们有两种办法，固定阈值一刀切，固定阈值 500ms，这样肯定会有部分的漏报和误报，比如 500ms 以内的异常波动，这种固定阈值就检测不出来，产生漏报。同时比如，新疆到北京可能链路一直都不好，一直都 510ms，但这个属于正常值，所以整条链路都成了误报。

所以我们最好是为 10 万链路，每个链路生成一个合适的报警阈值，我们不可能人工为 10 万链路定阈值，所以需要通过异常检测模型，来帮我们检测出每个链路的异常点，相当于每个链路有自己的动态阈值。

10 万的链路，我们首先通过聚类分成 200 左右的类，每一个类一个模型，聚类如果算法不好调优，我们可以通过人工经验，来通过源 cdn 机房来分类。

我们的异常检测模型，除了孤立森林，和曲线拟合 EWMA+3σ等，还有几个统计模型。这样给不同的模型加以权重，最后通过各个模型的投票来决定这个数据点是否异常。因为大部分情况下，孤立森林应该是权重最大，最准的，其他的模型只是为了在孤立森林判断不异常的时候，再去多次确认一下。三个臭皮匠顶一个诸葛亮。

这里整体的流程就是，当一个外网质量数据点过来，AI 中心会去 redis 队列，sub 当前该 point 2 个小时内的同类数据，每分钟 10 万条数据，每个数据经过 7 个模型的串联判断，7 个模型中的统计模型需要预加载数据，需要实时加载模型，然后模型本身处理数据也需要时间，所以要在一分钟内处理 10 万条数据，每个数据处理时间 1 分钟以内必须返回，不然影响报警的实时性。

单机内要缩短每个统计数据的加载时间（10s 左右），这个我们通过在报警数据处理层自己做滑动窗口来实现，AI 中心只接收数据，不做数据处理。

模型实时加载，本身耗时 10s 左右，我们通过提前热加载到内存，使用在线非实时模型，AI 中心通过后端的离线训练，每个 6 个小时，替换一次在线模型。前面两步总共节约了 20s，然后本身模型处理速度基本上 100ms 左右没法减少。单机 goroutine 并发 200，至此单机基本上一分钟能处理 12000 条数据，接着我们扩容 AI 中心，做成 10 台高性能模型处理集群。然后将 10 万的请求打散，每个机器抗 1 万多的模型处理量。为了控制带宽，我们的请求和 AI 中心的异常点返回，都是批量执行，所以 AI 中心我们有一个 map-reduce 机制。最后将 10 万数据的异常状态 1 分钟内分批次返回。

最后我们这些异常检测的数据，还会通过标注平台来人工标注，来反馈到我们的算法模型，算是人工校准一下模型。

时序模型预测用在资源回收的场景中，流程图如下，核心的地方在于分类的标注打标签和预测模型的准确度下。具体这里就不展开了。

关联分析这个模型，用在了 io 报警的关联分析上，我们通过关联分析模型来先判断多个时序数据之间是否有关联，然后通过异常检测发现的异常点先后顺序，来简单判断是否有前后根因。这里也不展开了。

标注平台

我们知道数据通过模型最后出来结果，但是这个结果需要不断反馈准确度，才能不断的进化，这里的标注平台就是起的这个作用。我们针对三个模型的相对于的场景，左边栏会显示模型输出的数据，比如异常模型输出的异常点，右边输出该指标的当前值，运维或者业务等模型使用者，可以选择 Y 或者 N，然后反馈会反推给模型数据库，根据这些反馈，离线模型再不断地更新和训练。

自愈平台

当前我们的自愈更多的是基于一些高频场景，例如机器 down 机，故障报修，进程重启。底层当前是基于 stackstorm 改造的，将日常的自愈场景抽象出来各种 action 原子操作，最后通过这些 action 原子操作组成 workflow 工作流，这样以后如果接入新的场景，业务就可以在界面上选择通用 action，自行编排，最后组成适合自己的工作流。当然 stackstorm 本身也有一些弊端，比如框架比较重，依赖 yaml 等文本，接入成本相对较高，这些都可以在以后的使用过程中不断替换和优化。

3 总结

以上的运维大数据 -> AI 中心 -> 标注平台 -> 报警自愈 -> 运维大屏就是我们当前内部的一个整体 AIOps 框架，当然在对内打磨的同时，我们也希望能将每个组件通用化，与公司解耦合，以后是否可以 Tob 帮助更多的团队落地 aiops。如果大家有任何 AIOps 落地心得也欢迎后台留言讨论。

本文转载自公众号 360 云计算（ID：hulktalk）。

原文链接：

https://mp.weixin.qq.com/s/abIhbSC87APQgyc97gPbbw