一种服务系统风险的评分方法与流程

1.本发明属于大数据技术领域，具体涉及一种服务系统风险的评分方法。


背景技术：

2.随着微服务的流行，服务的稳定性变得越来越重要，微服务的发展和治理愈发困难和难以量化。为此，我们需要对系统的功能、性能、可靠性、稳定性等进行全方位评估，建立服务风险治理模型，对系统的运行状况进行客观、定量的综合评估，为决策层提供系统运行维护的科学依据。


技术实现要素：

3.有鉴于此，本发明提供了一种服务系统风险的评分方法，以达到对系统的功能、性能、可靠性、稳定性等进行全方位评估，对系统的运行状况进行客观、定量的综合评估，为决策层提供系统运行维护的依据的目的。
4.本发明采用的技术方案如下：
5.一种服务系统风险的评分方法，包括以下步骤：
6.步骤1：建立不同的风险等级；
7.步骤2：根据管理员历史经验以及系统的历史问题确立系统的风险来源情况，并确立不同风险来源情况对应的风险等级；
8.步骤3：根据系统所包含的各类风险等级以及单个风险等级所占的权重对系统进行打分，并根据系统的分值判断系统的健康状况。
9.作为优选的，步骤2中所述风险来源情况具体包括：变更情况、监控警告情况、性能巡检情况以及容量巡检情况。
10.作为优选的，步骤1中，所述不同的风险等级具体分为五个风险等级，一级为稍有风险，二级为一般风险，三级为显著风险，四级为高度风险，五级为极其危险。
11.作为优选的，所述步骤2中针对所述变更情况进行风险等级的确立具体包括：
12.基于同一个系统在一周之内的紧急变更次数确定风险等级，紧急变更次数越多的风险等级越高；
13.基于同一个系统一周之内的投产次数确定风险等级，投产次数越多的风险等级越高；
14.作为优选的，所述步骤2中针对所述变更情况进行风险等级的确立具体还包括：
15.基于同一个系统进行非投产窗口变更且无关联的紧急变更工单，将其判定为高度风险；
16.基于同一个投产编排，执行多次且间隔时间相差a个小时，将其判定为稍有风险。
17.作为优选的，所述步骤2中针对所述监控警告情况进行风险等级的确立具体包括：
18.b天内超过c个小时仍未关闭的错误警告，将其判定为显著风险；
19.b天内超过c个小时仍未关闭的紧急警告，将其判定为高风险。
20.作为优选的，所述步骤2中针对所述性能巡检情况进行风险等级的确立具体包括：
21.若应用在过去d天中至少e天日均占用cpu使用率超过80％，将其判定为显著风险(e《d)；
22.若应用在过去d天中至少e天日均占用磁盘io使用率超过80％，将其判定为显著风险(e《d)；
23.若与昨日相比tps峰值变化小于10％，应用致使cpu使用率增加超过20％，将其判定为显著风险；
24.若与昨日相比tps峰值变化小于10％，应用致使内存增加超过20％，将其判定为显著风险；
25.若在f小时内，数据库导致cpu使用率超过70％、数据库连接数超过70％、且数据库连接超过e分钟，则将其判定为显著风险；
26.若g天中，有h天以上因为缓存导致cpu使用率超过80％，则将其判定为显著风险；
27.若g天中，有h天以上因为缓存导致内存使用率超过80％，则将其判定为显著风险(h《g)。
28.作为优选的，所述步骤2中针对所述性能巡检情况进行风险等级的确立还包括：
29.基于昨日接口缓慢的次数确定其风险等级，缓慢次数越多，其风险等级越高。
30.作为优选的，所述步骤2中针对所述容量巡检进行风险情况等级的确立还包括：
31.在连续的i日内，若磁盘使用率持续超过80％，则将其判定为显著风险；
32.若当系统中存在debug级日志，则将其判定为为显著风险；
33.若子系统日志量单日超过10g，则将其判定为为一般风险；
34.若单条日志超过1m，则将其判定为为一般风险。
35.作为优选的，上述步骤3具体包括以步骤：
36.步骤3.1：确立每个风险等级所占的权重，具体为：稍有风险为5％、一般风险为8％、显著风险为12％、高度风险为15％、极其危险为60％；
37.步骤3.2：统计系统中所有的风险来源情况以及各个风险来源情况所对应的风险等级；
38.步骤3.3：根据步骤3.1和步骤3.2对系统进行打分，具体为：系统总分数＝100-系统所包含的各个风险等级的权重分别乘以100后的和；
39.步骤3.4：根据步骤3.3的系统总分数判定系统的健康状况，具体为：
40.当系统总分数大于等于70时，状态为健康，则系统服务风险较低；
41.当系统总分数大于等于50时，且小于70时，状态为亚健康，则系统服务风险较高；
42.当系统总分数小于50时，状态为不健康，则系统服务风险极高。
43.综上所述，由于采用了上述技术方案，本发明的有益效果是：
44.该模型基于基础运维工具和数据挖掘技术，通过对应用系统各个维度的信息数据进行有机组合，同时结合系统管理员的运维经验和事件问题总结，按照一定的权重将运维数据进行数字化，可形成应用系统在某一维度上的数值反馈。此后，再根据业务系统从变更事件、资源容量、监控环境、交易数据、网络流量、日志信息等各个维度进行综合打分，将形成一个基于应用系统运行健康度的数字画像，最终再结合实际运维经验设定各个维度权重，即可得到一个业务系统的健康度得分。最后根据此得分，判断该业务系统是否存在风
险，对风险进行量化，为下一步的服务风险治理提供数据依据。
附图说明
45.本发明将通过例子并参照附图的方式说明，其中：
46.图1是本发明的流程结构示意图；
47.图2是本发明的变更情况的结构示意图；
48.图3是本发明的监控告警的结构示意图；
49.图4是本发明的性能巡检的结构示意图；
50.图5是本发明的容量巡检的结构示意图。
具体实施方式
51.为使本发明实施方式的目的、技术方案和优点更加清楚，下面将结合本发明实施方式中的附图，对本发明实施方式中的技术方案进行清楚、完整地描述，显然，所描述的实施方式是本发明一部分实施方式，而不是全部的实施方式。通常在此处附图中描述和示出的本发明实施方式的组件可以以各种不同的配置来布置和设计。
52.因此，以下对在附图中提供的本发明的实施方式的详细描述并非旨在限制要求保护的本发明的范围，而是仅仅表示本发明的选定实施方式。基于本发明中的实施方式，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施方式，都属于本发明保护的范围。
53.需要说明的是，在不冲突的情况下，本发明中的实施方式及实施方式中的特征可以相互组合。
54.应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。
55.在本发明的描述中，需要说明的是，术语“中心”、“上”、“下”、“左”、“右”、“竖直”、“水平”、“内”、“外”等指示的方位或位置关系为基于附图所示的方位或位置关系，或者是该发明产品使用时惯常摆放的方位或位置关系，或者是本领域技术人员惯常理解的方位或位置关系，仅是为了便于描述本发明和简化描述，而不是指示或暗示所指的装置或元件必须具有特定的方位、以特定的方位构造和操作，因此不能理解为对本发明的限制。此外，术语“第一”、“第二”等仅用于区分描述，而不能理解为指示或暗示相对重要性。
56.在本发明的描述中，还需要说明的是，除非另有明确的规定和限定，术语“设置”、“安装”、“相连”、“连接”应做广义理解，例如，可以是固定连接，也可以是可拆卸连接，或一体地连接；可以是机械连接，也可以是电连接；可以是直接相连，也可以通过中间媒介间接相连，可以是两个元件内部的连通。对于本领域的普通技术人员而言，可以具体情况理解上述术语在本发明中的具体含义。
57.在本发明中，除非另有明确的规定和限定，第一特征在第二特征之“上”或之“下”可以包括第一和第二特征直接接触，也可以包括第一和第二特征不是直接接触而是通过它们之间的另外的特征接触。而且，第一特征在第二特征“之上”、“上方”和“上面”包括第一特征在第二特征正上方和斜上方，或仅仅表示第一特征水平高度高于第二特征。第一特征在第二特征“之下”、“下方”和“下面”包括第一特征在第二特征正下方和斜下方，或仅仅表示
第一特征水平高度小于第二特征。
58.需要说明的是，在不冲突的情况下，本发明中的实施方式及实施方式中的特征可以相互组合。
59.实施例
60.本发明公开了一种服务系统风险的评分方法，包括以下步骤：
61.一种服务系统风险的评分方法，包括以下步骤：
62.步骤1：建立不同的风险等级；
63.风险等级具体分为五个风险等级，一级为稍有风险(1)，二级为一般风险(2)，三级为显著风险(3)，四级为高度风险(4)，五级为极其危险(5)。
64.步骤2：根据管理员历史经验以及系统的历史问题确立系统的风险来源情况，并确立不同风险来源情况对应的风险等级；即管理员根据自身经验以及系统的历史问题，收集系统的风险来源情况；步所述风险来源情况具体包括：变更情况、监控警告情况、性能巡检情况以及容量巡检情况。
65.步骤2具体如下：
66.2.1：如图1所示，针对变更情况进行风险等级的确立，具体包括：
67.2.11：基于同一个系统在一周之内的紧急变更次数确定风险等级，紧急变更次数越多的风险等级越高，具体为：2.111：当同一个系统中，若一周之内紧急变更次数为1次，标记为显著风险；2.112：当同一个系统中，若一周之内紧急变更次数≥2次，标记为高风险；
68.2.12：基于同一个系统一周之内的投产次数确定风险等级，投产次数越多的风险等级越高；具体为：2.121：当同一个系统中，若一周之内投产次数为2次，标记为稍有风险；2.122：当同一个系统中，若一周之内投产次为3次，标记为一般风险(2):2.123：当同一个系统中，若一周之内投产次数超过3次，标记为显著风险；
69.2.13：进一步的，所述步骤2中针对所述变更情况进行风险等级的确立具体还包括：
70.2.131：基于同一个系统进行非投产窗口变更且无关联的紧急变更工单，将其判定为高度风险；
71.2.132：基于同一个投产编排，执行多次且间隔时间相差a(a＝2)个小时，将其判定为稍有风险(1)。
72.2.2：如图2所示，具体的，所述步骤2中针对所述监控警告情况进行风险等级的确立具体包括：
73.2.21：b(b＝2)天内超过c(c＝12)个小时仍未关闭的错误警告，将其判定为显著风险；
74.2.22：b(b＝2)天内超过c(c＝12)个小时仍未关闭的紧急警告，将其判定为高风险。
75.2.3：如图3所示，具体的，所述步骤2中针对所述性能巡检情况进行风险等级的确立具体包括：
76.2.31：若应用在过去d(d＝7)天中至少e(e＝4)天日均占用cpu使用率超过80％，将其判定为显著风险；
77.2.32：若应用在过去d(d＝7)天中至少e(e＝4)天日均占用磁盘io使用率超过
80％，将其判定为显著风险；
78.2.32：若与昨日相比tps峰值变化小于10％，应用致使cpu使用率增加超过20％，将其判定为显著风险；
79.2.33：若与昨日相比tps峰值变化小于10％，应用致使内存增加超过20％，将其判定为显著风险；
80.2.34：若在f(f＝24)小时内，数据库导致cpu使用率超过70％、数据库连接数超过70％、且数据库连接超过e(e＝60)分钟，则将其判定为显著风险；
81.2.35：若g(g＝14)天中，有h(h＝4)天以上因为缓存导致cpu使用率超过80％，则将其判定为显著风险；
82.2.36：若g(g＝14)天中，有h(h＝4)天以上因为缓存导致内存使用率超过80％，则将其判定为显著风险(h《g)。
83.2.37：所述步骤2中针对所述性能巡检情况进行风险等级的确立还包括：基于昨日接口缓慢的次数确定其风险等级，缓慢次数越多，其风险等级越高。具体包括：2.371：若昨日接口缓慢的次数，超过该结构总调用量的5％，则为稍有风险；2.372：若昨日接口缓慢的次数，超过该结构总调用量的10％，则为一般风险；2.373：若昨日接口缓慢的次数，超过该结构总调用量的15％，则为显著风险；2.374：若昨日接口缓慢的次数，超过该结构总调用量的20％，则为高度风险；2.375：若昨日接口缓慢的次数，超过该结构总调用量的25％，则为极其风险。
84.2.4：如图4所示，所述步骤2中针对所述容量巡检进行风险情况等级的确立还包括：
85.2.41：在连续的i(i＝3)日内，若磁盘使用率持续超过80％，则将其判定为显著风险；
86.2.42：若当系统中存在debug级日志，则将其判定为为显著风险；
87.2.43：若子系统日志量单日超过10g，则将其判定为为一般风险；
88.2.44：若单条日志超过1m，则将其判定为为一般风险。
89.当风险来源以及风险来源的等级确定之后，执行步骤3。
90.步骤3：根据系统所包含的各类风险等级以及单个风险等级所占的权重对系统进行打分，并根据系统的分值判断系统的健康状况。
91.步骤3具体包括以步骤：
92.步骤3.1：确立每个风险等级所占的权重，具体为：稍有风险为5％、一般风险为8％、显著风险为12％、高度风险为15％、极其危险为60％；
93.步骤3.2：并统计系统中所有的风险来源情况以及各个风险来源情况所对应的风险等级；
94.步骤3.3：根据步骤3.1和步骤3.2对系统进行打分，具体为：系统总分数＝100-系统所包含的各个风险等级的权重分别乘以100后的和；
95.步骤3.4：根据步骤3.3的系统总分数判定系统的健康状况，具体为：
96.当系统总分数大于等于70时，状态为健康，则系统服务风险较低；
97.当系统总分数大于等于50时，且小于70时，状态为亚健康，则系统服务风险较高；
98.当系统总分数小于50时，状态为不健康，则系统服务风险极高。
99.在具体实施过程中，首先管理人员拉取系统的数据，获取系统的风险来源情况，例如下表：
[0100][0101]
对系统进行打分，系统总分数＝100-(0.15x100+0.12x100+0.15x100)＝58
[0102]
判定系统的健康状况，由于系统总分数58位于50和70之间，因此系统为亚健康。
[0103]
对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下，在其它实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。