风险检测包生成方法、风险检测方法及装置与流程

1.本发明属于移动通信领域，尤其涉及一种风险检测包生成方法、风险检测方法及系统。


背景技术：

2.随着软件系统的日益庞大、功能复杂度提升，为确保软件质量，会在软件使用前对软件进行多个方面的检测，例如：功能检测、性能检测、安全检测等等。根据检测手段的不同，又可以分为人工检测、自动化检测。但是不管是所涉方面、还是手段如何不同，它们的目标是一致的，都是为了能够让使用者可以正常的应用开发出来的软件。然而，尽管经过了层层测试，在软件上线后，仍然会出现异常现象。基于此，现有技术中，如：一种基于智能规则匹配的自动巡检系统及方法(申请号：cn201210497990.5)提出一种自动巡检方法，其通过规则匹配可以实时获取应用系统的运行情况，一旦发生异常时就进行报警提示，确实能够在系统上线使用后起到风险检测的作用。然而，实时的异常预警代表了异常已经发生，因此属于后置行为，可能异常已经影响了系统的使用。


技术实现要素：

3.为了解决现有技术的问题，本发明提出一种风险检测包生成方法、风险检测方法及系统。本方法通过对运维历史中通用、频繁出现的问题进行归纳总结，将问题转变成一个个检测项进而生成工具包，通过工具化的形式进行自动化检测，可以提前规避历史问题，从而全面提升整体应用系统的健康程度、降低使用风险。
4.本发明实施例提供的具体技术方案如下：
5.第一方面，提供一种风险检测包生成方法，所述方法包括：
6.获取运维库中的历史运维数据并进行分类，得到历史问题集；
7.基于所述历史问题集抽象生成与每一历史问题对应的检测项；
8.将所有检测项整合生成检测包以依据所述检测包对应用系统进行风险检测。
9.在一些实施例中，所述方法还包括：
10.当检测到所述运维库中有新运维数据时，判断所述新运维数据是否属于历史问题集；
11.当所述新运维数据不属于所述历史问题集时，创建新历史问题；
12.将所述新历史问题抽象生成新检测项；
13.基于所述新检测项更新所述检测包。
14.在一些实施例中，所述检测项包括检测包冲突检测、脚本检测、索引检测、脏数据检测、安全整改检测、框架整改检测、模块访问异常检测、模块权限检测、文件对比检测中的任意一种。
15.第二方面，提供一种风险检测方法，所述方法包括：
16.将检测包加载至应用系统；
17.当检测到检测包被触发时，基于检测包中的每一检测项对相应的应用系统进行检测；
18.生成与每一应用系统对应的检测结果并将所有检测结果发送至终端。
19.在一些实施例中，所述检测到检测包被触发具体包括：
20.判断应用系统是否接收到指定地址，若接收到，则确定所述检测包被触发。
21.在一些实施例中，所述检测到检测包被触发具体包括：
22.当所述应用系统启动时，自动开启所述检测包。
23.在一些实施例中，所述当所述应用系统启动后，自动开启所述检测包具体包括：
24.当所述应用系统启动后，获取定时任务；
25.基于所述定时任务的定时时间自动开启所述检测包。
26.在一些实施例中，所述方法还包括：
27.接收终端发送的已更新的检测包；
28.所述将检测包加载至应用系统具体包括：
29.基于所述更新的检测包对应用系统中已有的检测包进行替换。
30.第三方面，提供一种风险检测包生成装置，所述装置包括：
31.获取模块，用于获取运维库中的历史运维数据；
32.分类模块，用于对历史运维数据进行分类，得到历史问题集；
33.生成模块，用于基于所述历史问题集抽象生成与每一历史问题对应的检测项；
34.打包模块，用于将所有检测项整合生成检测包以依据所述检测包对应用系统进行风险检测。
35.第四方面，提供一种风险检测装置，所述装置包括：
36.加载模块，用于将检测包加载至应用系统；
37.处理模块，用于当检测到检测包被触发时，基于检测包中的每一检测项对相应的应用系统进行检测；以及用于生成与每一应用系统对应的检测结果；
38.发送模块，用于将所有检测结果发送至终端。
39.本发明实施例具有如下有益效果：
40.1、本发明通过对历史运维数据中通用、频繁出现的问题进行归纳总结，将问题转变成一个个检测项，并打包成一个检测包，通过检测包来对应用系统进行上线前/上线后的检测，从而可以提前规避历史问题，全面提升整体应用系统的健康程度、降低使用风险；
41.2、本发明在利用检测包进行风险检测时，无需任何配置，直接引入即可，检测包相当于一个可插拔的插件，方便高效，可以在不影响原有业务上实现检测；
42.3、本发明的检测包是动态更新的，当新的检测项纳入检测包，新发现的问题也能得到及时规避；
43.4、本发明可以对应用系统所有检测结果进行上报，运维人员可以基于上报数据查看未通过的检测项并对应用系统进行整改，当应用系统整改完成后，基于定时任务再次对应用系统进行检测，如此便形成了检测闭环，完善了应用系统。
附图说明
44.为了更清楚地说明本发明实施例中的技术方案，下面将对实施例描述中所需要使
用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
45.图1是根据本公开实施例的风险检测包生成方法的示例性流程图；
46.图2是根据本公开实施例的风险检测方法的示例性流程图；
47.图3是根据本公开实施例的风险检测方法的应用场景示意图；
48.图4是根据本公开实施例的风险检测包生成装置的结构示意图；
49.图5是根据本公开实施例的风险检测装置的结构示意图。
具体实施方式
50.为使本发明的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案行进清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
51.如背景技术所述，目前，现有的软件在上线后发生异常时，可以通过规则匹配的方法来对软件进行检测，找到问题所在。但该行为属于后置行为，可能异常已经影响了应用系统的使用。
52.并且，通常情况下，一个公司会有很多个应用系统。当某个应用运行时有异常预警时，即使其他的应用系统没有出现该预警，也并不代表该系统没有问题，可能只是没有触发该问题场景，因此仍然存在风险。如果只是实时检测，只会等到暴露了才去处理，最终可能会影响所有系统的使用。
53.基于此，本技术申请人创造性想到利用运维库中的历史运维数据生成检测包，从而利用检测包进行检测的技术方案。
54.图1示出了根据本公开实施例的风险检测包生成方法的示例性流程图，该风险检测包生成方法的详述如下：
55.步骤101、获取运维库中的历史运维数据并进行分类，得到历史问题集。
56.本实施例中，上述历史运维数据存储于运维库中，具体包括：问题的描述、产生的原因、造成的影响、以及解决方法等数据。
57.应用系统总是会存在隐患的，这种隐患会在使用过程中偶然或是必然的出现。因此如果将应用系统运行过程中出现的问题、解决方案等都记录下来，后期就可以基于这些数据生成每一问题的检测方法。
58.步骤102、基于历史问题集抽象生成与每一历史问题对应的检测项。
59.其中，每一检测项用于描述每一历史问题的检测方法/步骤，其可以由一个类或者多个类构成。
60.一些实施例中，检测项为检测包冲突检测、脚本检测、索引检测、脏数据检测、安全整改检测、框架整改检测、模块访问异常检测、模块权限检测、文件对比检测中的任一种。此外，还可以根据实际需要，对检测项进行增减，设计定制化检测项等。
61.步骤103、将所有检测项整合生成检测包以依据检测包对应用系统进行风险检测。
62.在具体的实施过程中，将应用系统可能遇到的所有历史问题所抽象得到的检测项
整合起来，生成一个检测包，后续便可利用该检测包对不同的应用系统进行风险检测。示例性的，若应用系统部署于web服务器上，检测包可以为jar包，将每一检测项放入独立的jar包中，并将jar包配置于每一应用系统，由此便可与应用系统形成对应关系。
63.其中，检测包拥有自己的前后台、登录校验、访问校验逻辑，其相当于一个检测插件，与应用业务隔开，不影响原有业务。
64.本发明通过对历史运维数据中通用、频繁出现的问题进行归纳总结，将问题转变成一个个检测项，并打包成一个检测包，通过检测包来实现应用系统的检测，可以提前规避历史问题，从而全面提升整体应用系统的健康程度、降低使用风险。需要说明的是，本实施例提供的检测包不仅仅适用于已上线系统还适用于未上线系统。
65.一些实施例中，上述风险检测包生成方法还包括：
66.当检测到运维库中有新运维数据时，判断新运维数据是否属于历史问题集；
67.当新运维数据不属于历史问题集时，创建新历史问题；
68.将新历史问题抽象生成新检测项；
69.基于新检测项更新检测包。
70.本发明的检测包是动态更新的，当新的检测项纳入检测包，新发现的问题也能得到及时规避。此外，检测包作为应用级别检测项的集合，支持针对部分产品、项目定制个性化的检测项，以便和通用检测项区分开。
71.图2示出了根据本公开实施例的风险检测方法的示例性流程图，本说明书提供的风险检测方法可以应用于服务器、计算机、平板电脑等设备中，所述风险检测方法的详述如下：
72.步骤201、将检测包加载至应用系统。
73.其中，检测包相当于一检测工具，无需任何配置即可引入应用系统，即插即用，对应用系统本身业务功能没有影响。
74.本说明书实施例提供的一个场景示例中，风险检测方法可以应用于执行风险检测的设备，设备可以包括一个服务器，也可以包括多个服务器组成的服务器集群。
75.下面以一公司应用场景来进行说明：
76.一个公司可能具有多个应用系统，这些应用系统可以部署于同一个服务器或者部署于不同服务器。以每一应用系统部署于不同服务器为例展开。具体参考图3，每一检测包相当于一检测工具，首先需要在应用系统中引入该检测包，即，将检测包加载至应用系统，由此检测包与应用系统便生成一一对应关系，后续便可利用检测包对相应的应用系统进行检测。
77.步骤202、当检测到检测包被触发时，基于检测包中的每一检测项对相应的应用系统进行检测。
78.检测包被引入应用系统之后，需要触发才可工作。当检测包被触发时，便可实现对应用系统的多项检测，如：检测包冲突检测、脚本检测、索引检测、脏数据检测、安全整改检测等。
79.在具体的实施过程中，触发信息可以是主动触发、也可以是自动触发。即，可以由运维人员根据实际需要主动发起检测包触发请求，还可以根据应用系统自动发起检测包触发请求。
80.一些实施例中，检测到检测包被触发具体包括：
81.判断应用系统是否接收到指定地址，若接收到，则确定检测包被触发。
82.在具体的实施过程中，每个检测包都具有自己的前后台、登录校验、访问校验逻辑等，因此作为运维人员，可以在应用系统页面上通过手动方式来触发检测包，具体操作如下：
83.运维人员登录检测包访问页面，输入用户访问账户及密码；
84.后台校验成功时，向访问页面返回验证消息；
85.运维人员发送访问地址，当服务器接收到访问地址时，则确定检测包被触发。
86.上述触发属于主动触发，运维人员可以根据实际需求选择性地对应用系统进行检测，而不必每次都对所有系统进行检测，从而可以节省计算机内部资源。
87.一些实施例中，检测到检测包被触发具体包括：
88.当应用系统启动后，自动开启检测包。
89.上述触发属于自动触发，与主动触发相反，运维人员无需进行任何操作，通过系统自检便可自动开启检测包，从而节省人力，节省成本。
90.更进一步的，上述当应用系统启动后，自动开启检测包具体还包括：
91.当应用系统启动后，获取定时任务；
92.基于定时任务的定时时间自动开启检测包。
93.本发明可以根据实际需要，实现自动检测或主动检测，因此灵活性强，并且，在自动检测时，还可以进一步通过定时任务，在定时时间内实现应用系统的自动巡检。
94.步骤203、生成与每一应用系统对应的检测结果并将所有检测结果发送至终端。
95.其中，终端上安装有运维平台，运维平台采集并展示所有服务器发送的检测结果，便于统一管理。
96.具体的，仍参考图3，检测结果与检测包所在应用系统相关联，运维平台通过采集到的检测数据，可以得知每一个应用系统哪些检测项通过了、哪些检测项未通过，后续可以通过邮件等形式下发，通知运维人员完善应用系统。
97.此外，当检测包被更新后，会在运维平台上生成备份，运维平台将该备份统一下发至各服务器，如：通过推送或者邮件等形式推送，运维人员可自行获取更新的检测包，将更新的检测包替换应用系统中已存在的检测包。
98.本发明实现了对应用系统所有检测结果进行上报，运维人员可以基于上报数据查看未通过的检测项并对应用系统进行整改，当应用系统整改完成后，基于定时任务再次对应用系统进行检测，如此便形成了检测闭环，完善了应用系统。
99.继续参见图4，作为对上述图1所示方法的实现，提供了风险检测包生成装置的一个实施例，该装置实施例与图1所示的方法实施例相对应，如图4所示，本实施例的风险检测包生成装置包括：
100.获取模块401，用于获取运维库中的历史运维数据；
101.分类模块402，用于对历史运维数据进行分类，得到历史问题集；
102.生成模块403，用于基于历史问题集抽象生成与每一历史问题对应的检测项；
103.打包模块404，用于将所有检测项整合生成检测包以依据检测包对应用系统进行风险检测。
104.在本实施例的一些可选的实现方式中，装置还包括：
105.判断模块405，用于当检测到运维库中有新运维数据时，判断新运维数据是否属于历史问题集；
106.分类模块402还用于当新运维数据不属于历史问题集时，创建新历史问题；
107.生成模块403还用于将新历史问题抽象生成新检测项；
108.更新模块406，用于基于新检测项更新检测包。
109.在本实施例的一些可选的实现方式中，上述检测项包括：检测包冲突检测、脚本检测、索引检测、脏数据检测、安全整改检测、框架整改检测、模块访问异常检测、模块权限检测、文件对比检测中的任意一种。
110.继续参见图5，作为对上述图2所示方法的实现，提供了风险检测装置的一个实施例，该装置实施例与图2所示的方法实施例相对应，如图5所示，本实施例的风险检测装置包括：
111.加载模块501，用于将检测包加载至应用系统；
112.处理模块502，用于当检测到检测包被触发时，基于检测包中的每一检测项对相应的应用系统进行检测；以及用于生成与每一应用系统对应的检测结果；
113.发送模块503，用于将所有检测结果发送至终端。
114.在本实施例的一些可选的实现方式中，处理模块502还用于判断应用系统是否接收到指定地址，若接收到，则确定检测包被触发。
115.在本实施例的一些可选的实现方式中，处理模块502还用于当应用系统启动后，自动开启检测包。
116.在本实施例的一些可选的实现方式中，处理模块502还用于：
117.当应用系统启动后，获取定时任务；
118.基于定时任务的定时时间自动开启检测包。
119.在本实施例的一些可选的实现方式中，装置还包括：
120.接收模块504，用于接收终端发送的已更新的检测包；
121.加载模块501还用于基于更新的检测包对应用系统中已有的检测包进行替换。
122.应理解，上述实施例中各步骤的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本技术实施例的实施过程构成任何限定。
123.需要说明的是，上述装置/单元之间的信息交互、执行过程等内容，由于与本技术方法实施例基于同一构思，其具体功能及带来的技术效果，具体可参见方法实施例部分，此处不再赘述。上述的装置根据对应方法实施例的描述还可以包括其他的实施方式。具体的实现方式可以参照上述对应的方法实施例的描述，此处不再赘述。
124.所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，仅以上述各功能单元、模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能单元、模块完成，即将所述装置的内部结构划分成不同的功能单元或模块，以完成以上描述的全部或者部分功能。实施例中的各功能单元、模块可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中，上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。另外，各功能单
元、模块的具体名称也只是为了便于相互区分，并不用于限制本技术的保护范围。上述系统中单元、模块的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
125.以上实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。
126.以上实施例仅表达了本发明的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本发明构思的前提下，还可以做出若干变形和改进，这些都属于本发明的保护范围。因此，本发明专利的保护范围应以所附权利要求为准。