Software application quality risk identification and early warning method, system and product

Abstract

The invention discloses a software application quality risk identification and early warning method, system and product used in the field of software security risk control. The method comprises the following steps: S100, deploying an application monitoring service to obtain application monitoring data; s200, creating a query task queue, and obtaining and storing an application state query index; s300, creating a query task consumption queue, obtaining an application state query index as an input parameter, and obtaining monitoring query data; s400, configuring an application management table based on the service state of the application; s500, a risk identification rule is defined, risk items are identified, and a risk detail table is obtained; and S600, carrying out risk field extraction on the risk detail table through the field processing configuration table, mapping the risk field to a risk result table, and carrying out risk item analysis and treatment based on the risk result table. According to the application, long-term tracking of the application running state can be realized, the application state is comprehensively obtained, the potential running risk is identified, and pre-warning is provided.

Description

Technical Field

[0001] This application relates to a method, system, and product for identifying and warning of software application quality risks in the field of software security risk control. Background Technology

[0002] Before official deployment, software applications must undergo testing to eliminate potential defects and operational risks. However, due to the inevitable differences between testing and actual operating environments, application services may malfunction during deployment due to factors such as code logic errors, performance bottlenecks, insufficient resources, and upstream / downstream anomalies. To ensure user experience and system stability, online monitoring methods are commonly used to monitor the operational status of various applications within the system in real time and to detect operational risks.

[0003] Existing online application monitoring systems primarily focus on real-time acquisition of the application's current operational status, anomaly detection, and fault alerts. Their core logic is based on sudden changes in target parameters or reaching thresholds when these parameters deviate from the normal baseline. While these methods can effectively detect serious application failures, they struggle to proactively identify potential operational risks—that is, issues that have not yet caused obvious failures but may lead to a decline in user experience or system crashes in the future. Summary of the Invention

[0004] The purpose of this application is to overcome the shortcomings of the prior art and provide a method, system and product for identifying and warning of software application quality risks, which can realize long-term tracking of application operation status, comprehensively obtain application status, identify potential operation risks and provide early warning.

[0005] The purpose of this application is to overcome the shortcomings of the prior art and provide an adjustable control method, system and product for an electric regulating valve actuator, which can achieve fast, accurate and robust regulation of medium flow under complex and changing operating conditions.

[0006] Firstly, this application provides a method for identifying and warning of software application quality risks, the technical solution of which includes the following steps: S100 deploys an application monitoring service to obtain monitoring data for all applications. S200: Create a query task queue. The query task queue periodically executes query tasks on application monitoring data to obtain the application status query index and stores it in the query task table. S300 creates a query task consumption queue. The query task consumption queue periodically obtains the application status query index from the query task table as input parameters, calls the query interface of the application monitoring service, obtains monitoring query data, and stores it in the service table. S400, configures application management tables based on application business status; S500 defines different risk identification rules based on different risk projects, stores them in the risk identification rule table corresponding to the risk project, and uses the service table and application management table obtained periodically as the identification objects to identify different risk projects and obtain each risk details table in real time. The S600 extracts risk fields from each risk details table through a field processing configuration table, maps all extracted risk fields to a risk result table for storage, and outputs, analyzes, and manages risk projects based on the risk result table.

[0007] By adopting the above technical solution, a query index for the query task consumption queue is built based on the application monitoring service through the query task queue. When the query task consumption queue is executed, it calls the query interface of the application monitoring service to obtain the application data pointed to by the query index. Then, based on the risk identification rules, it screens the application data to obtain the extraction results of the risk direction projects.

[0008] As a priority, in S100, the application monitoring data includes the application's link topology data, dependent service data, and interface request data.

[0009] By adopting the above technical solution, it is possible to obtain the topology and node information of the application through application monitoring data, and thereby perceive whether the application has potential security risks.

[0010] Preferably, in S200, the query task queue is divided into a topology query task queue for querying topology information and an interface query task queue for querying interface information. The application status query index obtained by the topology query task queue and the interface query task queue includes target application information and time slice information, and is then stored in the topology query task table and the interface query task table, respectively.

[0011] By adopting the above technical solution, query queues for topology information and interface information are set separately, and query tasks can be configured differently according to the content characteristics of topology information and interface information, thereby achieving a balance between the accuracy of query tasks and the consumption of system resources.

[0012] As a priority, in S300, the query task consumption queue is divided into a topology query task consumption queue and an interface query task consumption queue. Query time ranges are configured for the topology query task consumption queue and the interface query task consumption queue respectively. The obtained application status query index and query time range are used as input parameters to call the query interface of the application monitoring service, obtain monitoring query data, and store them in the service table respectively.

[0013] By adopting the above technical solution, the query task consumption queue is distinguished and set according to topology information and interface information, and a time range is configured for each task. This allows for time granularity configuration of query tasks, enabling information acquisition to meet different objectives of risk project identification, such as distinguishing between short-term and long-term risks for analysis. It also enables multi-dimensional comprehensive risk assessment of applications and optimization of risk response strategies.

[0014] Preferably, the monitoring query data obtained by the topology query task consumption queue includes node data and edge data; When the topology query task consumption queue is executed, it first traverses the edge data based on the input parameters to obtain the topology connection data between applications and stores it in the application topology service table; then it traverses the node data based on the input parameters. When the node is middleware, it obtains the topology connection data between the middleware and the application and stores it in the application topology service table. When the node is an interface, it obtains the relationship between the application and the dependent interface and stores it in the application dependency service table. The application topology service table and the application dependency service table together constitute the service table of the topology query task consumption queue.

[0015] By adopting the above technical solution, the node data and edge data obtained by the topology query task consumption queue are classified, identified, and stored in a categorized manner, making the data structure clear and explicit. This enables targeted retrieval and efficient aggregation analysis, improves the calculation efficiency of risk identification, and facilitates expansion when adding new node data and edge data.

[0016] Preferably, the monitoring query data obtained from the interface query task consumption queue includes the interface's QPS data and RT data, and the application stored in the interface query task consumption queue provides a service table.

[0017] By adopting the above technical solution, the current health level of the interface can be measured through QPS data and RT data, so as to predict and analyze potential risks.

[0018] Preferably, in S600, the risk result table divides the risk fields into dynamic risk fields that need to be updated and static risk fields that do not change once recorded unless a reset command is used; the dynamic risk fields are updated in real time based on the real-time obtained risk details table.

[0019] Through the above technical solutions, dynamic risk fields are suitable for handling risks related to the current state of the application, such as system resource utilization risks. They can track changes in the system state and cancel risk warnings after the system state recovers. Static risks are suitable for handling inherent defects in the application and treating them as pending issues for risk project governance.

[0020] Secondly, this application provides a software application quality risk identification and early warning system to implement the aforementioned early warning method, employing the following technical solution: This includes a basic data collection and synchronization module and a risk assessment module; The basic data collection and synchronization module includes an application monitoring service module, a query task module, and a storage module; The application monitoring service module is used to deploy application monitoring services; The query task module sends a query task to the application monitoring service module and returns an application status query index stored in the query task table. The query task table is stored in the storage module; The risk assessment module includes a data acquisition module, a risk identification rule module, and a risk output module. The data acquisition module accesses the storage module, calls the query interface of the application monitoring service based on the query task table, obtains monitoring query data, and stores it in the service table; at the same time, the data acquisition module obtains the application management table. The risk identification rule module is configured with risk identification rules, which identify different risk items based on the service table and the application management table, and obtain each risk details table in real time. The risk output module extracts the risk fields from each of the risk details tables, maps them to the risk result table for storage, and outputs the risk items through the risk result table.

[0021] As a preferred approach, the risk output module is connected to the backend risk governance module. The risk governance module pushes risk items to operations and maintenance personnel and drives the target application to execute risk governance strategies.

[0022] Thirdly, the computer program product provided in this application employs a technical solution including a computer program or instructions, which enables the computer program or instructions to implement the steps in the above-mentioned software application quality risk identification and early warning method.

[0023] In summary, this application includes at least one of the following beneficial technical effects: 1. This application uses an index for information acquisition built by a query task queue based on the application monitoring service. The query task consumption queue acquires topology and interface information as needed based on the index, which can acquire application status information at a preset time granularity, thereby realizing early warning and management of application risks at different time dimensions, and providing more forward-looking, accurate and operable technical support for software quality assurance.

[0024] 2. This application enables persistent and routine monitoring of application risk items, analyzes the application's operational status, and outputs the content of risk items to be optimized, providing a basis for the governance and optimization of application risk items.

[0025] 3. This application decouples the application monitoring service from the information acquisition process of topology and interfaces and the risk perception process, enabling users to personalize the data acquisition and risk identification rules according to their own needs, and has good online adjustability and scalability. Attached Figure Description

[0026] Figure 1 This is a flowchart illustrating a software application quality risk identification and early warning method according to an embodiment of this application; Figure 2 This is a schematic diagram of the task architecture for basic data collection and synchronization in a software application quality risk identification and early warning method according to an embodiment of this application; Figure 3 This is a flowchart illustrating the process of outputting a risk result table from basic data in a software application quality risk identification and early warning method according to an embodiment of this application. Figure 4 This is a schematic diagram of the architecture of a software application quality risk identification and early warning system according to an embodiment of this application; Figure 5 This is a schematic diagram of the architecture of an exemplary computer device according to an embodiment of this application. Detailed Implementation

[0027] This specific embodiment is merely an explanation of this application and is not intended to limit it. After reading this specification, those skilled in the art can make modifications to this embodiment without contributing any inventive step, but such modifications are protected by patent law as long as they are within the scope of this application.

[0028] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application. It should be noted that in the optional embodiments of this application, the object information and other related data involved require the permission or consent of the object when the embodiments of this application are applied to specific products or technologies, and the collection, use, and processing of related data must comply with the relevant laws, regulations, and standards of the relevant countries and regions. That is to say, if the embodiments of this application involve data related to the object, it needs to be obtained with the authorization and consent of the object, the authorization and consent of the relevant departments, and in compliance with the relevant laws, regulations, and standards of the country and region. If personal information is involved in the embodiments, the acquisition of all personal information requires the consent of the individual. If sensitive information is involved, the separate consent of the information subject is required, and the embodiments also need to be implemented with the authorization and consent of the object.

[0029] To achieve comprehensive application performance monitoring, users deploy online application monitoring systems to control the operational status of the entire application stack, from front-end data interfaces to back-end databases. ARMS is a cloud-deployed real-time application monitoring service with features including end-to-end performance tracing and application topology and dependency visualization. The following detailed description uses ARMS as an example of the application monitoring service in the software application quality risk identification and early warning method of this application. It should be noted that ARMS is an exemplary illustration of the embodiments of this application; other application performance management systems capable of collecting interface and topology data can serve as the basis for implementing the software application quality risk identification and early warning method of this application. ARMS is not a limitation on the scope of protection of this application.

[0030] Please see Figure 1 The software application quality risk identification and early warning method of this application includes the following steps.

[0031] S100 deploys the Application Monitoring Service (ARMS) to obtain application monitoring data.

[0032] This application utilizes the automatic discovery of upstream and downstream dependencies of the application monitoring service ARMS to extract and display the call chain between different applications, and then obtains the application's link topology data, dependent service data, and interface request data. The interface request data includes IP address, response time, response status (success or error), and request time.

[0033] S200: Create a query task queue. The query task queue periodically executes query tasks on application monitoring data to obtain an application status query index, which is then stored in the query task table.

[0034] In the embodiments of this application, XXL-JOB is used for task queue management. XXL-JOB is a distributed task scheduling platform that can issue execution instructions for preset tasks at preset times. The appTopoJobQueue and appEntrancesDetailsJobQueue queues are configured within XXL-JOB.

[0035] The appTopoJobQueue is a queue of topology query tasks used to query topology information. When executed, it performs a topology query task, retrieves the topology information of the target application, and stores it in the topology query task table app_topo_job_queue, which then drives the subsequent consumer queue.

[0036] The appEntrancesDetailsJobQueue is an interface query task queue used to query interface information. When executed, it performs an interface query task, retrieves the target application interface information, and stores it in the interface query task table app_common_details_task_queue, which then drives the subsequent consumption queue.

[0037] It should be noted that the target application topology information and target application interface information are the target application information for the target application's application status query index. Furthermore, the application status query index also includes time slice information, enabling the subsequent consumption queue to be driven by dividing tasks into several modular task units according to time ranges, thereby improving the consumption queue's responsiveness and processing efficiency.

[0038] The execution frequencies of the `appTopoJobQueue` and `appEntrancesDetailsJobQueue` queues are configured separately based on the predicted business objectives of the risk project. Topology information changes relatively steadily, typically only during application releases, scaling up / down, or changes to business network configurations; therefore, the `appTopoJobQueue` queue can use a lower query frequency. Node information, on the other hand, is more active, with more frequent node changes. Applications need to adjust nodes according to the current business scenario and obtain real-time heartbeat data to confirm node access; therefore, the `appEntrancesDetailsJobQueue` queue can use a higher query frequency. In the embodiments of this application, the `appTopoJobQueue` queue is executed daily, while the `appEntrancesDetailsJobQueue` queue is executed hourly.

[0039] S300 creates a query task consumption queue. The query task consumption queue periodically retrieves the application status query index from the query task table, uses it as input to call the query interface of the application monitoring service, obtains monitoring query data, and stores it in the service table.

[0040] Specifically, configure the armsTopoInfGetJob queue and the armsApiInfGetJob queue within XLL-JOB.

[0041] The armsTopoInfGetJob queue is a topology query task consumption queue. The armsTopoInfGetJob queue takes the application status query index of the app_topo_job_queue table and a preset time range as input parameters, calls the ARMS QueryAppTopology OpenAPI to query topology information, and stores it in the application topology service table. The preset time range is configured according to the specific content of the risk item, determining the time granularity of risk item identification. Fine-grained risk items, such as real-time risk monitoring after application release or configuration changes, sudden traffic surges, or instantaneous failures of basic interfaces, correspond to a smaller time range; coarse-grained risk items, such as stability assessments and trend discovery in daily operations or risks from periodic business (e.g., weekdays / weekends), correspond to a larger time range. In one specific embodiment of this application, the query frequency of both the armsTopoInfGetJob queue and the armsApiInfGetJob queue is set to query per minute, with a query range from one minute prior to the query time. Those skilled in the art will understand that other query frequencies and ranges can also be set according to the risk prediction objectives.

[0042] More specifically, the monitoring query data obtained by the armsTopoInfGetJob queue includes two categories: Nodes and Edges. First, the Edges data is traversed, storing the topology connection data between applications in the app_edge table (application topology service table). Then, the Nodes data is traversed. When the Nodes type is middleware, the topology connection data between the middleware and the application is stored in the app_edge table; when the Nodes type is interface (e.g., HTTP interface), the relationship between the application and its dependent interfaces is stored in the application_call_entrances table (application dependency service table). Distinguishing between the app_edge and application_call_entrances tables for storing topology monitoring query data allows for differentiation of different topology abstraction levels and relationship granularities, making data storage more aligned with actual analysis scenarios, thereby improving query efficiency, clarity, and scalability. Taking an HTTP interface as an example, this interface logically belongs to an application. If it is stored together with the call relationship between applications, it will result in each application that calls the interface recording an edge, resulting in a large number of duplicate records. In this application, the app_edge table only needs to record the dependency from application A to application B once, while the application_call_entrances table records the interface provided by application B once. The two are associated through application B, which makes the recording of the topology relationship concise, clear and without redundancy.

[0043] The armsApiInfGetJob queue is the API query task consumption queue. It takes the application status query index from the app_common_details_task_queue table and a preset time range as input parameters, calls the ARMS GetAppApi OpenAPI to query the API information, and stores it in the application dependency service table. More specifically, the obtained monitoring query data includes at least the API's QPS and RT data, which are stored in the application_entrances table (the application provides the service table).

[0044] Please see Figure 2 Through the above steps, the basic data collection and synchronization for application risk project prediction were completed.

[0045] S400 configures the application management table, application_management, based on the application's business status. The application_management table contains attributes such as application name, importance level, risk level, business category, and number of faults. It is derived from an assessment of the actual business status and operational status of each application, providing a systematic description of the application to determine its priority, importance, risk level, and other information, thus providing a basis for subsequent risk assessments.

[0046] S500 defines different risk identification rules based on different risk projects, stores the risk identification rule table corresponding to the risk project, and uses the service table and application management table obtained periodically as the identification objects to identify different risk projects and obtain the details table of each risk in real time.

[0047] In the embodiments of this application, the following uses the circuit breaker risk details table as an example to specifically explain how to obtain the risk details table.

[0048] For circuit breaker risk, the required service tables are `application_call_entrances` and `application_entrances`, which contain information such as the associated application, protocol, method, path, QPS, and RT of the interface. Then, the `application_management` table is obtained. Two circuit breaker rules are defined through the `risk_rule_config` table. These rules include filtering and connection conditions to filter application and interface data that meet the criteria, resulting in a circuit breaker risk details table. The details are shown below: "conditions": [ { "type": "filter", "table": "application_call_entrances", "field": "call_path_qps", "operator": ">", value: "20" }, { "type": "filter", "table": "application_management", "field": "level", "operator": "=", "value": "P1" }, { "type": "join", "left_table": "application_call_entrances", "left_field": "app_name", "right_table": "application_management", "right_field": "app_name", "operator": "=" } ] "conditions": [ { "type": "filter", "table": "application_call_entrances", "field": "resp_time", "operator": ">", "value": "500" }, { "type": "filter", "table": "application_management", "field": "level", "operator": "=", "value": "P1" }, { "type": "join", "left_table": "application_call_entrances", "left_field": "app_name", "right_table": "application_management", "right_field": "app_name", "operator": "=" } ] The specific meaning of the above circuit breaker rule is as follows: if application level = P1, call_path_q2ps>20 and application level = P1, resp_time>500, the tables are joined through the app_name field, and then the union of the two is taken.

[0049] It should be noted that the above embodiment illustrates the acquisition of the risk result table using the circuit breaker risk details table as an example. In actual deployment, the risk identification rules can be configured accordingly through the risk identification rule table based on the actual requirements for predicting and analyzing risk items, thereby obtaining the corresponding risk details table, including the rate limiting risk details table, the service external call details table, and the OSS external call details table, etc. Figure 3 As shown.

[0050] The S600 extracts risk fields from each risk details table through a field processing configuration table, maps all extracted risk fields to a risk result table for storage, and performs risk project analysis and governance based on the risk result table.

[0051] Specifically, the risk_type_config table defines how to map the risk fields extracted from each risk details table to the risk_circuit_breaking_detail table through the field processing configuration table.

[0052] More specifically, the risk results table divides risk fields into dynamic risk fields that need to be updated and static risk fields that do not change once recorded unless a reset command is used.

[0053] The core objective of dynamic risk fields is to reflect the current risk level of an application. They represent an instantaneous state, allowing the system or user to perceive the real-time risk situation. These fields need to be updated in real-time based on the risk details table obtained in real time. For example, a field monitoring server CPU utilization refreshes its value every second, always displaying the latest load. Dynamic risk fields can reflect real-time changes in risk items, providing a basis for determining whether risk items need to be addressed and managed.

[0054] The core objective of static risk fields is to retain the risk status. It is typically created by a triggering condition, and the system freezes and stores the state at that moment in the static risk field. Regardless of subsequent real-time data changes, this anomaly record will be saved, facilitating root cause analysis and providing a basis for risk management. For example, the CPU utilization field in a dynamic risk field may have returned to normal, but the static risk field may still record the information "reached a peak of 99% at 14:05:03".

[0055] Once a risk item is generated in the risk outcome table, a message can be automatically pushed to the corresponding responsible person, who can then handle the risk item according to the actual situation.

[0056] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0057] Please see Figure 4 The present application discloses a software application quality risk identification and early warning system for implementing the above-mentioned early warning method, which includes a basic data collection and synchronization module 1, a risk calculation module 2, and a risk management module 3.

[0058] The basic data collection and synchronization module includes an application monitoring service module 11, a query task module 12, and a storage module 13.

[0059] Application monitoring service module 11 is used to deploy application monitoring services, and in this application, it is used to deploy Arms.

[0060] The query task module 12 sends a query task to the application monitoring service module 11, using XXL-JOB, and returns the application status query index, which is stored in the query task table.

[0061] The query task table is stored in storage module 13. In the embodiments of this application, storage module 13 uses the cloud database service RDS, which is compatible with Arms deployed in the cloud.

[0062] The risk assessment module 2 includes a data acquisition module 21, a risk identification rule module 22, and a risk output module 23.

[0063] The data acquisition module 21 accesses the storage module 13, calls the OpenAPI query interface of the application Arms based on the query task table, obtains monitoring query data, and stores it in the service table. At the same time, the data acquisition module 21 obtains the application management table.

[0064] The risk identification rules module 22 is configured with risk identification rules, which identify different risk items based on the service table and application management table, and obtain the details of each risk table in real time.

[0065] The risk output module 23 extracts the risk fields from each risk details table, maps them to the risk result table for storage, and outputs the risk items through the risk result table. The risk output module 23 connects to the backend risk governance module 3, which pushes risk items to operations and maintenance personnel and drives the target application to execute risk governance strategies.

[0066] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0067] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the software application quality risk identification and early warning system described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0068] Please see Figure 5 In one embodiment, a computer device is provided, which may be a server. The computer device includes a processor, memory, a network interface, and a database connected via a system bus. The processor provides computing and control capabilities. The memory includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores an operating system, computer programs, and a database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The database stores relevant data for the software application quality risk identification and early warning method of this application. The network interface is used to communicate with external application terminals via a network connection. When the computer program is executed by the processor, it implements a software application quality risk identification and early warning method.

[0069] The above embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included within the protection scope of the present invention.

Claims

1. A method for identifying and warning of software application quality risks, characterized in that, Includes the following steps: S100 deploys an application monitoring service to obtain monitoring data for all applications. S200: Create a query task queue. The query task queue periodically executes query tasks on application monitoring data to obtain the application status query index and stores it in the query task table. S300 creates a query task consumption queue. The query task consumption queue periodically obtains the application status query index from the query task table as input parameters, calls the query interface of the application monitoring service, obtains monitoring query data, and stores it in the service table. S400, configures application management tables based on application business status; S500 defines different risk identification rules based on different risk projects, stores them in the risk identification rule table corresponding to the risk project, and uses the service table and application management table obtained periodically as the identification objects to identify different risk projects and obtain each risk details table in real time. The S600 extracts risk fields from each risk details table through a field processing configuration table, maps all extracted risk fields to a risk result table for storage, and outputs, analyzes, and manages risk projects based on the risk result table.

2. The software application quality risk identification and early warning method according to claim 1, characterized in that, In S100, the application monitoring data includes the application's link topology data, dependent service data, and interface request data.

3. The software application quality risk identification and early warning method according to claim 1, characterized in that, In S200, the query task queue is divided into a topology query task queue for querying topology information and an interface query task queue for querying interface information. The application status query index obtained by the topology query task queue and the interface query task queue includes target application information and time slice information, and is then stored in the topology query task table and the interface query task table, respectively.

4. The software application quality risk identification and early warning method according to claim 3, characterized in that, In S300, the query task consumption queue is divided into a topology query task consumption queue and an interface query task consumption queue. The query time range is configured for the topology query task consumption queue and the interface query task consumption queue respectively. The obtained application status query index and the query time range are used as input parameters to call the query interface of the application monitoring service, obtain monitoring query data, and store them in the service table respectively.

5. The software application quality risk identification and early warning method according to claim 4, characterized in that, The monitoring query data obtained by the topology query task consumption queue includes node data and edge data; When the topology query task consumption queue is executed, it first traverses the edge data based on the input parameters to obtain the topology connection data between applications and stores it in the application topology service table; then it traverses the node data based on the input parameters. When the node is middleware, it obtains the topology connection data between the middleware and the application and stores it in the application topology service table. When the node is an interface, it obtains the relationship between the application and the dependent interface and stores it in the application dependency service table. The application topology service table and the application dependency service table together constitute the service table of the topology query task consumption queue.

6. The software application quality risk identification and early warning method according to claim 4, characterized in that, The monitoring query data obtained from the interface query task consumption queue includes the interface's QPS data and RT data, and the application stored in the interface query task consumption queue provides a service table.

7. The software application quality risk identification and early warning method according to claim 1, characterized in that, In S600, the risk result table divides the risk fields into dynamic risk fields that need to be updated and static risk fields that do not change once recorded unless a reset command is used. Based on the real-time obtained risk details table, the dynamic risk fields are updated in real time.

8. A software application quality risk identification and early warning system, used to implement the early warning method according to any one of claims 1 to 7, characterized in that, This includes a basic data collection and synchronization module and a risk assessment module; The basic data collection and synchronization module includes an application monitoring service module, a query task module, and a storage module; The application monitoring service module is used to deploy application monitoring services; The query task module sends a query task to the application monitoring service module and returns an application status query index stored in the query task table. The query task table is stored in the storage module; The risk assessment module includes a data acquisition module, a risk identification rule module, and a risk output module. The data acquisition module accesses the storage module, calls the query interface of the application monitoring service based on the query task table, obtains monitoring query data, and stores it in the service table; at the same time, the data acquisition module obtains the application management table. The risk identification rule module is configured with risk identification rules, which identify different risk items based on the service table and the application management table, and obtain each risk details table in real time. The risk output module extracts the risk fields from each of the risk details tables, maps them to the risk result table for storage, and outputs the risk items through the risk result table.

9. A software application quality risk identification and early warning system according to claim 8, characterized in that, The risk output module connects to the backend risk governance module. The risk governance module pushes risk items to operations and maintenance personnel and drives the target application to execute risk governance strategies.

10. A computer program product, characterized in that, The computer program product includes a computer program or instructions that enable the computer program or instructions to perform the steps in the software application quality risk identification and early warning method according to any one of claims 1 to 7.

Images