什么是智能运维的最后一公里?

运维
既然使用单一技术很难解决复杂场景中的自动化运维的问题,那么结合这些技术的长处,使用鸡尾酒疗法能否解决这个问题呢?似乎这是目前我能够想到的比较好的解决方案吧。

AIOPS概念被提出的时候,人们对此是寄予厚望的,因为传统运维已经进了死胡同,走不通也无法掉头。智能化运维的愿景被设计出来了,似乎是无所不能的,可以解决几乎所有的传统运维问题。不过在AIOPS落地的时候发现实际场景的复杂性远远超出预期,很多看似很高大上的算法与智能化系统都很难解决用户遇到的问题。

最近和一个客户讨论AIOPS在大型数据库这种复杂度很高的IT基础设施上如何能真正实现,因为他也觉得他所见的AIOPS场景都是十分简单的,肉眼都可见的问题,而对于复杂一些的数据库问题,并没有见到特别有效的AIOPS解决方案。一些AIOPS表现出不错效果的场景,即使不使用AIOPS,以他们传统的技术手段可以轻松解决,而那些传统手段解决不了的问题,AIOPS似乎也束手无策。这就带来一个问题,AIOPS不是完全没用,在某些场景确实可以适当减少人力投入,但是又不明显,实施起来投入也很大。在这种情况下,是不是要投入巨资去实施AIOPS呢?对此我也一直在思考,今天和大家一起来探讨一下这个问题。

这些年做运维自动化的感受是,AIOPS的上游是数据与指标,下游是定位到具体原因的运维知识。做AIOPS的人往往都不大看得起指标,他们认为算法可以解决一切数据质量的问题,因此没有必要在指标的质量上去花太多工夫,实际上目前做AIOPS的企业也缺乏做运维数据质量方面的专家,在这方面是天然存在缺陷的。

我想可能有这样想法的人都没做过复杂系统的运维,或者来自于运维数据质量已经相当好的大型互联网企业吧,在这些企业里上游数据质量问题根本不需要做AIOPS的人去考虑。因此他们对算法充满了迷一样的自信,而对运维经验不屑一顾,认为那是传统运维时代的产物。

实际上指标与运维经验是运维知识中的精华,上周四与一些电网自动化的朋友相遇,他们的观点是数据,指标,规则,自动处置,故障自愈是一条十分优秀的流程链。把问题的内在原因分析清楚了,就可以知道该如何自动处置,实现自愈。然后再往前推,找到定位问题的方法以及所依赖的指标集,再把这些指标精准地采集回来,那么一个复杂的问题就用自动化的方法解决掉了。再对这些方法做适度的泛化,就可以将一个自动化控制的方法适配到更广泛的场景中了。

这个工作方法对于做AIOPS的人来说似乎很LOW,似乎已经过时了。确实,这种方法在自动化领域也全无新意,已经有上百年的历史了,在很多工业控制领域都被广泛应用。与信息化不同的是,自动化专业这些年里一直在把这些知识变成自动化装置,已经形成了体系化的行业解决方案和理论体系。在这种积累下,做什么项目都可以充分利用几十年来积累下来的标准件,从而实现稳定的技术迭代。而在信息化领域,这些知识往往只能不完整地沉淀在一些书籍中,能够开箱即用的标准件少之又少,无法广泛覆盖运维的常用场景。

在IT运维领域,将运维经验做成标准件难度极高,成本巨大,因此大家对能够不需要这种积累,天生具有普适泛化能力的AIOPS寄予厚望,认为这才是运维的未来。

可惜的是,这种完全依赖算法的泛化分析能力并不一定适合用于在复杂系统中做精准定位。比如说前几天我遇到的那个因为expression tracking的采集而引发的Oracle数据库的library cache pin/lock的问题,如果没有去采集相关的指标,那么我们如何知道问题存在呢?如果采集了library cache pin相关的指标,但是不知道Oracle library cache pin的内在原理,如何将指标存在的异常与这个问题点关联起来呢?从我们这些年做AIOPS的经验来看,摒弃高质量的指标是不可取的做法,特别对于复杂度较高的系统而言,指标质量越高,对算法的泛化分析而言就越有价值。

图片图片


智能化算法在运维自动化中是十分关键的基础能力,除了泛化分析的算法外,在AIOPS中,指标异常检测更需要智能化的算法加持。通过智能化算法生成“智能指标”,再利用这些智能指标通过传统的表达式构建较为精准的模型,是智能化算法与传统运维知识极为有效的融合点,这种方法在AIOPS方向上解决了更精准的推理收敛问题,在运维自动化上解决了规则无法泛化的问题。

目前大家已经十分认可智能化算法在普适场景的泛化分析上的有效性,但是对于其问题收敛的程度与收敛结果的准确性存在一定的疑问。而基于大模型的推理也天生具有泛化推理的能力,在推理结果的有效性方面,基于大模型的推理甚至会高于很多AIOPS的算法模型。

图片图片


我现在就经常使用GPT 4.0来帮我分析一些运维故障,推理问题的根因。对于非ZERO SHOT的问题,大模型推理的能力已经相当强悍,在很多情况下,已经完全能够替代人类专家了。前阵子我在文章中也介绍过一个利用GPT4.0分析一个十分复杂的PostgreSQL执行计划的案例。不过基于大模型的推理往往存在幻觉问题,这个问题暂时无解,因此基于大模型的推理也只能用于辅助,不能直接用于运维自动化中的重大决策。

既然使用单一技术很难解决复杂场景中的自动化运维的问题,那么结合这些技术的长处,使用鸡尾酒疗法能否解决这个问题呢?似乎这是目前我能够想到的比较好的解决方案吧。

图片图片

上面是我最近一直在思考的智能化分析引擎的未来模型,这个模型会结合专家系统、智能化运维系统、AIGC三种不同的技术框架来完成一个具体的分析任务。为了实现三者能够协同工作,指标化是核心。整个过程中,需要构建一套通用的“国际语言”,让多种分析引擎能够综合利用共同分析的结果。在这张图中,我们可以看到,基于知识自动化的“运维知识点诊断”是确认诊断结果的最后一个环节。无论前面采用什么方法进行泛化、分析、归纳、抽象。最终必须通过十分确定的“自动化诊断”,才能确定问题,得到结论。AIOPS的最后一公里是“运维知识自动化”。



责任编辑:武晓燕 来源: 白鳝的洞穴
相关推荐

2015-04-23 10:30:42

华为

2022-07-29 09:03:17

AIOPS运维工具

2022-07-26 07:35:30

数据库HTAP系统

2015-12-11 10:46:01

2017-02-21 13:30:42

数据网络终端

2017-02-21 12:30:21

数据中心智能终端网络

2011-12-25 20:54:57

移动支付

2012-09-24 15:07:09

云ERP恩信科技云应用

2022-04-19 08:09:11

PON光纤网络

2017-11-03 15:24:23

双十一无人机快递

2015-11-03 13:55:44

物联网最后一公里

2017-09-04 16:49:25

2014-09-28 10:00:38

2009-09-07 11:47:22

无线交换机

2018-01-12 05:13:35

2019-12-16 09:33:08

浪潮

2012-04-24 10:29:10

VDSL2光接入

2017-11-27 08:54:43

数据信息化智能

2017-11-22 17:41:17

商业智能企业数据
点赞
收藏

51CTO技术栈公众号