CN115904938A

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

Info

Publication number: CN115904938A
Application number: CN202211305683.2A
Authority: CN
Inventors: 邱硕; 王月凡; 俞灏宣
Original assignee: Alipay Hangzhou Information Technology Co Ltd
Current assignee: Alipay Hangzhou Information Technology Co Ltd
Priority date: 2022-10-24
Filing date: 2022-10-24
Publication date: 2023-04-04
Anticipated expiration: 2042-10-24
Also published as: CN117215948A; WO2024087949A1; CN115904938B

Abstract

The present specification provides a change risk prevention and control method, a system, an electronic device, and a storage medium, the system including: the rule configuration module is used for: storing a plurality of detection rules, wherein the acquisition mode comprises the following steps: providing a plurality of attributes which are predefined and used for describing change events, and receiving detection rules configured by a first type of users and attribute values of attribute configurations applicable to the detection rules; the change issuing module is used for: providing the plurality of attributes, and receiving a change issuing request of a second type of user, wherein the change issuing request carries a target attribute value of the second type of user to the attribute of the target change event; the change execution module is to: executing the target change event for multiple times in a plurality of preset execution environments according to a preset life cycle management sequence; before and after each target change event is executed, the currently matched detection rule is searched from the stored detection rules according to at least the target attribute value and executed to determine whether the event can be executed or determine whether the event causes an exception.

Description

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

Technical Field

The embodiment of the specification relates to the technical field of computers, in particular to a change risk prevention and control system, a change risk prevention and control method, electronic equipment and a storage medium.

Background

With the increasing speed of scientific and technological iteration, the upgrading of the service system is more and more frequent. The business system comprises a plurality of applications, and the change event release of the applications can update the applications, so that the business system is upgraded. For IT-related services, a change event initiated by an in-house developer may cause stability problems to the service system. In order to maintain the stability of the business system, abnormality detection may be performed before and after the release of a change event. However, different business systems have different anomaly detection methods, and different detection personnel have different anomaly detection experiences. On the one hand, the anomaly detection of the change event still depends on human experience, and if the experience of the detection personnel is insufficient, the anomaly may not be detected. On the other hand, if the tester is replaced, the previous tester can only give the testing experience to the next tester through mouth-to-mouth teaching, and the testing experience cannot be regularly precipitated.

Disclosure of Invention

The embodiment of the specification provides a change risk prevention and control system, a change risk prevention and control method, electronic equipment and a storage medium, so that systematic abnormality detection is provided.

According to a first aspect of embodiments herein, there is provided a change risk prevention and control system including:

a rule configuration module to: storing a plurality of detection rules, wherein the acquisition mode of the detection rules comprises the following steps: providing a plurality of attributes which are predefined and used for describing change events, and receiving a detection rule configured by a first type of users and attribute values of attribute configurations applicable to the detection rule;

a change publishing module to: providing the plurality of attributes and receiving a change issuing request of a second type of user, wherein the change issuing request carries a target attribute value of the second type of user to the attribute of a target change event;

a change execution module to: executing the target change event for multiple times in a plurality of preset execution environments according to a preset life cycle management sequence; before executing the target change event every time, searching a currently matched detection rule from the stored detection rules according to at least the target attribute value and executing the currently matched detection rule so as to determine whether the target change event can be executed or not; and after each target change event is executed, searching the currently matched detection rule from the stored detection rules according to at least the target attribute value and executing to determine whether the target change event causes abnormity.

In some examples, the plurality of attributes of the change event includes at least one of the following:

attributes of base information characterizing a change event, the base information including any of: header information, originator information, or time information;

attributes of type information characterizing the change event, the type information including any of: a code release type or a parameter configuration type;

attributes of execution information characterizing a change event, the execution information including any of: batch release mode information, blue-green release mode information or stop release mode information;

attributes characterizing influence range information of a change event, the influence range information including any one of: influence object information or influence degree information.

In some examples, the change execution module is to:

expanding one or more expanded attribute values according to the target attribute value, and searching and executing a currently matched detection rule from stored detection rules according to the target attribute value and the one or more expanded attribute values; the method for acquiring the extended attribute value includes:

and determining an upstream service system or a downstream service system of the target service system and other applications related to the target application according to the target application to be changed of the target change event and the target service system to which the target application belongs, and generating influence range information including an extended attribute value of any one of the upstream service system, the downstream service system or the other applications.

In some examples, the change risk prevention and control system is connected with a plurality of business systems, and the change event is used for changing one or more applications in the business systems; the change risk prevention and control system is integrated with various detection capabilities;

the rule configuration module comprises any one of the following sub-modules:

a first configuration submodule to: providing a configuration function for each detection capability, and acquiring configuration parameters of the second class of users for one or more service systems for which the detection capability is targeted and generating detection rules through the configuration function;

a second configuration submodule to: providing a code configuration function, acquiring a script file describing a detection rule submitted by a second type of user through the code configuration function, and generating the detection rule based on the script file;

a third configuration submodule to: and providing a service providing interface, and acquiring and storing the detection rule submitted by the second type of user through the service providing interface.

In some examples, the current matching detection rule found prior to execution of the target change event includes:

a detection rule for detecting whether a distribution condition of a target change event is satisfied, the distribution condition including any one of: a condition that a risk level of the target change event is less than a preset level threshold; wherein the level threshold is related to the traffic of the target service system at the current time and/or is related to whether the current time is within a specified date; the target business system is a business system changed by the target change event; or the like, or a combination thereof,

and the detection rule is used for detecting whether the parameter value of the target parameter configured in the target change event of the parameter configuration type passes the validity check.

In some examples, the plurality of detection rules includes a preset detection rule;

after each time of executing the change event, finding out a currently matched detection rule from the stored first detection rules according to the target attribute value, including:

comparing the error reporting quantity and/or error reporting type before and after the target change event is issued, and determining whether the updated application has abnormal error reporting rules according to the comparison result;

comparing service data transmitted between the target service system and the associated service system before and after the target change event is issued, and determining whether the updated application is abnormal according to the comparison result of the service data; wherein the target business system is a business system to which the application belongs, and the associated business system is an upstream and/or downstream business system of the target business system.

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

the preset life cycle management sequence is a pre-release execution environment, a gray scale release environment and a formal release environment in sequence.

According to a second aspect of embodiments herein, there is provided a change risk prevention and control method, the method comprising:

storing a plurality of detection rules, wherein the acquisition mode of the detection rules comprises: providing a plurality of attributes which are predefined and used for describing change events, and receiving a detection rule configured by a first type of users and attribute values of attribute configurations applicable to the detection rule;

providing the plurality of attributes and receiving a change issuing request of a second type of user, wherein the change issuing request carries a target attribute value of the second type of user to the attribute of a target change event;

executing the target change event for multiple times in a plurality of preset execution environments according to a preset life cycle management sequence; before executing the target change event every time, searching a currently matched detection rule from the stored detection rules according to at least the target attribute value and executing the currently matched detection rule so as to determine whether the target change event can be executed or not; and after each target change event is executed, searching a currently matched detection rule from the stored detection rules according to at least the target attribute value, and executing to determine whether the target change event causes an exception.

According to a third aspect of embodiments of the present specification, there is provided an electronic apparatus including:

a processor;

a memory for storing processor-executable instructions;

and when the processor calls the executable instruction, the operation of any one of the methods of the first aspect is realized.

According to a fourth aspect of embodiments herein, there is provided a computer readable storage medium having stored thereon computer instructions which, when executed, perform the method of any of the first aspects.

The technical scheme provided by the embodiment of the specification can have the following beneficial effects:

the embodiment of the specification provides a change risk prevention and control system, a change risk prevention and control method, an electronic device and a storage medium, wherein the change risk prevention and control system rule configuration module is used for: storing a plurality of detection rules, wherein the acquisition mode of the detection rules comprises: providing a plurality of attributes which are predefined and used for describing change events, and receiving detection rules configured by a first type of users and attribute values of attribute configurations applicable to the detection rules; a change publishing module to: providing the plurality of attributes and receiving a change issuing request of a second type of user, wherein the change issuing request carries a target attribute value of the second type of user to the attribute of a target change event; a change execution module to: executing the target change event for multiple times in a plurality of preset execution environments according to a preset life cycle management sequence; before executing the target change event every time, searching a currently matched detection rule from the stored detection rules according to at least the target attribute value and executing the currently matched detection rule so as to determine whether the target change event can be executed or not; and after each target change event is executed, searching the currently matched detection rule from the stored detection rules according to at least the target attribute value and executing to determine whether the target change event causes abnormity. Based on this, the change risk prevention and control system provides a rule configuration module for the first class users, and uniformly defines attributes for describing change events, so that the users can deposit the abnormal detection experience of each first class user into the system through the detection rule by configuring the attribute value of the attribute and the detection rule corresponding to the attribute value, different abnormal detection experiences of each detection person are simply and quickly fused, and the condition that the abnormal detection cannot be performed due to insufficient experience of the detection person is avoided. Moreover, for the second type of users, only the change issuing module needs to initiate a change issuing request, and the change execution module can execute the target change event for multiple times according to a preset life cycle management sequence in multiple preset execution environments, so that automatic management of the change event is realized.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of embodiments of the invention.

Drawings

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the embodiments of the specification and, together with the description, serve to explain the principles of the embodiments of the specification.

FIG. 1 is a schematic diagram illustrating various stages of a change event according to one embodiment of the present description.

Fig. 2 is a flowchart illustrating a method for risk change prevention and control according to an embodiment of the present disclosure.

Fig. 3 is a flow chart illustrating a method of risk alteration prevention and control according to another embodiment of the present disclosure.

Fig. 4 is a flowchart illustrating a method for risk control of changes according to another embodiment.

Fig. 5A is a flowchart illustrating a method for risk prevention and control of changes according to another embodiment.

Fig. 5B is a schematic diagram of a change risk prevention and control system according to another embodiment shown in the present specification.

FIG. 6 is a schematic diagram of a change risk prevention and control system, according to one embodiment of the present disclosure.

FIG. 7 is a hardware block diagram of an electronic device shown in accordance with one embodiment of the present description.

Detailed Description

Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, like numbers in different drawings represent the same or similar elements unless otherwise indicated. The implementations described in the following exemplary examples do not represent all implementations consistent with the examples of this specification. Rather, they are merely examples of apparatus and methods consistent with certain aspects of the embodiments of the specification, as detailed in the claims that follow.

The terminology used in the embodiments of the present specification is for the purpose of describing particular embodiments only and is not intended to be limiting of the embodiments of the present specification. As used in the specification examples and the appended claims, the singular forms "a", "an", and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should also be understood that the term "and/or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items.

It should be understood that although the terms first, second, third, etc. may be used in the embodiments of the present specification to describe various information, the information should not be limited to these terms. These terms are only used to distinguish one type of information from another. For example, the first information may also be referred to as second information, and similarly, the second information may also be referred to as first information, without departing from the scope of the embodiments herein. The word "if," as used herein, may be interpreted as "at … …" or "at … …" or "in response to a determination," depending on the context.

With the increasing speed of scientific and technological iteration, the upgrading of the service system is more and more frequent. Taking e-commerce as an example, shopping carts, commodity details and orders are independent applications, and a plurality of applications form a business system such as shopping, payment and the like. From a technical implementation point of view, each upgrade of a business system includes a change of one or more applications. In other words, the application's change event publication will cause the application to update, thereby upgrading the business system. The change of application comprises 5 stages as shown in fig. 1. Firstly, an internal developer initiates a change event request of an application and submits a change code, a reviewer browses change code logic, and the content of the change event is approved based on dimensions such as bug abnormity, code style, performance defects, repeated codes and the like. And after the approval is passed, the simulation test run is carried out, and risk simulation is carried out in a test environment. Then entering a release phase of the change event, and measuring the change event after release.

Aiming at the initiation stage and the auditing stage of the change event, the change event is usually realized by manual management in the industry. Namely, the risk problem in the change process is assisted and evaluated through the approval process of the internal reviewer. However, the human management is often difficult to comprehensively evaluate risks due to large auditing throughput, careless information filling of change initiators, insufficient experience and the like, so that some potential risks cannot be discovered and solved in an auditing stage.

On the basis, the platform also increases the perception capability of the change event while the change event initiation and audit are kept in the industry. The platform can actively sense each change event and actively check the possible risks of the change events, so that the review personnel can passively discover the risks of the change events from the data submitted by the change initiator and can actively discover the risks of various changes in the review stage. However, such a solution still cannot find the exception and intervene in time at the release stage of the change.

For IT-related services, a change event initiated by an in-house developer may cause stability problems to the service system. In order to maintain the stability of the business system, abnormality detection may be performed before and after the issuance of a change event. However, different business systems have different anomaly detection methods, and different detection personnel have different anomaly detection experiences. On the one hand, the anomaly detection of the change event still depends on human experience, and if the experience of a detection person is insufficient, the anomaly may not be detected. On the other hand, if the tester is replaced, the previous tester can only give the testing experience to the next tester through mouth-to-mouth teaching, and the testing experience cannot be regularly precipitated.

In the related art, most schemes are provided for the scene with a small number of service systems for risk prevention and control of change, so that the change issuing, the change event management and the change event exception detection are controlled by a technician initiating the change; however, the inventor of the present application finds that, with the increase of business of an enterprise, the number of business systems is increasing, an enterprise gradually lays out more and more business systems, and each business system has a dependency relationship with each other, and a technician of one business system only manages the change of the business system, and from the management of a change event, the technician of each business system may repeat some work, and from the anomaly detection of the change event, the rule of the anomaly detection depends on the experience of a person, and may cause the anomaly detection to have limitation because the conditions of other business systems are not known, and also the detection experience cannot be settled regularly for reuse.

Therefore, the embodiment of the specification provides a change risk prevention and control method which is applied to a change risk prevention and control system. Illustratively, the change risk prevention and control system may be a change risk prevention and control system integrated with Development (Development) and operation and maintenance (Operations). The change risk prevention and control system can be connected with one or more server clusters, and each server in the server clusters can run the same application. Illustratively, each server in the server cluster is loaded with the same business system, and therefore runs the same application. The above method comprises the steps as shown in fig. 2:

step S11: a plurality of detection rules are stored.

The acquisition mode of the detection rule comprises the following steps: the method comprises the steps of providing a plurality of attributes which are predefined and used for describing change events, and receiving detection rules configured by a first type of users and attribute values of attribute configurations applicable to the detection rules.

Step S12: providing the plurality of attributes, and receiving a change issuing request of a second type of users.

And the change issuing request carries a target attribute value of the attribute of the second type user to the target change event.

Step S13: and executing the target change event for multiple times in a plurality of preset execution environments according to a preset life cycle management sequence.

Before executing the target change event every time, searching a currently matched detection rule from the stored detection rules according to at least the target attribute value and executing the currently matched detection rule so as to determine whether the target change event can be executed or not; and after each target change event is executed, searching the currently matched detection rule from the stored detection rules according to at least the target attribute value and executing to determine whether the target change event causes abnormity.

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

For example, the change risk prevention and control system may be connected to a plurality of server clusters, and different server clusters carry different business systems. The service data flow interaction can exist between the service systems, and the service systems can also be independent of each other. And configuring detection rules by different field experts including research personnel, quality personnel and operation and maintenance personnel for each service system. In this way, experts in different fields can configure corresponding detection rules for the change events related to the business system by changing the rule configuration function provided by the risk prevention and control system.

Because the attribute for describing the change event of the application is predefined by the change risk prevention and control system, whether the change event is different change events of the same application, or change events of different applications in the same business system, or change events of applications of different business systems are described by adopting the attribute predefined by the change risk prevention and control system.

Therefore, when the domain expert, namely the first class user, needs to perform rule configuration, a rule configuration request can be sent to the change risk prevention and control system. In response to the rule configuration request, the change risk prevention and control system sends predefined attributes to the user.

Illustratively, if the predefined attribute includes a plurality, all attributes are sent to the user.

Illustratively, the change risk prevention and control system may send the predefined attributes to the user through a standard interface. For example, the standard Interface may be SPI (Service Provider Interface).

Subsequently, the first type of user may configure the attribute value for the received attribute and configure the detection rule corresponding to the attribute value. For example, the user may configure attribute values for at least some of all the received attributes, and configure at least one first-class detection rule corresponding to the attribute values. In this embodiment, the detection rule configured by the first type of user is referred to as a first type of detection rule; in practical applications, the detection rules stored in the system may also have other implementation manners, for example, the detection rules are configured in advance by technicians who develop the system of the embodiment.

As an example, if the predefined attributes include 10 attributes from attribute 1 to attribute 10, the change risk prevention and control system may send attribute 1 to attribute 10 to the user in response to the rule configuration request. The user may configure an attribute value a only for the attribute 2, configure an attribute value B for the attribute 3, and configure at least one corresponding first-type detection rule. For example, the user may configure one or more first-type detection rules for attribute value a of attribute 2 and one or more first-type detection rules for attribute value B of attribute 3. Then when the attribute value of attribute 2 of the change event is equal to a, then the configured one or more first-type detection rules are hit. For another example, the user may configure one or more first-type detection rules for attribute value a of attribute 2, and 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, then the configured one or more first-type detection rules are hit.

After the user completes 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 configured for the attributes used by the first type of detection rules.

In some examples, the obtaining manner for obtaining the detection rule by the first class of users may include any one of the following:

providing a configuration function for each detection capability, and acquiring configuration parameters of the second class of users for one or more service systems for which the detection capability is targeted and generating detection rules through the configuration function;

providing a code configuration function, acquiring a script file describing a detection rule submitted by a second type of user through the code configuration function, and generating the detection rule based on the script file;

and providing a service providing interface, and acquiring and storing the detection rule submitted by the second type of user through the service providing interface.

For example, the user may upload the configured attribute values and the corresponding first type detection rules to the change risk prevention and control system in the form of plug-ins.

Illustratively, the change risk prevention and control system may provide a configuration interface to the user, which may be exposed with all of the predefined attributes. In addition, the configuration interface can further comprise a configuration module, so that a user can configure the attribute values and the first detection rules in the configuration module. For example, the configuration module may include an attribute configuration submodule and a rule configuration submodule. The user can configure the attribute values of at least part of the attributes in the attribute configuration sub-module, and configure the first type of detection rules in the rule configuration sub-module.

Illustratively, the change risk prevention and control system stores the first type of detection rule and the mapping relation between the first type of detection rule and the attribute value. As an example, the mapping relationship of the first detection rule and the attribute value may be stored in the form of an expression. The expression may be an equation, one side of which may record the attribute values of the user-configured attribute, and the other side may record the first type of detection rule or the unique identification of the first type of detection rule. With the unique identification, the corresponding detection rule of the first type can be read.

In addition, the change risk prevention and control system also provides a change event release function, and research personnel can use the change event release function provided by the change risk prevention and control system to release the change event of the application. The rule configuration function and the change event issuing function of the change risk prevention and control system can be called by the same user or different users.

In this embodiment, the second type of user may also issue a change issue request for a change event, and in this embodiment, one change event issued by the second type of user is referred to as a target change event. The second category of users of the present embodiment includes a category of users having change requirements. Since the change risk prevention and control system predefines the attribute for describing the change event of the application, when a developer initiates a release request of a target change event of the application to the change risk prevention and control system, the release request carries a target attribute value of the attribute of the target change event. Optionally, if the predefined attributes include a plurality of attributes, the target attribute values of at least some of the attributes are configured by the developer, and the target attribute values of the remaining attributes are generated by the change risk prevention and control system.

In this embodiment, the target change event may be executed multiple times in multiple preset execution environments according to a preset lifecycle management order; before executing the target change event every time, searching a currently matched detection rule from the stored detection rules according to at least the target attribute value and executing the currently matched detection rule so as to determine whether the target change event can be executed or not; and after each target change event is executed, searching the currently matched detection rule from the stored detection rules according to at least the target attribute value and executing to determine whether the target change event causes abnormity.

Illustratively, the plurality of preset execution environments include: a pre-release execution environment, a gray release environment and a formal release environment; the preset life cycle management sequence is a pre-release execution environment, a gray scale release environment and a formal release environment in sequence.

The pre-sending execution environment refers to a pre-established test environment, a plurality of test servers are used for testing change events in the test environment, and the test servers do not provide services for real users but provide services for virtual users. By making changes in the pre-launch execution environment, change events can be tested without causing a disturbance to the real user.

The gray scale distribution environment refers to a distribution environment composed of special gray scale servers, which provide services for test users, which are users selected from a large number of real users. By changing the gray level distribution environment, a small number of test users can test whether the changed service system is abnormal, and a large number of users are not disturbed.

The official publishing environment refers to a publishing environment consisting of all servers that serve all users. When the change event is determined to be abnormal by the pre-release execution environment and the gray scale release environment, the change event can be released in the formal release environment.

As an example, taking a gray scale distribution environment or a formal distribution environment as an example, the change risk prevention and control system may distribute the target change event to the target server of the server cluster in response to the distribution request. The issue of the target change event may be understood as updating an application corresponding to the target change event running on the target server. After the application is published, a target first detection rule can be determined from the stored rules according to a target attribute value of the attribute carried by the publication request, and the updated application is subjected to exception detection according to the target first detection rule. The target first detection rule may be a first detection rule which is configured by a user according to the method history and stored in the change risk prevention and control system.

Illustratively, the target first detection rule may be determined according to the target attribute value and the mapping relationship between the first detection rule and the attribute value stored in the change risk prevention and control system, and there may be one or more detection rules matched each time.

For example, all expressions in the change risk prevention and control system may be traversed, and all first detection rules that hit the target attribute may be determined as the target first detection rule.

In the method for issuing a change event according to this embodiment, since the change risk prevention and control system defines the attribute for describing the change event in a unified manner, the user can deposit the abnormality detection methods corresponding to different business systems and the abnormality detection experiences of different detection personnel into the change risk prevention and control system through the first detection rule by configuring the attribute value of the attribute and the first detection rule corresponding to the attribute value, thereby fusing the different abnormality detection experiences of each business team simply and quickly, and avoiding the situation that the abnormality cannot be detected due to insufficient experiences of the detection personnel.

The plurality of attributes of the change event comprise at least one of the following types of attributes:

Illustratively, the distribution pattern of change events includes a variety of patterns, including, for example and without limitation, shutdown distribution, batch distribution, blue-green distribution, and the like.

And stopping issuing, namely closing the service system before the change event is issued, stopping user access of the service system, and then updating the application running in the server cluster. The batch release comprises the gold sparrow release and the gray release. The canary release means that a change event is firstly released to a part of servers of a server cluster, so that a part of service system users access an upgraded service system, and real user data is used for flow verification. And if the verification is passed, the change event is issued to the rest servers, otherwise, the code is rolled back, namely, the version before the change event is issued is recovered. The gray release is an extension of canary release, the release is divided into different batches, and the number of servers in each batch is increased step by step. And if no problem is found in the current batch after the change event is issued, entering the next batch until the issue of the change event of the server cluster is completed.

Blue-green release means that two identical and mutually independent production environments exist, one environment is called a 'blue environment', and the other environment is called a 'green environment'. Where the green environment is the production environment the user is using. The change event may be issued in the blue environment first, that is, in a server corresponding to the blue environment. And then, running a smoke test in the blue environment to check whether the service system after the change event is issued works normally. And if the test is successful, updating the routing configuration, and guiding the user traffic of the service system from the green environment to the blue environment so that the blue environment is changed into the production environment.

According to the change event distribution method, the target change event can be distributed in the server cluster in any distribution mode. Illustratively, the target change event is distributed in a server cluster in batch, and specifically includes the steps shown in fig. 3:

in response to a publication request for a target change event of an application, performing:

step S211: one or more servers to be published are selected from the server cluster as target servers of the current batch;

step S213: issuing the target change event to the target server;

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

the steps S211 to S22 refer to the above embodiments, and are not described herein again.

Step S23: judging whether the abnormality is detected;

if yes, go to step S24; if not, go to step S25.

Step S24: outputting a notification of the change exception and/or stopping the issuance of the target change event.

Step S25: judging whether the server cluster completes publishing;

if not, the process returns to step S21, and if so, the target change event is issued.

In this embodiment, the target change event is distributed in the server cluster in batches, the target first detection rule is used to perform the abnormality detection after the distribution of each batch, and the distribution of the next batch is performed after the detection is passed. Compared with the checking logic confirmed manually in the related art, the embodiment realizes systematic and automatic abnormality detection of each batch of release by the change risk prevention and control system, and reduces the dependence on human labor.

In some embodiments, the attributes predefined by the change risk prevention and control system to describe the change event include one or more of: the type attribute of the change event, or the influence attribute of the change event, the basic attribute representing the change event in the proposing stage, and the release attribute representing the change event in the releasing stage.

Illustratively, the type attributes of the change event include 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 service system is modified, the type attribute of the corresponding change event is a parameter configuration type.

Illustratively, the impact attributes of a change event include the impact object and/or the impact level of the change event. For example, the impact object may be other applications. For another example, the release of a change event to an application may affect associated business systems located upstream and downstream from the target business system, in addition to the target business system to which the application belongs. Thus, the impact object may be an associated business system.

Illustratively, the basic attribute of the characteristic change event in the presentation phase refers to an attribute carried by a developer when initiating a release request of the target change event, including but not limited to one or more of a title, an initiator, and an initiation time of the target change event.

Illustratively, the publishing attributes characterizing the change event at the publishing phase include a publishing mode of the change event, and/or flag information of the target server where the change event is published. As described above, the change event can be distributed in any one of the batch distribution, the cyan distribution, and the shutdown distribution. As such, the publishing attribute includes a publishing mode. And if the issuing mode is the shutdown mode, the target server is all the servers in the server cluster. And if the issuing mode is batch issuing or blue-green issuing, the target server is a part of servers in the server cluster. The flag information may be a unique flag of the server. In this way, the distribution mode of the change event and which servers to distribute can be known through the distribution attribute.

As an example, the user may configure the respective first detection rules for different type attributes. For example, a first detection rule (1) is configured for a change event of a code release type, and a first detection rule (2) is configured for a change event of a parameter configuration type. Therefore, after the change event with the type attribute being the code release type is released, carrying out exception detection according to a first detection rule (1); and after the change event with the type attribute being the parameter configuration type is released, carrying out exception detection according to a first detection rule (2).

As an example, the user may configure the respective first detection rules for different impact objects. For example, the first detection rule (3) is configured for all change events affecting the object for business system a. Namely, all the change events of the business system A which can be influenced include the change events of the application belonging to the business system A and the change events of the application of other business systems which have business data interaction with the business system A, and the abnormal detection is carried out according to the first detection rule (3) during the release.

As an example, the user may configure the respective first detection rules for the initiators of different change events. For example, the first detection rule (4) is configured for all change events initiated by a certain initiator. Abnormality detection is performed according to a first detection rule (4) after the issuance of the change event.

As an example, the user may configure the respective first detection rules for different publication modes. For example, a first detection rule (5) is configured for a change event of a batch distribution mode; configuring a first detection rule (6) for a change event of a blue-green distribution mode; a first detection rule (7) is configured for a change event of the shutdown publishing mode.

In some examples, the method of this embodiment may further include:

expanding one or more expanded attribute values according to the target attribute value, and searching and executing a currently matched detection rule from stored detection rules according to the target attribute value and the one or more expanded attribute values; the obtaining mode of the extended attribute value comprises the following steps:

and determining an upstream service system or a downstream service system of the target service system and other applications related to the target application according to the target application to be changed in the target change event and the target service system to which the target application belongs, and generating influence range information comprising an extended attribute value of any one of the upstream service system, the downstream service system or the other applications.

a detection rule for detecting whether a distribution condition of a target change event is satisfied, the distribution condition including any one of: a condition that a risk level of the target change event is less than a preset level threshold; wherein the level threshold is related to the traffic of the target service system at the current time and/or is related to whether the current time is within a specified date; the target business system is a business system changed by the target change event; or the like, or, alternatively,

In some embodiments, in response to the publishing request, before publishing the target change event to the target server, the method further comprises: and judging whether the release condition of the change event is met.

Wherein, the publishing conditions include but are not limited to:

(1) The risk level of the change event is less than a preset level threshold. Wherein the level threshold is associated with the traffic of the target service system at the current time and/or is associated with whether the current time is within a specified date. The target business system is the business system applying the target business system.

The higher the risk level of a change event, the greater the probability of a stability problem that may be caused by the representative change event.

Illustratively, for the issue of a change event of a certain application, the change risk prevention and control system determines a risk level threshold according to the traffic volume of the business system (i.e. the target business system) to which the application belongs at the current time. For example, the greater the traffic volume of the target traffic system, the lower the level threshold. That is, when the traffic of the target service system is large, the change event with low risk can be issued.

Optionally, when the traffic of the target service system exceeds a set traffic threshold, that is, during a traffic peak, the change event is not allowed to be issued. And when the traffic of the target system does not exceed the traffic threshold, determining a level threshold of the risk according to the traffic, and allowing the change event with the risk level below the level threshold to be issued.

Illustratively, the level threshold is related to whether the current time is within a specified date. By way of example, the specified date includes, but is not limited to, a national significant event, a holiday, a legal holiday, and the like. Since it is particularly important to stabilize the service system on the specified date, the level threshold value on the specified date may be set to be smaller than the level threshold value on the other dates other than the specified date. That is, change events with lower risk levels may be issued within a given date.

(2) And if the type attribute of the target change event is the parameter configuration type, the parameter value of the configured target parameter passes the validity check.

As described above, the attributes predefined by the change risk prevention and control system include the type attribute of the change event. And the type attribute comprises a code release type and a parameter configuration type. If the parameters in the service system are modified, the type attribute of the corresponding change event is the parameter configuration type. Since the parameter value requested to be configured in the change event is manually input by the developer, in this embodiment, the validity of the parameter value configured for the parameter to be modified (i.e., the target parameter) may be checked. And if the validity is verified, judging that the release condition is met.

Optionally, validity check may be performed according to historical parameter values of the target parameter. As an example, the value range of the target parameter may be determined according to the historical parameter value of the target parameter. And if the parameter value configured by the target change event falls into the value range, passing the validity check.

In this embodiment, if the distribution mode of the target change event is batch distribution, the method for distributing the change event provided in this embodiment includes the steps shown in fig. 4:

in response to a request for issuance of a target change event for an application, performing:

step S212: judging whether the release condition of the change event is met;

step S213: issuing the target change event to the target server;

step S23: judging whether an abnormality is detected;

if yes, go to step S24; if not, go to step S25.

Step S24: and outputting a notification of the abnormal change, and stopping the release of the target change event.

Step S25: judging whether the server cluster completes publishing;

The above steps refer to the above embodiments, and are not described herein again.

In the embodiment shown in fig. 4, the change event is tested at the burial point before and after the release of each batch. Before release, namely pre-burying points, the risk change prevention and control system judges whether the current time meets release conditions, namely, the admittance test is carried out. And automatically issuing the change events of the batch when the issuing condition is met, namely after the admittance test passes. After the release, namely the post-buried point, the risk prevention and control system is changed to perform anomaly detection. And automatically entering the admittance test and release of the next batch after the abnormity detection is passed. On one hand, compared with the prior art that the issuing opportunity of the target change event is judged manually and the anomaly detection is carried out manually, the embodiment realizes automatic admittance test and anomaly detection by burying points before and after each batch. On the other hand, in the batch issuing process of the change events, problems can be found in time, and the issuing of the change events can be fused.

In some examples, each time the change event is executed, finding a currently matching detection rule from the stored first detection rules according to the target attribute value includes:

comparing the service data transmitted between the target service system and the associated service system before and after the target change event is issued, and determining whether the updated application is abnormal according to the comparison result of the service data; wherein the target business system is a business system to which the application belongs, and the associated business system is an upstream and/or downstream business system of the target business system.

In the above embodiment, since the change risk prevention and control system predefines the attribute of the change event, the user can configure the corresponding first detection rule in a self-defined manner with respect to the predefined attribute. Different first detection rules apply for different change events. In some embodiments, different change events may also be detected for anomalies using the same second detection rule, i.e. the second detection rule applies to all change events. In this way, the change risk prevention and control system further stores a plurality of second detection rules, and after the target change event is issued, abnormality detection is performed on the updated application according to the common second detection rule in addition to the target first detection rule. Wherein the second detection rule may include, but is not limited to, an error reporting rule and a link rule.

For example, the number and/or types of errors before and after the target change event is issued may be compared according to the error reporting rule in the second detection rule, and whether an abnormality occurs in the updated application may be determined according to the comparison result.

Optionally, the error reporting rule indicates to compare error reporting numbers before and after the target change event is issued, and if a difference between the error reporting numbers before and after the target change event is greater than a preset number threshold, it is determined that an exception occurs. As an example, the change risk prevention and control system may monitor the number of error reports that occur for one or more business systems. The change risk prevention and control system can periodically count the error reporting number of the business system and output the error reporting number in the forms of reports, time sequence statistical curves and the like. Therefore, whether the updated application is abnormal or not can be judged according to the drop and rise of the error reporting quantity before and after the release.

Optionally, the error reporting rule indicates to compare error reporting types before and after the target change event is issued, and if a new error reporting type occurs after the target change event is issued, it is determined that an exception occurs. As an example, various error types and the number of errors for each type are described in the log. Whether the updated application is abnormal or not can be judged by identifying whether the log has a newly added error reporting type or not.

Optionally, the error reporting rule indicates to compare error reporting numbers of the specified error reporting types before and after the target change event is released, and if a difference between the error reporting numbers of the specified error reporting types before and after the target change event is released is greater than a number threshold, it is determined that an exception occurs. As an example, as described above, the log stores various error types and the number of errors for each type. Therefore, the difference value of the error reporting quantity of the specified error reporting type before and after the release can be obtained, and whether the abnormity occurs or not can be determined.

For example, the service data transmitted between the target service system and the associated service system before and after the target change event is issued may be compared according to the link rule in the second detection rule, and whether an updated application is abnormal may be determined according to a comparison result of the service data. The target business system is a business system to which the application belongs, and the related business system is an upstream business system and/or a downstream business system of the target business system.

And aiming at the release of the change event of a certain application, the service system to which the application belongs is the target service system. As described above, there may be interactions of traffic data traffic between the traffic systems. Therefore, the business data transmitted between the target business system and the business systems (namely, the related business systems) at the upstream and downstream of the target business system can be captured, and whether the abnormity occurs or not can be judged by comparing the difference of the business data before and after the distribution. For example, if the service data delivered to the associated service system by the target service system before the release is "Success" and the service data delivered after the release is "Fail", it is determined that the updated application is abnormal.

In this embodiment, the change risk prevention and control system further stores a plurality of second detection rules applicable to all change events. After the target change event is released, exception testing is carried out according to the first detection rule defined by the user and the universal second detection rule, so that the situation that the user corresponding to different service fields repeatedly configures the universal second detection rule is avoided.

In some embodiments, the distribution function provided by the change risk prevention and control system may also be applied in the simulation commissioning phase as shown in fig. 1. As shown in fig. 5A, that is, in the simulation commissioning phase and the release phase, the target change event may be released in batches in the test servers of the pre-release environment and the test environment in the simulation commissioning phase, and may be released in batches in the server cluster of the formal environment in the release phase. It is determined whether the above-described distribution conditions are satisfied before distribution of each batch. And after each batch is released, performing anomaly detection on the updated application according to the stored first detection rule and the second detection rule. And then enter the next batch of publication after passing the anomaly detection.

Fig. 5B is a schematic diagram of another change risk prevention and control system according to an exemplary embodiment, which can be used for risk prevention and control of application change of any business system in other multiple business systems.

For example, the change risk prevention and control system itself may integrate a plurality of detection capabilities in advance, for example, the shown defense capability integration may include a plurality of detection capabilities such as a polling platform, an application capacity platform, fault fusing, or simulation regression, and these defense capabilities serving as basic defense capabilities may be provided for the first type of user to configure the detection rule, so as to generate and store the detection rule required by the user.

In the change risk prevention and control system, a common detection rule may be configured in advance, for example, the built-in plug-in defense capability shown in the figure, that is, the common detection rule mentioned above, and the figure shows, as an example, the type of the common rule, such as a change barrier or a change conflict.

Illustratively, the change risk prevention and control system defines a standardized change event, and the plurality of attributes of the change event include at least one of the following types of attributes:

attributes of type information characterizing change events, the type information including any of: a code release type or a parameter configuration type;

When a second type user submits a target change event, a change release request needs to carry a target attribute value of the second type user for the attribute of the target change event. In this embodiment, the target attribute value configured by the second type of user may be obtained through an SPI (Service provider interface). SPI is a built-in standard for Java, allowing different developers to implement a particular service. For example, as shown in the figure, the present embodiment may set a standard SPI model for performing standardized definition on the information structure of the change event, i.e. describing which information a change event should have. The standard SPI model may include change triples, change impact surfaces, and defense verification models for attributes of change events. And the change triple and the change influence surface are used for acquiring the target attribute value of the current change event configured by the second type of users. Wherein, the change triple is used for configuring the following information: the user who initiates the change indicates information, the target application, and the type information of the change event, and the change triple describes which user performed what type of change event for which application. The change influence surface is an attribute representing influence range information of the change event and is used for configuring a corresponding attribute value by a user. And the defense checking model is used for configuring other attribute information by the user.

The rule configuration module includes a first configuration submodule for implementing the configured defensive functions shown in the figure. Specifically, a configuration function for each detection capability may be provided, and the configuration function may acquire configuration parameters of the first class of users for one or more service systems to which the detection capability is directed, and generate a detection rule. For example, the change risk prevention and control system provides a detection capability a for monitoring a certain type of service index to determine whether the service system to which the service index belongs is abnormal. The first class user can configure a parameter for the detection capability a, where the parameter is used to describe the name K of the service system, so that the first configuration sub-module can generate a detection rule for "monitoring a certain class of service of the service system K to determine whether the service system K is abnormal.

The rule configuration module of the change risk prevention and control system comprises a second configuration submodule for realizing the function of the code used for coded defense in the graph. Specifically, a code configuration function is provided, a script file describing the detection rule submitted by the second type of user is obtained through the code configuration function, and the detection rule is generated based on the script file. In this embodiment, the detection rule of the second type of user is implemented by using a script, that is, the second type of user writes the detection rule through a code, and after the system acquires a script file written by the user, the script file is converted into the detection rule through code analysis and stored.

A third configuration submodule to: and providing a service providing interface, wherein the embodiment can be used for each second type user to realize customized development through the SPI, and the detection rule submitted by the second type user is obtained through the service providing interface and is stored.

As shown in the figure, the second type of user is a user who needs to issue a change, and the second type of user initiates a change issue request, where the change issue request carries a target attribute value of an attribute of a target change event by the second type of user. The change risk prevention and control system of the embodiment can automatically control the whole life cycle of the target change event. The system of this embodiment splits the change into three environments: a pre-release execution environment, a gray release environment, and a formal release environment.

The gray scale distribution environment refers to a distribution environment composed of dedicated gray scale servers which provide services for test users who are users selected among a large number of real users. By changing the gray level distribution environment, a small number of test users can test whether the changed service system is abnormal, and a large number of users are not disturbed.

As shown in the figure, the present embodiment executes the change event multiple times according to a preset lifecycle management sequence, where the preset lifecycle management sequence is a pre-release execution environment, a grayscale release environment, and a formal release environment in sequence. Each time the change event is executed, the defense is performed by using the detection rule before (pre) and after (post). Before executing, determining whether the change event can be executed currently or not through a detection rule; after execution, it is determined by the detection rule whether the change event will cause an exception after execution. For example, at each pre or post time point in the graph, the system can automatically find out the currently matched detection rule from the stored detection rules and execute the detection rule based on the current execution environment. Based on this, management of the entire life cycle of the change event is achieved.

In some examples, considering the determination of the influence range of the one-time change event by the user, the target attribute value configured by the user may not accurately describe the influence range of the current change event due to various reasons such as insufficient experience of the user. For example, the present change event of the user is directed to only the configuration change of one parameter of a certain application in a certain service system, and the user considers that the influence range of the present change event is small and is directed to only the changed application, so the configuration of the target attribute value is directed to only the application. However, in practical applications, the business system may be associated with other business systems upstream and downstream, and the application is also associated with other applications in the business system, so that there is a need for detecting whether the changed business system and other applications are abnormal. Based on this, the change risk prevention and control system of the present embodiment may further perform the analysis of the influence surface before searching for the detection rule. Illustratively, the change execution module is configured to:

That is, the embodiment may expand more extended attribute values for the influence surface on the basis of the target attribute value configured by the user, so that more appropriate detection rules may be found for detection.

After the target attribute value and the extended attribute value are determined, the currently matched detection rule, namely the routing and matching of the rule shown in the figure, is searched each time. The detection rules searched for may be many, and when executed, concurrent invocation of the rules may be performed as shown in the figure.

Based on the method for issuing a change event according to any of the above embodiments, an embodiment of the present specification further provides a change risk prevention and control system 60 as shown in fig. 6. As shown in fig. 6, the change risk prevention and control system 60 includes:

a rule configuration module 610 for: storing a plurality of detection rules, wherein the acquisition mode of the detection rules comprises: providing a plurality of attributes which are predefined and used for describing change events, and receiving a detection rule configured by a first type of users and attribute values of attribute configurations applicable to the detection rule;

a change publishing module 620 to: providing the plurality of attributes and receiving a change issuing request of a second type of user, wherein the change issuing request carries a target attribute value of the second type of user to the attribute of a target change event;

a change execution module 630 configured to: executing the target change event for multiple times in a plurality of preset execution environments according to a preset life cycle management sequence; before executing the target change event every time, searching a currently matched detection rule from the stored detection rules according to at least the target attribute value and executing the currently matched detection rule so as to determine whether the target change event can be executed or not; and after each target change event is executed, searching the currently matched detection rule from the stored detection rules according to at least the target attribute value and executing to determine whether the target change event causes abnormity.

In some examples, the plurality of attributes of the change event include at least one of:

In some examples, the change execution module is to:

the rule configuration module comprises any one of the following sub-modules:

a detection rule for detecting whether a release condition of a target change event is satisfied, where the release condition includes any one of: a condition that a risk level of the target change event is less than a preset level threshold; wherein the level threshold is related to the traffic of the target service system at the current time and/or is related to whether the current time is within a specified date; the target business system is a business system changed by the target change event; or the like, or, alternatively,

Based on the method for issuing a change event according to any of the embodiments, an embodiment of this specification further provides a schematic structural diagram of an electronic device shown in fig. 7. As shown in fig. 7, at the hardware level, the electronic device includes a processor, an internal bus, a network interface, a memory, and a non-volatile memory, but 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 the computer program to implement the method for issuing a change event according to any of the embodiments described above.

Based on the method for issuing a change event according to any of the embodiments, an embodiment of the present specification further provides a computer storage medium, where a computer program is stored, and the computer program, when executed by a processor, is operable to execute the method for issuing a change event according to any of the embodiments.

The foregoing description of specific embodiments has been presented for purposes of illustration and description. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims may be performed in a different order than in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing may also be possible or may be advantageous.

Other embodiments of the present disclosure will be apparent to those skilled in the art from consideration of the specification and practice of the invention disclosed herein. The embodiments of the present specification are intended to cover any variations, uses, or adaptations of the embodiments of the specification that follow their general principles and include such departures from the present disclosure as come within known or customary practice in the art to which the embodiments of the specification are not applied. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the embodiments being indicated by the following claims.

Claims

1. A change risk prevention and control system, the change risk prevention and control system comprising:

a rule configuration module to: storing a plurality of detection rules, wherein the acquisition mode of the detection rules comprises: providing a plurality of attributes which are predefined and used for describing change events, and receiving a detection rule configured by a first type of users and attribute values of attribute configurations applicable to the detection rule;

2. The system of claim 1, the plurality of attributes of the change event comprising at least one of the following:

3. The system of claim 2, the change execution module to:

and determining an upstream service system and/or a downstream service system of the target service system and other applications related to the target application according to the target application to be changed in the target change event and the target service system to which the target application belongs, and generating influence range information including an extended attribute value of any one of the upstream service system, the downstream service system or the other applications.

4. The system of claim 1, the change risk prevention and control system interfacing with a plurality of business systems, the change event for a change to one or more applications in the business systems; the change risk prevention and control system is integrated with various detection capabilities;

the rule configuration module comprises any one of the following sub-modules:

a third configuration submodule to: and providing a service providing interface, and acquiring and storing the detection rule submitted by the second type of users through the service providing interface.

5. The system of claim 1, the target change event finding the current matching detection rule prior to execution, comprising:

6. The system of claim 1, wherein each time the change event is executed, finding a currently matching detection rule from the stored first detection rules based on the target attribute value comprises:

7. The system of claim 1, the plurality of preset execution environments comprising: a pre-release execution environment, a gray release environment and a formal release environment;

8. A change risk prevention and control method, the method comprising:

executing the target change event for multiple times in a plurality of preset execution environments according to a preset life cycle management sequence; before executing the target change event every time, searching a currently matched detection rule from the stored detection rules according to at least the target attribute value and executing the currently matched detection rule so as to determine whether the target change event can be executed or not; and after each target change event is executed, searching the currently matched detection rule from the stored detection rules according to at least the target attribute value and executing to determine whether the target change event causes abnormity.

9. An electronic device, the electronic device comprising:

a processor;

a memory for storing processor-executable instructions;

wherein the processor, when invoking the executable instructions, implements the operations of the method of claim 8.

10. A computer readable storage medium having stored thereon computer instructions which, when executed, perform the method of claim 8.