Repair program management method and device, equipment, storage medium and program product

Abstract

The invention provides a repair program management method and device, equipment, a storage medium and a program product, and relates to the field of artificial intelligence and the field of financial science and technology. The method comprises the steps of obtaining a to-be-put-into-production repair program and metadata of the to-be-put-into-production repair program; the metadata comprises product version information, influence range and configuration information of the repair program; the metadata of the to-be-put-into-production repair program is input into the risk scoring model, and the risk level of the to-be-put-into-production repair program is determined; the risk scoring model is used for calculating the risk of the to-be-put-into-production repair program based on the metadata; based on the risk level, matching a predefined processing rule, and generating a processing strategy of the to-be-put-into-production repair program; and based on the processing strategy of the to-be-put-into-production repair program, processing the to-be-put-into-production repair program, and tracking the life cycle of the to-be-put-into-production repair program. Through the combination of the risk scoring model and the rule engine, the uncertainty of subjective judgment is eliminated through quantitative scoring, and the problem of lack of quantitative indexes in the prior art is solved.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of artificial intelligence and the field of financial technology, in particular to a repair program management method and device, equipment, storage medium and program product. BACKGROUND

[0002] As the core infrastructure of the financial industry, the stability and security of the banking business system are directly related to transaction continuity, data security and customer trust. In actual operation, the banking business system is usually composed of hundreds of product components, covering operating systems (such as z / OS), databases, middleware and various business application modules. During the long-term operation of these systems, vendors will continue to release repair programs to address known defects, security vulnerabilities or performance issues in the business system.

[0003] However, due to the large number of repair programs (usually thousands of items), complex associated components, and significant differences in upgrade strategies, operations personnel need to assess the risks, prioritize, test and verify, and make production decisions on a large number of repair programs within a limited time. The existing operation process relies heavily on manual operations, such as manually checking repair description files released by vendors, manually comparing system environment differences, and manually recording evaluation results, which results in low efficiency and is prone to errors. In addition, the full life cycle management of repair programs (from release to installation, testing, production, and tracking) lacks systematic tool support, and the status information at each stage is scattered, making it difficult to form a closed-loop management. In peak business periods or sudden failure scenarios, the operations team often faces risks such as delayed repair program evaluation, conflicting testing resources, and out-of-control production progress, which directly affects business continuity. SUMMARY

[0004] The present application provides a repair program management method, device, equipment, storage medium and program product to solve the technical problem that repair program evaluation relies on manual experience and cannot efficiently handle the screening and evaluation of a large number of repair programs.

[0005] In a first aspect, the present application provides a repair program management method, the repair program being used to correct a business system, comprising:

[0006] Obtaining a repair program to be put into production and metadata of the repair program to be put into production; the metadata including product version information, impact range and configuration information of the repair program;

[0007] Inputting the metadata of the repair program to be put into production into a risk scoring model to determine a risk level of the repair program to be put into production; the risk scoring model being used to calculate the risk of the repair program to be put into production based on the metadata;

[0008] Based on the risk level, matching a predefined processing rule to generate a processing strategy for the repair program to be put into production;

[0009] Based on the processing strategy of the to-be-produced repair program, the to-be-produced repair program is processed, and the life cycle of the to-be-produced repair program is tracked.

[0010] In one of the embodiments, the metadata of the to-be-produced repair program is input into a risk scoring model, specifically including:

[0011] Obtaining product version information of the metadata; the product version information includes a software version currently running on the system and a repair program version released by the manufacturer;

[0012] Obtaining the influence range of the metadata; the influence range includes a module influence range of the repair program on the business system and a service influence range;

[0013] Analyzing configuration information of the metadata, the configuration information including component versions and running environment parameters on which the repair program depends;

[0014] Inputting the product version information, the influence range and the configuration information into the risk scoring model.

[0015] In one of the embodiments, based on the risk level, a predefined processing rule is matched to generate a processing strategy of the to-be-produced repair program, specifically including at least one of the following contents:

[0016] According to the risk level, a test priority rule is matched; the test priority rule includes: when the risk level of the to-be-produced repair program is a first risk, completing the test within a preset time;

[0017] According to the risk level, a production time limit rule is matched; the production time limit rule includes: when the risk level of the to-be-produced repair program is a first risk, completing the production within a preset time;

[0018] According to the risk level, a resource allocation rule is matched, the resource allocation rule including: allocating test resources based on the risk level of the to-be-produced repair program.

[0019] In one of the embodiments, the life cycle of the to-be-produced repair program is tracked, specifically including:

[0020] The life cycle stage of the to-be-produced repair program is monitored through a state machine; the life cycle stage includes release, reception, installation, test and production of the repair program;

[0021] When it is detected that the to-be-produced repair program has an exception in the life cycle stage, an alarm is triggered, and an exception event is recorded.

[0022] In one of the embodiments, the to-be-produced repair program and the metadata of the to-be-produced repair program are obtained, specifically including:

[0023] Based on the to-be-produced repair program, evaluation information of the to-be-produced repair program is obtained; the evaluation information includes risk influence and production and operation suggestion of the to-be-produced repair program;

[0024] The evaluation information is stored in the metadata of the to-be-produced repair program.

[0025] In one of the embodiments, the metadata of the to-be-produced repair program is input into a risk scoring model to determine a risk level of the to-be-produced repair program, specifically including:

[0026] Based on the business system running state, the parameter weight of the risk scoring model is adjusted; the running state of the business system includes transaction volume, response time and system load;

[0027] Based on the metadata and the parameter weight of the risk scoring model, the risk level of the to-be-produced repair program is determined.

[0028] In one of the embodiments, when it is detected that the to-be-produced repair program has an exception in the life cycle stage, an alarm is triggered, specifically including:

[0029] When it is detected that the to-be-produced repair program has an exception in the life cycle stage, version rollback is performed, and the environment state of the to-be-produced repair program is restored.

[0030] In a second aspect, the embodiments of the present application provide a repair program management device, including:

[0031] The obtaining module is configured to obtain a to-be-produced repair program and metadata of the to-be-produced repair program; the metadata includes product version information, influence range and configuration information of the repair program;

[0032] The determining module is configured to input the metadata of the to-be-produced repair program into a risk scoring model to determine a risk level of the to-be-produced repair program; the risk scoring model is used to calculate the risk of the to-be-produced repair program based on the metadata;

[0033] The generating module is configured to match a predefined processing rule based on the risk level to generate a processing strategy of the to-be-produced repair program;

[0034] The processing module is configured to process the to-be-produced repair program based on the processing strategy of the to-be-produced repair program and track the life cycle of the to-be-produced repair program.

[0035] In a third aspect, the embodiments of the present application provide an electronic device, including a processor and a memory in communication connection with the processor;

[0036] The memory stores computer execution instructions;

[0037] The processor executes the computer execution instructions stored in the memory to implement the method as any of the above.

[0038] In a fourth aspect, an embodiment of the present application provides a computer readable storage medium, and the computer readable storage medium stores computer execution instructions. When the computer execution instructions are executed by a processor, a method as any of the above is implemented.

[0039] In a fifth aspect, an embodiment of the present application provides a computer program product, and the computer program product includes a computer program. When the computer program is executed by a processor, a method as any of the above is implemented.

[0040] The repair program management method, device, equipment, storage medium and program product provided by the present application are provided. The repair program is used for correcting a business system. The method includes: obtaining a to-be-produced repair program and metadata of the to-be-produced repair program; the metadata includes product version information, an impact range and configuration information of the repair program; inputting the metadata of the to-be-produced repair program into a risk scoring model to determine a risk level of the to-be-produced repair program; the risk scoring model is used for calculating the risk of the to-be-produced repair program based on the metadata; based on the risk level, a predefined processing rule is matched to generate a processing strategy of the to-be-produced repair program; and based on the processing strategy of the to-be-produced repair program, the to-be-produced repair program is processed, and a life cycle of the to-be-produced repair program is tracked. Through the combination of the risk scoring model and the rule engine, the problem that the traditional repair program priority evaluation depends on artificial experience and lacks quantitative indicators is solved. The risk scoring model converts the metadata of the repair program into a risk level, and the uncertainty of subjective judgment is eliminated through quantitative scoring. According to the risk level, the predefined processing rule is matched to ensure that the high-risk repair program is processed first, the automation and dynamic adaptation of the repair program processing strategy are realized, and the rationality and efficiency of the operation and maintenance resource allocation are significantly improved. BRIEF DESCRIPTION OF DRAWINGS

[0041] The accompanying drawings, which are incorporated herein and form a part of the specification, illustrate embodiments consistent with the present application and, together with the description, further serve to explain the principles of the present application.

[0042] Figure 1 A flowchart of a repair program management method provided by an embodiment of the present application is shown in the figure.

[0043] Figure 2 A structural schematic diagram of a repair program management device provided by an embodiment of the present application is shown in the figure.

[0044] Figure 3 A structural schematic diagram of an electronic device provided by the present application is shown in the figure.

[0045] The specific embodiments of the application have been shown and described in the above drawings and text, and will be described in more detail below. These drawings and text are not intended to limit the scope of the concept of the application in any way, but to illustrate the concept of the application to those skilled in the art by referring to specific embodiments. DETAILED DESCRIPTION

[0046] The exemplary embodiments will be described in detail herein with reference to the attached drawings. The same numbers are used in different drawings to represent the same or similar elements. The embodiments described in the following exemplary embodiments are not meant to represent all embodiments consistent with the application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of the application as detailed in the appended claims.

[0047] It should be noted that the user information (including but not limited to user equipment information, user personal information, etc.) and data (including but not limited to data for analysis, stored data, displayed data, etc.) involved in the present application are all information and data authorized by the user or authorized by all parties, and the collection, storage, use, processing, transmission, provision, disclosure and application of related data comply with relevant laws, regulations and standards of relevant countries and regions, necessary security measures are taken, public order and good customs are not violated, and appropriate operation portals are provided for users to choose authorization or refusal.

[0048] And the present application involves big data analysis of user information (including but not limited to personal biological characteristics, identity data, consumption data, asset data, electronic terminal operation data, etc.), and uses artificial intelligence technology for automatic decision-making, and makes technical solutions based on automatic decision-making results that have a significant impact on personal rights and interests, provides corresponding operation portals for users to choose to agree or refuse automatic decision-making results; if the user chooses to refuse, the expert decision-making process is entered.

[0049] It should be noted that the repair program management method, device, equipment, storage medium and program product provided by the present application can be used in the field of artificial intelligence and the field of financial technology, and can also be used in any field other than the field of artificial intelligence and the field of financial technology. The application field of the repair program management method, device, equipment, storage medium and program product in the present application is not limited.

[0050] This application specifically targets business systems in the fintech field. The stability and security of these systems directly impact transaction continuity, data security, and customer trust. In practice, banking systems typically consist of hundreds or thousands of product components, encompassing operating systems (such as z / OS), databases, middleware, and various business application modules. Over long-term operation, vendors continuously release patches to address known defects, security vulnerabilities, or performance issues. However, due to the sheer number of patches (often thousands), the complexity of related components, and the significant differences in upgrade strategies, operations personnel must conduct risk assessments, prioritize, test, and make deployment decisions for these massive amounts of patches within a limited timeframe.

[0051] Existing technology: Current operation and maintenance processes rely heavily on manual operations, such as manually reviewing the remediation description files released by the vendor, manually comparing system environment differences, and manually recording evaluation results, which leads to low efficiency and a high risk of errors. In addition, the full lifecycle management of the remediation program (from release to installation, testing, deployment, and tracking) lacks systematic tool support. The status information at each stage is scattered, making it difficult to form a closed-loop management. During peak business periods or in the event of sudden failures, the operation and maintenance team often faces risks such as delayed remediation evaluation, conflicting testing resources, and loss of control over deployment progress, which directly affects business continuity.

[0052] The repair management method provided in this application solves the problems of traditional repair priority assessment relying on human experience and lacking quantitative indicators by combining a risk scoring model with a rule engine. The risk scoring model transforms the metadata of the repair into a risk level, and eliminates the uncertainty of subjective judgment through quantitative scoring. According to the risk level, predefined processing rules are matched to ensure that high-risk repairs are processed first, realizing the automation and dynamic adaptation of repair processing strategies, significantly improving the rationality and efficiency of operation and maintenance resource allocation, and aiming to solve the above-mentioned technical problems of existing technologies.

[0053] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will be described below with reference to the accompanying drawings.

[0054] like Figure 1 As shown, Figure 1 This is a flowchart of a repair program management method provided in an embodiment of this application. The repair program is used to correct a business system, and the repair program management method includes the following steps:

[0055] In step S101, a to-be-produced repair program and metadata of the to-be-produced repair program are acquired. The metadata includes product version information, an impact range, and configuration information of the repair program.

[0056] Specifically, the repair program to be put into the production environment is acquired, and metadata of the repair program is also acquired. The metadata is detailed description information of the repair program. The product version information can indicate which version of the product the repair program is for. The impact range can indicate which modules, functions, or data are affected by the repair program. The configuration information can include configuration parameters required by the repair program during running. For example, assuming that a vulnerability is found in a software product in version v2.3, a developer writes a repair program, and the metadata of the repair program is as follows: the product version information is v2.3; the impact range is a user login module in the software, because the vulnerability occurs in the user login process, and the repair program is only for the module; and the configuration information includes a database server address and a port required by the repair program during running.

[0057] In step S102, the metadata of the to-be-produced repair program is input into a risk scoring model to determine a risk level of the to-be-produced repair program. The risk scoring model is used to calculate the risk of the to-be-produced repair program based on the metadata.

[0058] Specifically, the risk scoring model can evaluate the risk of the to-be-produced repair program according to the input metadata. The risk scoring model can comprehensively consider various factors in the metadata, such as an influence degree of the repair program on a core function of the product, a number of users affected, complexity of the repair program, and the like, and then give a risk level. The risk level can be low, medium, high, or other more detailed classification manners. Taking the repair program for the user login module as an example, the risk scoring model analyzes the metadata. Because the user login module is an important function module of the software, a problem of the repair program can cause a large number of users to be unable to log in, so the impact range factor can increase the risk score. If the repair program has more code changes and complex logic, the risk score is also increased. If the repair program is for a software version with a large number of users, the number of users affected is large, and the risk level is also increased.

[0059] In step S103, a processing strategy of the to-be-produced repair program is generated based on the risk level and a predefined processing rule.

[0060] Specifically, the processing rule is prepared in advance according to different risks, and is used to guide how to process the to-be-produced repair program. The processing strategy includes, but is not limited to, test requirements of the repair program, a deployment manner, whether additional monitoring measures are required, and the like.

[0061] In one embodiment, step S103 specifically includes at least one of the following:

[0062] According to the risk level, a test priority rule is matched; the test priority rule includes: when the risk level of the to-be-deployed repair program is the first risk, the test is completed within a preset time.

[0063] Specifically, the first risk repair program needs to complete the test within a preset time, for example, within 72 hours, so when the risk level of the to-be-deployed repair program is the first risk, the test needs to be completed in priority, ensuring that the test task of the repair program is executed in priority. In other embodiments, multiple test priority rules are set according to the risk level of the to-be-deployed repair program. The risk level of the repair program can include multiple risk levels, and in this example, the first risk is a high risk level.

[0064] According to the risk level, a deployment time limit rule is matched; the deployment time limit rule includes: when the risk level of the to-be-deployed repair program is the first risk, the deployment is completed within a preset time.

[0065] According to the risk level, a resource allocation rule is matched, and the resource allocation rule includes: allocating test resources based on the risk level of the to-be-deployed repair program.

[0066] Specifically, when the risk level of the repair program is the first risk, the test priority rule is triggered automatically by the rule engine to ensure that the test task is executed in priority; at the same time, the deployment time limit rule is triggered to limit the deployment time window; and the resource allocation rule is triggered to allocate test resources in priority. This example matches multiple predefined processing rules through the rule engine, making the processing strategy of the repair program more flexible. For example, the test priority rule ensures that the test task of the high-risk repair program is not delayed; the deployment time limit rule avoids business risks caused by delay of the repair program; and the resource allocation rule optimizes the utilization efficiency of operation and maintenance resources, enhancing the adaptability of the repair program processing strategy and making operation and maintenance management more efficient.

[0067] Step S104: based on the processing strategy of the to-be-deployed repair program, processing the to-be-deployed repair program and tracking the life cycle of the to-be-deployed repair program.

[0068] Specifically, according to the processing strategy generated in step S103, specific processing operations such as testing, deployment, etc. are started on the to-be-deployed repair program; at the same time, the entire life cycle of the repair program is tracked, from being acquired to testing, deployment, and finally running in the production environment, the entire process is monitored and recorded, so that problems can be quickly located and solved when they occur, and basis can also be provided for subsequent optimization and improvement.

[0069] The application solves the problem of the traditional repair program priority assessment relying on artificial experience and lacking quantitative indicators by combining a risk scoring model with a rule engine. The risk scoring model converts the metadata of the repair program into a risk level, eliminates the uncertainty of subjective judgment through quantitative scoring, matches the predefined processing rules according to the risk level, ensures that high-risk repair programs are processed first, realizes the automation and dynamic adaptation of the repair program processing strategy, and significantly improves the rationality and efficiency of the operation and maintenance resource allocation.

[0070] In one of the embodiments, step S102 specifically includes the following steps:

[0071] Obtaining product version information of the metadata; the product version information includes a software version of the current system and a repair program version published by a manufacturer.

[0072] Obtaining an impact range of the metadata; the impact range includes a module impact range of the repair program on the business system and a service impact range.

[0073] Analyzing configuration information of the metadata; the configuration information includes a component version and a running environment parameter on which the repair program depends.

[0074] Inputting the product version information, the impact range and the configuration information into the risk scoring model.

[0075] Specifically, the product version information, the impact range and the configuration information are extracted step by step as input parameters of the risk scoring model; for example, the product version information is used to compare the compatibility of the current system and the repair program; the impact range is used to evaluate the potential impact area of the repair program on the business system; and the configuration information is used to analyze whether the dependent conditions of the repair program are met in the current system environment.

[0076] The example extracts the product version information, the impact range and the configuration information step by step, so that the input data of the risk scoring model is more accurate. For example, the comparison of the product version information can avoid the evaluation deviation caused by the incompatibility of the repair program and the current system version; the detailed analysis of the impact range can clearly define the specific impact area of the repair program on the business system; and the analysis of the configuration information can ensure the satisfaction of the dependent conditions of the repair program, thereby enhancing the accuracy of the risk scoring model and making the repair program priority adaptation result more suitable for actual operation and maintenance requirements.

[0077] In one of the embodiments, step S104 specifically includes the following steps:

[0078] Monitoring the life cycle stage of the repair program to be put into production through a state machine; the life cycle stage includes the release, reception, installation, testing and production of the repair program.

[0079] When detecting that the repair program to be put into production has an exception in the life cycle stage, triggering an alarm and recording the exception event.

[0080] Specifically, the state machine is used to manage the state transition model of the repair program life cycle stage, such as the state migration from testing to production completion. After generating the repair program processing strategy, the state machine continues to monitor its life cycle stage. For example, if the repair program stays in the testing stage for more than a preset threshold, the state machine detects the exception and triggers an alarm, records the exception event, and notifies the operation and maintenance personnel to intervene. The example monitors the life cycle stage of the repair program through the state machine to ensure the real-time and transparency of the state of each stage. For example, timely alarm of abnormal state (such as testing delay) can avoid interruption of the repair program processing flow, ensuring that the repair program proceeds as planned.

[0081] In one of the embodiments, step S101 specifically includes the following steps:

[0082] Based on the repair program to be put into production, the evaluation information of the repair program to be put into production is obtained; the evaluation information includes the risk impact and production operation and maintenance suggestion of the repair program to be put into production.

[0083] The evaluation information is stored in the metadata of the repair program to be put into production.

[0084] Specifically, before obtaining the repair program metadata, the evaluation information is obtained through the multi-role collaboration platform, such as the risk impact description and the production operation and maintenance suggestion, and these information is stored in the metadata of the repair program as the input data of the risk scoring model. The example integrates user evaluation information through the multi-role collaboration platform, making the repair program metadata more comprehensive. For example, the user's risk impact description can supplement the quantitative analysis of the risk scoring model, and the production operation and maintenance suggestion can optimize the development of the processing strategy, enhancing the comprehensiveness and collaboration efficiency of the repair program evaluation.

[0085] In one of the embodiments, step S102 specifically includes the following steps:

[0086] Based on the running state of the business system, the parameter weight of the risk scoring model is adjusted; the running state of the business system includes the transaction volume, the response time and the system load.

[0087] Based on the metadata and the parameter weight of the risk scoring model, the risk level of the repair program to be put into production is determined.

[0088] Specifically, when the running state of the business system is high load, the weight of the service response time is increased, and the repair program with greater impact on service availability is prioritized. The example adjusts the parameter weight through the real-time running state of the business system, making the risk scoring model more suitable for the current business needs. For example, in the high load scenario, the scoring model prioritizes the impact of the repair program on service availability rather than performance optimization, thereby optimizing the processing strategy of the repair program and enhancing the scene adaptability of the risk scoring model.

[0089] In one embodiment, step S104 specifically includes the following steps:

[0090] When an anomaly is detected in the lifecycle phase of a patch to be deployed, a version rollback is performed, and the environment state of the patch to be deployed is restored.

[0091] Specifically, if an anomaly is detected in the lifecycle of a patch to be deployed, such as an environmental anomaly, the patch can be rolled back to its previous state to ensure environmental availability. This example enhances the adaptability of the patch and prevents business system failures caused by patch anomalies.

[0092] like Figure 2 As shown, Figure 2 This is a schematic diagram of the structure of a repair management device provided in an embodiment of this application. The repair management device 200 includes: an acquisition module 201, used to acquire a repair program to be put into production and its metadata; the metadata includes the product version information, scope of impact, and configuration information of the repair program; a determination module 202, used to input the metadata of the repair program to be put into production into a risk scoring model to determine the risk level of the repair program to be put into production; the risk scoring model is used to calculate the risk of the repair program to be put into production based on the metadata; a generation module 203, used to generate a processing strategy for the repair program to be put into production based on the risk level and matching predefined processing rules; and a processing module 204, used to process the repair program to be put into production based on the processing strategy and track the lifecycle of the repair program to be put into production.

[0093] In one embodiment, the determining module 202 is used to obtain product version information of metadata; the product version information includes the software version currently running on the system and the patch version released by the vendor; obtain the scope of impact of the metadata; the scope of impact includes the scope of impact of the patch on the modules and services of the business system; analyze the configuration information of the metadata, the configuration information includes the component versions and runtime environment parameters on which the patch depends; and input the product version information, scope of impact and configuration information into the risk scoring model.

[0094] In one embodiment, the generation module 203 is used to match test priority rules according to risk level; the test priority rules include: when the risk level of the repair program to be put into production is the first risk, the test shall be completed within a preset time; match production time limit rules according to risk level; the production time limit rules include: when the risk level of the repair program to be put into production is the first risk, production shall be completed within a preset time; match resource allocation rules according to risk level; the resource allocation rules include: allocating test resources based on the risk level of the repair program to be put into production.

[0095] In one of the embodiments, the processing module 204 is configured to monitor a life cycle phase of the to-be-production repair program by the state machine; the life cycle phase comprises release, receiving, installation, testing and production of the repair program; when detecting that the to-be-production repair program has an exception in the life cycle phase, triggering an alarm and recording the exception event.

[0096] In one of the embodiments, the obtaining module 201 is configured to obtain evaluation information of the to-be-production repair program based on the to-be-production repair program; the evaluation information comprises risk influence and production operation suggestion of the to-be-production repair program; and the evaluation information is stored into the metadata of the to-be-production repair program.

[0097] In one of the embodiments, the determining module 202 is configured to adjust a parameter weight of the risk scoring model based on the running state of the business system; the running state of the business system comprises transaction volume, response time and system load; and the risk level of the to-be-production repair program is determined based on the metadata and the parameter weight of the risk scoring model.

[0098] In one of the embodiments, the processing module 204 is configured to perform version rollback and restore the environment state of the to-be-production repair program when detecting that the to-be-production repair program has an exception in the life cycle phase.

[0099] The repair program management apparatus 200 provided in the embodiment can execute the method provided in the method embodiment, and has similar implementation principles and technical effects, which will not be described here in detail.

[0100] The embodiment of the present application provides an electronic device, comprising: a processor, and a memory connected with the processor in communication;

[0101] The memory stores computer execution instructions;

[0102] The processor executes the computer execution instructions stored in the memory to implement the method as described above.

[0103] Figure 3 The structure schematic diagram of the electronic device provided in the present application is shown in the figure. Figure 3 As shown in the figure, the electronic device 300 provided in the embodiment comprises at least one processor 301 and a memory 302. Optionally, the electronic device 300 further comprises a communication component 303. The processor 301, the memory 302 and the communication component 303 are connected through a bus 304.

[0104] In the specific implementation process, the at least one processor 301 executes the computer execution instructions stored in the memory 302, so that the at least one processor 301 executes the method as described above.

[0105] The specific implementation process of the processor 301 can refer to the method embodiments described above, which have similar implementation principles and technical effects, and will not be described here again.

[0106] The present application also provides a computer program product comprising a computer program which, when executed by a processor, implements the method described above.

[0107] The present application also provides a computer-readable storage medium having computer-executable instructions stored therein, which, when executed by a processor, implement the method described above.

[0108] It should be noted that, for each of the above method embodiments, in order to simply describe, each is described as a combination of a series of actions, but those skilled in the art should know that the present application is not limited by the order of the actions described, because according to the present application, certain steps can be performed in other order or simultaneously. Secondly, those skilled in the art should know that the embodiments described in the specification are all optional embodiments, and the actions and modules involved are not necessarily required by the present application.

[0109] Further, it should be noted that although each step in the flowchart is displayed in sequence according to the arrow, these steps are not necessarily executed in sequence according to the arrow. Unless otherwise stated in this document, the execution of these steps has no strict order limitation, and these steps can be executed in other order. Moreover, at least part of the steps in the flowchart can include multiple sub-steps or multiple stages, which are not necessarily executed at the same time, but can be executed at different times, and the execution order of these sub-steps or stages is not necessarily sequential, but can be executed alternately or alternately with at least part of other steps or other steps.

[0110] It should be understood that the above-described device embodiments are only illustrative, and the device of the present application can also be implemented in other ways. For example, the division of units / modules in the above-described embodiments is only a logical functional division, and actual implementation can have another division method. For example, multiple units, modules or components can be combined, or can be integrated into another system, or some features can be omitted or not executed.

[0111] In addition, unless otherwise specified, each functional unit / module in each embodiment of the present application can be integrated in one unit / module, or each unit / module can exist physically, or two or more units / modules can be integrated together. The above integrated unit / module can be realized in the form of hardware or in the form of a software program module.

[0112] If the integrated units / modules are implemented in the form of hardware, the hardware can be a digital circuit, an analog circuit, etc. The physical implementation of the hardware structure includes, but is not limited to, transistors, memristors, etc. Unless otherwise specified, the processor can be any appropriate hardware processor, such as a CPU, a GPU, an FPGA, a DSP, an ASIC, etc. Unless otherwise specified, the storage unit can be any appropriate magnetic storage medium or magneto-optical storage medium, such as resistive random access memory (RRAM), dynamic random access memory (DRAM), static random access memory (SRAM), enhanced dynamic random access memory (EDRAM), high-bandwidth memory (HBM), hybrid memory cube (HMC), etc.

[0113] If the integrated units / modules are implemented in the form of software program modules and sold or used as independent products, they can be stored in a computer readable storage medium. Based on this understanding, the technical solutions of the present application or the essential part or all or part of the technical solutions that make contributions to the prior art can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes a plurality of instructions for causing a computer device (which can be a personal computer, a server or a network device, etc.) to execute all or part of the steps of the embodiments of the present application. The aforementioned storage medium includes a U disk, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk or an optical disk, and various media that can store program codes.

[0114] In the above embodiments, the description of each embodiment has its own focus, and the parts not described in detail in a certain embodiment can be referred to the related description of other embodiments. The technical features of the above embodiments can be combined arbitrarily. In order to make the description concise, not all possible combinations of the technical features in the above embodiments are described, but as long as the combination of the technical features does not exist contradictory, it should be considered as the scope of the present application.

[0115] Other embodiments of the application will be apparent to those skilled in the art from consideration of the specification and practice of the application disclosed herein. It is intended that the specification and examples be considered as exemplary only, with the true scope and spirit of the application being indicated by the following claims.

[0116] It is to be understood that the application is not limited to the precise construction herein disclosed and shown in the drawings, and that various modifications and changes can be made by those skilled in the art without departing from the scope of the application. The scope of the application is limited only by the claims that follow.

Claims

1. A method for managing repair programs, wherein the repair programs are used to fix business systems, characterized in that, include: Obtain the repair program to be put into production, as well as the metadata of the repair program to be put into production; The metadata includes the product version information, scope of impact, and configuration information of the fix; The metadata of the repair procedure to be put into production is input into the risk scoring model to determine the risk level of the repair procedure to be put into production; The risk scoring model is used to calculate the risk of the repair procedure to be put into production based on the metadata. Based on the risk level, a processing strategy for the repair program to be put into production is generated by matching predefined processing rules. Based on the processing strategy of the repair program to be put into production, the repair program to be put into production is processed, and the life cycle of the repair program to be put into production is tracked.

2. The method according to claim 1, characterized in that, The step of inputting the metadata of the repair procedure to be put into production into the risk scoring model specifically includes: Obtain the product version information of the metadata; the product version information includes the software version currently running on the system and the patch version released by the manufacturer; Obtain the scope of impact of the aforementioned metadata; the scope of impact includes the impact of the fix on modules and services of the business system. Analyze the configuration information of the metadata, which includes the versions of the components the fix depends on and the runtime environment parameters; The product version information, the scope of impact, and the configuration information are input into the risk scoring model.

3. The method according to claim 1, characterized in that, The process of generating a processing strategy for the remediation procedure to be deployed based on the risk level and matching predefined processing rules specifically includes at least one of the following: Based on the risk level, a test priority rule is matched; the test priority rule includes: when the risk level of the repair procedure to be put into production is the first risk, the test shall be completed within a preset time. Based on the risk level, a production time limit rule is matched; the production time limit rule includes: when the risk level of the repair procedure to be put into production is the first risk, production shall be completed within a preset time. Based on the risk level, a resource allocation rule is matched, which includes allocating test resources based on the risk level of the repair procedure to be put into production.

4. The method according to claim 1, characterized in that, The tracking of the lifecycle of the repair procedure to be put into production specifically includes: The lifecycle stages of the patch to be deployed are monitored through a state machine; the lifecycle stages include the release, receipt, installation, testing, and deployment of the patch. When an anomaly is detected in the lifecycle stage of the repair program to be put into production, an alarm is triggered and the abnormal event is recorded.

5. The method according to claim 1, characterized in that, The acquisition of the repair program to be put into production, and the metadata of the repair program to be put into production, specifically includes: Based on the repair procedure to be put into production, obtain the evaluation information of the repair procedure to be put into production; the evaluation information includes the risk impact of the repair procedure to be put into production and production operation and maintenance suggestions; The evaluation information is stored in the metadata of the repair program to be put into production.

6. The method according to claim 2, characterized in that, The step of inputting the metadata of the remediation procedure to be put into production into the risk scoring model to determine the risk level of the remediation procedure to be put into production specifically includes: The parameter weights of the risk scoring model are adjusted based on the operating status of the business system; the operating status of the business system includes transaction volume, response time, and system load. Based on the metadata and the parameter weights of the risk scoring model, the risk level of the repair procedure to be put into production is determined.

7. The method according to claim 4, characterized in that, When an anomaly is detected in the lifecycle stage of the repair program to be put into production, an alarm is triggered, specifically including: When an anomaly is detected in the lifecycle phase of the patch to be deployed, a version rollback is performed, and the environment state of the patch to be deployed is restored.

8. A repair program management device, characterized in that, include: The acquisition module is used to acquire the repair program to be put into production, as well as the metadata of the repair program to be put into production; The metadata includes the product version information, scope of impact, and configuration information of the fix; The determination module is used to input the metadata of the repair procedure to be put into production into the risk scoring model to determine the risk level of the repair procedure to be put into production; The risk scoring model is used to calculate the risk of the repair procedure to be put into production based on the metadata. The generation module is used to generate a processing strategy for the repair program to be put into production based on the risk level and predefined processing rules. The processing module is used to process the repair program to be put into production based on the processing strategy of the repair program to be put into production, and to track the life cycle of the repair program to be put into production.

9. An electronic device, characterized in that, include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1 to 7.

11. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method of any one of claims 1 to 7.

Images