1、敏捷感知，精准决策：基于 AI 与数据驱动的通信网络智能运维实践刘裕良 研究员中国科学院自动化研究所博士，现为华为诺亚方舟实验室研究员。2016年开始参与ICT智能运维相关工作，主要从事小样本学习、数据异常检测、根因推荐、智能诊断、时空聚类、关联挖掘、预训练模型、Zero-Touch Operation等方向研究。在研究工作中提出的V-Sharpness、iRCRR、根因基、MSGR、AdaSTE等算法和框架，已成功应用到AUTIN等相关产品。具有丰富的AI算法设计、优化、落地经验，同时熟悉无线、传输、核心网的基本运维机制，理解运维语言和运维痛点。通信网络发展趋势及运维挑战通信网络未来运维模式

2、华为智能运维实践总结与展望通信网络发展趋势及运维挑战通信网络发展趋势网络运维面临的挑战网络运维转型趋势根据行业预测，未来的运维的发展趋势，将逐渐从面向网络与设备的被动式管理转型成为面向客户的预测、预防式管理，通过高度自动化的服务为客户提供自助服务的模式。而通过面向客户的并且提供预测 预防管理的智能运维模式，虽然网络环境逐渐趋向复杂与多元，但网络故障的处理时长、运维人员与人为引入故障的数量都将得到较大控制，传统的网络环境复杂度与维护成本、人数等运维的工作量之间的矛盾将得到极大缓解。引入 AI 是电信行业趋势所向Tractica 电信行业 AI 收入预测全球知名市场研究公司 Tractica/Ov

3、um 对 30 个领域近 300 个真实的 AI 使用场景进行的研究表明，电信领域在 AI 技术方面尤为积极，并且是目前最大的 AI 细分市场。根据 Tractica/Ovum 预测，到 2025 年，全球电信业对人工智能软件、硬件和服务的投资将达到 367 亿美元。其中，电信业 AI 软件市场将以 48.8%的年复合增长率从 2016 年的3.157 亿美元增至 2025年的 113 亿美元。预计至 2025 年，电信运营商主要将 AI 用于网络运营监控和管理，这方面的支出将占到电信业 AI 支出的61%通信网络未来运维模式新需求和挑战对未来运维模式的期望人工智能在电信网络运维中的作用电信网

4、络未来运维模式：人机协同运维体系迭代发展过程中人、数据、机器的角色与关系随着人工智能的技术不断成熟并在运维中扮演越来越重要的角色，推动运维管理由传统“人+流程”的运维模式转向人机协同的运维模式，人机协同的运维模式是让机器把机器学习、深度学习等人工智能算法应用于运维工具和业务系统所采集的大型数据集，并尝试模拟人类行为（如感知、分析、决策、执行等）协助运维的模式。人机协同模式让运维管理具备算法和机器学习能力，通过持续学习将运维人员从纷繁复杂的告警中解放出来、使运维变得智能化。在新的运维模式下，新技术可以赋能运营团队，以人的独特经验和判断力注入数据底座，点石成金，将数据升华为知识，并以此推动机器的学

5、习能力，形成机器自决策、自执行的闭环，打开电信网络的未来新模式的大门。新一代电信网络运维模式人机协同运维模式的演进方法华为智能运维实践华为智能运维核心能力：场景化专业能力借助于丰富的项目经验与过硬的技术能力，华为已经建立了强大的在MBB/FBB/NFV&5G 下的场景化专业能力。华为智能运维核心能力：AI 算法与数据服务能力统一 AI 算法能力，赋能场景数据赋能故障预测与管理案例介绍1：无线网络故障管理自动化1.人工总结故障树，耗时耗力，场景覆盖度仅40%，2.单棵故障树准确率70%；3.MV场景无专家经验积累，覆盖难度大。竞争力突破业务痛点1.标注工作量大，2人月/项目；2.场景仅覆盖MBB

6、；3.推理过程不可视，无参数暴露，客户无法参与1.图主题挖掘技术突破，标注工作量2人月 5人天；2.构建通用传播图，场景拓展到承载网（PTN/OTN）；3.推理过程可视智能识别（AABD Pro）人工识别-机器挖掘+无感标注智能诊断（RCF）人工总结-自主系统+场景覆盖度故障管理业务流数据采集故障识别修复&闭环故障诊断网络拓扑&资源数据实时告警历史告警训练态推理态ProAI能力支撑故障修复传播关系挖掘时空聚类根因网元识别故障传播图故障根因推断修复方案推荐智能识别智能诊断业务痛点竞争力突破基于RCF根因基模型构建浅层根因决策能力，无线接入场景覆盖率从40%提升到80%，准确率90%，支持MV。单

7、层定位多层定位问题抽象N1N3N2N4N6N5N7N1N3N2N4N6N5N7N1N3N2N4N6N5N7N1N3N2N4N6N5N7N1N3N2N4N6N5N7N1N3N2N4N6N5N7N1N3N2N4N6N5N7TT1=N1,N2,N3,N4,N5,N5,N6rcNe1=N2TT1=N1,N2,N3,N4,N5,N5rcNe1=N2TT2=N6rcNe2=N61!#!$故障定界：精准确定故障影响范围，减少工单数量，避免重复派单；故障定位：准确上报根网元，提高运维效率，避免无效上站N1N3N2N4N6N5N7业务问题：“告警太多（百万/天）了，我们一线运维工程师根本看不过来！”传统方法：告

8、警压缩，对告警进行分级处理，从而减少告警数量；这种方法需要大量人工经验，而且无法解决“群障”，因此对工单数量减少有限。问题抽象：在无人工经验的条件下确定异质图的时空边界关键发现：1、异质序列之间具有物理关联性，联合建模可以提高精度;2、在一较小邻域内发生同时发生两个故障的概率较小。以印尼XX为例：网元【10W+】，产生告警【200W+/天】，实际故障约【2W/天】业务问题：“我应该先处理上哪个站？带什么工具去？”传统方法：代维人员靠经验决定工单处理的先后顺序，重复上占率高；问题抽象：在样本极少且有错标的情况下，异质图的推理问题关键发现：1、故障的时空一致性；2、故障的传播性以印尼XX为例：工单

9、【2W/天】，其中10%需要上站，重复/错误上站20%-30%；每一单的成本【80美金】TT1=N1,N2,N3,N4,N5,N5,N6TT1=N1,N2,N3,N4,N5,N5TT2=N6!#$%!#$%!&%!&%技术挑战与解决方案解决方案：建立了故障流模型（FSM），以事件驱动的方式处理“群障”，并提出了拓扑融合方案MTF解决了空间边界的问题；提出基于异质序列变分协的等待时长预测方案VSDA以解决时间边界的问题；在少人工经验的条件下确定异质图的时空边界MSGR:解决TE黏连问题VSDA:解决时间边界问题MTF:解决空间边界问题空间边界时间边界解决方案：从可解释和小样本两条路径进行了探索：

10、1、可解释：因果推理、属性图关系挖掘、神经时序点过程挖掘2、小样本：小样本图节点分类方法；小样本根因分类；在样本极少且有错标的情况下，异质图的推理根因网元识别根因告警识别根因推断&修复建议123MetaGCN:解决有标注时的根因网元推断1AdaSTE:降低假阳性ICT-大模型:拓扑完整时的推断关系挖掘INTLA:拓扑不全的推断关系挖掘!=(%#:%!&!#()/(%#:%!&!1)2RCF:解决样本分部不均时的故障根因推断3单层定位多层定位案例介绍2：5G核心网故障管理自动化故障管理业务流 网络产品多：5GC云化网络涉及VNF、CloudOS层（VM、FS、E9000）、网络层（交换机、TOR

11、）、存储（磁阵、硬盘）等多种产品，产品之间可采用近10种组网方式，每种产品又涉及几十个组件设备（如右图所示）运维经验少：5GC建网时间短，客户积累的运维经验少，跨层故障发生时不知如何应对 定界时间长：5GC故障现象涉及的设备和数据多，需要人工结合拓扑进行关联分析定界，时间花费长，是当前客户运维Top痛点业务指标倒换隔离根因推荐智能关联智能定界CHR日志运行日志设备告警网络拓扑KPI检测CHR检测日志检测时空汇聚(通用)模糊匹配数据采集多维关联与定界业务恢复异常检测定位闭环深层诊断问题抽象异常检测：对多种不同类型数据进行实时快速检测故障定界：准确推荐根因设备，支撑后续隔离倒换，快速恢复业务多维关

12、联：将多种数据业务准确关联，生成一个故障事件UDMAMFPCFAUSFAFUPFSMF业务层垂直层SMF-VM1SMF-VM2SMF-VM3PCF-VM3PCF-VM2PCF-VM1性能时序运行日志CHR日志CHRError code小区终端号段Sip statusRelease NET-TORST-TORM-TORDisk0Host0Disk1Host2Host1M-HostvDisk0vDisk1Disk2vDisk2VM2VM1VM0异常设备正常设备Host1 Host2Host3Host4现有解决方案异常检测：对不同类型数据采取不同检测方法，准确率90%+故障定界：在关联基础上结合历史

13、故障先验和拓扑连接，计算子图中各节点异常得分，实现根因节点推荐，准确率75%；同时探索基于因果传播链的根因推理多维关联：文本&节点向量叠加网络拓扑，基于异常相似度进行关联匹配，关联准确率85%特征1特征2特征3特征4专家规则iI层虚拟机重启场景：特征1：分区负载监控告警特征2：服务中和服务通信故障特征3：分区过载监控特征4：节点故障Network EmbeddingAMF SMF UDM业务全阻AMF SMF到单类型网元全阻AMF SMF到单个网元连接断I层虚机故障I层主机端口异常等关联规则关联规则Word EmbeddingAMF2VM3VM4VM5S0S1S2Host1Router1故障子

14、图（有向无环）主机端口故障某主机故障的因果传播关系主机状态异常虚机故障虚机链接中断网元资源单元故障稀疏矩阵检测CHR日志运行日志模板生成与匹配性能时序动态阈值监控故障场景热门方向：基础模型https:/arxiv.org/pdf/2108.07258.pdf在2021年8月份，百余位科学家联合发文，提出了大规模预训练模型面临的基于和挑战，文中建议将预训练大模型统一称作Foundation Models，即AI基础模型/大模型。文中指出AI基础模型最典型的特征是“涌现”和“同质化”。Emergence means that the behavior of a system is implicit

15、ly induced rather than explicitly constructed;it is both the source of scientific excitement and anxiety about unanticipated consequences.Homogenization indicates the consolidation of methodologies for building machine learning systems across a wide range of applications;it provides strong leverage

16、towards many tasks but also creates single points of failure.Foundation models have led to an unprecedented level of homogenization:Almost all state-ofthe-art NLP models are now adapted from one of a few foundation models,such as BERT,RoBERTa,BART,T5,etc.ICT运维基础模型识和数据双轮驱动的电信网络维护人工智能框架。经纶运维大模型是一个“编码-

17、解码”框架下的序列数据模型，通过在正常数据上进行自监督预测学习的方式进行训练；其中的自然语言预训练模型用于生成通信原理的表征并与现网数据融合，可以独立训练，直接支撑语言序列的下游任务；借鉴预训练的思想，我们可以在“编码-解码”框架下完成预训练，而只使用编码器部分的网络作为预训练模型，为不同的下游任务（机器数据序列的预测、检测、分析等）提供融合表征作为输入。随着2/3/4/5G全融合，虚拟网元数量激增，控制面全集中，转发面全分布，虚拟化网络功能上/下线自动化程度上升，网络故障定位需要跟踪的调用环节同步上升、故障定位难度剧增。我们提出一种通信网络运维领域的机器学习大模型框架，不仅将网络运维所需要处

18、理的多种形式的数据统一在一个学习范式中，而且将网络运维中的各种任务以下游任务的形式也统一到该学习框架中。该框架也是融合知数据准备构建经纶运维大模型所需的数据分为两类：文档类数据以技术类文档为主，包括Hedex产品文档、3GPP协议文档、技术会议文档、技术博客、技术书籍等。用于构建通信领域的预训练语言模型，支持在设备数据建模过程中融合通信原理，同时支撑文本类下游任务的应用文档类数据设备数据序号来源说明样例1产品文档设备描述产品Hedex文档2协议文档基础技术文档3GPP标准、RFC（请求意见稿）3技术博客技术类帖3MS4技术会议、期刊标准来源文档ICASAP、ICC、Globecom5技术书籍标

19、准工具书CCNA、HCIA、TCP/IP详解等序号数据类型数据形式描述1Perf时间序列设备各类指标的打点计数2Alarm事件序列设备在运行过程中产生的告警信息3Debuglog结构化文本设备产生的高度日志4MML半结构化文本相关命令的输入输出5CHRToken序列CCNA、HCIA、TCP/IP详解等设备数据各类设备产生的数据，如Perf、Alarm、Debuglog、MML、CHR等。用于对经纶运维大模型的“编码-解码”框架进行训练及下游任务的验证已收集处理产品文档：无线、数通、云核、传送、接入、IT等6个产品线 共计4,714,7494,714,749个网页页面，47G47G大小（中英文

20、）解析成通用结构语料，共计17G17G（中英文）已收集处理协议文档：共计38,67138,671个协议文档，28G28G大小（英文）抽取后的逻辑文档数量为1,548,0001,548,000个，共计6.2G6.2G（英文）ICT基础模型：日志关联场景 在海量非结构化日志中，根据语义的异常找到关键日志*，并且找到上下文关联的相关日志是日志分析的核心问题。通常的，工程师能够显式的根据问题描述找到关键的异常日志，但是上下文相关联的日志查找费时费力，我们期望通过领域知识模型助力日志推荐功能，实现精准的日志关联推荐。!#$%&!#$%&PrecisionRecallF1baseline0.7450.69

21、80.707Googlebert+non-finetune0.6740.4680.548XXXX+non-finetune0.8780.6250.715Googlebert+finetune0.8430.6330.718XXXX+finetune0.8000.7010.732 我们在IT服务器日志分析场景收集了80w条日志数据，涉及42个故障场景。专家标注了少量的故障相关的日志（42个故障），并且指明现象日志（Query）。基于Pairwise的构建方法我们扩充了数据集。压缩前日志()*+,()*+,-.+,/-.+,/非相关日志对2520200901/0沙掽蟆诧蟆悪&摸

22、)BiLSTMLog 1Log 2Log 1Log 21/0ClassifierCLS/MEAN基于Siamese Network的日志关联推荐模型XX框架日志关联推荐数据集构建背景数据方法 基于模板对日志进行压缩，保留关键语义信息，屏蔽语义无关的参数信息。基于经纶大模型对语义信息生成词向量，构建如下图所示的分类模型。实验结果2022-04-09T09:55:11.279722+08:00 euler nova-api DEBUG pid:3156690 GreenThread-437 tid:70369507448976 session.py:548 _http_log_response-R

23、ESP:200 Content-Length:17665 Content-Type:application/json Date:Sat,09 Apr 2022 01:55:11 GMT Server:Apache Vary:X-Auth-Token X-Frame-Options:DENY X-Subject-Token:SHA256aa84e15fecfec1cc43a577250f7303ce240e1fb383e512e682adcfd3ab853c75 connection:close x-openstack-request-id:req-034f041a-2c0c-4356-b707

24、-76e8a4b43cca _http_log_response/usr/lib/python3.7/site-packages/keystoneauth1/session.py:548 RESP:Content-Length:Content-Type:application/json Date:Server:Apache Vary:X-Auth-Token X-Frame-Options:DENY X-Subject-Token:connection:close x-openstack-request-id:_http_log_response:日志模板精简ICT基础模型：信令分析场景当前信

25、令模型没有考虑信元的语义信息，导致不同信元之间的语义关联没有显式建模，因此信元级别的任务效果仍不理想。基于此，我们在信元表示上引入语义信息，同时借助专业文档训练的预训练语言模型进一步提升语义的表达能力。当前使用的token信息：#消息:50547#信元:599446实际的语义信息：#消息：sip.CSeq.method,SUBSCRIBE,#信元：sip.P-Access-Network-Info.access-type:3GPP-NR-TDD,sip.contact.uri|e164.msisdn|e164.country_code:86，.h1hi-1x1,1xi-1,1Informati

26、on Element-Level AttentionTOKEN POSITION ENCODING.firstmessage.Information Element-Level AttentionlastmessageMESSAGE POSITION ENCODINGMessage-Level Attentionx1,nxi-1,n.xi,1.Decoder Attentioncurrentmessagexi,j-1Softmaxxi,jPOOLINGPOOLINGTOKEN EMBEDDINGSEMANTIC EMBEDDINGBERT CLS Information Element Exp

27、lanationCLS Information Element ExplanationBERT CLS Information Element ExplanationBERT CLS Information Element ExplanationBERT CLS Information Element ExplanationBERT CLS Information Element ExplanationBERT SHAREBasic ModelSense Unit实验方案实验数据实验结果模型/指标TOP1 PRECISIONMAPNDCGBaseline23.0829.4869.28+Goog

28、le Bert26.9231.8972.25+运维大模型42.3134.474.47ICT基础模型：MO场景FinetuneFinetune样本数：25774；正样本：12887；负样本：12887；其中10%用来测试；90%用来训练；Finetune过程中，测试集最高准确率98.175%；Domain覆盖：无线、传输、动环、RNG-2G、RNG-3G、RNG-4G、MW、POWER、RAN；Vendor：高新兴、艾默生、烽火、大唐、华为、爱立信、阿尔卡特朗讯、铁塔、中兴力维、中兴、诺基亚、ZTE、ERICSSON、CISCO、NEC、HUAWEI；ValidationAABDPRO挖掘得到的

29、传播关系：304条；挖掘过程中不使用方向先验(r002)；专家标注Y：56 -挖掘正确，方向正确F：53 -关联正确，推断方向错误（相反）N：195 -关联错误，告警间无关系Domain：传输网、动环、无线接入网；Vendor：华为、XX；生成验证数据 验证数据生成后会与Finetune数据去重，保证验证用的数据是模型“没见过”的；因为不同厂家对同一种Domain描述有差异，所以分成Domain对齐和未对齐两种场景。FinetunedModelUnfinetunedModelCurrent Method（bow）Y_F89.908%(98/109)85.321%(93/109)48.624%Y

30、_F_reverse87.156%(95/109)82.569%(90/109)48.624%Y_F_vendor_domain_aligned96.970%(64/66)96.970%(64/66)48.624%验证数据一：Y_F 取Y和F类型的数据；数据大小：109条验证数据二：Y_F_reverse 取Y和F类型的数据 对所有数据反向，即把alarm1-alarm2;变成alarm2-alarm1;数据大小：109条验证数据三：Y_F_vendor_domain_aligned 取Y和F类型的数据；将”传输网”修改为“传输”；“无线接入网”修改为“无线”；与finetune对齐；数据大小

31、：66条总结与展望CT网络与IT网络的差异电信网络IT数据中心CTIT网络体系3G,4G,5G,TCP/IP设备类型BSC,RNC,MME,HSS,eNB,S-GW,服务器，路由器/交换机连接方式线缆，无线线缆设备分布室内+室外（分散式）室内机房（集中式）应用分布用户与设备强耦合应用与设备弱耦合/解耦商业模式运行商：购买设备，少量自营业务=设备厂商负责运维，运行商开权限、提诉求设备、业务都归IT公司所有=主人与保姆同体CT网络运维 VS IT网络运维CTIT数据收集链条长，限制多，挑战大，成本高（室外设备：天气，人为破坏，）代价较小数据预处理标准化低=依赖领域/厂商知识标准化高=易实现数据标定

32、设备关联，数据关联=工作量大工作量较小AI基础技术不存在本质差别（异常检测、深度学习、在线学习、强化学习，预训练）用户诉求诉求高实时性要求不高、对运维效果感知较弱验证测试上线周期长，实测成本高易上线测试，试错成本低可复制性差强展望随着5G网络商用进展的不断推进，以及AI与电信网络运维的深度融合，华为的人机协同智能运维解决方案使运维从“人拉肩扛”走向“自动化和智能化”。通过技能转型使运维人员向数据分析师、网络策略师和应用编排师转型，把专家经验总结的规则、AI 模型封装成运维流程资产及运维认知资产注入智能运维平台；智能运维平台能够基于这些资产实现智能运维，通过这种人机协同的运维模式，华为智能运维解决方案能够打破运维资源随设备线性增长的定律，利用自动化减少人为失误，提升运维效率；基于 AI 技术实现网络及业务故障的预测预防，提升运维质量，从而保障超可靠的四代共生的电信网络。面向未来，华为将持续利用在产品、技术和专业服务领域的优势和经验，将更多的“主动、预测、预防”带进现实，与行业一起携手打造更健康、更具活力的电信运维生态。华为愿与运营商携手合作，在电信网络运维领域不断探索，持续创新，开放华为全球运维经验及生态，助力运营商构筑智能化运维能力，实现降低成本、提高网络质量、使能运维转型。Thanks开放运维联盟高效运维社区DevOps 时代荣誉出品