基于 Flink ML 搭建的智能运维算法服务及应用

摘要：本文整理自阿里云计算平台算法专家张颖莹，在 Flink Forward Asia 2022 AI 特征工程专场的分享。本篇内容主要分为五个部分：
1.阿里云大数据平台的智能运维
2.智能运维算法服务应用场景
3.传统算法工程链路的局限性
4.使用 Flink ML 搭建智能运维算法服务
5.总结和开源计划

一、阿里云大数据平台的智能运维

阿里云计算平台提供了多个非常核心的大数据计算和人工智能相关的产品，支撑了阿里集团内部以及云上各行各业客户很多核心的业务场景。在这里我挑选了三个非常典型的大数据计算产品来给大家做介绍，它们是大数据计算服务 MaxCompute、实时计算 Flink、实时数仓 Hologres。

这些产品所支撑的业务场景大家其实也都非常熟悉，比如我们日常在手机淘宝、蚂蚁森林中收取的能量数据就依赖于像 MaxCompute 大数据计算服务定时产出，因为它主要负责大规模数据的离线计算；双十一期间，我们会看到非常多炫酷的数字大屏，这些大屏上实时滚动的数字就依赖于像 Flink 实时大数据处理系统；当我们日常在手机淘宝上搜索一些商品的关键词的时候，Hologres 则会在底层帮我们进行实时的交互式分析，从而为我们推荐出实时的搜索结果。

可以看出，这几个大数据平台所支撑的业务场景是非常丰富的，它的用户规模非常的庞大，平台本身的架构也十分复杂。因此保障平台的稳定性就变成了一项重要且富有挑战性的工作。我们计算平台专门设置了一支运维中台的研发团队，也就是我所在的团队，来负责大数据平台的统一运维管控。

比较有意思的一点是，我们既是大数据平台的使用者，同时我们也负责平台的智能化运维工作。

从运维的视角来看，我们最关心的核心问题主要有三个层面，分别是稳定性、成本、效率。

• 在稳定性层面，涉及到的问题包括是否能够及时发现大数据平台中发生的异常、定位异常背后的根本原因、及时的止血和修复问题。
• 在成本层面，我们关心能否通过更加合理的资源配置以及优化应用的排布，在保障稳定性的前提下，能够让我们的成本降到最低。
• 在效率层面，我们不仅关注大数据平台本身的性能的提升，同时我们也希望使用大数据平台的用户能到能够得到非常高效的技术支持和答疑。

前面提到的典型场景当然都离不开数据的支撑，随着系统的云原生化以及可观测性理念的普及，我们现在所能获取到的系统层面的可观测性数据也越来越丰富了，包括指标、日志、Trace 等等多种不同形态的数据。

基于传统的人工分析已经很难实现对海量数据的全面高效分析，因此也就催生出了对于智能运维算法能力的需求。那么在智能运维场景里，我们对算法模型都有哪些需求呢？

首先，我们希望算法模型能够处理来自多个不同数据源、各个不同形态的数据。比如我们前面所提到的指标就属于时间序列类型的数据，而日志属于文本类型的数据。

同时，我们希望在智能运维场景中的算法还要具备足够高的性能。因为在运维的场景中，我们需要面对的往往是信息密度比较低的海量数据。

此外，无论是从大数据平台所支撑的业务场景来看（比如我们刚才提到的双十一的数字大屏），还是从阿里云所承诺给用户的服务质量的角度而言，我们对于智能运维场景中算法的实时性也都有非常高的要求。

二、智能运维算法服务应用场景

那么接下来我们就通过几个典型的案例来给大家介绍，在智能运维的场景中都有哪一些比较典型的算法模型，以及他们是如何应用在我们的实际业务场景中的。我们依然会从智能运维的核心场景稳定性、成本和效率三个层面进行展开。

稳定性层面，我们前面提到的关键问题是，我们能否及时发现系统中的异常。在我们实际的生产中，对应的平台的运维人员会去建立自己的一套核心指标监控大盘，但对于像阿里云这样庞大的平台，即使是核心指标，它的数量也远远超过了人工能够覆盖的范畴。因此我们就需要利用时间序列的异常检测算法，它能自动捕获在运维场景中几种比较典型的异常，包括方差的变化、均值的变化、尖峰深谷、断崖式跌落、趋势增长等等。

那么通过这些智能持续的异常检测算法，我们就能够更快的发现系统中的异常问题，最终的目的则是为了保障我们承诺给用户的稳定性 SLA。常见的稳定性 SLA 的量化标准是 MTTR，也就是问题从发生到最终解决的耗时。而时间序列异常检测算法所要解决的是其中非常关键的 MTTD 环节。因此如果我们能够去缩短时间序列异常检测算法链路侧的延时，就能够缩短 MTTD，进而缩短 MTTR，最终保障我们整体稳定性 SLA 的达成。

成本层面，我们希望通过更加合理的资源配置，使得在保障用户体验和平台稳定性的前提下，能够把成本降到最低。为了达到这个目的，需要具备以下两个基本要素。

• 我们需要能够对用户的负载和资源需求进行非常精准的预测。
• 我们在系统底层