精彩演讲实录｜在确定性和不确定性中探索 AIOps 的适用性

作者：TRaaS

2022 年 9 月 01 日
浙江
本文字数：8043 字
阅读完需：约 26 分钟

文章内容摘自中国信息通讯研究院云计算与大数据研究所联合 DBAPlus 社群开展的线上技术沙龙，主题为“释放 AI 效能，迈向智能运维深水区”，以下为蚂蚁技术专家徐新龙的演讲实录；

大家好，非常荣幸能参加本次线上的技术沙龙主题分享，本次分享的主题是《在确定性和不确定性中探索 AIOps 的适用性》，是一个非常具有挑战性的主题，内容主要是针对我们在 AIOps 实践探索上的一些新的思考和总结，希望能带给大家一些收获和启发。

从字面意思来讲，AIOps 是一个合成词，本次分享我们会尝试把 AI 和 OPS 这两个词拆开来介绍，然后再把这两个词捏在一起来解读和理解。

为了试图找到一个逻辑自洽的视角，本次分享主要从以下 4 个方面进行展开：

通过运维中的不确定性了解一些运维背景知识；
概括性地介绍下 AI，让大家对 AI 有些确定性的认知；
然后分享我们对于 AIOps 场景适用性的一些思考和总结；
最后重点介绍蚂蚁基础设施侧在建设 SLO 健康度体系的实践探索和落地成果。

1.运维中的不确定性

开始第一部分内容的介绍：运维中的不确定性；

（我们常说 AIOps 是通过算法对运维赋能，也习惯性的假设我们的听众是了解运维的，但结合过往分享的统计，有很大一部分听众对运维的了解还不是很清楚，也有一些听众是来自高校的学生，所以借此机会简单介绍下运维相关的一些背景。)

运维本质上是对网络、服务器、服务的生命周期各个阶段的运营与维护，在成本、稳定性、效率上达成一致可接受的状态。从专业性角度看，运维是一个强领域知识的计算机应用，要想对运维有更深刻的理解，需要丰富的工作实践。

借鉴国外大型互联网公司的职位定义和划分，运维工程师目前普遍也被称作是网站可用性工程师 SRE(Site Reliability Engineering)，按照业务、系统架构的层级一般划分为三类，自下而上依次是：

基础设施类，主要负责最基础的硬件设备、网络，类似于 IaaS 层的维护；

平台、中间件类，提供中间件技术和一些开箱即用的服务维护，类似于 PaaS 层的维护；

业务类，维护业务服务和应用的正常运行。

从运维工程师改名作网站可用性工程师，不难看出，可用性对于网站的重要性程度。在影响可用性的众多因素中，规模演进带来的复杂性占据了主导。从早期的单体应用，到现在的分布式、微服务架构，伴随着网站规模的扩展，复杂度不断提升，为 SRE 和运维带来了非常多的不确定性。

运维可谓是个“活久见”的职业，正常地，从业时间越长，实践和阅历就相对越丰富，大多数运维工程师的成长都是伴随着故障一起的。运维中的很多不确定性都是由小概率事件引起的，这些不确定性导致的风险使得网站变得脆弱。因此，建设网站高可用架构是 SRE 或运维应对风险最主要的课题之一。后面我们要介绍的一些 AIOps 使用场景中，就是借助 AI 来识别和发现不确定性带来的风险，从而消除网站隐患。

伴随着软件交付的容器化和云原生架构演进，软件生命周期的治理和运维方式也在发生着一次又一次的迭代，尽管我们现在正朝着智能化运维的深水区前进，但在实际复杂的运维环境中，不同的运维方式依旧会长期存在、发挥作用。

在网站架构的演进过程中，运维变得越来越复杂，用一个直观的指标来衡量就是单人所运维的机器或服务数量呈几何增长。整体来看，运维面临两个比较大的挑战：一是系统架构越来越复杂；另一个是数据越来越多。在应对这种系统复杂度和数据体量时，单靠堆人来解决已经是不现实的了。我们必须通过机器学习、数据分析，训练以机器“人”的智慧，让部分运维场景具备自主决策的能力，最终达到尽可能无人值守的状态。

题外话，互联网技术日新月异、层出不穷，参考 CNCF Cloud Native Landscape，技术人想要跟上行业的步伐，可以发力的方向还是很多的。

以上是第一部分内容，关于运维相关的一些背景知识简介。

2.AI 中的确定性

接下来我们展开第二部分内容，AI 中的确定性；

涉及到 AI 和机器学习算法，相信大部分人可能会望而却步，觉得门槛高、有学习成本，或者找不到学习路线来了解。希望通过这次分享，带领大家简单的浏览下人工智能中的一些分类和问题描述，以便对人工智能有一个整体的知识轮廓。事实上，在目前 AIOps 的实践中，所涉及到的大部分算法是相对比较简单和容易理解的。

（题外话，曼德勃罗特集是一个非常有趣的分形图，来自数学的一个分支。从事人工智能、机器学习，一般都会需要比较扎实的数学基础。当然，从事互联网计算机技术行业，学好数学也是非常有帮助的。）

日常中我们经常可以听到人工智能、机器学习、深度学习这几个词，从图中的包含关系，可以比较清晰的看到人工智能所涉及的范围更广，主要是用来逼近“人”的智慧，就目前的研究看还没没有能超出人类的智慧。通俗一点，从字面意义上理解就是人工 + 智能、用人工换智能，付出多少人工换取多少智能。

要实践好人工智能，是有条件的。这里我们引用了中国科学院长张钹院士的观点，也是清华裴丹教授多次引用的观点，随着 AIOps 的深入实践，我们也是非常赞同这些观点。有充足的数据或知识是实践 AI 的原材料；完全信息要求样本空间可以表征整体数据空间；Well-defined 需要问题描述清晰、输入输出明确；可预测性要求场景演进遵循物理规律，这样模型才可以具备解释性；单领域比如语音识别、图像识别、围棋等应用场景。

接下来我们介绍下：实践 AIOps 可能会使用到的 AI 知识背景和框架；

如何了解机器学习，我们比较推荐大家沿着 scikit-learn 算法工具包的数据处理路线进行学习，这里边包含了很多具体的算法和样例，包括有监督式的和无监督式的。机器学习从功能上划分类别，主要包括：有监督的分类算法、无监督的聚类算法、数据回归模型算法、以及用来处理数据压缩的降维算法。

深度学习的原理主要基于人工神经网络，通过训练数据来拟合一个黑盒函数，因为模型的网络结构或网络层次比较厚，故而被称作是深度学习。

在模型训练的时候，需要定义清楚学习目标和代价函数；在学习过程中为了使代价函数变小，需要选择合适的优化策略，比如梯度下降类的优化算法。深度学习一般以监督式学习和半监督式的强化学习为主，当网络神经元数量足够多、足够大的时候，模型可以携带的智慧就越多。

自然语言处理也是实践 AIOps 过程中会使用到的算法领域，比如从日志或者文本中提取关键实体信息，在 ChatOps 智能机器人对话中识别用户意图。中文切词、词性标注、语言生成、文本分类、信息检索、信息抽取、人机问答、机器翻译、自动摘要等是自然语言处理主要解决的问题。

最后要介绍的，也是 AIOps 实践应用中使用最多的算法领域，时间序列处理。时序分析在金融、气候变化、地质勘探等众多场景也是有广泛的应用。时间序列处理最核心的问题是预测，预测一般指趋势预测。这里要提一下的是，大部分时序算法都是在数据统计特性满足弱平稳性假设的前提下发挥作用的，这点很重要。时间序列分析方法包括时间域分析和频率域分析两种，统计学一般基于时间域分析，而信号处理更多是基于频率域。

前面绍了人工智能中的算法框架，希望可以为大家构筑一个大致的轮廓。在实际使用中，这些能力已经被写入到了开源的算法工具包之中，例如我们在表格中罗列的这些算法工具。工作中，一般只要定义清楚需要处理的问题之后，按照工具包的要求加工数据集，调用对应的算法，就可以便捷地使用到 AI 能力。当然，很多时候可能还要涉及一堆调参问题，就需要花精力学习专业知识了。

如何让 AI 更好地产出确定性、更好地发挥效果，以便管理好用户预期，我们思考总结了几点建议，供大家参考下：清楚地描述场景问题，定义明确的输入、输出。有什么、要什么，这很关键；尽可能构建或选择解释性良好的模型，避免黑盒逻辑；效果不理想的时候，一定要好好分析数据，最好事前就做好充足的数据分析；最后一条就是不能太盲目崇拜 AI，以免期待过高。

3.AIOps 场景适用性分析

前面铺垫了许多，把 AI 跟 OPS 这两个词拆开来解读，希望可以带给大家不一样的收获和启发。

第三部分我们来介绍：关于 AIOps 场景的适用性分析。

通过前面运维和 AI 的背景知识分享，这里我们要提出的适用性观点是：让 AI 产出可以支撑运维决策和驱动运维演进的数据，这样的跨领域搭配才是有意义的。比如我们罗列的这些典型运维场景，也是行业分享中比较多见的典型场景。

此外，我们把 AIOps 实践的典型场景提炼和抽象成了一种范式，为成功实践 AIOps 提供指导和参考。

在挑选运维场景时，必须有明确定义出的问题，要做什么、解决什么，以及达成什么样的效果，有垂直领域完备的专家知识，还有很重要的一点是场景的数字化能力，通过数字化描述问题和表征问题；

然后针对数字化场景，设计算法输入输出接口、选择合适的算法模型，根据过往的历史数据训练模型参数，将算法调优达到预期效果后进行投产，在运行过程中持续收集有效反馈，以此迭代更新算法自身的演进，形成良性的人机闭环；

因为直接使用原始场景数据不能达成运维目的，所以经过算法框架加工过的数据必须是形成了某种“智慧”，可以是辅助运维决策、或是为后续执行提供输入，从更高的层次，也可以是为架构的演进提供数据驱动力。

接下来跟大家分享下 AIOps 中实践最为广泛的几个应用，为了突出重点内容，我们会以原理性介绍为主。首先是异常检测，从统计视角，异常检测是通过统计学原理发现存在样本集中的离群点或野值。抽象地解释，异常检测的过程就是将实际观测和预期目标之间的差异和判定阈值做比对，如果差异超出了预期的阈值，则识别为异常，反之，则视为正常。这样一来，我们就可以把异常检测抽象为两个核心问题：预测和检验。

时序的预测问题可以理解为基于时刻之前的数据来预测时刻或者未来一段时间的趋势。一般在弱平稳性假定下，对时间序列分析和预测的常见算法包括：ARIMA、指数平滑、STL 分解、频域分析、RNN、LSTM 等。预测的本质是希望从历史数据中提取出规律性和确定性，以此来做数据外推和预期管理。AIOps 实践中，在成本、质量、效率、稳定性的很多运维场景中，也是需要具备数据预测的能力。

基于统计原理的异常检验算法，一般需要对样本集(残差时间序列)的分布做出假设或限定，比如大数定理下的正太分布。在构建统计量后，根据假设检验原理，选择一定的显著性水平，拒绝原假设或者接受备择假设。常见的异常判断准则和算法包括：3sigma 准则，又叫做拉依达准则、箱体图法、Grubbs 检验、Dixon 检验、t 检验等。

图中展示了通过预测+检验方式发现异常的效果：一种是动态阈值的效果；一种是由观测数据 - 预测数据构成的残差序列做归一化变换所得到的时间序列。从数学上来看，两种发现机制本质上是等效的，都是极大的提升了阈值设定的泛化能力。

除异常检测外，故障定位也是 AIOps 实践的一个重要方向。系统发生故障在所难免，如何在预警发生之后快速地定位出故障域和故障根因是后续采取止损措施的关键。故障定位主要是挖掘事件和事件之间的关联程度，基于相对统一的规则进行打分；同时基于专家经验推理因果关系。从相对通用的定位思路出发，我们依次跟大家分享一些常用的定位策略和相关性打分机制。

形态相关性定位顾名思义，用来检验不同时序形状上的相似程度，一般是需要序列长度和时间点对齐，主要使用皮尔逊相关系数计算，因为计算结果的归一化特点，非常适合做关联打分，另外余弦距离也可以是备选的策略。

在故障定位中，我们经常需要为异常发生的时间点和某个运维操作事件的关联性打分，以时间间隔作为自变量，设计经验函数，比如随着时间间隔地增加，分数线性递减、指数递减、或开关式递减等。在大多数情况下，我们会选用类似 Sigmoid 函数的柔性开关式打分策略。相比二值开关，这种方式可以精细化地区分候选项事件的关联程度。

稍微复杂一点的场景中，比如多维错误时序的异常检测结合时间相关性判断时，在对多维度打分结果做数据融合时，可以采用调和平均分数据综合。

基于领域知识构建服务依赖相关性定位，侧重点在于定位故障链上的传导。依赖相关性定位需要能够提前梳理好系统的上下游依赖、系统的拓扑结构等知识。例如，K8S 资源调度系统具有非常高的复杂度，在如此复杂的系统中想要能够快速定位出故障根因，必须梳理清楚不同组件之间的调用关系和依赖。一旦系统发生预警，顺着故障可能传播的路径就可以相对容易地定位出问题的根源。

空间相关性定位更多的是从物理拓扑的视角挖掘故障域信息。需要利用应用或系统的元数据描述故障定位时的下钻方向，这些资产数据一般被定义在 CMDB 或 PaaS 中，例如机房信息、机柜机架编排信息、网络设备和布线信息、物理服务器和网卡信息，再到具体应用或系统部署信息等。为了更加高效的使用这些资产拓扑信息，在做故障定位时，一般将这些信息存储在图数据中，借助图算法的多样化查询检索能力，快速关联聚合故障实体，以此确定故障域。

历史相关性定位基于对以往的故障数据提炼加工、构建故障知识库，通过异常特征匹配和检索找到故障根因。构建故障知识库是一个精细又漫长的过程，需要垂直领域的专家经验沉淀，将历史的故障信息和原因归类梳理，形成故障手册，算法侧需要将对应故障手册的经验数据抽象和建模，通过特征工程构建知识库。通过历史相关性实施故障定位，本质上属于概率推理，即贝叶斯原理，基于历史数据计算的先验概率(比如，某类运维操作下发生故障的频次等)，求解最大化后验概率的条件。这种方案的难点主要在于样本数据(覆盖比较齐全的故障数据)的收集需要很长的时间，以及需要非常专业的领域知识梳理。

以上就是这部分要分享的主要内容，针对 AI 赋能 OPS 的一些适用性思考和总结。AIOps 是跨领域技术的应用，正式引入和落地的时候，需要运维、算法、开发、产品等多方对齐认知，避免用户需求漂移和能力供给失衡，从这个视角看，复合型的行业人才是比较稀缺的。另外，选择场景实践 AIOps 时，做好充分的背景调研和效果推演，避免简单问题复杂化了，造成投入产出比不高。

4.基于 SLO 精耕细作、创造价值

最后一章跟大家分享的内容是蚂蚁基础设施在 SLO 健康度体系和框架下的实践内容。通过精细化投入，构建高价值的数据资产，然后结合 AI 能力，更好的赋能运维场景，让 AIOps 的落地更成体系化。

蚂蚁的基础设施侧存在众多的异构系统，被上层的业务应用和服务所依赖。考虑到不同系统的技术栈、架构、部署等因素，我们需要找到一种通用的、泛化性强的数字化方案指导和构建基础设施域内的健康度体系。基于这样的客观现状，我们开启了蚂蚁基础设施域内从 0 到 1 的 SLO 健康度体系建设和实践。

实践 SLO，概括下就是在相对标准、统一的框架下指导和推动服务质量的数字化建设，形成对组织有价值的数据资产和流程。前面我们也提到过，算法的上限受限于数据质量的好坏，所以从源头上建设高质量的数据非常重要。

介绍 SLO 体系，绕不过这三个概念，SLI、SLO 和 SLA。

SLI：选取服务性能相关的 Metric 构造具有普遍解释性的可以度量服务质量的时间序列指标；

SLO：针对 SLI 的过往表现和历史数据分析，声明服务在一定统计窗口内的目标值，即为 SLI 设置阈值，例如为某个服务的月度成功率设置为 99.99%；

SLA：为了约束服务方对于 SLO 承诺的履行效果，制定出的奖惩措施和免责声明。例如，大部分云服务厂商都会对其售卖的云产品和服务声明 SLO，同时绑定相应的 SLA，公示和声明当服务不达标时会采取什么样的补偿方案。

针对精加工过的 SLO 数据和传统监控的 Metric 数据，我们从不同维度进行了一些对比。整体而言，在大规模场景运维下，SLO 是具有明显的优势。对比但不搞对立，两种不同层次的观测性侧重点不同，相互补充：SRE 日常可以重点关注在服务 SLO 相关的监控。而系统级的 Metric 指标可以用来发现、定位服务器实体粒度上的一些故障，现代互联网架构大都具备高可用方案，一旦系统级监控发现故障，可以通过 AIOps 的自愈能力，直接完成故障实体的替换。

基于 SLO 的健康度体系具备很多优势，然而所有的提升都是需要代价的，在建设 SLO 过程当中也需要更多地投入，这也意味着我们迈进了精细化运维的阶段。从整体上看，我们把 SLO 的健康度体系分成了 4 层结构: 最下层是目标系统的运行层，是提供服务的对象实体，包括基础设施域内所有提供服务的应用和系统；其上是 SLO 的数据层，数据层包括 SLI 数据收集、SLO 数据加工、数据展示、SLO 元数据建模、数据清洗、以及常见分析的数据抽取等；再之上是基于 SLO 数据的场景分析处理能力层，包括基于场景的更高级的数据分析能力、异常检测、故障发现、故障定位、预案关联、以及相关产品建设等能力；最上层则是基于场景能力划分的应用层，用于数据通晒的 SLO 健康度大盘、健康度应急流水线、辅助计价和成本分摊等应用，赋能到质量、效率、稳定性、成本等具体场景中去。

为了更好地利用 SLO 数据，以 Prometheus 中的数据模型为例，我们先简单了解下时间序列的格式。Prometheus 属于单值数据模型的时间序列数据库，其 Metric 由时间戳、监控数值及标签组构成。SLO 数据形式上也是一个加工过的多维标签的时间序列数据。

为了使得依赖相关性定位变得更加通用，结合 SLO 数据，我们定义了一些扩展概念。Prometheus 的数据模型，一条 SLO 数据是由时间戳、监控数值和众多的维度标签构成，每一组标签即可代表该条数据某个维度的归属，也是该条 SLO 数据被分解的方向，于是我们引了服务水平影响因子(Service Level Factor，SLF)。在构建 SLO 数据的过程中，我们将可能会影响到服务水平的维度注入到 SLO 数据中，以便在 SLO 序列预警的时候，遵循相关的维度对异常进行下钻，从而定位出故障信息。

受限于单条 SLO 数据所能携带的维度信息量有限，以及维度信息过多会导致异常下钻时需要遍历地笛卡尔积空间过大，会导致大量的算力消耗，以至于影响定位效率。针对这些问题，在 SLF 基础上，我们又拓展了服务水平依赖(Service Level Dependencies, SLD)，将相关的 SLO 数据集或监控集作为某一个 SLO 的依赖项，用来构建可能的故障传播路径。在依赖相关性定位时，不同的 SLO 或监控指标之间可以通过共同的维度传递下钻信息，以此挖掘出潜藏在上下游系统中更多的异常信息。

数据通晒是 SRE 常态化的运营机制，通过定期采集并计算不同粒度的 SLO 数据和达标结果，SLO 质量大盘按照产品集将相关的服务归类后，把相同产品集下不同粒度 SLO 的达标结果直观的呈现出来。如下图表所示，我们提供了月度视角、周视角、以及天视角来展示 SLO 的运行结果和达标情况，红色的表格代表了在对应的时间窗口内，该产品集存在部分 SLO 不达标的情况，通过颜色区分，直观明了。同时，SLO 质量大盘还和故障定位、周月报告等运营机制打通，提升了数字大盘的分析透视能力、交互体验和驱动力。

当 SLO 产生预警时，会根据 SLO 配置中的告警优先级，选择不同的通知方式进行投递。例如低优先级的告警，只推送告警信息到相应的钉钉应急群；而高优先级的告警除了推送到钉钉应急群外，还会通过电话外呼值班 SRE 及时关注处理。应急完成后，一个重要的步骤是需要对告警的有效性进行打标，以便日后的统计分析、以及优化。

在 SLO 预警之后，相应的故障定位流程就会被激活，按照前面介绍的相关性定位方法，以此实现异常下钻和根据归类。一般的，故障定位报告包括：故障域信息(异常 SLF 和 SLD)和根因信息(大部分情况下，故障都是由某个具体的变更引起)。为了更加清晰地呈现出故障报告内容，我们也实现了桌面端的拓扑图展示，通过钉钉消息卡片的链接跳转过去。为了获得更多的定位结果反馈信息，在 UI 侧增加更全面的反馈选项，这些反馈信息可以帮助定位能力更好地优化和演进。

当完成故障定位的分析后，结合垂直领域的专业知识设计的智能索引，将匹配到的最佳预案自动推送给应急值班 SRE，每种预案都对应了相应的故障恢复操作，值班人员通过 ChatOps 的交互能力或外链跳转完成预案执行。为了证实预案操作后有效与否，最直接的方式是观察 SLO 告警是否恢复，以及借助异常检测能力自动检验 SLO 是否恢复到正常水平。