Change risk prevention and control system, method, electronic device and storage medium

Abstract

The present specification provides a change risk prevention and control method, system, electronic device and storage medium, the system comprising: a rule configuration module for storing multiple detection rules, the acquisition method comprising: providing multiple predefined attributes for describing change events, and receiving detection rules configured by a first type of user and attribute values ​​of the attribute configuration applicable to the detection rules; a change publishing module for providing the multiple attributes and receiving a change publishing request from a second type of user, which carries the target attribute values ​​of the attributes of the target change event for the second type of user; a change execution module for executing the target change event multiple times in a preset execution environment according to a preset lifecycle management order; wherein, before and after each execution of the target change event, at least the currently matched detection rule is found from the stored detection rules according to the target attribute value and executed to determine whether the event can be executed or whether the event causes an exception.

Description

[0001] This application is a divisional application with the application date of October 24, 2022, application number 2022113056832, and the name of the invention being "Change risk prevention and control system, method, electronic device and storage medium". Technical Field

[0002] The embodiments of this specification relate to the field of computer technology, and in particular to change risk prevention and control systems, methods, electronic devices, and storage media. Background Art

[0003] As the speed of technological iteration increases, the upgrade of business systems is becoming more and more frequent. Business systems include multiple applications. The release of application change events will update the applications and thus upgrade the business systems. For IT-related businesses, change events initiated by internal developers may cause stability issues for business systems. In order to maintain the stability of the business system, anomaly detection can be performed before and after the release of change events. However, different business systems have different anomaly detection methods, and different detectors have different anomaly detection experience. On the one hand, anomaly detection of change events still relies on human experience. If the detector is not experienced enough, it may not be possible to detect anomalies. On the other hand, if the detector is replaced, the previous detector can only pass on the detection experience to the next detector by word of mouth, and the detection experience cannot be precipitated in a regular manner. Summary of the invention

[0004] The embodiments of this specification provide a change risk prevention and control system, method, electronic device and storage medium to provide systematic anomaly detection.

[0005] According to a first aspect of an embodiment of this specification, a change risk prevention and control system is provided, the change risk prevention and control system comprising:

[0006] A rule configuration module, for storing a plurality of detection rules, wherein the detection rules are obtained by providing a plurality of predefined attributes for describing a change event, and receiving a detection rule configured by a first type of user and an attribute value of an attribute configuration applicable to the detection rule;

[0007] A change publishing module, configured to: provide the plurality of attributes, and receive a change publishing request from a second type of user, wherein the change publishing request carries a target attribute value of the attribute of the target change event for the second type of user;

[0008] A change execution module is used to: execute the target change event multiple times in a preset lifecycle management order in multiple preset execution environments; wherein, before each execution of the target change event, the currently matching detection rule is searched out from the stored detection rules at least according to the target attribute value and executed to determine whether the target change event can be executed; and after each execution of the target change event, the currently matching detection rule is searched out from the stored detection rules at least according to the target attribute value and executed to determine whether the target change event causes an exception.

[0009] In some examples, the multiple attributes of the change event include at least one of the following attributes:

[0010] An attribute representing basic information of a change event, wherein the basic information includes any of the following: title information, initiator information, or time information;

[0011] An attribute representing the type information of a change event, where the type information includes any of the following: code release type or parameter configuration type;

[0012] Characterizing the attributes of the execution information of the change event, the execution information including any of the following: batch release mode information, blue-green release mode information, or shutdown release mode information;

[0013] The attribute characterizing the impact scope information of the change event, wherein the impact scope information includes any of the following: impact object information or impact degree information.

[0014] In some examples, the change execution module is used to:

[0015] One or more extended attribute values ​​are extended according to the target attribute value, and a currently matched detection rule is searched from the stored detection rules according to the target attribute value and the one or more extended attribute values ​​and executed; wherein the extended attribute value is obtained by:

[0016] Based on the target application to be changed by the target change event and the target business system to which the target application belongs, the upstream business system or downstream business system of the target business system, as well as other applications associated with the target application, are determined, and impact scope information is generated including extended attribute values ​​of any of the upstream business system, downstream business system or other applications.

[0017] In some examples, the change risk prevention and control system is connected to multiple business systems, and the change event is used to change one or more applications in the business system; the change risk prevention and control system is integrated with multiple detection capabilities;

[0018] The rule configuration module includes any of the following sub-modules:

[0019] A first configuration submodule is used to: provide a configuration function for each of the detection capabilities, obtain configuration parameters of the second type of user for the business system targeted by one or more of the detection capabilities through the configuration function, and generate detection rules;

[0020] A second configuration submodule is used to: provide a code configuration function, obtain a script file describing the detection rule submitted by the second type of user through the code configuration function, and generate the detection rule based on the script file;

[0021] The third configuration submodule is used to provide a service provision interface, and obtain and store the detection rules submitted by the second type of users through the service provision interface.

[0022] In some examples, the currently matched detection rules found before the target change event is executed include:

[0023] A detection rule for detecting whether a release condition of a target change event is satisfied, wherein the release condition includes any of the following: a condition that the risk level of the target change event is less than a preset level threshold; wherein the level threshold is related to the business volume of the target business system at the current moment, and / or is related to whether the current moment is within a specified date; the target business system is the business system changed by the target change event; or,

[0024] A detection rule used to detect whether the parameter value of the target parameter configured in the target change event of the parameter configuration type passes the legality check.

[0025] In some examples, the plurality of detection rules include preset detection rules;

[0026] After each execution of the change event, the currently matched detection rule is searched from the stored first detection rules according to the target attribute value, including:

[0027] Compare the number and / or type of errors before and after the target change event is released, and determine whether the updated application has abnormal error reporting rules based on the comparison results;

[0028] Compare the business data transmitted between the target business system and the associated business systems before and after the target change event is released, and determine whether an abnormal link rule occurs in the updated application based on the comparison result of the business data; wherein the target business system is the business system to which the application belongs, and the associated business system is the upstream and / or downstream business system of the target business system.

[0029] In some examples, the plurality of preset execution environments include: a pre-release execution environment, a phased release environment, and a formal release environment;

[0030] The preset lifecycle management order is pre-release execution environment, grayscale release environment and formal release environment.

[0031] According to a second aspect of an embodiment of this specification, a change risk prevention and control method is provided, the method comprising:

[0032] Storing a plurality of detection rules, wherein the detection rules are obtained by providing a plurality of predefined attributes for describing a change event, and receiving a detection rule configured by a first type of user and an attribute value of an attribute configuration applicable to the detection rule;

[0033] Providing the plurality of attributes, and receiving a change publishing request from a second type of user, the change publishing request carrying a target attribute value of the attribute of a target change event for the second type of user;

[0034] In multiple preset execution environments, the target change event is executed multiple times in a preset lifecycle management order; wherein, before each execution of the target change event, the currently matching detection rule is searched out from the stored detection rules at least based on the target attribute value and executed to determine whether the target change event can be executed; and after each execution of the target change event, the currently matching detection rule is searched out from the stored detection rules at least based on the target attribute value and executed to determine whether the target change event causes an exception.

[0035] According to a third aspect of the embodiments of this specification, an electronic device is provided, the electronic device comprising:

[0036] processor;

[0037] a memory for storing processor-executable instructions;

[0038] Wherein, when the processor calls the executable instruction, it implements the operation of any method described in the first aspect.

[0039] According to a fourth aspect of the embodiments of this specification, a computer-readable storage medium is provided, on which a number of computer instructions are stored, and when the computer instructions are executed, any method described in the first aspect is performed.

[0040] The technical solutions provided by the embodiments of this specification may have the following beneficial effects:

[0041] The embodiments of the present specification provide a change risk prevention and control system, method, electronic device and storage medium, a change risk prevention and control system rule configuration module, used to: store multiple detection rules, the detection rules are obtained in the following manner: providing a plurality of predefined attributes for describing a change event, and receiving a detection rule configured by a first type of user and an attribute value of an attribute configuration applicable to the detection rule; a change release module, used to: provide the plurality of attributes, and receive a change release request from a second type of user, the change release request carrying a target attribute value of an attribute of a target change event by the second type of user; a change execution module, used to: execute the target change event multiple times in a preset lifecycle management order in multiple preset execution environments; wherein, before each execution of the target change event, at least according to the target attribute value, a currently matched detection rule is searched out from the stored detection rules and executed to determine whether the target change event can be executed; and after each execution of the target change event, at least according to the target attribute value, a currently matched detection rule is searched out from the stored detection rules and executed to determine whether the target change event causes an exception. Based on this, since the change risk prevention and control system provides a rule configuration module for the first type of users, and uniformly defines the attributes used to describe change events, users can configure the attribute values ​​of the attributes and the detection rules corresponding to the attribute values, and deposit the abnormal detection experience of each first type of user into the system through the detection rules, and simply and quickly integrate the different abnormal detection experiences of each detection personnel, avoiding the situation where the abnormality cannot be detected due to the lack of experience of the detection personnel. In addition, for the second type of users, it is only necessary to initiate a change release request through the change release module. The change execution module can execute the target change event multiple times in multiple preset execution environments according to the preset life cycle management order, thereby realizing the automatic management of change events.

[0042] It should be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the embodiments of the present specification. BRIEF DESCRIPTION OF THE DRAWINGS

[0043] The accompanying drawings herein are incorporated in the specification and constitute a part of the embodiments of the specification, illustrate embodiments consistent with the embodiments of the specification, and together with the description, are used to explain the principles of the embodiments of the specification.

[0044] Figure 1 It is a schematic diagram of various stages of a change event according to an embodiment of the present specification.

[0045] Figure 2 This is a flow chart of a change risk prevention and control method shown in this specification according to an embodiment.

[0046] Figure 3It is a flow chart of a change risk prevention and control method shown in this specification according to another embodiment.

[0047] Figure 4 It is a flow chart of a change risk prevention and control method shown in this specification according to another embodiment.

[0048] Figure 5A It is a flow chart of a change risk prevention and control method shown in this specification according to another embodiment.

[0049] Figure 5B It is a schematic diagram of a change risk prevention and control system shown in this specification according to another embodiment.

[0050] Figure 6 It is a schematic diagram of a change risk prevention and control system shown in this specification according to an embodiment.

[0051] Figure 7 This is a hardware structure diagram of an electronic device according to an embodiment of the present specification. DETAILED DESCRIPTION

[0052] Exemplary embodiments will be described in detail herein, examples of which are shown in the accompanying drawings. When the following description refers to the drawings, the same numbers in different drawings represent the same or similar elements unless otherwise indicated. The implementations described in the following exemplary embodiments do not represent all implementations consistent with the embodiments of this specification. Instead, they are merely examples of devices and methods consistent with some aspects of the embodiments of this specification as detailed in the appended claims.

[0053] The terms used in the embodiments of this specification are only for the purpose of describing specific embodiments, and are not intended to limit the embodiments of this specification. The singular forms of "a", "said" and "the" used in the embodiments of this specification and the appended claims are also intended to include plural forms, unless the context clearly indicates other meanings. It should also be understood that the term "and / or" used in this article refers to and includes any or all possible combinations of one or more associated listed items.

[0054] It should be understood that although the terms first, second, third, etc. may be used to describe various information in the embodiments of this specification, these information should not be limited to these terms. These terms are only used to distinguish the same type of information from each other. For example, without departing from the scope of the embodiments of this specification, the first information may also be referred to as the second information, and similarly, the second information may also be referred to as the first information. Depending on the context, the word "if" as used herein may be interpreted as "at the time of" or "when" or "in response to determining".

[0055] As the speed of technological iteration increases, business system upgrades are becoming more frequent. Taking e-commerce as an example, shopping carts, product details, and ordering are all independent applications, and many applications constitute business systems such as shopping and payment. From the perspective of technical implementation, each business system upgrade includes changes to one or more applications. In other words, the release of application change events will update the application, thereby upgrading the business system. Application changes include: Figure 1 The five stages are shown in Figure 1. First, the internal developer initiates the application change event request and submits the change code. The reviewer browses the change code logic and approves the content of the change event based on vulnerability exceptions, code style, performance defects, duplicate code and other dimensions. After approval, the simulation trial run is started to simulate risks in the test environment. Then the change event is released and the change event is measured after release.

[0056] In the industry, the change event initiation and review stages are often achieved through manual management. That is, through the approval process of internal reviewers, the risk issues in the change process are assisted in assessment. However, manual management is often difficult to conduct a comprehensive assessment of risks due to the large audit throughput, omissions in the change initiator information, lack of experience, etc., so some potential risks cannot be discovered and resolved during the review stage.

[0057] On this basis, while retaining the initiation and review of change events, the platform has also increased the ability to perceive change events. The platform can actively perceive each change event and actively check the possible risks of the change event, so that reviewers can not only passively discover the risks of the change event from the information submitted by the change initiator, but also actively discover the risks of various changes during the review stage. However, such a solution still cannot detect anomalies and intervene in time during the release stage of the change.

[0058] For IT-related businesses, change events initiated by internal developers may cause stability problems for business systems. In order to maintain the stability of business systems, anomaly detection can be performed before and after the change events are released. However, different business systems have different anomaly detection methods, and different detectors have different anomaly detection experiences. On the one hand, anomaly detection of change events still relies on human experience. If the detector is not experienced enough, it may not be possible to detect anomalies. On the other hand, if the detector is replaced, the previous detector can only pass on the detection experience to the next detector by word of mouth, and the detection experience cannot be precipitated in a regular manner.

[0059] In the related art, for the risk prevention and control of changes, most solutions are proposed for scenarios with smaller business systems. Therefore, from the release of changes, the management of change events to the anomaly detection of change events, they are all controlled by the technical personnel who initiate the changes. The inventors of the present application found that with the growth of corporate business, the size of business systems is increasing. An enterprise gradually deploys more and more business systems, and each business system has dependencies on each other. The technical personnel of a business system only manages the changes of their own business system. From the perspective of change event management, the technical personnel of each business system may have some duplication of work. From the perspective of anomaly detection of change events, the rules of anomaly detection rely on human experience. Due to the lack of understanding of the situation of other business systems, anomaly detection may have limitations, and it is impossible to regularize the detection experience for reuse.

[0060] To this end, an embodiment of this specification provides a change risk prevention and control method, which is applied to a change risk prevention and control system. Exemplarily, the change risk prevention and control system can be a change risk prevention and control system that integrates development (Development) and operations (Operations). The change risk prevention and control system can be connected to one or more server clusters, and each server in the server cluster can run the same application. Exemplarily, each server in the server cluster is equipped with the same business system, and therefore runs the same application. The above method includes the following steps: Figure 2 Steps shown:

[0061] Step S11: storing multiple detection rules.

[0062] The method for acquiring the detection rule includes: providing a plurality of predefined attributes for describing a change event, and receiving a detection rule configured by a first type of user and an attribute value of an attribute configuration applicable to the detection rule.

[0063] Step S12: providing the plurality of attributes, and receiving a change publishing request from a second category of users.

[0064] The change publishing request carries the target attribute value of the attribute of the target change event for the second type of user.

[0065] Step S13: Execute the target change event multiple times in a plurality of preset execution environments according to a preset lifecycle management sequence.

[0066] Wherein, before each execution of the target change event, the currently matching detection rule is searched out from the stored detection rules at least based on the target attribute value and executed to determine whether the target change event can be executed; and after each execution of the target change event, the currently matching detection rule is searched out from the stored detection rules at least based on the target attribute value and executed to determine whether the target change event causes an exception.

[0067] Exemplarily, there is no sequential execution order between step S11 and step S12.

[0068] Exemplarily, the change risk prevention and control system can be connected to multiple server clusters, and different server clusters can be equipped with different business systems. There can be interaction of business data traffic between the various business systems, or they can be independent of each other. Each business system is configured with detection rules by different domain experts, including R&D personnel, quality personnel, and operation and maintenance personnel. In this way, different domain experts can configure corresponding detection rules for change events related to the business system through the rule configuration function provided by the change risk prevention and control system.

[0069] Since the change risk prevention and control system predefines attributes for describing application change events, no matter whether it is different change events of the same application, change events of different applications in the same business system, or change events of applications in different business systems, they are all described using the attributes predefine by the change risk prevention and control system.

[0070] Thus, when a domain expert, that is, the first type of user, needs to configure a rule, he can initiate a rule configuration request to the change risk prevention and control system. In response to the rule configuration request, the change risk prevention and control system will send predefined attributes to the user.

[0071] Exemplarily, if the predefined attributes include multiple attributes, all attributes are sent to the user.

[0072] Exemplarily, the change risk prevention and control system may send predefined attributes to the user through a standard interface, such as a SPI (Service Provider Interface).

[0073] Subsequently, the first category of users can configure attribute values ​​for the received attributes, and configure detection rules corresponding to the attribute values. Exemplarily, the user can configure attribute values ​​for at least some of all the received attributes, and configure at least one first category of detection rule corresponding to the attribute values. In this embodiment, the detection rules configured by the first category of users are referred to as first category detection rules; in actual applications, the detection rules stored in the system can also be implemented in other ways, for example, they are pre-configured by the technicians who develop the system of this embodiment.

[0074] As an example, if the predefined attributes include 10 attributes from attribute 1 to attribute 10, then in response to the rule configuration request, the change risk prevention and control system can send attributes 1 to attribute 10 to the user. Among them, the user can only configure the attribute value A for attribute 2, and the attribute value B for attribute 3, and configure at least one corresponding first-class detection rule. For example, the user can configure one or more first-class detection rules for the attribute value A of attribute 2, and configure one or more first-class detection rules for the attribute value B of attribute 3. Then when the attribute value of attribute 2 of the change event is equal to A, one or more configured first-class detection rules are hit. For another example, the user can configure one or more first-class detection rules for the attribute value A of attribute 2, and the attribute value B of attribute 3. Then when the attribute value of attribute 2 of the change event is equal to A, and the attribute value of attribute 3 is equal to B, one or more configured first-class detection rules are hit.

[0075] After the user completes the configuration, the change risk prevention and control system receives and stores the first type of detection rules configured by the user, and the attribute values ​​of the attribute configuration used by the first type of detection rules.

[0076] In some examples, the acquisition method of acquiring the detection rule through the first type of user may include any of the following:

[0077] Providing a configuration function for each of the detection capabilities, obtaining configuration parameters of the second type of user for the business system targeted by one or more of the detection capabilities through the configuration function and generating detection rules;

[0078] Providing a code configuration function, obtaining a script file describing the detection rule submitted by the second type of user through the code configuration function, and generating the detection rule based on the script file;

[0079] A service provision interface is provided, through which the detection rules submitted by the second category of users are obtained and stored.

[0080] Exemplarily, the user may upload the configured attribute values ​​and the corresponding first-category detection rules to the change risk prevention and control system in the form of a plug-in.

[0081] Exemplarily, the change risk prevention and control system may provide a configuration interface to the user, and the configuration interface may display all predefined attributes. In addition, the configuration interface may also include a configuration module for the user to configure attribute values ​​and the first detection rule in the configuration module. For example, the configuration module may include an attribute configuration submodule and a rule configuration submodule. The user may configure the attribute values ​​of at least some attributes in the attribute configuration submodule, and configure the first type of detection rule in the rule configuration submodule.

[0082] Exemplarily, the change risk prevention and control system stores the first type of detection rules and the mapping relationship between the first type of detection rules and the attribute values. As an example, the mapping relationship between the first type of detection rules and the attribute values ​​can be stored in the form of an expression. The expression can be an equation, one side of which can record the attribute value of the attribute configured by the user, and the other side can record the first type of detection rules or the unique identifier of the first type of detection rules. Using the unique identifier, the corresponding first type of detection rule can be read.

[0083] In addition, the change risk prevention and control system also provides a change event publishing function, which R&D personnel can use to publish change events for applications. The rule configuration function and the change event publishing function of the change risk prevention and control system can be called by the same user or by different users.

[0084] In this embodiment, a second type of user can also publish a change publishing request for a change event. In this embodiment, a change event published by a second type of user is called a target change event. The second type of users in this embodiment include a type of users with change requirements. Since the change risk prevention and control system predefines attributes for describing application change events, when the R&D personnel initiate a publishing request for the target change event of the application to the change risk prevention and control system, the publishing request carries the target attribute value of the attribute of the target change event. Optionally, if there are multiple predefined attributes, the target attribute values ​​of at least some of the attributes are configured by the R&D personnel, and the target attribute values ​​of the remaining attributes are generated by the change risk prevention and control system.

[0085] In the present embodiment, the target change event can be executed multiple times in a preset lifecycle management order in multiple preset execution environments; wherein, before each execution of the target change event, the currently matching detection rule is searched out from the stored detection rules at least based on the target attribute value and executed to determine whether the target change event can be executed; and after each execution of the target change event, the currently matching detection rule is searched out from the stored detection rules at least based on the target attribute value and executed to determine whether the target change event causes an exception.

[0086] Exemplarily, the multiple preset execution environments include: a pre-release execution environment, a grayscale release environment, and a formal release environment; the preset lifecycle management order is pre-release execution environment, grayscale release environment, and formal release environment.

[0087] The pre-launch execution environment refers to a pre-established test environment with multiple test servers for testing change events. The test servers do not provide services for real users, but for virtual users. By making changes in the pre-launch execution environment, change events can be tested without disturbing real users.

[0088] A grayscale release environment is a release environment composed of dedicated grayscale servers that provide services to test users, who are selected from a large number of real users. By making changes in a grayscale release environment, you can use a small number of test users to test whether the changed business system is abnormal without disturbing a large number of users.

[0089] The official release environment refers to the release environment composed of all servers, which are used to provide services to all users. After the change event is confirmed to be normal through the pre-release execution environment and the gray release environment, the change event can be released in the official release environment.

[0090] As an example, taking the grayscale release environment or the formal release environment as an example, in response to the above release request, the change risk prevention and control system can publish the target change event to the target server of the server cluster. The so-called release of the target change event can be understood as updating the application corresponding to the target change event running in the target server. After the release, the target first detection rule can be determined from the stored rules according to the target attribute value of the attribute carried by the release request, and the updated application can be detected for anomalies according to the target first detection rule. Among them, the target first detection rule can be the first detection rule that the user has historically configured according to the above method and stored in the change risk prevention and control system.

[0091] Exemplarily, the target first detection rule may be determined based on the target attribute value and the mapping relationship between the first detection rule and the attribute value stored in the above-mentioned change risk prevention and control system, and there may be one or more detections matched each time.

[0092] Exemplarily, all expressions in the change risk prevention and control system may be traversed to determine all first-category detection rules that hit the target attribute as the target first detection rules.

[0093] This embodiment provides a method for publishing a change event. Since the change risk prevention and control system uniformly defines attributes for describing change events, users can configure the attribute values ​​of the attributes and the first detection rules corresponding to the attribute values ​​to deposit the anomaly detection methods corresponding to different business systems and the anomaly detection experience of different detection personnel into the change risk prevention and control system through the first detection rules, thereby simply and quickly integrating the different anomaly detection experiences of various business teams and avoiding the situation where anomalies cannot be detected due to insufficient experience of detection personnel.

[0094] The multiple attributes of the change event include at least one of the following attributes:

[0095] An attribute representing basic information of a change event, wherein the basic information includes any of the following: title information, initiator information, or time information;

[0096] An attribute representing the type information of a change event, where the type information includes any of the following: code release type or parameter configuration type;

[0097] Characterizing the attributes of the execution information of the change event, the execution information including any of the following: batch release mode information, blue-green release mode information, or shutdown release mode information;

[0098] The attribute characterizing the impact scope information of the change event, wherein the impact scope information includes any of the following: impact object information or impact degree information.

[0099] Exemplarily, there are multiple release modes for change events, including but not limited to shutdown release, batch release, blue-green release, etc.

[0100] Downtime release means shutting down the business system before the change event is released, stopping user access to the business system, and then updating the applications running in the server cluster. Batch release includes canary release and grayscale release. Canary release means first releasing the change event to some servers in the server cluster, so that some business system users can access the upgraded business system and use real user data to verify the traffic. If the verification passes, the change event is released to the remaining servers, otherwise the code is rolled back, that is, the version before the change event is released. Grayscale release is an extension of canary release, which is to divide the release into different batches, and the number of servers in each batch increases step by step. If no problems are found in the current batch after the change event is released, it will enter the next batch until the change event release of the server cluster is completed.

[0101] Blue-green release means that there are two completely identical and independent production environments, one called "blue environment" and the other called "green environment". The green environment is the production environment currently in use by users. Change events can be released in the blue environment first, that is, in the server corresponding to the blue environment. Then run a smoke test in the blue environment to check whether the business system works normally after the change event is released. If the test is successful, update the routing configuration to direct the business system user traffic from the green environment to the blue environment, so that the blue environment becomes the production environment.

[0102] The present application provides a method for publishing a change event, and the target change event can be published in the server cluster in any of the above publishing modes. For example, the target change event is published in batches in the server cluster, specifically including: Figure 3 Steps shown:

[0103] In response to a publish request for an applied target change event, execute:

[0104] Step S211: selecting one or more servers to be released from the server cluster as target servers of the current batch;

[0105] Step S213: publishing the target change event to the target server;

[0106] Step S22: determining a target first detection rule from the stored rules according to the target attribute value, and performing anomaly detection on the updated application according to the target first detection rule;

[0107] Among them, steps S211 to S22 refer to the above embodiment and are not described again here.

[0108] Step S23: Determine whether an abnormality is detected;

[0109] If yes, go to step S24; if no, go to step S25.

[0110] Step S24: Output a notification of abnormal change and / or stop publishing target change events.

[0111] Step S25: Determine whether the server cluster has completed publishing;

[0112] If not, return to step S21, and if so, complete the release of the target change event.

[0113] In this embodiment, the target change events are published in batches in the server cluster. After each batch is published, the target first detection rule is used to perform anomaly detection, and the next batch is published only after passing the detection. Compared with the manual confirmation check logic in the related art, this embodiment realizes the systematic and automatic anomaly detection of each batch of releases by the change risk prevention and control system, reducing the reliance on manual work.

[0114] In some embodiments, the attributes predefined by the change risk prevention and control system for describing change events include one or more of the following: type attributes of the change event, or impact attributes of the change event, basic attributes that characterize the change event in the proposal stage, and release attributes that characterize the change event in the release stage.

[0115] Exemplarily, the type attribute of the change event includes a code release type and a parameter configuration type. For example, if a function provided by the business system is added and / or modified, the type attribute of the corresponding change event is a code release type. For another example, if a parameter in the business system is modified, the type attribute of the corresponding change event is a parameter configuration type.

[0116] Exemplarily, the impact attribute of the change event includes the impact object and / or impact degree of the change event. For example, the impact object may be other applications. For another example, the release of the application change event may not only affect the target business system to which the application belongs, but also may affect the associated business systems located upstream and downstream of the target business system. Therefore, the impact object may be the associated business system.

[0117] Exemplarily, the basic attributes that characterize the change event at the proposal stage refer to the attributes carried by the R&D personnel when initiating a release request for the target change event, including but not limited to one or more of the title, initiator, and initiation time of the target change event.

[0118] Exemplarily, the publishing attributes characterizing the change event in the publishing stage include the publishing mode of the change event, and / or the flag information of the target server on which it is published. As described above, the change event can be published in any one of the publishing modes of batch publishing, blue-green publishing, and shutdown publishing. In this way, the publishing attributes include the publishing mode. If the publishing mode is the shutdown mode, the target servers are all servers in the server cluster. If the publishing mode is batch publishing or blue-green publishing, the target servers are some of the servers in the server cluster. The flag information can be a unique flag of the server. In this way, the publishing mode of the change event and the servers on which it is published can be known through the publishing attributes.

[0119] As an example, the user can configure the corresponding first detection rules for different type attributes. For example, the first detection rule ① is configured for the change event of the code release type, and the first detection rule ② is configured for the change event of the parameter configuration type. In this way, the change event with the type attribute of the code release type is detected for anomalies according to the first detection rule ① after being released; the change event with the type attribute of the parameter configuration type is detected for anomalies according to the first detection rule ② after being released.

[0120] As an example, the user can configure corresponding first detection rules for different impact objects. For example, the first detection rule ③ is configured for all change events whose impact object is business system A. That is, all change events that affect business system A, including change events of applications belonging to business system A, and change events of applications of other business systems that interact with business system A, are all released for anomaly detection according to the first detection rule ③.

[0121] As an example, the user can configure corresponding first detection rules for different initiators of change events. For example, configure first detection rule ④ for all change events initiated by a certain initiator. After the change event is released, anomaly detection is performed according to first detection rule ④.

[0122] As an example, the user can configure corresponding first detection rules for different release modes. For example, configure first detection rule ⑤ for change events in batch release mode; configure first detection rule ⑥ for change events in blue-green release mode; configure first detection rule ⑦ for change events in shutdown release mode.

[0123] In some examples, the method of this embodiment may also include:

[0124] One or more extended attribute values ​​are extended according to the target attribute value, and a currently matched detection rule is searched from the stored detection rules according to the target attribute value and the one or more extended attribute values ​​and executed; wherein the extended attribute value is obtained by:

[0125] Based on the target application to be changed by the target change event and the target business system to which the target application belongs, the upstream business system or downstream business system of the target business system, as well as other applications associated with the target application, are determined, and impact scope information is generated including extended attribute values ​​of any of the upstream business system, downstream business system or other applications.

[0126] In some examples, the currently matched detection rules found before the target change event is executed include:

[0127] A detection rule for detecting whether a release condition of a target change event is satisfied, wherein the release condition includes any of the following: a condition that the risk level of the target change event is less than a preset level threshold; wherein the level threshold is related to the business volume of the target business system at the current moment, and / or is related to whether the current moment is within a specified date; the target business system is the business system changed by the target change event; or,

[0128] A detection rule used to detect whether the parameter value of the target parameter configured in the target change event of the parameter configuration type passes the legality check.

[0129] In some embodiments, in response to the publishing request, before publishing the target change event to the target server, it also includes: determining whether a publishing condition of the change event is met.

[0130] The release conditions include but are not limited to:

[0131] (1) The risk level of the change event is less than a preset level threshold. The level threshold is related to the business volume of the target business system at the current moment and / or whether the current moment is within a specified date. The target business system is the business system described in the application.

[0132] The higher the risk level of a change event, the greater the probability of stability problems that may be caused by the change event.

[0133] For example, for the release of a change event of a certain application, the change risk prevention and control system determines the risk level threshold according to the business volume of the business system (i.e., the target business system) to which the application belongs at the current moment. For example, the larger the business volume of the target business system, the lower the level threshold. That is, when the business volume of the target business system is large, a low-risk change event can be released.

[0134] Optionally, when the business volume of the target business system exceeds a set business volume threshold, that is, during the peak business volume period, change events are not allowed to be published. When the business volume of the target system does not exceed the above business volume threshold, the risk level threshold is determined according to the business volume, and change events with risk levels below the level threshold are allowed to be published.

[0135] Exemplarily, the level threshold is related to whether the current moment is within a specified date. As an example, the specified date includes, but is not limited to, major national events, festivals, statutory holidays, etc. During the above-mentioned specified date, the stability of the business system is particularly important, so the level threshold within the specified date can be set to be lower than the level threshold within other dates outside the specified date. That is, within the specified date, change events with a lower risk level can be released.

[0136] (2) If the type attribute of the target change event is a parameter configuration type, the parameter value of the configured target parameter passes the legality check.

[0137] As described above, the predefined attributes of the change risk prevention and control system include the type attribute of the change event. The type attribute includes the code release type and the parameter configuration type. If the parameters in the business system are modified, the type attribute of the corresponding change event is the parameter configuration type. Since the parameter values ​​requested to be configured in the change event are manually entered by the R&D personnel, in this embodiment, the parameter values ​​configured for the parameters to be modified (i.e., the target parameters) can be checked for legality. If the legality check is passed, it is determined that the release conditions are met.

[0138] Optionally, a validity check may be performed based on the historical parameter values ​​of the target parameter. As an example, based on the historical parameter values ​​of the target parameter, a value range of the target parameter may be determined. If the parameter value configured by the target change event falls within the value range, the validity check passes.

[0139] In this embodiment, if the publishing mode of the target change event is batch publishing, a method for publishing a change event provided by this embodiment includes the following steps: Figure 4 Steps shown:

[0140] In response to a publish request for an applied target change event, execute:

[0141] Step S211: selecting one or more servers to be released from the server cluster as target servers of the current batch;

[0142] Step S212: Determine whether the release conditions of the change event are met;

[0143] Step S213: publishing the target change event to the target server;

[0144] Step S22: determining a target first detection rule from the stored rules according to the target attribute value, and performing anomaly detection on the updated application according to the target first detection rule;

[0145] Step S23: Determine whether an abnormality is detected;

[0146] If yes, go to step S24; if no, go to step S25.

[0147] Step S24: Output a notification of abnormal change and stop issuing target change events.

[0148] Step S25: Determine whether the server cluster has completed publishing;

[0149] If not, return to step S21, and if so, complete the release of the target change event.

[0150] The above steps refer to the above embodiments and will not be described again here.

[0151] exist Figure 4 In the illustrated embodiment, the change events are embedded before and after the release of each batch for corresponding tests. Before the release, that is, the pre-embedded point, the change risk prevention and control system determines whether the current time meets the release conditions, that is, performs an accessibility test. When the release conditions are met, that is, after the accessibility test is passed, the change events of this batch are automatically released. After the release, that is, the post-embedded point, the change risk prevention and control system performs anomaly detection. And after the anomaly detection passes, it automatically enters the accessibility test and release of the next batch. On the one hand, compared with the manual judgment of the release timing of the target change event and the manual anomaly detection in the related art, this embodiment realizes automatic accessibility testing and anomaly detection by embedding points before and after each batch. On the other hand, in the process of releasing change events in batches, problems can be discovered in time and the release of change events can be cut off.

[0152] In some examples, after each execution of the change event, searching for a currently matched detection rule from the stored first detection rules according to the target attribute value includes:

[0153] Compare the number and / or type of errors before and after the target change event is released, and determine whether the updated application has abnormal error reporting rules based on the comparison results;

[0154] Compare the business data transmitted between the target business system and the associated business systems before and after the target change event is released, and determine whether an abnormal link rule occurs in the updated application based on the comparison result of the business data; wherein the target business system is the business system to which the application belongs, and the associated business system is the upstream and / or downstream business system of the target business system.

[0155] In the above embodiment, since the change risk prevention and control system predefines the attributes of the change event, the user can customize the corresponding first detection rule for the predefined attributes. Different change events are subject to different first detection rules. In some embodiments, different change events can also use the same second detection rule for anomaly detection, that is, the second detection rule applies to all change events. In this way, the change risk prevention and control system also stores multiple second detection rules. Then, after the target change event is released, in addition to the target first detection rule, the updated application is also detected for anomalies according to the general second detection rule. Among them, the second detection rules may include but are not limited to error reporting rules and link rules.

[0156] Exemplarily, the error reporting rules in the second detection rules may be used to compare the number of errors and / or error types before and after the target change event is released, and determine whether an abnormality occurs in the updated application based on the comparison result.

[0157] Optionally, the error reporting rule indicates a comparison of the number of errors before and after the target change event is released. If the difference in the number of errors before and after the release is greater than a preset number threshold, it is determined that an abnormality has occurred. As an example, the change risk prevention and control system can monitor the number of errors that occur in one or more business systems. The change risk prevention and control system can periodically count the number of errors that occur in the business system and output it in a form such as a report, a time series statistical curve, etc. In this way, it can be determined whether an abnormality has occurred in the updated application based on the increase or decrease in the number of errors before and after the release.

[0158] Optionally, the error reporting rule indicates to compare the error reporting types before and after the target change event is released, and if a new error reporting type appears after the release, it is determined that an exception has occurred. As an example, the log records various error reporting types and the number of errors corresponding to each type. It is possible to determine whether an exception has occurred in the updated application by identifying whether there is a new error reporting type in the log.

[0159] Optionally, the error reporting rule indicates that the number of errors of a specified error type before and after the target change event is released is compared, and if the difference in the number of errors of the specified error type before and after the release is greater than a quantity threshold, it is determined that an exception has occurred. As an example, as described above, the log records various error types and the number of errors corresponding to each type. Therefore, the difference value of the number of errors of the specified error type before and after the release can be obtained, and it is determined whether an exception has occurred.

[0160] Exemplarily, the link rule in the second detection rule can be used to compare the business data transmitted between the target business system and the associated business system before and after the target change event is released, and determine whether an abnormality occurs in the updated application based on the comparison result of the business data. The target business system is the business system to which the application belongs, and the associated business system is the upstream and / or downstream business system of the target business system.

[0161] For the release of a change event for a certain application, the business system to which the application belongs is the target business system. As mentioned above, there may be interaction of business data traffic between business systems. Therefore, the business data transmitted between the target business system and its upstream and downstream business systems (i.e., associated business systems) can be captured, and the difference between the business data before and after the release can be compared to determine whether an abnormality has occurred. For example, if the business data transmitted from the target business system to the associated business system before the release is "Success", and the business data transmitted after the release becomes "Fail", it is determined that an abnormality has occurred in the updated application.

[0162] In this embodiment, the change risk prevention and control system also stores multiple second detection rules applicable to all change events. After the target change event is released, in addition to the user-defined first detection rule, the anomaly test is also performed according to the general second detection rule, eliminating the need for users corresponding to different business fields to repeatedly configure the general second detection rule.

[0163] In some embodiments, the publishing function provided by the change risk prevention and control system can also be applied to Figure 1 The simulation trial run phase is shown in Figure 2. Figure 5A As shown, that is, in the simulation trial operation stage and the release stage, the target change event can be released in batches in the test servers of the pre-release environment and the test environment in the simulation trial operation stage, and can be released in batches in the server cluster of the formal environment in the release stage. Before the release of each batch, it is determined whether the release conditions recorded above are met. After each batch is released, the updated application is detected for anomalies according to the stored first detection rule and the second detection rule. And after passing the anomaly detection, the next batch is released.

[0164] like Figure 5B , which is a schematic diagram of another change risk prevention and control system according to an exemplary embodiment of the present specification, which can be used to perform risk prevention and control on application changes of any business system among multiple other business systems.

[0165] Exemplarily, the change risk prevention and control system itself can pre-integrate multiple detection capabilities, such as the defense capability integration shown in the figure, which can include multiple detection capabilities such as inspection platform, application capacity platform, fault fuse or simulation regression. These defense capabilities, as basic defense capabilities, can be used by the first type of users to configure detection rules to generate and store the detection rules required by the users.

[0166] In the change risk prevention and control system, general detection rules can also be pre-configured, such as the built-in plug-in defense capability shown in the figure, that is, the general detection rules mentioned above. The figure shows the types of general rules such as change roadblocks or change conflicts as examples.

[0167] Exemplarily, the change risk prevention and control system defines the change event in a standardized manner, and the multiple attributes of the change event include at least one of the following attributes:

[0168] An attribute representing basic information of a change event, wherein the basic information includes any of the following: title information, initiator information, or time information;

[0169] An attribute representing the type information of a change event, where the type information includes any of the following: code release type or parameter configuration type;

[0170] Characterizing the attributes of the execution information of the change event, the execution information including any of the following: batch release mode information, blue-green release mode information, or shutdown release mode information;

[0171] The attribute characterizing the impact scope information of the change event, wherein the impact scope information includes any of the following: impact object information or impact degree information.

[0172] When the second type of user submits a target change event, the change release request needs to carry the target attribute value of the attribute of the target change event for the second type of user. In this embodiment, the target attribute value configured by the second type of user can be obtained through SPI (Serviceprovider interface). SPI is a built-in standard of Java, which allows different developers to implement a specific service. Exemplarily, as shown in the figure, this embodiment can set a standard SPI model to standardize the information structure of the change event, that is, to clearly describe what information a change event should have. The standard SPI model may include a change triple, a change impact surface, and a defense verification model for the attributes of the change event. In this case, the change triple and the change impact surface are used to obtain the target attribute value of the change event configured by the second type of user. In this case, the change triple is used to configure the following information: user representation information of the initiator of the change, target application, and type information of the change event. The change triple describes which user has executed what type of change event on which application. The change impact surface is an attribute that represents the impact range information of the change event, which is used for users to configure corresponding attribute values. The defense verification model is used for users to configure other attribute information.

[0173] The rule configuration module includes a first configuration submodule, which is used to implement the function of the configured defense shown in the figure. Specifically, a configuration function for each of the detection capabilities can be provided, and the configuration function can be used to obtain the configuration parameters of the first type of user for the business system targeted by one or more of the detection capabilities and generate detection rules. For example, the change risk prevention and control system provides a detection capability A, which is used to monitor a certain type of business indicator to determine whether the business system to which the business indicator belongs is abnormal. The first type of user can configure a parameter for the detection capability A, and the parameter is used to describe the name K of the business system, so that the first configuration submodule can generate a detection rule of "monitoring a certain type of business of business system K to determine whether business system K is abnormal".

[0174] The rule configuration module of the change risk prevention and control system includes a second configuration submodule, which is used to implement the function of the code described in the figure for coded defense. Specifically, a code configuration function is provided, through which a script file describing the detection rules submitted by the second type of user is obtained, and a detection rule is generated based on the script file. In this embodiment, the detection rules of the second type of user are implemented by scripts, that is, the second type of user writes the detection rules through code, and after the system obtains the script file written by the user, it is converted into a detection rule through code analysis and stored.

[0175] The third configuration submodule is used to provide a service provision interface. In this embodiment, the second-category users can implement customized development through the SPI, and the detection rules submitted by the second-category users are obtained and stored through the service provision interface.

[0176] As shown in the figure, the second type of user is the user who needs to publish the change. The second type of user initiates a change publishing request, and the change publishing request carries the target attribute value of the attribute of the target change event for the second type of user. The change risk prevention and control system of this embodiment can automatically manage and control the target change event throughout the life cycle. The system of this embodiment divides the change into three environments: a pre-release execution environment, a grayscale release environment, and a formal release environment.

[0177] The pre-launch execution environment refers to a pre-established test environment with multiple test servers for testing change events. The test servers do not provide services for real users, but for virtual users. By making changes in the pre-launch execution environment, change events can be tested without disturbing real users.

[0178] A grayscale release environment is a release environment composed of dedicated grayscale servers that provide services to test users, who are selected from a large number of real users. By making changes in a grayscale release environment, you can use a small number of test users to test whether the changed business system is abnormal without disturbing a large number of users.

[0179] The official release environment refers to the release environment composed of all servers, which are used to provide services to all users. After the change event is confirmed to be normal through the pre-release execution environment and the gray release environment, the change event can be released in the official release environment.

[0180] As shown in the figure, this embodiment executes the change event multiple times according to the preset lifecycle management order, and the preset lifecycle management order is pre-release execution environment, gray release environment and formal release environment. In addition, before (pre) and after (post) the execution of each change event, detection rules will be used for defense. Before execution, the detection rules are used to determine whether the change event can be executed at present; after execution, the detection rules are used to determine whether the change event will cause anomalies after execution. At each pre or post time point in the figure, the system can automatically find the currently matched detection rules from the stored detection rules based on the current execution environment and execute them. Based on this, the management of the entire life cycle of the change event is realized.

[0181] In some examples, considering the user's judgment on the scope of impact of a change event, it may be due to a variety of reasons such as the user's lack of experience, resulting in the target attribute value configured by the user may not accurately describe the scope of impact of this change event. For example, the user's change event only targets the configuration change of a parameter of an application in a business system. The user believes that the impact of this change event is small and only targets the changed application, so the configuration of the target attribute value is only for this application. However, in actual applications, the business system may be associated with other upstream and downstream business systems, and the application is also associated with other applications in the business system. Therefore, there is a need to detect whether other business systems and other applications are abnormal after the change. Based on this, the change risk prevention and control system of this embodiment can also perform an impact analysis before searching for detection rules. Exemplarily, the change execution module is used to:

[0182] One or more extended attribute values ​​are extended according to the target attribute value, and a currently matched detection rule is searched from the stored detection rules according to the target attribute value and the one or more extended attribute values ​​and executed; wherein the extended attribute value is obtained by:

[0183] Based on the target application to be changed by the target change event and the target business system to which the target application belongs, the upstream business system or downstream business system of the target business system, as well as other applications associated with the target application, are determined, and impact scope information is generated including extended attribute values ​​of any of the upstream business system, downstream business system or other applications.

[0184] That is, this embodiment can expand more extended attribute values ​​for the impact surface based on the target attribute value configured by the user, so that more suitable detection rules can be found for detection.

[0185] After determining the target attribute value and the extended attribute value, each time the currently matched detection rule is searched, that is, the routing and matching of the rule shown in the figure. There may be many detection rules to be searched, and when executing, the rules can be called concurrently as shown in the figure.

[0186] Based on a method for publishing a change event described in any of the above embodiments, the embodiments of this specification also provide Figure 6 A change risk prevention and control system 60 is shown. Figure 6 As shown, the change risk prevention and control system 60 includes:

[0187] A rule configuration module 610 is used to: store a plurality of detection rules, wherein the detection rules are obtained by: providing a plurality of predefined attributes for describing a change event, and receiving a detection rule configured by a first type of user and an attribute value of an attribute configuration applicable to the detection rule;

[0188] The change publishing module 620 is used to: provide the multiple attributes and receive a change publishing request from a second type of user, wherein the change publishing request carries a target attribute value of the attribute of the target change event for the second type of user;

[0189] The change execution module 630 is used to: execute the target change event multiple times in a preset lifecycle management order in multiple preset execution environments; wherein, before each execution of the target change event, the currently matching detection rule is searched out from the stored detection rules at least according to the target attribute value and executed to determine whether the target change event can be executed; and after each execution of the target change event, the currently matching detection rule is searched out from the stored detection rules at least according to the target attribute value and executed to determine whether the target change event causes an exception.

[0190] In some examples, the multiple attributes of the change event include at least one of the following attributes:

[0191] An attribute representing basic information of a change event, wherein the basic information includes any of the following: title information, initiator information, or time information;

[0192] An attribute representing the type information of a change event, where the type information includes any of the following: code release type or parameter configuration type;

[0193] Characterizing the attributes of the execution information of the change event, the execution information including any of the following: batch release mode information, blue-green release mode information, or shutdown release mode information;

[0194] The attribute characterizing the impact scope information of the change event, wherein the impact scope information includes any of the following: impact object information or impact degree information.

[0195] In some examples, the change execution module is used to:

[0196] One or more extended attribute values ​​are extended according to the target attribute value, and a currently matched detection rule is searched from the stored detection rules according to the target attribute value and the one or more extended attribute values ​​and executed; wherein the extended attribute value is obtained by:

[0197] Based on the target application to be changed by the target change event and the target business system to which the target application belongs, the upstream business system or downstream business system of the target business system, as well as other applications associated with the target application, are determined, and impact scope information is generated including extended attribute values ​​of any of the upstream business system, downstream business system or other applications.

[0198] In some examples, the change risk prevention and control system is connected to multiple business systems, and the change event is used to change one or more applications in the business system; the change risk prevention and control system is integrated with multiple detection capabilities;

[0199] The rule configuration module includes any of the following sub-modules:

[0200] A first configuration submodule is used to: provide a configuration function for each of the detection capabilities, obtain configuration parameters of the second type of user for the business system targeted by one or more of the detection capabilities through the configuration function, and generate detection rules;

[0201] A second configuration submodule is used to: provide a code configuration function, obtain a script file describing the detection rule submitted by the second type of user through the code configuration function, and generate the detection rule based on the script file;

[0202] The third configuration submodule is used to provide a service provision interface, and obtain and store the detection rules submitted by the second type of users through the service provision interface.

[0203] In some examples, the currently matched detection rules found before the target change event is executed include:

[0204] A detection rule for detecting whether a release condition of a target change event is satisfied, wherein the release condition includes any of the following: a condition that the risk level of the target change event is less than a preset level threshold; wherein the level threshold is related to the business volume of the target business system at the current moment, and / or is related to whether the current moment is within a specified date; the target business system is the business system changed by the target change event; or,

[0205] A detection rule used to detect whether the parameter value of the target parameter configured in the target change event of the parameter configuration type passes the legality check.

[0206] In some examples, the plurality of detection rules include preset detection rules;

[0207] After each execution of the change event, the currently matched detection rule is searched from the stored first detection rules according to the target attribute value, including:

[0208] Compare the number and / or type of errors before and after the target change event is released, and determine whether the updated application has abnormal error reporting rules based on the comparison results;

[0209] Compare the business data transmitted between the target business system and the associated business systems before and after the target change event is released, and determine whether an abnormal link rule occurs in the updated application based on the comparison result of the business data; wherein the target business system is the business system to which the application belongs, and the associated business system is the upstream and / or downstream business system of the target business system.

[0210] In some examples, the plurality of preset execution environments include: a pre-release execution environment, a phased release environment, and a formal release environment;

[0211] The preset lifecycle management order is pre-release execution environment, grayscale release environment and formal release environment.

[0212] Based on a method for publishing a change event described in any of the above embodiments, the embodiments of this specification also provide Figure 7 A schematic diagram of the structure of an electronic device is shown in FIG. Figure 7 At the hardware level, the electronic device includes a processor, an internal bus, a network interface, a memory, and a non-volatile memory, and may also include hardware required for other services. The processor reads the corresponding computer program from the non-volatile memory into the memory and then runs it to implement a method for publishing a change event described in any of the above embodiments.

[0213] Based on a method for publishing a change event described in any of the above embodiments, an embodiment of this specification further provides a computer storage medium, which stores a computer program. When the computer program is executed by a processor, it can be used to execute a method for publishing a change event described in any of the above embodiments.

[0214] The above describes specific embodiments of the present specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recorded in the claims can be performed in an order different from that in the embodiments and still achieve the desired results. In addition, the processes depicted in the accompanying drawings do not necessarily require the specific order or continuous order shown to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0215] Those skilled in the art will readily appreciate other implementations of the embodiments of the present specification after considering the specification and practicing the inventions claimed herein. The embodiments of the present specification are intended to cover any variations, uses, or adaptations of the embodiments of the present specification, which follow the general principles of the embodiments of the present specification and include common knowledge or customary techniques in the art that are not claimed in the embodiments of the present specification. The description and embodiments are to be considered merely as exemplary, and the true scope and spirit of the embodiments of the present specification are indicated by the claims below.

Claims

1. A method for preventing and controlling change risks, the method comprising: In response to a rule configuration request from a first type of user, providing a plurality of predefined attributes for describing a change event; Acquire and store the detection rule configured by the first category of users, wherein the detection rule includes the attribute value configured by the first category of users for the attribute describing the change event applicable to the detection rule; When the second user needs to initiate a target change event, providing the multiple attributes so that the second type of user configures the target attribute value of the attribute of the target change event based on the multiple attributes; receiving a change publishing request from a second type of user, the change publishing request carrying a target attribute value of an attribute of the target change event configured by the second type of user; Before each execution of the target change event, a detection rule matching the target change event is searched from the stored detection rules at least based on the target attribute value and executed to determine whether the target change event can be executed; and after each execution of the target change event, a detection rule matching the target change event is searched from the stored detection rules at least based on the target attribute value and executed to determine whether the target change event causes an exception.

2. The method according to claim 1, wherein the target change event comprises a plurality of preset execution environments, and executing the target change event comprises: The target change event is executed in each preset execution environment according to a preset lifecycle management order.

3. The method according to claim 2, wherein the plurality of preset execution environments comprises: Pre-release execution environment, grayscale release environment, and official release environment; The preset lifecycle management order is pre-release execution environment, grayscale release environment and formal release environment.

4. The method according to claim 1, wherein before each execution of the target change event, searching for a detection rule matching the target change event from stored detection rules at least according to the target attribute value, comprises: At least according to the target attribute value, a detection rule for detecting whether a release condition of the target change event is satisfied is searched from the stored detection rules, wherein the release condition includes any of the following: The risk level of the target change event is less than a preset level threshold; wherein the level threshold is related to the business volume of the target business system at the current moment, and / or whether the current moment is within a specified date; the target business system is the business system changed by the target change event; or, A condition used to detect whether the parameter value of the target parameter configured in the target change event of the parameter configuration type passes the legality check.

5. The method according to claim 1, wherein after each execution of the target change event, searching for a detection rule matching the target change event from stored detection rules at least according to the target attribute value, comprises: Compare the number and / or type of errors before and after the target change event is released, and determine whether the updated application has abnormal error reporting rules based on the comparison results; Compare the business data transmitted between the target business system and the associated business systems before and after the target change event is released, and determine whether an abnormal link rule occurs in the updated application based on the comparison result of the business data; wherein the target business system is the business system to which the application belongs, and the associated business system is the upstream and / or downstream business system of the target business system.

6. The method according to claim 1, wherein the multiple attributes of the change event include at least one of the following attributes: An attribute representing basic information of a change event, wherein the basic information includes any of the following: title information, initiator information, or time information; An attribute representing the type information of a change event, where the type information includes any of the following: code release type or parameter configuration type; Characterizing the attributes of the execution information of the change event, the execution information including any of the following: batch release mode information, blue-green release mode information, or shutdown release mode information; The attribute characterizing the impact scope information of the change event, wherein the impact scope information includes any of the following: impact object information or impact degree information.

7. The method according to claim 1, wherein searching for a detection rule matching the target change event from stored detection rules at least according to the target attribute value comprises: Determine the impact scope of the target change event; One or more extended attribute values ​​are extended based on the target attribute value and the impact range, and a currently matched detection rule is searched from the stored detection rules according to the target attribute value and the one or more extended attribute values.

8. The method according to claim 7, wherein the extended attribute value comprises one or more of the following: The extended attribute values ​​of other applications associated with the target application to be changed by the target change event, the extended attribute values ​​of the upstream business system of the target business system to which the target application belongs, and the extended attribute values ​​of the downstream business system of the target business system to which the target application belongs.

9. The method according to claim 1, wherein the method is applicable to a change risk prevention and control system, wherein the change risk prevention and control system is connected to multiple business systems, wherein the change event is used to change one or more applications in the business system, and wherein the change risk prevention and control system is integrated with multiple detection capabilities; The obtaining the detection rule configured by the first type of user includes: Obtaining configuration parameters of the first type of user for the business system targeted by one or more of the detection capabilities through the configuration function provided by the change risk prevention and control system for each of the detection capabilities and generating detection rules; Obtaining a script file describing detection rules submitted by the first category of users through a code configuration function provided by the change risk prevention and control system, and generating detection rules based on the script file; The detection rules submitted by the first category of users are obtained through a service provision interface provided by the change risk prevention and control system.

10. A change risk prevention and control system, the change risk prevention and control system comprising: A rule configuration module, for providing a plurality of predefined attributes for describing a change event in response to a rule configuration request from a first type of user; Acquire and store the detection rule configured by the first category of users, wherein the detection rule includes the attribute value configured by the first category of users for the attribute describing the change event applicable to the detection rule; The change publishing module is used to provide the multiple attributes when the second user needs to initiate a target change event so that the second type of user can configure the target attribute value of the attribute of the target change event based on the multiple attributes; receive a change publishing request from the second type of user, the change publishing request carrying the target attribute value of the attribute of the target change event configured by the second type of user; A change execution module is used to, before each execution of the target change event, search for a detection rule that matches the target change event from the stored detection rules at least based on the target attribute value and execute it to determine whether the target change event can be executed; and after each execution of the target change event, search for a detection rule that matches the target change event from the stored detection rules at least based on the target attribute value and execute it to determine whether the target change event causes an exception.

11. An electronic device, comprising: processor; a memory for storing processor-executable instructions; Wherein, when the processor calls the executable instruction, it implements the method described in any one of claims 1-9.

12. A computer-readable storage medium, wherein a plurality of computer instructions are stored on the computer-readable storage medium, and when the computer instructions are executed, the method according to any one of claims 1 to 9 is performed.

Images