【云驻共创】数字化转型时代，运维人员会失业吗？

一 背景

在数字化转型的时代，无论是电信运维或是IT运维，都面临这非常大的挑战，传统人工、工具化运维已经不能满足网络新需求，智能化转型的需求迫在眉睫。

如今，AIOps已经成为智能化运维转型的核心手段，通过构建电信领域AIOps平台能力，快速实现智能运维升级，那么在这种背景下，运维人员会在新的浪潮中失业吗？

二 需求挑战

1.1 CT电信领域 新技术、新挑战、呼唤高度智能典型网络

以5G为代表的新技术为人民的生活带了了诸多便利，例如：大链接，低时延。

但是也带了了复杂性，例如：

新老技术的共同存在，网络的复杂度非常高，四世同堂的技术并存；

新需求：企业融入生产，对网络要求非常高，网络可靠性要求高；

成本压力：运维成本高，能耗高。

1.2 IT领域，数字化转型时代，传统运维面临挑战

数字化转型时代，传统运维也面临巨大挑战，IT领域无论从硬件和软件规模，微服务领域都非常复杂，利用数据演进过程：

人工查询。

基于规则的运维。

大数据如何进行处理，成为挑战。

1.3 AI是提升电信网络自动化和智能化的关键技术

应对于大数据和挑战，如果利用AI提升电信网络自动化和智能化进程。

通过AI降低运维成本：

基站节能：在空闲的时段下，载波关闭，LSTM神经网络降低能耗。

核心网KPI异常检测：故障TOP原因为DNS解析失败，运营商的提前五个钟头发生故障提前报告，避免影响高峰用户体验。

故障识别及根因定位：无线基站网，重复派单问题，引发派单告警风暴，通过根因定位，使得故障收敛，快速定位问题并解决。

1.4 AI应用的阻碍

AI很好，那么运维人员会失业吗？AI应用的主要障碍：

1.4.1 模型

企业成熟度：人员技能，数据范围或质量，治理或各种顾虑；

恐惧未知：理解增益和用途，安全或隐私顾虑，衡量价值；

寻找起点：寻找用例，制定策略；

厂商策略：集成复杂度。

1.4.2 华为经验

AI应用开发门槛高

缺乏AI算法开发人员；

业务于算法结合难（算法和业务结合），运维人员排斥。

业务人员学习算法。

高质量数据收集难

工程化开发要求高

AI应用开放周期长

单一AI技术无法满足企业诉求，效果难体现，流程编排难度大。

运维人员需要人工编码开放不同场景的AI应用，耗时耗力。

三 华为AIOps服务

目的：降低AI应用开放门槛，

底层：数据管理，采集，拓扑管理

原子能力：预测，检测，诊断，识别，每种原子能力都是经过过实际检验

框架编排能力：框架，流程

开箱即用APP：行业AI应用。

华为AIOps服务的三大能力价值可以总结为：

一是，支持通用数据源。支持Kafka、数据库、文件系统、Restful 等运维系统的主流数据对接方式，让数据上的来。采用数据治理SDK方式，将异构数据（时序数据、非结构化数据、文本数据等）治理成AIOps 原子能力标准输入数据，有效解决数据适配问题。

二是，有丰富的AIOps 原子能力。运维领域AI模型和算法具有开发门槛高，开发周期长的特点，重复开发公共能力，造成资源浪费。华为通过沉淀核心AI资产，采用自主研发+生态合作相结合的方式，提供数字化基础组件，提高AI应用开发效率，降低AI开发门槛。通过行业知识与AI算法融合，优化和自研AI算法，内置电信领域业务模型参数，支持设计态的泛化，运行态的调优。此外，华为AIOps服务 原子能力模型统一标准，使得原子能力可串接。

三是，场景组合编排与DevOps。通过编排能力，不需要写代码，只需可视化的拖拽式编排，降低AI快速开发应用的门槛。

2.1 多场景数据采集治理，提升数据开发效率

设备不同，数据格式，接口不同，

丰富的数据采集能力：

高效数据治理能力：

智能辅助数据标注能力：

2.2 20+原子能力覆盖预测、检测、诊断、识别等网络运维场景

四大场景：

目标：不仅仅是算法的实现，而是通过实际经验的优选。华为专家的经验融入其中，并支出开放能力。

2.3 零编码场景化流程编排，支持合作伙伴低门槛快速开放AI应用

AIOps提供零编码流程编排能力，针对不同场景，可视化拖拽式编排，大幅提升运维人员AI应用开发效率。

2.4 前台灵活编排，大屏按需定制，运维效果实时可视

轻松搭建可视化大屏，业务结果快速呈现，满足项目复杂需求，有效提升运维管理效率。

2.5 RPA助理AIOps对接现有运维系统

故障恢复，RPA（机器人流程自动化）完成跨系统数据对接，数据搬运，工单发放，消息通知等，提升企业运维效率。

工单系统对接

自恢复

问题单

2.6 10+开箱即用APP，支持快速部署

KPI异常检测APP，5步实现告警预警，覆盖全场景，灵活部署，开发生态。

四 AIOps SAAS监控监控

4.1 微服务架构下的故障

问题：

故障特征

微服务通过调用关系和共享基础设施相互影响，常常多个微服务同时故障。

故障发出异常实际，数据量大，信息少。

故障处理思路

多模态数据异常检测，发现异常事件

疆同一故障触发异常事件聚合在一起

如有多个异常微服务，进行故障定界，找出根因微服务

对根因微服务，进行故障定位，找出故障根因

对接故障处理流程，进行故障恢复

解决

故障根因

微服务外部

调用链传播

基础设施传播

微服务内部

软件bug

配置问题

其他

4.2 典型场景：SaaS从故障发现道根因定位

对象：云服务

指标：接口

数据：多种数据，多模态数据

流程：采集数据->对接->提取->异常检测->汇聚识别->根因定界->故障诊断

4.3 高精度，融合多种KPI智能检测算法，可致辞10万+同时检测

KPI异常检测，整体流程如下：

全量KPI指标->属性分析->数据预处理->异常检测->异常显著度->异常告警->异常指标关

传统人工设置指标值，多个指标无法联合

4.4 大规模服务及其，海量日志实时检测，性能达40万条/秒

故障发生：

提取模版，匹配模版（事件），提取日期，事件，变量和常量。

基于实际窗内的模版判断。

推荐出异常时间窗内的top根因日志。

故障发现：日志词频，日志检测。

故障分析：异常特征，关键日志推荐，日志展示，反馈。

4.5 事件聚合

根据事件发生时间聚合，支持事件乱序到达

时间窗大小可配置

先通知，后追加机制，兼顾及时性与完整性

4.6 基于调用链的故障定界

局域调用链，定界根因微服务。

trace日志->调用链实时提取->调用链分析

4.7 故障定位

根因定位为独立原子能力，训练态与推理态合一

根因发现定位，采用随机游走

演译推理。

五 AIOps建议

5.1 AIOps部署建议-选定成熟场景，循序渐进部署AIOps

原因：

数据上不来，数据质量低下

命令下不去，缺乏自动化运维工具，不能主动检测，恢复操作

模型不智能：不能有效积累日常运维中标注信息，不能实现模型自学习

建议：

成熟场景出发，循序渐进推进部署，容错场景

数据上的来

命令下的去：对接后端工具

有效积累标注数据。

运维人员拥抱AI是大势所趋。拥抱AI，对于自身的成长进阶也有积极意义。如果坚守故土一成不变，可能会面临时代带来的新挑战。

查看活动详情：https://bbs.huaweicloud.com/blogs/281988

AI 运维

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。