云卷云舒:大型电信运营商应用软件健康度评估方法

2024-01-07 22:19:37

????????大型电信运营商内均会自建云资源池,并基于云资源池构建自己上层应用软件资源,但是各类上层应用软件的故障频发也给运维工作带来了较大的压力,电信运营商急需一种较完善的方法实现对于应用软件的健康度评测,以进一步指导运维完成应急预案的制定。

? ? ? ? 这也是智能运维的最基础的一部分。

一、现有技术

目前,针对于应用软件的健康度的评测的方法一般包括如下几种:

(1)最简单的方案下,通过各类应用软件发生的故障数据来进行评估的,具体通过应用软件故障的数量进行评估的,应用软件故障数量越多评分越低,应用软件健康度则越高;

(2)在(1)的基础之上,将应用软件故障进行了细分,提出了应用软件故障级别的概念,级别越高扣分越多,通过加权实现总体得分,得分越低,应用软件健康度则越高。

(3)在应用软件评分周期上,采取利用过去一定时间(如一个月)的应用软件故障数据进行评分,每间隔相对更短的一定时间(如一天)进行评分滚动更新。

二、当前技术问题分析

????????现有技术(1)中,简单通过应用软件故障的数量进行应用软件健康度的评估,输入影响参数单一,必然存在着准确性低的问题;

?????????相比技术(1),不同的是技术(2)对于应用软件故障做了级别的细分,介入通过加权的方法实现得分的评估,其实仍然停留在应用软件故障的个数这一单一因素上,且故障判别均通过固定阈值方式开展,对于实际指标值大于极端阈值(如内存使用率大于90%)时判别为故障,判别准确性得不到保证;另外,该方案没有考虑到应用软件故障集中度的因素,因为故障分布分散,侧面代表应用软件异常的快速恢复,这也是应用软件性能的一个重要参考因素;另外应用软件故障在生产过程中是很少发生的,一般每月的应用软件故障数也不会超过5个,即样本数量过少,导致评分根本无法保证,很大概率下每月的应用软件评分都是100分满分,应用软件的故障预期效果得不到保证。

????????技术(3)内的评分周期一般均较长,其实这使得应用软件的短期故障被淹没,如两个应用软件一个月内均发生30起故障,但是应用软件的故障集中和较分散属性,并没有体现出来,我们认为应用软件的短期故障,即集中式的应用软件故障相对于分散的故障来说是更严重的,理应评分越低。

三、本文提出的方案

? ? ? ? ?本文方案架构如下图:

?

根据上图所示,系统架构和工作流程图描述如下:

1、系统架构

分为三个模块:

  • 故障数据收集模块;
  • 小时级健康度评分模块;
  • 迭代评分模块。

2、系统工作流程

  • 故障数据收集模块:每小时针对小时内每一分钟是否为异常点进行判别,通过异常检测算法ARIMA算法进行;得出小时内60个分钟的异常数据数组;
  • 小时级健康度评分模块:针对一个小时内的所有异常,从异常个数特性识别模块和异常集中性识别特性两个方面评分,得出该小时的健康度,健康度级别可分为健康/轻微/一般/中等/严重五个级别:

总分数=异常个数特性得分(50分)+异常集中特性得分(50分)

评分标准如下:

  1. 如果发生异常20处及以上,或10处及以上的连续异常分钟,健康度级别判定为严重;扣30分
  2. 如果发生异常10处及以上不足20处,或5处以上10处以下的连续异常分钟,健康度级别判定为中等;扣20分
  3. 如果发生异常5处及以上不足10处,或大于0且小于5处以下的连续异常分钟,健康度级别判定为一般;扣10分
  4. 如果发生异常0处以上且5处以下,且无连续异常分钟,健康度级别判定为轻微;扣5分
  5. 如果无异常,健康度级别判定为健康。不扣分

示例:如果一个小时内的60个分钟的异常分布如下:

分种

异常与否

分种

异常与否

分种

异常与否

分种

异常与否

0

异常

15

30

45

1

16

31

46

2

异常

17

异常

32

异常

47

3

18

33

48

4

异常

19

异常

34

49

5

异常

20

35

50

6

异常

21

36

51

7

异常

22

37

52

8

异常

23

异常

38

53

9

异常

24

异常

39

异常

54

10

异常

25

40

异常

55

11

异常

26

异常

41

56

12

异常

27

42

57

13

28

43

58

14

29

44

59

上图内异常个数为19,健康度级别判定为中等,扣分20分,异常个数特性得分30分;

上图内连续异常个数为10,健康度级别判定为严重,扣分30分, 异常集中特性得分20分;

小时级评分=30+20=50分。

????????通过上述例子可以看出,小时内异常总数为19个,评级为中等;但是异常比较集中,连续异常达到了10处,代表着应用软件的异常恢复能力较差,所以评级为严重;体现出了该算法充分考虑到了更多的因素,评分会相比传统更加准确和全面。

3、迭代评分模块

????????针对过去一个月(固定为30天)内每一个小时级(共30x24=720个小时)的评分做出加权计算,具体计算逻辑如下:

????????30天的数据距离当前时间越近越具备较大的参考价值,应该给予较大的权重,本文内每间隔6天变更一次权重,权重分配参考二进制递进的原则,即1/2,1/4,1/8,1/16,1/32.由于每月共30天,具体权重做了微调,保证权重总和为1,具体的权重分配如下:

  • 第1个6天权重为w1=15/30;
  • 第2个6天权重为w2=8/30;
  • 第3个6天权重为w3=4/30;
  • 第4个6天权重为w4=2/30;
  • 第5个6天权重为w5=1/30;

?最后得出应用软件健康度评估的总分数:

????????其中score?of?144hours代表着第n个6天共144个小时的评分数组,具体规则:

????????分别计算出每个6天(共144=24*6小时)的小时级别平均值,然后将一个月30天内,共5个平均值做加权,代表该月内小时级别的异常评分。

三、总结? ? ??

????????该架构体系,对于电信运营商应用软件的健康度评估,综合了传统健康度评估的思想,通过引入人工智能技术实现故障前异常数据的识别,扩充了评测的样本,避免了传统评分体系中故障样本不足的弊端,同时经过滚动迭代计算评分,并根据距离当前时间远近设置不同的权重来进行综合评分,整体上考虑到了更多的因素,包括空间和时间的双重因素,准确度更高,更具有说服力。

文章来源:https://blog.csdn.net/bishenghua/article/details/135394280
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。