大型电信运营商内均会自建云资源池，并基于云资源池构建自己上层应用软件资源，但是各类上层应用软件的故障频发也给运维工作带来了较大的压力，电信运营商急需一种较完善的方法实现对于应用软件的健康度评测，以进一步指导运维完成应急预案的制定。
这也是智能运维的最基础的一部分。
一、现有技术
目前，针对于应用软件的健康度的评测的方法一般包括如下几种：
（1）最简单的方案下，通过各类应用软件发生的故障数据来进行评估的，具体通过应用软件故障的数量进行评估的，应用软件故障数量越多评分越低，应用软件健康度则越高；
（2）在（1）的基础之上，将应用软件故障进行了细分，提出了应用软件故障级别的概念，级别越高扣分越多，通过加权实现总体得分，得分越低，应用软件健康度则越高。
（3）在应用软件评分周期上，采取利用过去一定时间（如一个月）的应用软件故障数据进行评分，每间隔相对更短的一定时间（如一天）进行评分滚动更新。
二、当前技术问题分析
现有技术（1）中，简单通过应用软件故障的数量进行应用软件健康度的评估，输入影响参数单一，必然存在着准确性低的问题；
相比技术（1），不同的是技术（2）对于应用软件故障做了级别的细分，介入通过加权的方法实现得分的评估，其实仍然停留在应用软件故障的个数这一单一因素上，且故障判别均通过固定阈值方式开展，对于实际指标值大于极端阈值（如内存使用率大于90%）时判别为故障，判别准确性得不到保证；另外，该方案没有考虑到应用软件故障集中度的因素，因为故障分布分散，侧面代表应用软件异常的快速恢复，这也是应用软件性能的一个重要参考因素；另外应用软件故障在生产过程中是很少发生的，一般每月的应用软件故障数也不会超过5个，即样本数量过少，导致评分根本无法保证，很大概率下每月的应用软件评分都是100分满分，应用软件的故障预期效果得不到保证。
技术（3）内的评分周期一般均较长，其实这使得应用软件的短期故障被淹没，如两个应用软件一个月内均发生30起故障，但是应用软件的故障集中和较分散属性，并没有体现出来，我们认为应用软件的短期故障，即集中式的应用软件故障相对于分散的故障来说是更严重的，理应评分越低。
三、本文提出的方案
本文方案架构如下图：
根据上图所示，系统架构和工作流程图描述如下：
1、系统架构
分为三个模块：
- 故障数据收集模块；
- 小时级健康度评分模块；
- 迭代评分模块。
2、系统工作流程
- 故障数据收集模块：每小时针对小时内每一分钟是否为异常点进行判别，通过异常检测算法ARIMA算法进行；得出小时内60个分钟的异常数据数组；
- 小时级健康度评分模块：针对一个小时内的所有异常，从异常个数特性识别模块和异常集中性识别特性两个方面评分，得出该小时的健康度，健康度级别可分为健康/轻微/一般/中等/严重五个级别：
总分数=异常个数特性得分（50分）+异常集中特性得分（50分）
评分标准如下：
- 如果发生异常20处及以上，或10处及以上的连续异常分钟，健康度级别判定为严重；扣30分
- 如果发生异常10处及以上不足20处，或5处以上10处以下的连续异常分钟，健康度级别判定为中等；扣20分
- 如果发生异常5处及以上不足10处，或大于0且小于5处以下的连续异常分钟，健康度级别判定为一般；扣10分
- 如果发生异常0处以上且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个平均值做加权，代表该月内小时级别的异常评分。
三、总结
该架构体系，对于电信运营商应用软件的健康度评估，综合了传统健康度评估的思想，通过引入人工智能技术实现故障前异常数据的识别，扩充了评测的样本，避免了传统评分体系中故障样本不足的弊端，同时经过滚动迭代计算评分，并根据距离当前时间远近设置不同的权重来进行综合评分，整体上考虑到了更多的因素，包括空间和时间的双重因素，准确度更高，更具有说服力。
)
