作者简介：郭宁，广东移动信息系统部运维能力建设规划专家、中国移动IT运维专家、信通院  AIOps 能力成熟度技术规范编制专家。负责广东移动业务支撑系统、管理支撑系统运维平台能力的整体规划建设。

01

1.1 广东移动的 IT 系统领域

首先介绍一下广东移动的 IT 系统领域，熟悉运营商的朋友可能会比较清楚，运营商整体的 IT 系统分为四个部分：B域、M域、 O域和S域。

• B域主要负责业务支撑系统，就是负责支撑公司的业务营销和计费账务的实现，比如你的手机去订购套餐、修改产品或是开通功能。另外手机使用语音或流量，产生的计费，也是在业务支撑系统里实现。

• M域是管理支撑系统，平时办公会用到的OA、邮箱、行政、人力资源、财务等等。

• O域是网管支撑系统，负责移动通信网络的全方位管理，包括无线网络、有线网络，都需要 IT 系统的管理和调度。

• 最后是近年来兴起的S域。主要是面向行业客户，比如企信通、校讯通、智慧城市、平安广东等等，类似于特定的政企客户所开发的 IT 系统。

而本文要介绍的 AIOps 应用，主要是在 B 域和 M 域的系统。

1.2 当前重点运维对象

02

2.1 我们对 AIOps 的研究历程

2019年，广东移动开展了 AIOps 的场景预研，2020年重点选取了部分运维痛点场景进行建设。根据集团下发的第一期 AIOps 白皮书，选取了异常检测、根因分析、告警收敛、智能知识库等 27 个对象的场景落地，这个阶段我们也初步具备了 AIOps 的算力+算法+知识图谱的框架。

2021年，在2020年的基础上进一步地去扩展生产对象和丰富场景，做了三个扩充：

• 扩充对象：之前的异常检测主要针对主机，2021 年进一步扩充到了中间件/数据库/网络等领域。

• 扩充场景：前期重点建设质量与效率提升，2021 年重点做了成本管理方面的 AIOps 场景，比如主机资源的优化提升，数据库存储的智能成本优化等。

• 扩充联动：将相关场景进行一个串联，形成更复杂的关联性 AIOps 闭环场景。

这一期建设了52个对象场景，打造了像故障诊断、知识管理联动等高阶场景。随着数据对象及场景的丰富，这个时期形成了算力+算法+数据的框架。

2022年，进行了集团下发的自动驾驶模型的对标优化，将每一个场景都在 5 个维度——感知、分析、决策、执行、知识更新——进行分析，通过维度去评判它的实现方式。

将 5 个维度和 4 个实现方式综合起来进行评判，得到场景自动驾驶模型水平，根据这个模型对已有场景进行优化提升，平均达到了 L3 的水平，这个阶段就形成了算力+算法+数据+知识图谱的框架。

2.2 日常面临的运维痛点

接下来说几个具体场景，主要针对四大运维难题：

• 监控的阈值设置难：如果大量的监控点通过模板进行设置，精准度不一定能够匹配，如果对每个监控点进行人工分析处理，所花费人工成本又很高昂。所以对于传统固定阈值监控点的设置方式有点难。

• 系统变更风险高：我们知道系统最危险都是出现在变更第二天，特别是版本发布后第二天，个个如临大敌，系统变更风险从来就是一个亘古不变的道理。

• 处理故障效率低：现在系统架构越来越复杂，横向节点扩充快，纵向节点  IaaS 层、 PaaS 层、 SaaS 层分工也越来越精细，每一层都可能由专门的专家去分析情况。如果系统出现故障，需要把不同的团队召集并进行综合的评判。

• 一线投诉处理慢：广东移动是国内最大的省级运营商，IT 投诉工单量始终位居前列，IT 投诉处理人员数量不足，对于一线，怎样去提升 IT 投诉工单的处理时效也是一个难题。

针对四大难题，广东移动引入了4个对应的 AIOps 能力。在监控管理方面应用了“智能异常检测”。

在变更管理方面应用了“智能变更评估”。在故障管理方面应用了“智能故障诊断”。在投诉管理方面应用了“智能运维机器人”。

2.3 最广泛最成熟：智能异常检测

在 AIOps 里应用最广泛、最成熟的就是异常检测了，现在大家如果用 AIOps，第一个入门的场景也必定是异常检测。

目前广东移动的智能异常检测已经扩展到了 20 类生产资源，100 多种指标，覆盖了 90 多个系统， 13000 多个监控点，查全率98%，查准率93%，整体比人工的误告警下降35%。

异常检测模型有三个环节，首先会根据历史数据去进行数据特征的聚类，以此来判断监控点属于的数据特征（波动特征/周期特征/趋势特征），然后根据不同的数据特征选择对应的算法，最后将监控点的异常检测模型进入到模型库。实时数据去匹配模型库判断它是否有异常。告警处理人员觉得这个异常点是准确的就处理它，如果不准确就会做标注，检测结果的标注也会反馈到异常检测模型库里，去进行一个系统的自动迭代。

智能异常检测模型的特点是首先会实现指标的聚类，它不是每一个监控点都会去训练模型，而是把相同数据特征的指标进行聚类并共用一个模型，好处就是低算力消耗和实现多种异常模式的识别。它还能实现模型迭代自优化，根据告警处理人员的反馈去对这个模型去进行一个自我迭代。

这套模型应用到主机/中间件/应用/业务集群等等生产对象上，最便利还是主机相关的异常检测指标，只要数据连续性、指标规律性较好，异常检测模型是应用的效果是最佳的。

2.4 控制易失控的事：智能变更评估

Google SRE 研究表明， 70% 的生产事故都是由变更触发的，移动业务支撑系统也不例外，大部分故障其实都在变更之后，那怎样通过 AIOps 去减缓变更的风险，我们主要是从两个方向：

第一、变更前做评估，主要是从变更单的几个要素里抽取。根据 ITIL 流程，需要变更单去做相应的流程管控，变更单里有变更系统、变更耗时、变更对象、变更的操作类型等。抽取这些相关要素带入业务图谱里，找到变更所涉及的业务、关联对象、关联的资源，变更关联的监控点，形成一个变更前的评估报告。

这个评估报告里包含影响的业务等级、风险类型、关联对象、关联监控点等等。拿到变更前的报告可以据此做针对性保障，这样在某种程度上可以提前管控变更的相关风险。

这里有最关键的两个点：

• 第一是变更单的规范

• 第二是业务图谱是否全面

这两个点如果做好了，这个变更前评估才能做得好。

第二、变更后评估，系统在变更后自动触发变更后评估。比如变更时间是从凌晨 1 点到 6 点结束，6 点以后去触发变更后评估。

变更后评估的内容就是本次变更涉及到的监控点，变更对象相应的监控要素统一由变更后评估去进行变更前和变更后的比对。

这个评估报告包括评估概要、变更信息及评估详情，还有相应的变更指标图表。比对方式可以是时间序列的异常检测，也可以是离群异常检测。

整体来说通过这两个层面去控制变更风险。2022 年我们整体触发了智能变更评估的次数是 102 次，102 次主要指的是日常的版本发布，有效规避了 28 次变更风险。

2.5 王冠上的宝石：智能故障诊断

智能故障诊断可以说是 AIOps 王冠上的宝石。我们应用了 2 代的智能故障诊断模型。

第一代是比较初始化也是比较经典的时间聚类算法，然后通过 CMDB 关系图谱里的关联挖掘算法，找到相应的告警根因。我们应用后发现效果并不是太明显，升级了第二代。

第二代模型有了质的飞跃，输入的数据相对丰富，包含日志、告警、 KPI 指标、性能指标、调用链、资产等，几乎囊括了所有运维相关的数据。

拿到数据后第一步进入异常感知，从数据里挖掘出对应的异常点，形成异常事件集；第二步故障识别，从异常事件集里去找到对应的异常对象，从对象的维度去分析对象是否发生异常，然后将这些异常对象排列出来进行层次挖掘，形成了故障知识图谱。

故障知识图谱将所有有关联的异常对象进行串联，然后进入故障诊断，找到根源是在哪里？根因分析方法用的是 FP growth 和有向图随机游走，去找到故障知识图谱里最原始的异常点。知识图谱还会辅助知识推理，最终得到根因。

2.6 为故障定位带来捷径：智能故障诊断

故障卡片代表的是某个具体故障。现在只需要关注每一张故障卡片，通过故障卡片下钻发现故障图谱情况。如果发现不对，可以改变这个图谱之间的连线。

左下角是模型里的四个环节，每个环节的可视化呈现。我们落地 AIOps 最怕就是不知道这个东西是怎么得来的，每个分析环节结论是怎么样的，很希望把每一个重点关键的分析步骤做到可视化呈现。

最后它还可以关联故障解决方案，比如去匹配历史的故障，匹配运维专家手工添加这种方案，或者操作来自动触发故障解决预案。

在故障诊断方面，目前广东移动已完成 B 域和 M 域核心系统的接入，包括性能、业务、告警、日志等四大类在内的 3500 种指标项，纳管的资源 5000 多项，每天处理的指标数据 300 多万条。统计这个模型，它的故障诊断准确率是89%，通过这套模型的使用，运维成本降低了80%，故障处理的效能提升了62%。同时这一套故障诊断模型也是国内首个通过信通院评估根因分析模块的模型。

2.7 面向一线赋能：智能运维机器人

投诉管理智能运维机器人主要面向一线进行赋能。广东移动 IT 工单投诉流程大体上是由各个地市公司进行预处理，处理不了的它通过事件单/数据修改单的形式发送到省侧的二线团队。

我们的系统是在省侧管理，一线运维团队不能及时知道省侧系统的变更要素。出现这种情况，一线团队的 IT 工单投诉很大程度上转换成了二线的投诉工单，一线自己能处理的很少，造成 IT 工单投诉时延。

我们现在 IT 工单投诉一般流转至少需要 36 个小时，在 36 个小时流转程度下很难满足一线客户投诉要求，所以我们必须把投诉能力往前移。那么我们就基于运维知识图谱开发了智能运维机器人。

智能运维机器人主要提供三大块的能力：

• 智能问答能力：为一线人员查找故障案例、故障处理方案、相应的需求概设文档及业务文档等，都是可以通过智能问答能力查找出来，可能大家会有疑问，文档的时效性怎么样？这套东西一线和二线团队共用，所以时效性不会存在任何问题。

• 智能工单推荐能力：一线运维人员收到了投诉内容以后，把投诉内容输入到智能工单推荐就可以推荐出对应的历史发生故障情况，可以从这里选择跟本次投诉性质比较像的工单参考。

• 智能修复能力：查找完智能工单后会给出一个故障应该在哪个菜单进行的处理，你可以直接通过一键式智能修复把这个号码输进去，只要一键式的操作就能够在系统后台自动完成系统号码修复。避免了一线运维人员权限上的控制问题。

智能运维机器人的应用效果还是比较明显，智能问答推荐每月有 3. 6 万次，减少了 1. 5 万张事件单，每年能节约人力成本大概是 500 万，操作执行是 9. 6万次。

数据修改单是 1. 9 万张，每年节约人力成本是 700 多万元。以某千万级用户级别的地市为例，现在 IT 投诉工单的平均处理时长缩短了90%。

2.8 AIOps 推广应用价值

广东移动整体应用 AIOps 模型的效成比较显著，它减少了人力成本的投入。测算了每年人力成本减少上千万，告警处理时间下降了75%，故障平均发现时长缩短了50%， IT 投诉处理时长缩短了 93. 5%，工单的流转效率提升了 66. 7%，智能问答的降单率降单了29.1%。

03

3.1 AIOps 应用推广之 “TRL” 方法

我给 AIOps 应用推广总结了一个 “TRL” 方法。首先 AIOps 建设从来就不是立竿见影的，它不像运维自动化或监控，一上去就马上能呈现效果。

AIOps 需要大量对模型的调测、演进甚至改进优化的过程，成本是非常高的。

像今年比较流行的 ChatGPT，这个算法已经出来很多年了，为什么到今年才爆发？其实是一个量变到质变的过程，等量到达了一定程度以后，AI 的能力才能够发挥出来效用。

• T 就是 Target：是指要有目标、有计划、有协同地去做这件事情。要明确推广的目标和计划，就是 AIOps 场景特点是什么？它能够解决现实什么的运维痛点，它具体的推广目标到底想达到什么程度以及落地的时间计划，这些都要非常明确，把它确定下来。
  

• 第二在推广过程中要建立团队分工协同机制，AIOps 场景应用可能涉及到不同团队、不同部门之间协调配合，每个团队之间要做什么事情？这个分工要明确，可以通过周报月会的形式进行推动，我们是每两周针对运维能力 AIOps 的推广去进行落地复盘会议，把所有的问题都摆出来，然后进行持续的迭代。

• R 就是 review ：要滚动量化推广效果。首先必须要构建一个推广效果评估指标。我们每一个 AIOps 的场景最好都能找到一个量化的指标去做一个评判。比如异常检测，你可以去定义它的覆盖率、查全率、查准率。故障诊断，你可以定一个指标，就是它的诊断的准确性。有了指标以后，我们会把它形成一个整体的月报，这个月报能够去横向地比较指标的运转的趋势，是向好还是向差的。

• 第二重点场景是专项分析推广效果。什么叫重点场景？就是异常检测、故障诊断这些应用非常广泛的，推广的使用者非常多的场景我们是需要进行专题分析，内容包含了它的指标项、使用效果及相应的参数调优和后续优化计划，这些都是属于重点场景的专题分析。

• L 就是 limit：强化运维操作管控。首先优化运维工作量结构，转变运维人员的思维。有很多运维团队的思维还是习惯从后台主机进行操作。这个方式跟后续运维的发展方向其实是有冲突的，所以去引导运维人员尽量通过自动化、智能化的工具平台去实现运维工作。

• 第二管控运维后台登录账号，每位合作伙伴最多给 10 个后台登录账号，剩下的运维工作必须通过新一代数字运维平台相关模块去进行，因为我们是属于一个外包程度相对较高的公司，不同的合作伙伴，有点像半强制的要求他们必须通过运维平台进行操作。然后我们还会定期去统计每一个运维团队后台账号使用情况。

3.2 运维平台建设规划之“分合”原则

我个人简单地将广东移动运维平台发展历程分成了三个纪元：乱纪元-恒纪元-中心纪元。

乱纪元是我刚接手的时候，各种各样大小的运维工具非常多，各种各样同质化的运维平台也同时存在。这都是由一些历史的遗留问题所导致的，它们之间的功能又是交叉的，他们的使用的项目团队又不统一，所以这个是乱纪元。

怎样去处理？我定义了一个分合原则。第一，分就是要明确分工界限，我们要把每个平台、每个相应的运维工具的分工界限给梳理出来。合就是把同质能力合并，两个平台之间的能力差不多，我们把它合在一起。怎么合呢？保留好的，去掉差的，或者说你的工具脚本能不能编撰在我的运维平台里面，去通过一个平台去实现这个能力。

通过这个原则，现在已经进入到恒纪元——现在的新一代数字化运维管理平台。它主要是由 9 大模块组成，它的统一入口都在 IT 网管，由 IT 网管去串接容器智慧运维平台、流程平台、日志平台、数据库管理平台、自动化测试平台以及知识图谱，所有的运维相关场景都必须在这个框架内去实现。

未来的演进方向还有中心纪元，希望在未来把它演进成四个中心：

端到端可观测中心、智能决策中心、运维数据中心、自动化操作中心这四大中心是构成中心纪元的关键。

其中最关键的是运维数据中心，它要把其他相关的运维平台数据统一汇聚到运维数据中心，然后再由智能决策中心去连接运维数据中心和自动化操作中心，去进行 AIOps 场景的应用。最后统一入口都在端到端可观测中心，可以通过端到端可观测中心去监控、查看、进行操作等。

04

我们还在不断探索尝试应用各种 AlOps 场景…

我们也在寻求应用效果不错的 AlOps 场景…

我们也期盼交流新技术、新理念在运维中的应用，例如元宇宙、ChatGPT。

怎么样去将新的技术、概念应用到运维的领域里，其实也是我们非常感兴趣的一个话题。

05