月均调用AI模型10亿次：中国移动信息技术中心集中化 AIOps 是如何建设的？

admin 10 月 17, 2023 228 0

本文根据演讲者在 GOPS 2023·深圳站演讲整理而成，如有图文不妥，请以视频为准。更多精彩，请关注高效运维公众号。

陈理华，中国移动信息技术中心广州业务支撑中心资深专家。

本文将分享集中化 AIOps 的建设经验和心得。内容从以下5个方面展开，首先，将简要介绍团队负责的 AIOps 规划、建设和实施。其次，将介绍在落地 AIOps 过程中遇到的一些挑战和问题。然后，将说明采取的解决方法。最后，将分享一个案例，并探讨 AIOps 的理解和展望。

中国移动信息技术中心集中化 AIOps 介绍

我们团队负责集中化 AIOps 的落地，总体的目标是助力中国移动数字化转型。初心是借 AIOps 帮助运维运维人员发现故障、抢通业务。另一个是系统没有故障时帮助运维人员从繁琐的工作中抽身出来，去做一些更有价值的工作。

基于以上的目的和初心，我们从大的方向规划，参考 AIOps 白皮书中的质量保障、效率提升和成本管理等5大方向，建立了8大能力维度和33个场景能力。

通过近四年实践下来发现，其中有些场景跟我们预期的效果存在差距，因此我们将重心放在了与生产运维最相关的9个场景中。由于我们团队主要负责省 CRM /BOSS 系统，这9个场景与之紧密相关并且其能力已经得到验证。

同时，为了充分发挥 AIOps 场景的能力，需要将多个场景联动起来协作，实现多场景的协同。这就意味着我们需要充分发挥每个场景的能力，把它们组合起来，以赋能生产上的运维场景。

目前，我们已经将所有场景平台化，并且全部承载在 IT 智能决策平台上。这个平台现在作为运维人员的第二个工作台，主要有两点作用：一是实时感知系统的运行状态，判断其是否正常运行；二是系统出现异常后，调用平台上承载的故障发现、异常检测和故障诊断能力，并启动故障治愈流程，完成联动智能决策。

经过几年的实践打磨，这些能力已经在运维的工作中得到应用，他们使用过程中会提出问题，AI专家根据这些问题打磨模型、优化效果。

作为中国移动智慧中台的一个能力，我们模型调用量已经超过十亿次/每月，AI模型已经达到了五万+，日均分析日志量化达到一次40TB以上。

以某个具体系统的数据来看，我们取得了故障发现、故障定界、故障恢复和运维服务质量等方面的显著提升。对于 CRM/ BOSS 的运维人员来说，投诉工单处理是非常重要的一项任务。现在处理一张投诉工单只需要6个小时左右，相比22年前的平均数值而言，没有使用 AIOps 能力时，处理一张投诉工单可能需要10个小时左右。效率就是生命，时间就是金钱，对于运维人员来说同样如此。

我们团队在四年的时间里经历了三个阶段。

第一阶段：在2019年底，当时 AIOps 非常热门，我们的团队非常兴奋，因为我们跟很多厂商同行沟通，他们都想和我们一起做 AIOps。虽然有些同行夸大了AIOps 的效果，但我们仍然对这个技术充满信心，因此我们的团队非常努力地推进这个项目。
第二阶段：我们做了一年之后，我们发现这个东西跟我们当初预期的有差距。第一，它的效果跟19年某些同行吹捧的差距较大。第二，在实施的过程中遇到了很多具体的挑战和问题。有什么具体问题和挑战？待会举几个例子和大家分享。

那个时候（20年底-21年初），我们比较迷茫，因为这个东西投了这么多精力和时间，却没有看到预期效果出来。我们团队也开始怀疑自己的能力和方向，是不是技术上和管理上没做到位等等。但是面对这种情况，我们没有退缩，没有逃避问题。我们针对每一个具体的问题和挑战都把它拉出来，一个一个解决，最终找到了相应的举措来解决这些问题。
第三阶段：到 22 年底，包括今年在内，现在面对 AIOps 的心态非常平和，因为我们已经经历了所有建设 AIOps 过程中的困难和挑战。我们现在对 AIOps 的定义以及未来三至五年的发展方向都比较清楚。

由异常检测能力建设运营引出的挑战

作为运维人员，必须回到 AIOps 的本质，即它的作用是什么。标准的机器学习流程范式包括问题描述、数据收集等9个方面，在实际生产过程中，我们也遇到了一些困难和挑战，想和大家分享一下。

我们面临的第一个挑战是异常检测。最初，我们选择异常检测作为研究方向，因为这是比较通用的场景，而且可以更快地落地和产生效果。我们在2020年初开始进行了第一阶段的研究。但是，当我们将其与标准范式进行对照时，我们发现只有四个阶段可以完全对应：问题描述、数据收集、基本模型训练和持续学习。另外五个阶段无法套用。

在系统建设过程中，我们是为了多个省建立系统，而不仅仅是一个省。因此，在开始建设时，我们以每个省为切入点进行建设。但问题来了：当在 A省落地后，如何在其他10个省复用和推广模型呢？即使在A省落地后取得了一定的效果，结论是我们经过验证，不能直接将模型复用到其他省份。

即使我们投入了很多精力和专家经验，利用AI的特点和专家的经验相结合，最终落地这个系统，也不能直接复用AI模型到其他省份，稍后我会对我们实现AI模型复用进行简单的分享。

基于业务故障管控的运维优化实践

我认为第一步都应该是标准化处理。有了标准化才能进行流程化操作，才能进行自动化处理，自动化处理完成后，才进行智能化处理。

如果自动化都做不到，你就不能直接通过AI去实现智能化。我们的范式包括10个步骤，其中数据接入评估、精召率过滤编排和负样本反馈这三个流程阶段需要专家经验介入处理，其他流程则可以通过AI算法直接实现。

特别是在数据接入评估这一块，我们做了大量实验，发现数据质量的高低决定了后续的效果。如果数据质量很差，想要直接通过AI去弥补数据质量缺陷，我认为很难。

我们在数据接入时对周期性和非周期性的数据都做了要求，并对数据的连续性进行了要求。因此，我们首先要将这个流程标准化，在数据治理和数据接入方面做出严格的要求，这是我们的第一个应对措施。

第二点，我们摒弃了业界 PPT 或公开文章中常提及的观点，因为在我们实际的实现中，我们放弃了追求检测结果的准确性，认为这并没有太大意义。

为什么这样说呢？如果要追求准确性，我可能需要投入100%的精力来实现它，但结果可能只有30%，这意味着投入和回报不成比例。

此外，追求准确性的目的是什么呢？对我来说，我的系统只需要确保其稳定性。如果出现故障，它应该帮助我快速恢复服务。目前，AI 无法帮助快速恢复服务，它只能协助实现这一点。从投入和回报的角度来看，我们认为追求准确性是没有意义的。

例如某系统一天出现 10 次异常，我追求的是什么？我追求的是它能够捕获所有这 10 次异常。

我们将异常检测和后续的根因分析（实际上，我更喜欢称之为定界诊断）结合在一起。目前，我认为 AIOps 无法实现根本原因分析，它只能帮助我诊断哪个模块或节点有问题，但无法诊断为什么这个节点有问题。实际上，这仍然相当困难，因为系统非常复杂。

当检测到异常时，我会快速诊断并推荐几种可能的异常结果，然后绑定一些自己的处理策略。在这里，将其称为策略编排自动化，听起来很好，但坦白说，它主要涉及三个方面：清理磁盘、重启或切换，所有这些事情都被绑定在一起。

在这种情况下，只要出现异常，我们都有相应的处理流程来处理，并确保系统的稳定性。即使它产生了一些误报警，也没有关系，因为它会自动执行后续的流程，不会影响我们系统的稳定性。

第三，正如之前所说 AIOps 是为运维人员而设计。因此，在我们成功构建 AIOps 后，我们的第一件事就是让运维团队去使用它，包括一线和二线人员，以及技术支持人员。他们在使用过程中会遇到一些问题并向我们反馈，这样我们就可以了解如何进行改进。

因此，我们制定了一些模板和问题收集模板，以及一些标准化的异常处理流程。例如，我们建立了基于 AIOps 的故障管理流程，将各种 AIOps 能力整合到日常运维流程中，并通过实际系统异常故障来检验各项 AIOps 能力。

除了实施方案之外，我们还需要思考如何应用这个方案。我们知道，机器学习中的异常检测本质上是一个分类问题。正如之前的老师所说，我们的系统大部分时间都是稳定的，没有太多故障。

在这种情况下，常用的 ML/DL 方法并不实用。因此，我们必须摒弃教条主义，不一定非要按照书本上的方法来做，而是要回到现实，回到我们的初心。

因此，我们果断将异常检测问题转化为学习正常数据分布的问题。在这种情况下，我们有很多选择，可以使用各种统计学、距离、密度等算法。

我们将 KPI 异常检测问题的分类问题转化为以无漏报为目标。同时，我们采用理论与实践相结合的方式来评估模型的性能，并从数据拟合、数据走势、业务异常率三个维度来优化模型。

例如，在数据引流方面，我们建立了 MSE（均方误差）和 RMSE（均方根误差）等评价指标；在数据走势偏差方面，我们使用了平均绝对百分比误差和中位绝对百分比误差等指标。异常检测能力必须进行效果量化监控，但不能依赖标注训练模型。我们的评估指标旨在降低数据分布拟合误差，并同时保证较低的业务异常率。

最后，我们需要评估 AIOps 对运维人员的帮助，并了解他们在使用我们产品时使用哪些指标进行评价和反馈。就像评估老师的授课一样，我们需要进行调查问卷，例如列出 10 个评价指标，每个指标打分等，以获取运维人员的反馈。因此，我们设计了一个基于 AI、告警和 AIOps 运营等方面的 14 个子指标的调查问卷，以评估整个 AIOps 的性能。

典型案例分析

接下来，我想分享一下 AIOps 在 2022 年为运维人员提供了哪些价值。以某系统为例，在 2022 年，AIOps 帮助我们发现了 20 个异常，其中有 10 个异常是传统的 BMC（告警系统）没有发现的。

这些异常中有些是由于技术原因导致 BMC 无法告警，有些则是 BMC 不擅长告警。另外 10 个异常传统 BMC 有告警，但是我们的 AIOps 异常检测比传统 BMC 的告警时间平均快了 6 分钟。

通过这些具体的案例，证明了 AI 专家、AI 团队和 OPS 团队协作是可行的。但是，这需要大量的运维专家经验。也就是说，AI 模型的优势+专家经验制定的规则，二者相结合才能真正赋能于运维。

此外，需要将多个场景协同起来，而不仅仅是关注某一个场景。我们必须将这些场景与生产运维场景相匹配。

举个例子，如果生产环境出现故障，我们需要将故障响应、故障发现、故障诊断、定位和抢通整合起来。

分享一个具体案例，2022年 7 月遇到的一个真实故障。当时，很多接口服务都超时了。现在大部分服务都是微服务架构，某个接口服务异常很容易形成雪崩效应。我们知道告警只是现象，当系统出现问题后，一个告警会引发很多其他告警，即所谓的告警风暴。但是我们的 AIOps 可以针对告警风暴进行收敛。

这是 7 月份 AIOps 捕捉到的异常。在发现异常后，我们的诊断系统会与异常检测系统进行联动，然后进行诊断。根据我们的诊断结果，最终定位到一个服务节点存在异常。具体来说，当我们的服务调用外围平台时，由于外围平台发生故障，导致我们的业务受到影响。这是 AI 发现并帮助我们进行诊断的结果。

然而，正如之前所述，它只能诊断出哪个节点出了问题，但通常情况下无法确定节点为什么会出问题。尽管如此，对我来说，只要它能帮助我进行诊断就足够了。

就好比森林里有 1 万棵树，其中有 5 棵树出现了问题。如果我亲自去找，从 1 万棵树中找出这 5 棵树是很困难的。但是 AI 诊断可以快速地帮助我找到这 5 棵树中有哪些生病了，然后将它们围起来，以防病毒传播到其他树上。

当然事后，我们会请专家对 AI 的诊断结果进行验证，以确保其准确性。我们进行了一次全流程跟踪分析，最终发现 AI 的诊断结果与专家经验得出的结果一致。此外，我们还进行了时间轴分析，发现 AI 在当天 23:38 就捕获了异常，并在短短 2 分钟内得出了诊断结果。

经过实际观测，专家经验发现问题的时间比 AI 晚。此外，由于系统过于复杂，每个工作岗位的分工非常细化，因此出现故障后需要多个人协同处理，包括应用维护、数据库维护、中间件和云原生等相关人员。专家经验花了将近半个小时来排查问题。从发现问题到定位问题的时间来看，AI 比专家经验快得多。

通过这个案例的分享，我想告诉大家，对于需要定界并进行应用的场景，经过充分打磨的，AI 能力可以发挥重要作用。

然而，对于某些过于复杂的系统，或样本积累不足的系统，AI 可能无法进行准确的诊断。即使 AI 能够进行诊断，其推荐结果与实际结果之间的差异可能仍然很大。这是根据我们的实际结果得出的结论。

AIOps 能力建设感悟

其实，我之前的分享已大致说明了我们在 AIOps 方面的实践。从 2019 年开始，我们就与许多同行进行了沟通，参观了实验室，进行了充分的交流。

中国科学院院士张博提出了人工智能要满足 5 个条件才能做好。

第一个条件是需要充足的数据和知识；第二个条件是需要更多的信息；第三个条件是需要对日志数据进行明确定义；第四个条件是需要具备可预测性；第五个条件是需要单一领域，例如图片识别，因为在这种情况下，猫就是猫，狗就是狗，猫生病了就是猫生病了。

然而，在我们的系统中，如果某个指标出现问题，它是否能代表系统出现问题、是否会影响业务并不一定。例如，有许多指标和服务响应超时情况，但业务可能并未受到影响。这种情况下，我们的系统变得非常复杂。我们对比了咱们系统中的这 5 个条件，最终只满足了其中的 3 个。

第一个条件是需要充足的数据和知识。有些系统可能需要进行改造才能满足这一点，第二个条件是数据需要有明确定义。因此，在系统建设和架构设计的过程中，运维人员的能力和系统架构的能力需要综合考虑。运维能力不仅仅取决于运维人员的能力，还要考虑系统建设和架构设计的能力。

第三个条件是需要具备一定的周期性和可预测性等特点。虽然有些情况确实不可行，但我们在实践中发现，有些情况是可以实现的。因此，在我们的实践中，我们尝试了 33 个场景，但只重点打磨了其中的 9 个。这是因为有些场景目前还不够成熟，我们并不需要在目前不成熟的阶段追求突破。我们只需专注于那些已经成熟且有望进一步改进的场景，而那些不成熟的场景可能需要等到未来出现新技术后再进行改进。