Configuration change risk management and control method and device, storage medium and computer equipment
By using a configuration change model and a dynamically updated rules engine architecture, configuration changes are uniformly identified and classified, enabling efficient risk management, ensuring the legality of changes and risk identification, and preventing failures from affecting business operations.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-12-30
- Publication Date
- 2026-04-07
AI Technical Summary
Existing configuration change risk management methods cannot ensure the accuracy and completeness of detection rules, leading to frequent failures during configuration change processes and affecting the stable operation of enterprise business.
By configuring a change model, a change instance of the database is generated. Then, a dynamically updatable rule engine architecture with general and personalized checkers is used to verify the data type and business logic of the change instance. Custom notifications are pushed, and risk blocking is implemented when verification fails.
It enables the identification and classification of changes to different systems within a unified framework, improving the effectiveness and efficiency of verification rules, ensuring the legality of changes at the basic data level and the identification of risks at the business level, and preventing business disruptions due to change failures.
Smart Images
Figure CN121810053A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of computer technology, and in particular to a method, apparatus, storage medium and computer equipment for managing configuration change risks. Background Technology
[0002] With the accelerating pace of enterprise informatization, various systems are constantly iterating and upgrading, making configuration changes a critical operation to ensure that systems adapt to business development. From simple configuration adjustments for early standalone systems to comprehensive configuration changes covering Admin systems, middleware, and complex business systems today, the scale and complexity have grown exponentially.
[0003] Currently, most configuration change risk management methods adopt a decentralized approach, which involves developing independent detection scripts or tools for different systems. This results in significant barriers to change detection and risk awareness between systems, making it difficult to share and collaborate on information in a timely manner. Consequently, it is difficult to ensure the accuracy and completeness of detection rules, leading to frequent failures during configuration changes and seriously affecting the stable operation of enterprise business. Summary of the Invention
[0004] The purpose of this application is to at least address one of the aforementioned technical deficiencies, particularly the technical deficiency in existing configuration change risk management methods that fail to ensure the accuracy and completeness of detection rules, leading to frequent failures during configuration changes and seriously affecting the stable operation of enterprise business.
[0005] This application provides a method for managing configuration change risks, the method comprising:
[0006] The configuration change model generates database change instances and determines the corresponding back shards for the change instances; the configuration change model is equipped with a general inspector and a personalized inspector, and the personalized inspector adopts a dynamically updatable rule engine architecture.
[0007] The change instance is routed to the corresponding detection node in the configuration change model based on the post-sharding;
[0008] In the detection node, the general inspector is invoked to perform data type verification on the change instance, and the personalized inspector is invoked to perform business logic verification on the change instance, and the verification results are obtained.
[0009] A custom notification is pushed to the verification result, and a risk blocking operation is performed when the verification result fails.
[0010] Optionally, the configuration process of the configuration change model includes:
[0011] Metadata parsing is performed on the database to obtain business attributes and data structures, and an initial change model is defined based on the business attributes and data structures.
[0012] Multiple sharding rules for the database are determined according to a preset partitioning strategy; each sharding rule corresponds to a rule execution environment.
[0013] Based on each sharding rule, multiple subsequent shards are set in the initial change model to obtain an intermediate change model;
[0014] Based on the database's verification requirements, multiple checkers are attached to the intermediate change model to obtain the final configuration change model.
[0015] Optionally, the dynamic update process of rules in the personalized inspector includes:
[0016] Historical data within a predetermined time period is acquired at a preset frequency; the historical data includes discrete fields and continuous fields.
[0017] Numerical clustering is performed on the discrete fields, and an enumeration list is generated based on the clustering results. In addition, a range calculation is performed on the continuous fields to obtain a reasonable value range.
[0018] The personalized checker is dynamically updated based on the enumeration list and the reasonable value range.
[0019] Optionally, generating a database change instance through configuring a change model includes:
[0020] The configuration change model is used to monitor the message stream in the database to capture change data;
[0021] The configuration change model is used to parse the change fields in the change data and the comparison values of the change fields before and after the change. The change fields and the comparison values are then structured to form change instances.
[0022] Optionally, the step of calling the general inspector in the detection node to perform data type validation on the changed instance includes:
[0023] The general inspector is invoked through the detection node;
[0024] The general inspector is used to obtain the type validation rules corresponding to each field in the change instance, and the field values of the corresponding fields are validated using each type validation rule.
[0025] Optionally, the step of invoking the personalization inspector to perform business logic validation on the changed instance includes:
[0026] The personalized inspector is invoked through the detection node;
[0027] The personalization inspector is used to read discrete and continuous fields in the change instance, and to determine the enumeration list corresponding to the discrete fields and the reasonable value range corresponding to the continuous fields.
[0028] In the personalized checker, the field values of the discrete field are numerically validated based on the enumeration list, and the field values of the continuous field are range-validated based on the reasonable value range.
[0029] Optionally, the risk blocking operation when the verification result fails includes:
[0030] When the verification result is a failure, determine the failed detection item and the risk level of the detection item;
[0031] The detection item is blocked by taking countermeasures corresponding to the level of risk, and the results are sent to the person in charge of the detection item.
[0032] This application also provides a configuration change risk management device, including:
[0033] The instance generation module is used to generate a database change instance through a configuration change model and determine the corresponding post-shard of the change instance; the configuration change model is equipped with a general inspector and a personalized inspector, and the personalized inspector adopts a dynamically updatable rule engine architecture.
[0034] The node routing module is used to route the change instance to the corresponding detection node in the configuration change model according to the post-sharding;
[0035] The data verification module is used in the detection node to call the general checker to perform data type verification on the change instance and to call the personalized checker to perform business logic verification on the change instance, and obtain the verification result.
[0036] The risk blocking module is used to push customized notifications to the verification results and to perform risk blocking operations when the verification results are failed.
[0037] This application also provides a storage medium storing computer-readable instructions, which, when executed by one or more processors, cause the one or more processors to perform the steps of the configuration change risk management method as described in any of the above embodiments.
[0038] This application also provides a computer device, including: one or more processors, and memory;
[0039] The memory stores computer-readable instructions, which, when executed by the one or more processors, perform the steps of the configuration change risk management method as described in any of the above embodiments.
[0040] As can be seen from the above technical solutions, the embodiments of this application have the following advantages:
[0041] The configuration change risk management method, apparatus, storage medium, and computer equipment provided in this application can generate a database change instance after each configuration change through a configuration change model. This allows changes from different systems to be identified and classified within a unified framework. Then, the corresponding post-sharding for each change instance can be determined. This post-sharding can systematically organize different risk rules, improving the effectiveness of the verification rules. Furthermore, the change instance can be routed to the corresponding detection nodes in the configuration change model for parallel processing based on the post-sharding, improving efficiency. Subsequently, in each detection node, a general checker and a personalized checker can be invoked to comprehensively verify the change instance from different levels. The verification results not only ensure the legality of the change at the basic data level but also accurately identify risks at the business level. The personalized checker employs a dynamically updatable rule engine architecture, allowing for dynamic optimization based on actual conditions, improving the practicality of the rules. After obtaining the final verification result, this application can send a customized notification to the verification result and perform risk blocking operations when the verification result fails, preventing the impact of change failures on enterprise business. Attached Figure Description
[0042] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0043] Figure 1 A flowchart illustrating a configuration change risk management method provided in this application embodiment;
[0044] Figure 2 A schematic diagram of a configuration change risk management device provided in this application embodiment;
[0045] Figure 3 This is a schematic diagram of the internal structure of a computer device provided in an embodiment of this application. Detailed Implementation
[0046] 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, and 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.
[0047] Currently, most configuration change risk management methods adopt a decentralized approach, which involves developing independent detection scripts or tools for different systems. This results in significant barriers to change detection and risk awareness between systems, making it difficult to share and collaborate on information in a timely manner. Consequently, it is difficult to ensure the accuracy and completeness of detection rules, leading to frequent failures during configuration changes and seriously affecting the stable operation of enterprise business.
[0048] Based on this, this application proposes the following technical solution, as detailed below:
[0049] In one embodiment, such as Figure 1 As shown, Figure 1 This is a flowchart illustrating a configuration change risk management method provided in an embodiment of this application. This application provides a configuration change risk management method, specifically including the following:
[0050] S110: Generate database change instances by configuring change models and determine the corresponding post-shards for the change instances; the configuration change model is equipped with a general inspector and a personalized inspector, and the personalized inspector adopts a dynamically updatable rule engine architecture.
[0051] In this step, after each system configuration change, the risk management system can generate a corresponding database change instance through the configuration change model, so that configuration changes of different systems can be identified and classified under a unified framework. Subsequently, the corresponding post-shard can be determined. The post-shard can organize different risk rules in an orderly manner and improve the effectiveness of the verification rules.
[0052] Understandably, the configuration change model is the core metadata definition and control blueprint in a risk management system. It provides a standardized, structured, and semantic abstract description of changeable configurations within the system. Therefore, through this model, the risk management system can perform structured parsing and semantic mapping of change content based on a pre-built configuration change model and its corresponding database, thereby generating change instances. This allows configuration changes from different systems, configuration types, and granularities to be uniformly abstracted into a single data model and processing framework, ensuring that all types of configuration changes have a consistent logical expression and identifiable characteristics.
[0053] Subsequently, the configuration change model can further determine the corresponding post-shards for a change instance based on its attribute characteristics, scope of impact, and change order. Here, post-sharding refers to the mechanism in the configuration change model used to dynamically divide and route change instances to different processing units according to predefined strategies. Therefore, the model can systematically orchestrate and organize various adaptive validation rules, enabling different rules to act on their respective change instances one by one according to predetermined execution logic and dependencies.
[0054] It should be noted that the configuration change model incorporates multiple inspectors as internal rule execution units. Each inspector defines verification rules corresponding to its functional positioning, enabling automated verification of change instances from multiple dimensions. For example, the inspectors incorporated into the configuration change model in this application may include general inspectors and personalized inspectors. General inspectors primarily carry basic verification rules applicable to various business scenarios, such as data type verification and format verification. Personalized inspectors, on the other hand, can perform targeted verifications based on business logic, operational rules, and business strategies, building upon the passing of general checks. For instance, they may specify rules such as ensuring coupon discount rates do not exceed preset discount rates or that product promotion start times must precede end times.
[0055] S120: Route the change instance to the corresponding detection node in the configuration change model based on the post-sharding.
[0056] In this step, after determining the post-shard of the change instance through step S110, the configuration change model can route the change instance to the corresponding detection node for processing, so that configuration changes of different categories or priorities can enter the appropriate detection execution channel.
[0057] Understandably, each detection node, as a relatively independent rule execution entity, can perform rule verification operations on the received change instances in parallel, thereby avoiding processing blockage or response delay caused by the increase in the number of changes in the traditional serial detection mode.
[0058] S130: In the detection node, the general inspector is called to perform data type verification on the changed instance, and the personalized inspector is called to perform business logic verification on the changed instance, and the verification results are obtained.
[0059] In this step, after the change instance is routed to the detection node through step S120, the configuration change model can call the general checker to perform data type verification on the change instance and call the personalized checker to perform business logic verification on the change instance in the detection node. This allows the configuration change model to perform comprehensive verification of the change instance from different levels. The verification results obtained in this way can not only ensure the legality of the change at the basic data level, but also accurately identify risks at the business level.
[0060] S140: Push customized notifications for verification results and perform risk blocking operations when the verification result fails.
[0061] In this step, after obtaining the verification result of the configuration change model output for the change instance through step S130, the risk management system can push a custom notification to the verification result and perform risk blocking operations when the verification result fails, so as to avoid the impact of change failure on the enterprise's business.
[0062] Specifically, the risk management system can push customized notifications of the verification results of change instances based on preset notification policies and business rules, promptly sending them to the relevant operations and maintenance personnel, business owners, or automated operations and maintenance platforms, thereby achieving visualized feedback and rapid response to configuration change results. When the verification result is determined to be a failure or high-risk, the risk management system can also automatically trigger risk blocking operations to intercept, roll back, or freeze the relevant configuration changes, preventing potentially risky changes from taking effect or spreading to the production environment.
[0063] In the above embodiments, after each configuration change, a change instance in the database can be generated through the configuration change model. This allows changes from different systems to be identified and categorized within a unified framework. Then, the corresponding post-shard can be determined. This post-shard can systematically organize different risk rules, improving the effectiveness of the verification rules. Furthermore, the change instance can be routed to the corresponding detection nodes in the configuration change model for parallel processing based on the post-shard, improving efficiency. Subsequently, in each detection node, a general checker and a personalized checker can be invoked to comprehensively verify the change instance from different levels. The resulting verification not only ensures the legality of the change at the basic data level but also accurately identifies risks at the business level. The personalized checker employs a dynamically updatable rule engine architecture, enabling dynamic optimization based on actual conditions and improving the practicality of the rules. After obtaining the final verification result, this application can send a customized notification to the verification result and perform risk blocking operations when the verification result fails, preventing the impact of change failures on enterprise business.
[0064] In one embodiment, the configuration process for configuring the change model in step S110 may include:
[0065] S111: Perform metadata parsing on the database to obtain business attributes and data structures, and obtain an initial change model based on the defined business attributes and data structures.
[0066] S112: Determine multiple sharding rules for the database based on the preset partitioning strategy; each sharding rule corresponds to a rule execution environment.
[0067] S113: Based on each sharding rule, set multiple subsequent shards in the initial change model to obtain the intermediate change model.
[0068] S114: Based on the database verification requirements, multiple checkers are attached to the intermediate change model to obtain the final configuration change model.
[0069] In this embodiment, when constructing the configuration change model, the risk management system can first perform metadata parsing on the corresponding database to obtain metadata such as business attributes and data structures, and then define an initial change model based on these metadata. Subsequently, the risk management system can determine multiple sharding rules of the database according to a preset partitioning strategy, and set multiple post-sharding in the initial change model based on each sharding rule to obtain an intermediate change model. Finally, multiple checkers can be attached to the intermediate change model based on the database's verification requirements to obtain the final configuration change model.
[0070] Specifically, after the risk management system parses the metadata in the database, it can use this metadata to uniformly model the objects, attributes, and change boundaries involved in the configuration changes, thereby forming an initial change model that accurately reflects the actual structure and business semantics of the database. It should be noted that the initial change model not only defines the business attributes and data structures of each field in the database, but also defines metadata information such as constraints and dependencies, which are not restricted here.
[0071] Based on the initial change model, the risk management system can logically partition the database according to a pre-defined partitioning strategy, determining multiple sharding rules. Each sharding rule corresponds to an independent rule execution environment, used to handle configuration change verification tasks of a specific category or scope. Multiple subsequent shards can be set in the initial change model according to each sharding rule, constructing an intermediate change model with sharding scheduling capabilities. Subsequently, the risk management system can incorporate the database's verification requirements in terms of security, stability, and business consistency by attaching corresponding checkers to the intermediate change model, ultimately forming a configuration change model with a clear structure, complete rules, and scalability.
[0072] In one embodiment, the dynamic update process of the rules in the personalization inspector in step S110 may include:
[0073] S115: Obtain historical data within a historical time period according to a preset frequency; historical data includes discrete fields and continuous fields.
[0074] S116: Perform numerical clustering on discrete fields and generate an enumeration list based on the clustering results; and perform range calculation on continuous fields to obtain a reasonable value range.
[0075] S117: Dynamically update rules for the personalized checker based on the enumeration list and reasonable value range.
[0076] In this embodiment, the personalized checker in the configuration change model adopts a dynamically updatable rule engine architecture, thus enabling dynamic updates to its defined personalized verification rules. During each update, the risk management system acquires historical data within a given time period; then, it performs numerical clustering on the discrete fields and generates an enumeration list based on the clustering results; and performs range calculations on the continuous fields to obtain a reasonable value range. Based on the enumeration list and the reasonable value range, the personalized checker rules can be dynamically updated.
[0077] Understandably, through a dynamically updatable rule engine architecture, the personalized verification rules defined by the personalized inspector no longer rely on manual static configuration, but can continuously evolve based on system operating status and historical data characteristics. During each rule update, the risk management system can obtain historical data samples related to configuration changes within a preset historical time period, and perform statistical analysis and feature extraction on this historical data to dynamically update and reconfigure the verification rules in the personalized inspector, ensuring that rule constraints can keep pace with the real-time changes in business data.
[0078] For example, in an order configuration change scenario, the risk management system can scan the historical data of the "order settlement configuration table" within the last 3 months at regular intervals and extract field values that are highly related to business stability, such as warehouse code, order discount rate and settlement currency.
[0079] For discrete fields like "warehouse code", the risk management system can perform cluster analysis on its field values. If the analysis finds that the warehouse code values are mainly concentrated on three stable values, "WH01", "WH02", and "WH03", then an enumeration list is automatically generated: ['WH01', 'WH02', 'WH03']. This list is then used as the enumeration list for warehouse codes and updated in the personalized verification rules to intercept abnormal warehouse codes that occur during configuration changes.
[0080] For discrete fields such as "order discount rate", the risk management system can perform statistical analysis on its field values. After removing obvious anomalies or extreme values that occur only once, if the main distribution range of the order discount rate is calculated to be [0.1, 0.99], then this range is determined as the reasonable range of the order discount rate and updated in the personalized verification rules to intercept out-of-range order discount rates that occur during configuration changes.
[0081] In one embodiment, the process of generating a database change instance by configuring the change model in step S110 may include:
[0082] S118: Monitor message streams in the database by configuring a change model to capture change data.
[0083] S119: Use the configuration change model to parse the changed fields in the changed data and the comparison values of the changed fields before and after the change, and structure the changed fields and comparison values to form a change instance.
[0084] In this embodiment, the risk management system can listen to the message stream in the database through the configuration change model and capture the change data generated by various configuration change operations. After capturing the change data, the risk management system can trigger the configuration change model to parse the change fields in the change data and the comparison values of the change fields before and after the change, and structure the change fields and comparison values to form a change instance with a unified format.
[0085] Furthermore, after the risk management system captures the changed data, it can also generate a capture notification for the changed data and push the notification to a preset information interface, such as the relevant operation and maintenance personnel, business managers, or automated operation and maintenance platform, so as to facilitate subsequent audit tracking and ensure the visibility of changes.
[0086] In one embodiment, the process of calling the general inspector in the detection node to perform data type validation on the changed instance in step S130 may include:
[0087] S131: Call the general inspector through the detection node.
[0088] S132: Use the general inspector to obtain the type validation rules corresponding to each field in the change instance, and use each type validation rule to perform type validation on the field value of the corresponding field.
[0089] In this embodiment, during general rule verification, the risk control system can call the general inspector through the detection node, and then use the general inspector to obtain the type verification rule corresponding to each field in the change instance, and use each type verification rule to perform type verification on the field value of the corresponding field.
[0090] Specifically, the risk management system can leverage the detection nodes in the configuration change model to proactively invoke the general checker mounted within the model, making it the core unit for rule execution in the verification process of change instances. Once invoked, the general checker automatically retrieves the type validation rules corresponding to each field in the change instance. These rules typically include the field's data type and format specifications. Subsequently, the general checker performs type validation on the actual field values in the change instance, comparing the field values with their corresponding validation rules to determine whether they conform to predefined data types and format specifications. When fields that do not meet the conditions are found, exception information is recorded promptly, thereby ensuring that all changed fields are legal and valid in terms of basic data structure, type, and format.
[0091] In one embodiment, the process of calling the personalization inspector to perform business logic verification on the changed instance in step S130 may include:
[0092] S133: Invoke the personalized inspector through the detection node.
[0093] S134: Use the personalization inspector to read discrete and continuous fields in the change instance, and determine the enumeration list corresponding to the discrete fields and the reasonable value range corresponding to the continuous fields.
[0094] S135: In the personalized inspector, perform numerical validation on the field values of discrete fields based on an enumerated list, and perform range validation on the field values of continuous fields based on a reasonable value range.
[0095] In this embodiment, during personalized rule verification, the risk control system can call the personalized inspector through the detection node, and then use the personalized inspector to read the discrete and continuous fields in the change instance, as well as determine the enumeration list corresponding to the discrete fields and the reasonable value range corresponding to the continuous fields, so that the personalized inspector can perform numerical verification on the field values of the discrete fields based on the enumeration list, and perform range verification on the field values of the continuous fields based on the reasonable value range.
[0096] Specifically, after being invoked, the personalization inspector can automatically read the key field information contained in the change instance and distinguish between discrete and continuous data attributes. For discrete fields, the personalization inspector can obtain its corresponding enumeration list, which is derived from historical data analysis or business strategy definitions, clearly defining the allowed legal value range of the field. For continuous fields, the inspector can determine its corresponding reasonable value range, that is, the acceptable numerical range of the field in actual business operation obtained through historical data statistics or business rules calculation. Subsequently, the personalization inspector can perform numerical verification on the field values of discrete fields based on the enumeration list to ensure that their values conform to the business-allowed options, and perform range verification on the field values of continuous fields based on the reasonable value range to determine whether they are within the business-acceptable numerical range, thereby accurately identifying potential business logic risks and abnormal changes in configuration changes.
[0097] In one embodiment, the process of performing risk blocking operation when the verification result fails in step S140 may include:
[0098] S141: When the verification result is a failure, determine the failed detection item and the risk level of the detection item.
[0099] S142: Implement risk blocking operations on the test items using response measures corresponding to the level of risk, and push the operation results to the person in charge of the test items.
[0100] In this embodiment, when the verification result of the change instance fails, the risk management system can determine the failed detection item and the risk level of the detection item, and take corresponding countermeasures to perform risk blocking operations on the detection item, and push the operation result to the person in charge of the detection item to prevent potential risks from damaging the business operation of the enterprise.
[0101] For example, in an order configuration change scenario, if there is a data change in its configuration table, such as setting the discount rate of a certain product to 1.5, when the configuration change model is validated, the personalization checker finds that the changed data exceeds the reasonable range of order discount rates [0.1, 0.99]. Therefore, the validation result is judged as a failure, and its risk level is high. Thus, the risk control system can automatically trigger a risk blocking operation to intercept the discount rate configuration change, prevent it from taking effect, and push the blocking result and reason to the operation or business personnel responsible for the product configuration, prompting them to adjust the discount rate to comply with the specifications.
[0102] The configuration change risk management device provided in the embodiments of this application is described below. The configuration change risk management device described below can be referred to in correspondence with the configuration change risk management method described above.
[0103] In one embodiment, such as Figure 2 As shown, Figure 2 This application provides a schematic diagram of a configuration change risk management device according to an embodiment of the present application. The present application also provides a configuration change risk management device, including an instance generation module 210, a node routing module 220, a data verification module 230, and a risk blocking module 240, specifically comprising the following:
[0104] The instance generation module 210 is used to generate a changed instance of the database through the configuration change model and determine the corresponding post-shard of the changed instance; the configuration change model is equipped with a general inspector and a personalized inspector, and the personalized inspector adopts a dynamically updatable rule engine architecture.
[0105] The node routing module 220 is used to route change instances to the corresponding detection nodes in the configuration change model based on the subsequent shards.
[0106] The data verification module 230 is used in the detection node to call the general checker to verify the data type of the changed instance and to call the personalized checker to verify the business logic of the changed instance, and obtain the verification results.
[0107] The risk blocking module 240 is used to push customized notifications for verification results and to perform risk blocking operations when the verification result fails.
[0108] In the above embodiments, after each configuration change, a change instance in the database can be generated through the configuration change model. This allows changes from different systems to be identified and categorized within a unified framework. Then, the corresponding post-shard can be determined. This post-shard can systematically organize different risk rules, improving the effectiveness of the verification rules. Furthermore, the change instance can be routed to the corresponding detection nodes in the configuration change model for parallel processing based on the post-shard, improving efficiency. Subsequently, in each detection node, a general checker and a personalized checker can be invoked to comprehensively verify the change instance from different levels. The resulting verification not only ensures the legality of the change at the basic data level but also accurately identifies risks at the business level. The personalized checker employs a dynamically updatable rule engine architecture, enabling dynamic optimization based on actual conditions and improving the practicality of the rules. After obtaining the final verification result, this application can send a customized notification to the verification result and perform risk blocking operations when the verification result fails, preventing the impact of change failures on enterprise business.
[0109] In one embodiment, the instance generation module 210 may include:
[0110] The data parsing submodule is used to parse the metadata of the database to obtain business attributes and data structures, and to obtain the initial change model based on the defined business attributes and data structures.
[0111] The rule determination submodule is used to determine multiple sharding rules for the database based on a preset partitioning strategy; each sharding rule corresponds to a rule execution environment.
[0112] The sharding setting submodule is used to set multiple subsequent shards in the initial change model based on various sharding rules to obtain an intermediate change model.
[0113] The Inspector Mounting Submodule is used to mount multiple inspectors in the intermediate change model based on database verification requirements, resulting in the final configuration change model.
[0114] In one embodiment, the instance generation module 210 may further include:
[0115] The data acquisition submodule is used to acquire historical data within a preset time period at a preset frequency; the historical data includes discrete fields and continuous fields.
[0116] The data calculation submodule is used to perform numerical clustering on discrete fields and generate an enumeration list based on the clustering results, as well as to perform range calculations on continuous fields to obtain a reasonable value range.
[0117] The rule update submodule is used to dynamically update the rules of the personalized checker based on the enumeration list and the reasonable value range.
[0118] In one embodiment, the instance generation module 210 may further include:
[0119] The message listening submodule is used to listen to the message stream in the database by configuring a change model in order to capture the changed data.
[0120] The instance generation submodule is used to parse the changed fields in the changed data and the comparison values of the changed fields before and after the change using the configuration change model, and to structure the changed fields and comparison values to form a change instance.
[0121] In one embodiment, the data verification module 230 may include:
[0122] The first calling submodule is used to invoke the general inspector through the detection node.
[0123] The first verification submodule is used to obtain the type verification rules corresponding to each field in the change instance using the general inspector, and to perform type verification on the field values of the corresponding fields using each type verification rule.
[0124] In one embodiment, the data verification module 230 may further include:
[0125] The second calling submodule is used to invoke the personalized inspector through the detection node.
[0126] The Field Reading submodule is used to read discrete and continuous fields in a change instance using the personalization inspector, and to determine the enumeration list corresponding to discrete fields and the reasonable value range corresponding to continuous fields.
[0127] The second verification submodule is used in the personalized checker to perform numerical verification on the field values of discrete fields based on an enumeration list, and to perform range verification on the field values of continuous fields based on a reasonable value range.
[0128] In one embodiment, the risk blocking module 240 may include:
[0129] The risk determination submodule is used to determine the failed detection item and its risk level when the verification result is a failure.
[0130] The risk blocking submodule is used to perform risk blocking operations on the test items using response measures corresponding to the risk level, and push the operation results to the person in charge of the test items.
[0131] In one embodiment, this application also provides a storage medium storing computer-readable instructions that, when executed by one or more processors, cause the one or more processors to perform the steps of the configuration change risk management method as described in any of the above embodiments.
[0132] In one embodiment, this application also provides a computer device storing computer-readable instructions that, when executed by one or more processors, cause the one or more processors to perform the steps of the configuration change risk management method as described in any of the above embodiments.
[0133] Indicatively, such as Figure 3 As shown, Figure 3 This is a schematic diagram of the internal structure of a computer device 300 provided in an embodiment of this application. The computer device 300 can be provided as a server. (Refer to...) Figure 3 The computer device 300 includes a processing component 302, which further includes one or more processors, and memory resources represented by memory 301 for storing instructions, such as application programs, that can be executed by the processing component 302. The application programs stored in memory 301 may include one or more modules, each corresponding to a set of instructions. Furthermore, the processing component 302 is configured to execute instructions to perform the configuration change risk management method of any of the above embodiments.
[0134] The computer device 300 may also include a power supply component 303 configured to perform power management of the computer device 300, a wired or wireless network interface 304 configured to connect the computer device 300 to a network, and an input / output (I / O) interface 305. The computer device 300 may operate on an operating system stored in memory 301, such as Windows Server™, Mac OS X™, Unix™, Linux™, Free BSD™, or similar.
[0135] Those skilled in the art will understand that Figure 3 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.
[0136] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.
[0137] The various embodiments in this specification are described in a progressive manner. Each embodiment focuses on the differences from other embodiments. The various embodiments can be combined as needed, and the same or similar parts can be referred to each other.
[0138] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.
Claims
1. A method for managing configuration change risks, characterized in that, The method includes: The configuration change model generates database change instances and determines the corresponding back shards for the change instances; the configuration change model is equipped with a general inspector and a personalized inspector, and the personalized inspector adopts a dynamically updatable rule engine architecture. The change instance is routed to the corresponding detection node in the configuration change model based on the post-sharding; In the detection node, the general inspector is invoked to perform data type verification on the change instance, and the personalized inspector is invoked to perform business logic verification on the change instance, and the verification results are obtained. A custom notification is pushed to the verification result, and a risk blocking operation is performed when the verification result fails.
2. The configuration change risk management method according to claim 1, characterized in that, The configuration process of the configuration change model includes: Metadata parsing is performed on the database to obtain business attributes and data structures, and an initial change model is defined based on the business attributes and data structures. Multiple sharding rules for the database are determined according to a preset partitioning strategy; each sharding rule corresponds to a rule execution environment. Based on each sharding rule, multiple subsequent shards are set in the initial change model to obtain an intermediate change model; Based on the database's verification requirements, multiple checkers are attached to the intermediate change model to obtain the final configuration change model.
3. The configuration change risk management method according to claim 1, characterized in that, The dynamic update process of rules in the personalized inspector includes: Historical data within a predetermined time period is acquired at a preset frequency; the historical data includes discrete fields and continuous fields. Numerical clustering is performed on the discrete fields, and an enumeration list is generated based on the clustering results. In addition, a range calculation is performed on the continuous fields to obtain a reasonable value range. The personalized checker is dynamically updated based on the enumeration list and the reasonable value range.
4. The configuration change risk management method according to claim 1, characterized in that, The method of generating database change instances through configuration change models includes: The configuration change model is used to monitor the message stream in the database to capture change data; The configuration change model is used to parse the change fields in the change data and the comparison values of the change fields before and after the change. The change fields and the comparison values are then structured to form change instances.
5. The configuration change risk management method according to claim 1, characterized in that, The step of calling the general inspector in the detection node to perform data type validation on the changed instance includes: The general inspector is invoked through the detection node; The general inspector is used to obtain the type validation rules corresponding to each field in the change instance, and the field values of the corresponding fields are validated using each type validation rule.
6. The configuration change risk management method according to claim 1, characterized in that, The step of invoking the personalization inspector to perform business logic verification on the changed instance includes: The personalized inspector is invoked through the detection node; The personalization inspector is used to read discrete and continuous fields in the change instance, and to determine the enumeration list corresponding to the discrete fields and the reasonable value range corresponding to the continuous fields. In the personalized checker, the field values of the discrete field are numerically validated based on the enumeration list, and the field values of the continuous field are range-validated based on the reasonable value range.
7. The configuration change risk management method according to claim 1, characterized in that, The risk blocking operation when the verification result fails includes: When the verification result is a failure, determine the failed detection item and the risk level of the detection item; The detection item is blocked by taking countermeasures corresponding to the level of risk, and the results are sent to the person in charge of the detection item.
8. A configuration change risk management device, characterized in that, include: The instance generation module is used to generate a database change instance by configuring a change model and determine the post-shard corresponding to the change instance; The configuration change model includes a general inspector and a personalized inspector, and the personalized inspector adopts a dynamically updatable rule engine architecture. The node routing module is used to route the change instance to the corresponding detection node in the configuration change model according to the post-sharding; The data verification module is used in the detection node to call the general checker to perform data type verification on the change instance and to call the personalized checker to perform business logic verification on the change instance, and obtain the verification result. The risk blocking module is used to push customized notifications to the verification results and to perform risk blocking operations when the verification results are failed.
9. A storage medium, characterized in that: The storage medium stores computer-readable instructions that, when executed by one or more processors, cause the one or more processors to perform the steps of the configuration change risk management method as described in any one of claims 1 to 7.
10. A computer device, characterized in that, include: One or more processors, and memory; The memory stores computer-readable instructions, which, when executed by the one or more processors, perform the steps of the configuration change risk management method as described in any one of claims 1 to 7.