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

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

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

一、现有技术

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

（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个平均值做加权，代表该月内小时级别的异常评分。

三、总结? ? ??

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