Network change exception handling method, apparatus, device, and storage medium

Abstract

The application discloses an abnormality processing method, device and equipment of network change and a storage medium. The method comprises the following steps: obtaining an operation scheme of a target network device, calling an atomic template in the operation scheme, and executing each task step of a network change task on the target network device; and monitoring a network abnormal event in the execution process of the network change task. If the network abnormal event is monitored, the task step executed when the network abnormal event is monitored is determined as a target task step, a network abnormality processing corresponding to the target task step is obtained from the operation scheme, and the obtained network abnormality processing is executed. It can be seen that the application can automatically perform network change, reduce the risk caused by manual misoperation, and improve the success rate of network change. In addition, the application can automatically process network abnormality in the network change process, and improve the abnormality processing efficiency.

Description

Technical Field

[0001] This application relates to the field of Internet technology, specifically to the field of computer technology, and in particular to a method, apparatus, device, and storage medium for handling network change anomalies. Background Technology

[0002] In the field of communication technology, network changes are very common, such as upgrading the OS (network operating system) version of network devices or expanding the bandwidth of a link between two network devices. Current network change methods typically require manual intervention by technical personnel. However, with the rapid development of networks and their increasing complexity and size, the volume of network upgrades and modifications is rising year by year. This is not only time-consuming and labor-intensive but also increases management difficulty and costs. Furthermore, even slight errors in manual operation can cause network failures, leading to network change failures. Therefore, how to better conduct network changes and resolve network anomalies during the change process has become a research hotspot. Summary of the Invention

[0003] This application provides a method, apparatus, device, and storage medium for handling network changes, which can automate network changes to reduce the risk of human error, improve the success rate of network changes, and automatically handle network anomalies during the network change process, thereby improving anomaly handling efficiency.

[0004] On the one hand, embodiments of this application provide a method for handling network change anomalies, the method including:

[0005] An operation plan for obtaining a target network device is provided, wherein the operation plan is used to modify the network of the target network device according to a network change task; the operation plan includes: atomic templates for executing each task step of the network change task, and network exception handling corresponding to each task step;

[0006] The atomic template in the operation scheme is invoked to execute each task step of the network change task on the target network device; and network anomaly events are monitored during the execution of the network change task.

[0007] If the network anomaly event is detected, the task steps executed when the network anomaly event is detected will be determined as the target task steps;

[0008] Obtain the network anomaly handling corresponding to the target task step from the operation plan, and execute the obtained network anomaly handling.

[0009] On the other hand, embodiments of this application provide an anomaly handling device for network changes, the device comprising:

[0010] An acquisition unit is used to acquire an operation plan for a target network device. The operation plan is used to modify the network of the target network device according to a network change task. The operation plan includes: atomic templates for each task step of the network change task, and network exception handling corresponding to each task step.

[0011] The processing unit is used to call the atomic template in the operation scheme to execute each task step of the network change task on the target network device; and to monitor network abnormal events during the execution of the network change task.

[0012] The processing unit is further configured to, if the network anomaly event is detected, determine the task steps executed when the network anomaly event is detected as the target task steps;

[0013] The processing unit is further configured to obtain the network anomaly handling corresponding to the target task step from the operation scheme, and execute the obtained network anomaly handling.

[0014] In another aspect, embodiments of this application provide a computer device, the computer device including an input interface and an output interface, the computer device further including:

[0015] Processor and computer storage media;

[0016] The processor is adapted to implement one or more instructions, and the computer storage medium stores one or more instructions, which are adapted to be loaded by the processor and executed by the aforementioned network change exception handling method.

[0017] In another aspect, embodiments of this application provide a computer storage medium storing one or more instructions, which are adapted to be loaded by a processor and executed by the aforementioned network change exception handling method.

[0018] In another aspect, embodiments of this application provide a computer program product comprising one or more instructions; when one or more instructions in the computer program product are executed by a processor, the aforementioned network change exception handling method is implemented.

[0019] This application embodiment can automate network changes by setting atomic templates for each task step and corresponding network exception handling in the operation plan of the target network device. This allows the execution of network change tasks by calling the atomic templates in the operation plan, reducing the risk of human error and increasing the success rate of network changes. Furthermore, by monitoring network anomalies during the execution of network change tasks, and identifying the task step executed at the time of detection as the target task step, the corresponding network exception handling can be retrieved from the operation plan and executed. This automates the handling of network anomalies detected during network changes, improving exception handling efficiency. Attached Figure Description

[0020] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0021] Figure 1a This is a schematic diagram illustrating the principle of an automated network change scheme provided in an embodiment of this application;

[0022] Figure 1b This is a schematic diagram illustrating the principle of a network change anomaly handling method provided in an embodiment of this application;

[0023] Figure 2 This is a flowchart illustrating a method for handling network change anomalies provided in an embodiment of this application;

[0024] Figure 3 This is a schematic diagram of a network anomaly detection method provided in an embodiment of this application;

[0025] Figure 4 This is a flowchart illustrating a method for handling network change anomalies according to another embodiment of this application;

[0026] Figure 5a This is a schematic diagram of the framework of a network quality monitoring system provided in an embodiment of this application;

[0027] Figure 5b This is a schematic diagram of a device isolation method provided in an embodiment of this application;

[0028] Figure 5cThis is a schematic diagram of an exception notification processing method provided in an embodiment of this application;

[0029] Figure 6a This is a schematic diagram illustrating the working principle of a network change anomaly handling system provided in an embodiment of this application;

[0030] Figure 6b This is a schematic diagram of the workflow of a network change anomaly handling system provided in an embodiment of this application;

[0031] Figure 6c This is a configuration diagram of an emergency operation procedure and an emergency deactivation procedure for a yellow light provided in an embodiment of this application;

[0032] Figure 6d This is a schematic diagram of an unattended timed task provided in an embodiment of this application;

[0033] Figure 6e This is a configuration diagram of an emergency operation procedure and an emergency deactivation procedure for a red light provided in an embodiment of this application;

[0034] Figure 6f This is a structural schematic diagram of an emergency operation procedure for a red light provided in an embodiment of this application;

[0035] Figure 6g This is a schematic diagram of a scenario illustrating an emergency red light clearance procedure provided in an embodiment of this application;

[0036] Figure 6h This is a schematic diagram of another unattended timed task provided in an embodiment of this application;

[0037] Figure 7a This is a schematic diagram of a network architecture between a convergence device and a core device provided in an embodiment of this application;

[0038] Figure 7b This is a schematic diagram of a batch task provided in an embodiment of this application;

[0039] Figure 7c This is a schematic diagram of a change operation template provided in an embodiment of this application;

[0040] Figure 7d This is a timing diagram of a task group provided in an embodiment of this application;

[0041] Figure 7e This is a schematic diagram of the first task execution state provided in the embodiments of this application;

[0042] Figure 7f This is a schematic diagram of the first type of task execution log provided in the embodiments of this application;

[0043] Figure 7gThis is a schematic diagram of the first type of update change order provided in the embodiments of this application;

[0044] Figure 7h This is a schematic diagram of a traffic light turning yellow, provided in an embodiment of this application;

[0045] Figure 7i This is a partial schematic diagram of the second type of task execution log provided in the embodiments of this application;

[0046] Figure 7j This is a schematic diagram illustrating how a traffic light changes from yellow to green, according to an embodiment of this application.

[0047] Figure 7k This is a complete schematic diagram of the second type of task execution log provided in the embodiments of this application;

[0048] Figure 7l This is a schematic diagram of the second task execution state provided in the embodiments of this application;

[0049] Figure 7m This is a schematic diagram of the second type of update change order provided in the embodiments of this application;

[0050] Figure 7n This is a schematic diagram of a traffic light turning red, provided in an embodiment of this application;

[0051] Figure 7o This is a schematic diagram of the third type of task execution log provided in the embodiments of this application;

[0052] Figure 7p This is a schematic diagram of the execution record of an emergency operation procedure provided in an embodiment of this application;

[0053] Figure 7q This is a schematic diagram of a traffic light being modified to a yellow light according to an embodiment of this application;

[0054] Figure 7r This is a schematic diagram of another traffic light changing from yellow to green, provided in an embodiment of this application;

[0055] Figure 7s This is a schematic diagram of the lighting log of the traffic light provided in the embodiment of this application;

[0056] Figure 7t This is a schematic diagram of the third execution state provided in the embodiments of this application;

[0057] Figure 7u This is a schematic diagram of the third type of update change order provided in the embodiments of this application;

[0058] Figure 7v This is a schematic diagram of the fourth type of task execution log provided in the embodiments of this application;

[0059] Figure 7w This is a schematic diagram of the fourth task execution state provided in the embodiments of this application.

[0060] Figure 7x This is a schematic diagram of the fourth type of update change order provided in the embodiments of this application;

[0061] Figure 8 This is a schematic diagram of the structure of a network change exception handling device provided in an embodiment of this application;

[0062] Figure 9 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0063] The technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings.

[0064] This application proposes an automated network change scheme to automate network changes to network devices, reducing the risks associated with human error. Network devices can refer to dedicated hardware devices used to interconnect various servers, terminals, and application terminals to form an information communication network; for example, network devices may include switches, routers, optical transceivers, fiber optic transceivers, etc.

[0065] Specifically, the implementation principle of this scheme is roughly as follows: s11, the operations required during network change are broken down into several task steps, and a corresponding atomic template is configured for each task step. An atomic template for any task step can be understood as a subset of commands (or instructions) that have template properties and can be used to execute the corresponding task step. s12, according to the scenario requirements of a specific network change scenario, the atomic templates corresponding to each task step of the network change task to be executed in that scenario can be combined to generate the corresponding network change task's operation template. It can be seen that by configuring corresponding atomic templates for each task step, the atomic templates corresponding to each task step can have high reusability, thereby enabling the rapid generation of any network change task's operation template in different network change scenarios by combining the atomic templates corresponding to each task step, improving template generation efficiency. s13, by filling in the relevant device information (such as device identifier and related parameters) of the network device to be changed into the generated operation template, the operation plan for that network device can be generated. s14, based on the process scheduling strategy, calls the atomic template in the operation plan of the network device, and sequentially executes the corresponding task steps of the network change task on the network device, thereby realizing the network change of the network device according to the network change task.

[0066] For example, see Figure 1aAs shown, taking the common network change scenario of link expansion in network operation as an example: the network change task in this scenario is a link expansion task, which includes the following steps in sequence: checking port status, configuring the port, checking port status again, configuring the network protocol, checking the network protocol again, and verifying the change result. In specific implementation, operators can break down the operations required during the network change process into multiple task steps such as status checks and configuration modifications in advance, and configure atomic templates for each task step (e.g., ...). Figure 1a The system uses atomic templates for status checks, configuration modifications, and network management checks (as shown in the diagram). These templates combine the atomic templates corresponding to each task step of the link expansion task required in the scenario, generating an operation template for the link expansion task. Subsequently, the relevant device information of the device being changed (i.e., the network device undergoing network changes) is filled into this template, automatically generating the corresponding operation plan. Once the change window (i.e., the time window for network changes) is entered, the operator only needs to click the start button to trigger the network change system to automatically schedule the atomic templates in the operation plan according to the established process, executing each task step of the link expansion task on the corresponding device to achieve network changes for that device.

[0067] Based on the above description, it can be seen that the network change automation solution proposed in this application has at least the following characteristics:

[0068] ① Atomization of the change process: The network change process is broken down into several atoms (such as task steps). Each atom has the atomic ability to complete a set sub-function. The atom is a composable and iteratively replaceable unit.

[0069] ② Scenario-based change operation: Change operation scenarios (i.e. scenarios that include network change tasks) are classified according to the operation content of network change operations, the device type of network devices, and the network architecture characteristics of network devices. Under different change operation scenarios, atomic templates corresponding to each task step to be executed in the corresponding change operation scenario are arranged based on atomic capabilities to generate operation templates for network change tasks in the corresponding change operation scenario.

[0070] ③ Change verification template: Combine specific change operation scenarios to build a general checklist and anomaly detection standards, and embed the inspection plan into the operation template to verify the execution results of network change tasks.

[0071] ④ Automated execution process: Based on an open-source process engine, the network change system can automate process scheduling according to the task steps defined in the operation template.

[0072] Based on the implementation principle of the aforementioned automated network change scheme, this application further proposes a method for handling network change exceptions. This method can be achieved by setting atomic templates for each task step of performing network change tasks on the target network device (any network device) and network exception handling (e.g., ...) in the operation scheme of the target network device (any network device). Figure 1b As shown, this allows for the invocation of atomic templates within the operation plan when making network changes to a target network device. This enables the execution of various task steps within the network change task on the target network device, thereby automating the network change process, reducing the risk of human error, and improving the success rate of network changes. Furthermore, it can monitor network anomalies during the execution of network change tasks. Upon detecting an anomaly, the task steps executed at the time of the anomaly are identified as target task steps. The corresponding network anomaly handling is then retrieved from the operation plan and executed, thus automating the handling of network anomalies detected during the network change process and improving anomaly handling efficiency.

[0073] In specific implementations, the network change exception handling method proposed in this application embodiment can be executed by a computer device, which can be a terminal or a server; alternatively, the network change exception handling method can also be executed jointly by a terminal and a server. The terminal mentioned here can be a smartphone, computer (such as a tablet, laptop, desktop computer, etc.), smart wearable device (such as a smartwatch, smart glasses), smart voice interaction device, smart home appliance (such as a smart TV), vehicle terminal, or aircraft, etc.; the server can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN (Content Delivery Network), and big data and artificial intelligence platforms, etc. Furthermore, the terminal and server can be located within or outside the blockchain network, without limitation; even further, the terminal and server can upload any data stored internally to the blockchain network for storage to prevent the internally stored data from being tampered with and improve data security.

[0074] The following example uses computer equipment as the executing entity, and combines it with... Figure 2The flowchart shown illustrates the specific implementation process of the network change exception handling method proposed in this application embodiment. It is worth emphasizing that, in this application embodiment, if user information or other related data is involved, when any method embodiment proposed in this application is applied to a specific product or technology, this related data is collected with the user's permission or consent, and the collection, use, and processing of the related data comply with the relevant laws, regulations, and standards of the relevant region.

[0075] Please see Figure 2 As shown, the network change anomaly handling method proposed in this application embodiment can generally include the following steps S201-S204:

[0076] S201, Obtain the operation plan for the target network device.

[0077] The operation scheme for the target network device is used to modify the network of the target network device according to the network change task. It may include at least one task group, and each task group includes at least one task step of the network change task. Further, the operation scheme may also include: atomic templates for executing each task step of the network change task, and network anomaly handling (or network anomaly handling procedure) corresponding to each task step. Network anomaly handling, also known as Emergency Operating Procedures (EOP), is a process executed when a network anomaly is detected, which can be used to quickly restore network quality or prevent network quality deterioration. For example, the network anomaly handling corresponding to a task step may include at least one of the following: pausing network change processing (or pausing network change processing procedure) and rolling back network change processing (or rolling back network change processing procedure); wherein, pausing network change processing is used to suspend the execution of the network change task, and rolling back network change processing is used to revert the network state of the network device to a stable state, which can be a network state preset based on business needs or experience values. It is evident that pausing network change processing can prevent network quality from deteriorating when network quality is abnormal, while rolling back network change processing can quickly restore network quality by reverting to the previous state when network quality is abnormal, thereby shortening the duration of the anomaly's impact.

[0078] It should be noted that the network exception handling for different task steps can be the same or different, and there is no limitation on this. For example, the network exception handling for each task step can include pausing network change processing, and the execution logic of pausing network change processing for different task steps can be the same or different. Similarly, the network exception handling for each task step can include rolling back network change processing, and the execution logic of rolling back network change processing for different task steps can be the same or different. Furthermore, the network exception handling for each task step can include both pausing and rolling back network change processing; or, considering that some task steps may only involve reading commands, the execution of such task steps will not cause changes in the network status of network devices, and therefore will not cause network exceptions. Therefore, the network exception handling for these task steps can only include pausing network change processing, without including rolling back network change processing, to save memory space required for process storage.

[0079] In addition, the network change task is configured with a target change order, which serves as the basis for the network change. Specifically, it may include at least the device information of at least one group of network devices for which the network change task is to be performed. Therefore, the target change order indicates at least one group of network devices for which the network change task is to be performed; in this case, the aforementioned target network devices are any group of network devices indicated by the target change order. It is understood that each group of network devices indicated by the target change order undergoes network changes according to the network change task, and the network changes performed on at least one group of network devices constitute the network changes corresponding to the target change order. Furthermore, for any group of network devices, when it is necessary to perform the various task steps of the network change task on this group of network devices, this group of network devices can be considered as the network devices for which the network change task is to be performed. Here, a group of network devices is the smallest unit affected by a network change task; that is, a group of network devices includes at least one network device involved in performing a network change task. For example, when a network change task is an OS version upgrade task for network devices, since performing an OS version upgrade task involves only one network device, each group of network devices indicated in the target change order in this case includes one network device; that is, the target network device in this case includes one network device. Similarly, when a network change task is a link bandwidth expansion task between network devices, since performing a link bandwidth expansion task involves two network devices, each group of network devices indicated in the target change order in this case includes two network devices; that is, the target network device in this case includes two network devices.

[0080] It should be noted that: ① When the target change order indicates multiple groups of network devices, each group of network devices can have its own operation plan. The operation plan for any group of network devices is generated using the device information of each network device in the corresponding group. Each group of network devices can undergo network changes simultaneously according to the corresponding operation plan, or they can undergo network changes in batches. If network changes are performed in batches, the target change order may also include the batch number of each group of network devices. ② The above is only an illustrative description of the contents of the target change order and is not exhaustive. For example, the target change order may also include a network change time window and network monitoring configurations for each network device, etc. The network monitoring configuration for any network device may include: at least one monitoring item and the monitoring range (i.e., configuration item) under each monitoring item; any monitoring range may include the network type of the network to be monitored and at least one network transmission direction of the network to be monitored. This network transmission direction may include a source area identifier (i.e., the identifier of the area from which the network probe originates, which is usually the identifier of the area where the network device to be changed is located) and a destination area identifier (i.e., the identifier of the area reached by the network probe). As can be seen, the network monitoring configuration of any network device can be used to indicate multiple areas to be monitored for network quality (such as the source and destination areas indicated by the network transmission direction under each monitoring item). Since the network quality of these areas may be affected by network changes of the corresponding network devices, the areas indicated by the network monitoring configurations of each network device in the target change order can constitute the scope of impact of the target change order. For example, if the target change order includes network device a and network device b, and the network monitoring configuration of network device a includes one network transmission direction, and the source area indicated by this network transmission direction is city A and the destination area indicated by this network transmission direction is city B, then the network monitoring configuration of network device a can be used to indicate that the areas to be monitored for network quality include city A and city B. Similarly, if the network monitoring configuration of network device b indicates that the areas to be monitored for network quality include city C, city D, and city E, then by integrating the areas indicated by the network monitoring configurations of network device a and network device b, the scope of impact of the target change order can be obtained as including city A, city B, city C, city D, and city E.

[0081] S202, invoke the atomic template in the operation plan to execute each task step of the network change task on the target network device; and monitor network abnormal events during the execution of the network change task.

[0082] In its implementation, the computer device can distribute the various task steps of a network change task to the target network device and sequentially call the corresponding atomic templates in the operation plan to execute the distributed task steps on the target network device. Furthermore, during the execution of the network change task (i.e., during the network change process), the computer device can monitor network anomaly events in real time. These network anomaly events refer to events that detect network anomalies related to the target change order. Specifically, network anomalies related to the target change order can include at least one of the following: network anomalies caused by the network change corresponding to the target change order (i.e., network changes performed on at least one group of network devices indicated by the target change order), and network anomalies existing within the scope of the change's impact (i.e., the area indicated by the network monitoring configuration of each network device in the target change order).

[0083] Based on this, computer equipment can detect whether the network change corresponding to the target change order has caused a network anomaly, and whether there is a network anomaly within the scope of the target change order's impact, during the execution of a network change task. If a network anomaly is detected, or if a network anomaly is detected within the scope of the target change order's impact, then a network anomaly event can be determined to have been detected; if a network anomaly is detected, and the network change corresponding to the target change order has not caused a network anomaly, and there is no network anomaly within the scope of the target change order's impact, then no network anomaly event can be determined to have been detected.

[0084] See Figure 3 As shown, during task execution, a specific implementation method for detecting whether network changes corresponding to the target change order have caused network anomalies, and whether network anomalies exist within the scope of the target change order's impact, may include the following steps s21-s25:

[0085] s21, During the execution of the network change task, scan for network alarms. Network alarms refer to alarm information generated when network anomalies are detected. Specifically, they can be generated based on each network transmission direction where anomalies are detected, and can include at least one source region identifier and at least one destination region identifier.

[0086] s22, If a network alarm is detected, the network devices indicated in the target change order will be associated with the network alarm in three dimensions; these three dimensions may include spatial dimension, temporal dimension and content dimension.

[0087] (1) The spatial association logic can be as follows: if the source area indicated by the network monitoring configuration of the network device includes the source area indicated by the network alarm (i.e., source-source matching), and the destination area indicated by the network monitoring configuration of the network device includes the destination area indicated by the network alarm (i.e., destination-destination matching), then the network device and the network alarm can be considered successfully associated in the spatial dimension; or, if the source area indicated by the network monitoring configuration of the network device includes the destination area indicated by the network alarm (i.e., source-destination matching), and the destination area indicated by the network monitoring configuration of the network device includes the source area indicated by the network alarm (i.e., destination-source matching), then the network device and the network alarm can be considered successfully associated in the spatial dimension. It is understood that this is merely an illustrative description of a specific implementation of spatial association and is not intended to limit the scope of the association.

[0088] (2) The association logic in the time dimension can be as follows: A time association window can be determined, which can be a preset time period before the alarm generation time of the network alarm (i.e., the event that begins network alarming), or a preset time period before the start time of the anomaly corresponding to the network alarm. Additionally, the device operation logs of the network device (any network device indicated by the target change order, or a network device successfully associated with the network alarm in the spatial dimension) can be obtained. These logs record the executed device operations and their execution times. For example, the device operation logs can be 3A operation logs (i.e., AAA operation logs), where AAA refers to Authentication, Authorization, and Accounting. Furthermore, if the network device's operation logs include target device operations, which refer to network change operations performed within the time association window (i.e., operations generated by the task steps of performing network change tasks on the network device), then it can be determined that the corresponding network device and the network alarm are successfully associated in the time dimension; otherwise, it can be determined that the corresponding network device and the network alarm are not successfully associated in the time dimension.

[0089] (3) The association logic at the content dimension can be as follows: obtain the operation command of the target device operation from the device operation log of the network device corresponding to the successful time association; and perform command identification on the operation command of the target device operation to identify whether the operation command is located in the dangerous command set. If the operation command of the target device operation is located in the dangerous command set, the target device operation can be determined to be a dangerous device operation (i.e., a dangerous network change operation), thereby determining that the corresponding network device and network alarm are successfully associated at the content dimension; otherwise, it can be determined that the corresponding network device and network alarm are not associated at the content dimension.

[0090] S23. If no network device and network alarm are successfully associated in all three dimensions, then it is determined that the network change corresponding to the target change order has not caused network anomalies, and there are no network anomalies within the scope of the target change order's impact. That is, if no network device and network alarm are successfully associated in the spatial, temporal, and content dimensions, then it can be determined that the network change corresponding to the target change order has not caused network anomalies, and there are no network anomalies within the scope of the target change order's impact.

[0091] S24. If a network device and a network alarm are successfully correlated in one or two dimensions, it is determined that the network change corresponding to the target change order has not caused a network anomaly, and a network anomaly exists within the scope of the target change order's impact. That is: if a network device and a network alarm are successfully correlated in the spatial dimension but fail to be correlated in both the temporal and content dimensions, or if a network device and a network alarm are successfully correlated in both the spatial and temporal dimensions but fail to be correlated in the content dimension, it can be determined that the network change corresponding to the target change order has not caused a network anomaly, and a network anomaly exists within the scope of the target change order's impact.

[0092] S25. If network devices and network alarms are successfully correlated across three dimensions, then it is determined that the network change corresponding to the target change order caused the network anomaly. That is, if network devices and network alarms are successfully correlated across spatial, temporal, and content dimensions, it can be determined that the network change corresponding to the target change order caused the network anomaly.

[0093] S203, If a network anomaly event is detected, the task steps executed when the network anomaly event is detected will be determined as the target task steps.

[0094] In practical implementation, if a network anomaly is detected, the computer device can determine the task step executed when the anomaly was detected as the target task step. For example, suppose a network change task includes 6 task steps. If the computer device detects a network anomaly while executing the 3rd task step on the target network device, then the target task step is the 3rd task step; if the computer device detects a network anomaly while executing the 5th task step on the target network device, then the target task step is the 5th task step.

[0095] S204. Obtain the network exception handling corresponding to the target task step from the operation plan, and execute the obtained network exception handling.

[0096] As mentioned above, the network anomaly handling corresponding to the target task step includes at least one of the following: pausing network change processing and rolling back network change processing. Based on this, the specific implementation method for the computer device to obtain the network anomaly handling corresponding to the target task step from the operation plan can be: directly obtaining the pause network change processing corresponding to the target task step from the operation plan, or directly obtaining the rollback network change processing corresponding to the target task step. Alternatively, the pause network change processing or rollback network change processing corresponding to the target task step can be obtained from the operation plan based on the event content of the network anomaly event.

[0097] Specifically, if the network anomaly event content is: "A network anomaly caused by a network change corresponding to the target change order has been detected," then the rollback network change processing step for the target task can be obtained from the operation plan. This rollback process can then be executed to restore the network quality of the network devices. If the network anomaly event content is: "A network anomaly has been detected within the scope of the change affected by the target change order," then the pause network change processing step for the target task can be obtained from the operation plan. This pause process can then be executed to suspend the network change task and prevent further operation from causing network quality deterioration.

[0098] This application embodiment can break down a network change task into at least one task step, and set atomic templates for each task step of the network change task and corresponding network exception handling for each task step in the operation plan of the target network device. This allows for automated network changes to be performed on the target network device by calling the atomic templates in the operation plan, thereby reducing the risk of human error and improving the success rate of network changes. Furthermore, by monitoring network anomalies during the execution of the network change task, and identifying the task step executed when the anomaly is detected as the target task step, the corresponding network exception handling for the target task step is obtained from the operation plan and executed, thus automating the handling of network anomalies detected during the network change process and improving exception handling efficiency.

[0099] Based on the above Figure 2 The description of the method embodiments shown in this application further proposes a method for handling network change anomalies; in this application embodiment, a computer device is still used as the execution subject for explanation. Please refer to... Figure 4 As shown, the anomaly handling method for this network change can generally include the following steps: S401-S407:

[0100] S401, Obtain the operation plan of the target network device.

[0101] In its implementation, the computer device can obtain an operation template for a network change task. This template may include: information fields for filling in device information, atomic templates for each task step in executing the network change task, and network exception handling for each task step. Additionally, the computer device can obtain the device information of the target network device for the network change task to be executed. Specifically, it can obtain the device information of the target network device from the target change order corresponding to the network change task. This device information may include, but is not limited to: device identifiers (such as device name, device serial number, etc.), and relevant parameters required for the network change. Furthermore, the computer device can fill the device information of the target network device into the information fields of the operation template to obtain the operation plan for the target network device.

[0102] As can be seen, this embodiment of the application can automatically construct an operation plan for the target network device by obtaining the operation template corresponding to the network change task and filling in the device information of the target network device on the template. This simplifies the technical threshold and process required for plan construction, thereby improving the efficiency of plan construction. Furthermore, the operation plan for the target network device constructed in this way includes at least: atomic templates for each task step of performing the network change task on the target network device, and network anomaly handling corresponding to each task step.

[0103] Optionally, the operation template corresponding to the aforementioned network change task may further include: an exception handling resolution operation (or exception handling resolution process) for each task step; correspondingly, in this case, the operation scheme for the target network device constructed based on the operation template also includes: an exception handling resolution operation for each task step. The exception handling resolution operation, also known as reverse EOP, is a processing flow executed when a network exception is detected and resolved. It is used to resolve the network exception handling of the corresponding task step, so as to return from the corresponding network exception handling process to the main process of network change (i.e., the process of executing the network change task), thereby continuing the execution of the network change task.

[0104] For example, when the network exception handling corresponding to any task step includes at least one of pausing network change processing and rolling back network change processing, the exception handling release operation may include at least one of the following: a breakpoint resume operation and a rollback release operation. The breakpoint resume operation is used to release the paused network change processing. The execution process of the breakpoint resume operation includes: continuing execution of the breakpoint and the task steps following the breakpoint, where the breakpoint refers to the first task step in the currently paused task steps. The rollback release operation is used to release the rollback of network change processing and trigger the main network change process; it is the inverse operation of the corresponding rollback network change processing.

[0105] It should be noted that the specific operations in the exception handling and resolution process for any task step can be set based on actual needs and are not limited thereto. For example, for any task step, if its corresponding network exception handling includes pausing network change processing, then the exception handling and resolution process for that task step may include a resume operation; if its corresponding network exception handling includes rolling back network change processing, then the exception handling and resolution process for that task step may include or may not include a rollback cancellation operation, and there are no limitations thereto.

[0106] It is understood that the above is merely an illustrative description of one way of constructing an operation plan and is not intended to limit it. For example, in other embodiments, the operation plan can also be manually written by the operator based on the target device information, the atomic templates of each task step for performing network change tasks, and at least one of the network anomaly handling and anomaly handling resolution operations corresponding to each task step, thereby obtaining the operation plan for the target device.

[0107] S402 invokes the atomic template in the operation plan to execute each task step of the network change task on the target network device.

[0108] S403 monitors abnormal network events during the execution of network change tasks.

[0109] In practical implementation, the target network devices are any group of network devices indicated by the target change order corresponding to the network change task; and the target change order is configured (i.e., attached) with a signal light to indicate whether there is a network anomaly, which can be controlled by the network quality monitoring system. Specifically, the network quality monitoring system may include an input module, an orchestration module, an association module, and a signal light module, etc. Among them:

[0110] ① The input module supports multi-dimensional monitoring. For example, on the network side, it supports overall monitoring and personalized monitoring to check for alarm information; on the business side, it supports monitoring for alarm information based on key business indicators; and on the user side, it supports monitoring for alarm information based on user reports.

[0111] ② The orchestration module supports precise configuration, which can be used to estimate the scope of impact of any change order, or to determine the network monitoring configuration of the network device indicated by any change order. The network monitoring configuration includes at least one monitoring item and the monitoring scope (such as monitoring area) under each monitoring item.

[0112] ③ The association module can determine whether there is a spatial, temporal, and content association between network alarms and the network devices indicated in the corresponding change orders, based on the configuration information generated by the orchestration module (such as the scope of change impact, network monitoring configuration, etc.), and obtain the association results. Spatial association can include physical spatial association (such as whether the monitoring area corresponding to the network device is consistent with the area corresponding to the network alarm) and logical spatial association (such as whether the service type corresponding to the network device is consistent with the service type corresponding to the network alarm), but is not limited to these. Temporal association can include change window association (such as determining whether the alarm generation time of the network alarm is within the network change time window) and operation time association (such as determining whether there is a network change operation within a preset time period before the alarm generation time (or abnormal start time) of the network alarm), but is not limited to these. In addition, content association can include command recognition, that is, identifying whether the command corresponding to the network change operation is a dangerous command.

[0113] ④ The indicator module can accurately illuminate the indicator light corresponding to the change order based on the association results output by the association module. For example, for any change order, if the association results indicate that there is no spatial, temporal, or content association between the network device and the network alarm, it can be determined that the network change corresponding to the change order has not caused a network anomaly, and there is no network anomaly within the scope of the change order's impact. In this case, the indicator light corresponding to the change order can be illuminated using a base color (such as green). Otherwise, the indicator light can be illuminated using a target color, which indicates at least one of the following: the network change corresponding to the change order has caused a network anomaly, or there is a network anomaly within the scope of the change order's impact. Furthermore, to more clearly indicate network anomaly conditions through the indicator light's display color, the target color can be subdivided into a first color (such as yellow) and a second color (such as red), thereby using either the first or second color to illuminate the indicator light. Specifically, if the association results indicate that there is one or two of the following: spatial association, temporal association, and content association between network devices and network alarms, it can be determined that the network change corresponding to the change order did not cause network anomalies, but network anomalies exist within the scope of the change order's impact. In this case, the first color (such as yellow) can be used to illuminate the indicator light. If the association results indicate that there is spatial association, temporal association, and content association between network devices and network alarms, it can be determined that the network change corresponding to the change order caused network anomalies, and network anomalies exist within the scope of the change order's impact. In this case, the second color (such as red) can be used to illuminate the indicator light.

[0114] Based on the above description, the network quality monitoring system can accurately and quickly locate the type of network anomaly through four modules: input, arrangement, association, and indicator lighting. This allows the system to then illuminate the corresponding indicator light for the target change order using the appropriate color. For example... Figure 5a As shown: The network quality monitoring system detects through four modules that the network change corresponding to Change Order 1 did not cause network anomalies and there were no network anomalies within the scope of the change's influence. Therefore, the indicator light corresponding to Change Order 1 can be lit using the base color (such as green). Similarly, since the network change corresponding to Change Order 2 was detected to have caused network anomalies, the indicator light corresponding to Change Order 2 can be lit using the second color (such as red). Since the network change corresponding to Change Order 3 was detected not to have caused network anomalies, but there were network anomalies within the scope of the change's influence, the indicator light corresponding to Change Order 3 can be lit using the first color (such as yellow).

[0115] Based on this, the specific implementation of step S403 by the computer device can be as follows: During the execution of the network change task, the display color of the indicator light corresponding to the target change order is monitored. If the display color of the indicator light is the base color (e.g., green), since the base color is used to indicate that the network change corresponding to the target change order has not caused a network anomaly, and there is no network anomaly within the scope of the target change order's change influence, it can be determined that no network anomaly event has been detected. If the display color of the indicator light is the target color, since the target color is different from the base color, it can be used to indicate at least one of the following: the network change corresponding to the target change order has caused a network anomaly, and there is a network anomaly within the scope of the target change order's change influence, therefore it can be determined that a network anomaly event has been detected. Further, the target color can be a first color (e.g., yellow) or a second color (e.g., red); the first color (e.g., yellow) is used to indicate that the network change corresponding to the target change order has not caused a network anomaly, and there is a network anomaly within the scope of the target change order's change influence; the second color (e.g., red) is used to indicate that the network change corresponding to the target change order has caused a network anomaly.

[0116] S404 If a network anomaly event is detected, the task steps executed when the network anomaly event is detected will be determined as the target task steps.

[0117] S405: Obtain the network exception handling corresponding to the target task step from the operation plan, and execute the obtained network exception handling.

[0118] In specific implementation, the specific implementation method for obtaining the network anomaly handling corresponding to the target task step from the operation plan can be as follows: If the indicator light displays the first color (such as yellow), it can be determined that the network change corresponding to the target change order has not caused a network anomaly, and there is a network anomaly within the scope of the change's influence. In this case, the pause network change handling corresponding to the target task step can be obtained from the operation plan; if the indicator light displays the second color (such as red), it can be determined that the network change corresponding to the target change order has caused a network anomaly. In this case, the rollback network change handling corresponding to the target task step can be obtained from the operation plan.

[0119] If the obtained network anomaly handling is to pause network change handling, the specific implementation method for executing the obtained network anomaly handling can be: determining the remaining task steps, which include: the task steps following the target task steps in the various task steps of the network change task executed on the target network device; pausing the execution of the remaining task steps on the target network device to pause the execution of the network change task. Specifically, the computer device can pause the execution of the remaining task steps on the target network device by freezing them; specifically, freezing the remaining task steps can be achieved by: modifying the status bit of the network change task to a paused state, and adding the paused network change task to a pause queue, thereby freezing the remaining task steps.

[0120] Optionally, when pausing the execution of the remaining task steps on the target network device, the computer device can also record and store the target task parameters, which are parameters used for resuming interrupted downloads. For example, if the network change process involves variable passing, the target task parameters can be intermediate variables generated by the target task steps. That is, when pausing the execution of the remaining task steps, the intermediate variables generated by the execution of the target task steps can be recorded and stored. When resuming interrupted downloads later, these intermediate variables can be retrieved and passed to the breakpoint (i.e., the first task step in the remaining task steps) to resume the download. For example, if the target task step is a cyclic task node, the target task parameter can be the number of times the target task step has been executed. That is, when pausing the execution of the remaining task steps, the number of times the target task step has been executed can be recorded and stored. When resuming the download later, the remaining number of executions of the target task step can be determined based on the number of executions, and the target task step can be executed based on the remaining number of executions. For example, if the target task step is a task step that needs to be executed 10 times, and a network abnormal event is detected when executing the target task step for the 3rd time, the execution of the remaining task steps is paused, and the number of executions of the target task step is recorded as 3. When resuming the download later, the remaining number of executions can be determined as 7 based on the total number of executions required (10 times) and the number of executions (3 times), and the target task step can be executed 7 more times.

[0121] If the obtained network anomaly handling is a rollback of network change handling, the specific implementation method for executing the obtained network anomaly handling can be: calling the configuration modification atomic template (i.e., the instruction set used to perform modification operations) to roll back the network state of the target network device to the stable state indicated by the rollback of network change handling. This stable state can be, for example, the initial state before the network change, the previous stable state (i.e., the network state before executing the previous task step), or the most recent stable state. The so-called most recent stable state refers to the stable state that requires the fewest rollback operations among the multiple network states supported by the target network device; for example, the multiple network states supported by the target network device include the initial state, the previous stable state, the isolated state, etc. If the rollback operations required to roll back to the isolated state are less than the rollback operations required to roll back to other network states, then the most recent stable state is the isolated state; if the rollback operations required to roll back to the initial state are less than the rollback operations required to roll back to other network states, then the most recent stable state is the initial state, and so on.

[0122] Optionally, considering that the obtained rollback network change processing may fail to execute, such as the rollback network change processing not being executed due to failure to initiate the rollback network change processing, or the rollback network change processing execution error, if the obtained rollback network change processing fails to execute, the computer equipment can perform fault self-healing processing (or fault self-healing process) on the network devices indicated by the target change order to restore network quality. Fault self-healing processing is used to isolate the fault point. The fault point refers to the network device among the network devices indicated by the target change order that caused the network anomaly (i.e., the network device that has spatial, temporal, and content-related associations with the network alarm). Specifically, device isolation is an operation used to remove the fault point from the existing network (i.e., the network architecture where the fault point is located). This may include, but is not limited to, isolating ports, isolating cards, or isolating the entire machine (e.g., shutting down the fault point). Removing the fault point from the existing network can be understood as: the fault point cannot communicate with other network devices in the existing network, such as... Figure 5b As shown.

[0123] It should be noted that if the obtained rollback network change processing fails, the computer equipment can directly perform fault self-healing processing on the network equipment indicated in the target change order. Alternatively, considering that fault self-healing processing requires a certain degree of network redundancy, before performing fault self-healing processing on the network equipment indicated in the target change order, the computer equipment can conduct a risk assessment of the device isolation operation at the fault point based on the network capacity requirements of the existing network where the fault point is located, the current network capacity of the existing network, and the network capacity of the fault point. This risk assessment refers to assessing the risk that the remaining network capacity after performing device isolation operation on the fault point in the existing network will not be able to meet the network capacity requirements; the so-called network capacity refers to the maximum amount of data transmission or the number of users that the network can handle under specific conditions. Specifically, the network capacity of the fault point can be subtracted from the current network capacity of the existing network to obtain the remaining network capacity after performing device isolation operations on the fault point in the existing network. If the remaining network capacity is greater than the capacity indicated by the network capacity requirement of the existing network, it can be determined that the device isolation operation of the fault point is risk-free. In this case, the step of performing fault self-healing processing on the network device indicated by the target change order can be triggered. If the remaining network capacity is less than the capacity indicated by the network capacity requirement of the existing network, it can be determined that the device isolation operation of the fault point is risky. In this case, the step of performing fault self-healing processing on the network device indicated by the target change order is prohibited.

[0124] Optionally, considering that the aforementioned fault self-healing process may fail to execute, such as the fault self-healing process not being executed due to a failure to initiate the process, or an error occurring during its execution, the computer device can also execute an anomaly notification process (or an anomaly notification procedure) to restore network quality if the fault self-healing process fails. Specifically, this anomaly notification process is used to notify the network change implementer to handle network anomalies. This can include, for example, notifying the network change implementer to go online and handle the relevant network anomalies via telephone calls or information (such as SMS or social media messages). Figure 5c As shown. It should be noted that in actual applications, there may be instances where both the rollback network change processing and fault self-healing processing are executed normally, but no network quality recovery is detected until the observation window ends, and the indicator light's display color is not corrected from the second color (e.g., red) to the first color (e.g., yellow). In this case, it can be determined that the rollback network change processing and fault self-healing processing have not taken effect. In order to restore network quality, the computer device can also execute the abnormal notification processing.

[0125] S406, after executing the acquired network anomaly handling, monitors the network anomaly resolution event.

[0126] As mentioned above, network anomaly handling is performed when a network anomaly event is detected. In practical applications, various factors may lead to the false detection of network anomalies, or the network anomaly corresponding to the network anomaly event may have been resolved. In both cases, the network anomaly event can be considered resolved, and the network anomaly handling that has been executed can be terminated to return to the main process of network change and improve the success rate of network change tasks.

[0127] Based on this, after executing the acquired network anomaly handling, the computer device can monitor network anomaly resolution events. A network anomaly resolution event refers to an event in which a network anomaly has been resolved. As described above, a network anomaly event refers to an event in which a network anomaly related to the target change order is detected (a network anomaly caused by the network change corresponding to the target change order, or a network anomaly existing within the scope of the target change order's change influence). Therefore, if it is detected that the network change corresponding to the target change order did not cause a network anomaly and there is no network anomaly within the scope of the target change order's change influence, then it can be determined that a network anomaly resolution event has been detected; or if it is detected that the network anomaly related to the target change order has been repaired, then it can be determined that a network anomaly resolution event has been detected.

[0128] In its implementation, the target change order is configured with a semaphore indicator to show whether a network anomaly exists. In this case, the network quality monitoring system, after illuminating the semaphore corresponding to the target change order based on whether the network device indicated by the target change order has spatial, temporal, and content-related associations with the network alarm, can also obtain the context information of the network alarm. Based on this context information, it performs a secondary analysis of the correlation between the network alarm and the target change order, obtaining a correlation detection result. This result is used to correct the display color of the semaphore corresponding to the target change order, making the semaphore display color more accurate, reducing the missed detection rate in abnormal network change scenarios and the false detection rate in normal network change scenarios, thereby improving the accuracy of network change monitoring. The context information may include, but is not limited to, at least one of the following: information indicating whether a network alarm has been assigned to the target change order, and the cause of the anomaly corresponding to the network alarm (such as network device malfunction, server operation, main light jitter, etc.).

[0129] It should be noted that the embodiments of this application do not limit the specific implementation of the secondary analysis of the correlation between network alarms and target change orders based on context information; and the embodiments of this application do not limit the specific implementation logic of correcting the display color of the traffic light corresponding to the target change order based on the correlation detection result. For example, when the correlation detection result indicates that the network alarm is unrelated to the target change order, the display color of the traffic light can be corrected from the second color (such as red) to the base color (such as green), or from the second color (such as red) to the first color (such as yellow). When the display color of the traffic light is the first color (such as yellow), if the network alarm is detected to be repaired, it can be determined that the network anomaly has been repaired. At this time, the display color of the traffic light can be further corrected from the first color (such as yellow) to the base color (such as green).

[0130] Based on this, the specific implementation of step S406 by the computer device can be as follows: after processing the acquired network anomaly, monitor the display color of the indicator light; if the display color of the indicator light is the base color, it is considered that the network change corresponding to the target change order has not caused a network anomaly and there is no network anomaly within the scope of the target change order's change of influence, or it is considered that the network anomaly related to the target change order has been repaired, and at this time it can be determined that a network anomaly resolution event has been detected; if the display color of the indicator light is the target color, it is considered that the network change corresponding to the target change order has caused a network anomaly, or a network anomaly has been detected within the scope of the target change order's change of influence, or a network anomaly related to the target change order has not been repaired, and at this time it can be determined that no network anomaly resolution event has been detected.

[0131] It is understood that this is merely an illustrative example of one specific implementation of step S406 and is not intended to limit it. For example, in other embodiments, when the computer device executes step S406, it can also perform a secondary analysis of the correlation between the network alarm and the target change order based on the context information of the network alarm to obtain the correlation detection result. Based on the correlation detection result, it can detect whether there is a network anomaly resolution event. The detection logic is similar to the principle of detecting network anomaly resolution events based on the display color of the traffic lights, and will not be elaborated here.

[0132] S407 If a network anomaly resolution event is detected, obtain the anomaly resolution operation corresponding to the target task step from the operation plan, and execute the obtained anomaly resolution operation.

[0133] In the specific implementation, if the pause network change processing corresponding to the target task step has been executed (i.e., the target network device has been subjected to the pause network change processing corresponding to the target task step), the breakpoint resume operation corresponding to the target task step can be obtained from the operation plan, and the obtained breakpoint resume operation can be executed on the target network device. That is, the breakpoint (i.e., the first task step in the remaining paused task steps) and the task steps after the breakpoint can continue to be executed. Specifically, the breakpoint and the task steps after the breakpoint can be unfrozen. The implementation method for unfreezing the breakpoint and subsequent task steps can be: modifying the status bit of the network change task to the executable state, and deleting the network change task in the executable state from the pause queue, thereby unfreezing the corresponding task steps. Optionally, if the computer device records and stores the target task parameters when pausing the execution of the remaining task steps on the target network device, the computer device can also read the target task parameters when performing the obtained breakpoint resume operation on the target network device, and perform the obtained breakpoint resume operation based on the target task parameters. The specific implementation logic can be found in the relevant description in the aforementioned step S405, and will not be elaborated here.

[0134] If the rollback network change processing corresponding to the target task step has been executed (i.e., the target network device has undergone the rollback network change processing corresponding to the target task step), then the unrollback operation corresponding to the target task step can be obtained from the operation plan, and the obtained unrollback operation can be executed on the target network device. Optionally, considering the possibility that the unrollback operation corresponding to the target task step may not be configured in the operation plan; in this case, it will be impossible to obtain the unrollback operation corresponding to the target task step from the operation plan. Based on this, if the unrollback operation corresponding to the target task step is not obtained from the operation plan, the network state of the target network device can be maintained at the target stable state, and it can be determined that the network change task for the target network device has failed; where the target stable state refers to the stable state of the target network device's network after the rollback network change processing corresponding to the target task step is executed on the target network device. For example, if the rollback network change processing corresponding to the target task step is used to roll back the network state of the network device to the initial state, then the stable state of the target network device's network after the rollback network change processing corresponding to the target task step is executed on the target network device is the initial state, and the target stable state in this case is the initial state.

[0135] Optionally, as mentioned above, in the event of a detected network anomaly, the network anomaly handling of the target task steps may fail, resulting in a fault self-healing process (i.e., device isolation of the fault point) being performed on the network device indicated in the target change order. Based on this, in the event of a detected network anomaly resolution event, if the fault point was isolated, the computer device can respond to the network anomaly resolution event by performing a device rollback. Device rollback refers to the reverse operation of device isolation, which can be used to rejoin the fault point into the existing network (i.e., the network architecture where the fault point is located). This can include, but is not limited to, port rollback, board rollback, and whole-device rollback (such as powering on the fault point). The meaning of rejoining the fault point into the existing network can be understood as: the fault point re-establishing communication with other network devices in the existing network.

[0136] Optionally, the operation scheme includes at least one task group, and a task group includes at least one task step of a network change task; in a specific implementation, the computer device can execute each task group sequentially; or, a timer can be set for each task group, which can be used to indicate the start execution time of the corresponding task group, which can specifically be the time to start executing the first task step in the task group, and the computer device can start executing each task step in the corresponding task group when the timer of any task group arrives.

[0137] Based on this, with each task group having its own timing, after detecting a network anomaly resolution event, the computer device can determine the duration of the network anomaly event. This duration indicates the time interval between the time the network anomaly event was detected and the time the network anomaly resolution event was detected. Furthermore, it can determine the remaining task groups, which include task groups that begin execution after the target task group. The target task group refers to the task group containing the target task step. Further, the computer device can update the timing of the remaining task groups based on the duration of the network anomaly event. The updated timing is obtained by postponing the previous timing by the duration of the network anomaly event; that is, the updated timing is later than the previous timing, and the time difference between the two timings is the duration of the network anomaly event. For example, if the timing of the remaining task groups is 02:10:10, and the duration of the network anomaly event is 30 seconds, then the timing of the remaining task groups can be updated based on 30 seconds, making the updated timing 02:10:40, so that the remaining task groups begin execution at 02:10:40.

[0138] This application embodiment can configure the operation scheme of the target network device to set atomic templates for each task step of the network change task, network anomaly handling for each task step, and anomaly handling resolution operation for at least one task step. This allows for automated network changes to the target network device by calling the atomic templates in the operation scheme, reducing the risk of human error and improving the success rate of network changes. Furthermore, by monitoring network anomaly events during the execution of the network change task, and identifying the task step executed when the anomaly event is detected as the target task step, the corresponding network anomaly handling can be obtained from the operation scheme and executed. This automates the handling of network anomalies detected during the network change process, improving anomaly handling efficiency. Moreover, if a network anomaly resolution event is detected, the anomaly handling resolution operation corresponding to the target task step can be obtained from the operation scheme and executed, further improving the success rate of network changes.

[0139] Based on the above Figure 2 and Figure 4 The description of the method embodiments shown in this application illustrates a network change anomaly handling system. Taking a link expansion task as an example, see [link to example]. Figure 6a As shown, this system can continuously monitor network quality throughout the entire network change process by integrating a network quality monitoring system (taking a traffic light system as an example) alongside the automated change process. This avoids the problems of long anomaly detection times and undetectable anomalies associated with serial monitoring and simple network device monitoring. Simultaneously, it pre-sets matching emergency operation procedures (i.e., network anomaly handling) for different traffic light display colors and different operation nodes (i.e., task steps). For example, it pre-sets a matching yellow light EOP (EOP Y, i.e., pause network change processing) for each task step and a matching red light EOP (EOP Rx, i.e., rollback network change processing) for some task steps, thereby improving the automation level of the anomaly handling process. Furthermore, it can add an emergency deactivation operation procedure (reverse EOP, i.e., anomaly deactivation operation), enabling network change operations to continue even in the event of false alarms, thus improving the success rate of network changes.

[0140] In this embodiment of the application, the following three colors of the traffic light are used as examples for illustration:

[0141] (1) Red (i.e. the second color mentioned above): used to indicate that the current change operation is abnormal (i.e., the network change corresponding to the target change order has caused network abnormality); in this case, the system can be triggered to automatically start the red light EOP (i.e. EOP Rx), which can be done by calling the configuration modification atomic template to revert the network configuration (such as network status) of the network device to a stable state, thereby quickly restoring network quality;

[0142] (2) Yellow (i.e. the first color mentioned above): indicates that the current change operation is normal (i.e. the network change corresponding to the target change order has not caused network anomalies), but there are network anomalies within the scope of the change of the target change order; in this case, in order to avoid the network quality deterioration caused by continuing network change operation, the system can automatically start the yellow light EOP (i.e. EOP Y) to suspend the change process.

[0143] (3) Green (i.e. the base color mentioned above): indicates that the current change operation is normal (i.e. the network change corresponding to the target change order has not caused network anomalies) and there are no network anomalies within the scope of the change of the target change order; in this case, the network change process can be maintained to run normally.

[0144] In specific implementation, the workflow of the network change processing system proposed in the embodiments of this application can be found in [reference needed]. Figure 6b As shown, it is roughly as follows:

[0145] (1) Create a change order (such as the target change order mentioned above).

[0146] (2) In the change order, fill in the device identifier of the network device and the network change time window.

[0147] (3) Create batch tasks according to the risk control principle (that is, process multiple network devices in batches and fill in the batch number of each network device in the change order).

[0148] (4) Calculate the network monitoring configuration for each network device, and add the network monitoring configuration for each network device to the change order.

[0149] (5) After the network change time window begins, scan for network alarms; and sequentially obtain the operation plan for each network device in each batch, and perform each task step in the network change task for the corresponding network device based on the corresponding operation plan to carry out network change.

[0150] (6) If no network alarm is detected, the indicator light will be turned on as green; optionally, the indicator light can be displayed as green by default, in which case the indicator light will always remain green.

[0151] (7) If a network alarm is detected, determine whether the network alarm is associated with the change order. Specifically, determine whether there is a network device in the network device indicated by the change order that is associated with the network alarm in terms of space (i.e., successfully associated in the spatial dimension), time (i.e., successfully associated in the time dimension) and content (i.e., successfully associated in the content dimension). In this way, determine whether the network alarm is associated with the change order.

[0152] (8) If the network alarm is not associated with the change order, turn the signal light green.

[0153] (9) If a network alarm is associated with a change order, the indicator light will be illuminated as yellow or red. Specifically, if the network change corresponding to the change order causes a network anomaly, the indicator light will be illuminated as red; if the network change corresponding to the change order does not cause a network anomaly but a network anomaly exists within the scope of the change's impact, the indicator light will be illuminated as yellow. Additionally, if a network alarm is not associated with a change order, the indicator light will be illuminated as green.

[0154] (10) If the signal light is lit up as green, proceed normally (i.e., carry out network changes normally) until the network changes are completed.

[0155] (11) If the indicator light is illuminated as yellow, the change is paused (i.e., the network change processing corresponding to the target task step is paused), and the alarm (i.e., network alarm) is further checked to see if it has recovered. If it has recovered, the indicator light changes from yellow to green (i.e., yellow to green), and at this time, the breakpoint resume operation (i.e., the breakpoint resume operation corresponding to the target task step) can be performed to continue implementing the network change until the change is completed.

[0156] (12) If the signal light is red, the change is rolled back (i.e., the rollback network change processing corresponding to the target task step is executed). Further, it checks whether the rollback is normal (i.e., whether the rollback network change processing was executed successfully); if yes (i.e., the rollback network change processing was executed successfully), it checks whether the alarm has been corrected; if no (i.e., the rollback network change processing failed), it performs fault self-healing (i.e., fault self-healing processing is executed). Further, after performing network configuration rollback through fault self-healing, it checks whether the rollback is normal (i.e., whether the fault self-healing processing was executed successfully); if yes (i.e., the fault self-healing processing was executed successfully), it checks whether the alarm has been corrected; if no (i.e., the fault self-healing processing failed), it automatically calls for manual processing (i.e., performs exception notification processing) and checks whether the alarm has been corrected.

[0157] The process of detecting whether an alarm has been corrected involves performing a secondary analysis of the correlation between the network alarm and the target change order based on the context information of the network alarm. If the secondary analysis determines that the network alarm is related to the change order, the alarm is considered uncorrected, and the change is deemed a failure. If the secondary analysis determines that the network alarm is unrelated to the change order, the alarm is considered corrected. In this case, it can be checked whether the network alarm has recovered. If it has recovered, the indicator light will turn green (it could be red to green, or red to yellow and then back to green). Further checks can be performed to determine if the network device currently performing the network change task has a reverse EOP (i.e., a rollback operation corresponding to the target task step) configured in its operation plan. If the reverse EOP is configured, it will be executed to restart the current batch (i.e., to re-execute network change tasks on network devices in the current batch or continue to do so), and after the network change of the current batch is completed, the next batch will be executed (i.e., to execute network change tasks on network devices in the next batch); if the reverse EOP is not configured, it can be determined that the current batch has failed, and the next batch will be executed directly (i.e., to execute network change tasks on network devices in the next batch) until the change is completed.

[0158] Based on the above description, the logic of the network change anomaly handling system proposed in this application for automatic response and processing based on different display colors of traffic lights can be summarized as follows:

[0159] ① When the indicator light changes from green to yellow: This indicates that there is a network anomaly within the scope of the change, which means that the current change environment is abnormal. In this case, the implementation should be suspended (i.e., the change is paused).

[0160] ② When the indicator light changes from yellow to green, it means that the network error has been resolved and the current environment has returned to normal. In this case, the process can continue from the pause point (i.e., the breakpoint).

[0161] ③ When the indicator light changes color from green to red or from yellow to red, it indicates that the network change corresponding to the change order has caused a network anomaly (i.e., the current change operation is abnormal). In this case, a change rollback can be triggered; if the rollback fails, the fault self-healing will be triggered; if the self-healing fails, manual intervention will be automatically called.

[0162] ④ The indicator light's color changes from red to yellow and then further to green after network anomaly recovery: This indicates that the previous red light was judged as a false alarm. If a reverse EOP is configured, the reverse EOP is executed to return to the main process of network change and continue execution; if a reverse EOP is not configured, the current batch maintains the EOP state (i.e., the network state reached based on the rollback of network change processing) and the next batch is executed automatically.

[0163] Therefore, during network changes, the network change processing system proposed in this application can automatically respond and process based on the different display colors of traffic lights, thereby maximizing the success rate of changes while ensuring rapid recovery from abnormal changes.

[0164] The following example, using a link expansion and modification task, details the emergency operation and deactivation procedures for the red and yellow light (connection indicator light). This link expansion and modification task includes four sets of operations: pre-modification checks (including checking the status of uplink and downlink devices), uplink configuration (including configuring uplink device ports and protocols), downlink configuration (including configuring downlink device ports and protocols), and post-modification checks (including checking the status of uplink and downlink devices). Specifically, the emergency operation and deactivation procedures for the red and yellow light can be as follows:

[0165] (a) Yellow light (i.e., a signal light that displays yellow):

[0166] When the traffic light turns from green to yellow, it indicates that the network change did not cause network anomalies, but network anomalies exist within the affected area (i.e., network quality is abnormal within the scope of the change). In this case, the system needs to pause the implementation of the change order. Therefore, the emergency procedure for the yellow light is to pause network change processing, involving a pause operation. When the traffic light returns to green, it means that the network anomaly within the affected area has been resolved, the change environment has returned to normal, and the paused change order can continue. Therefore, the emergency de-emergence procedure for the yellow light is to resume interrupted downloads, involving a resumed download operation. See also... Figure 6c As shown, considering that both the green light turning yellow and the yellow light turning green may occur during the entire network change process, the corresponding emergency operation procedures and emergency deactivation procedures can be implemented throughout the entire change process. That is, each task step can be configured with the emergency operation procedure and emergency deactivation procedure corresponding to the yellow light.

[0167] See Figure 6dAs shown, taking an unattended scheduled task as an example, assume there are 3 task groups, each containing at least one task step; where the timing for task group 1 is 01:30, the timing for task group 2 is 2:00, and the timing for task group 3 is 2:00. During network changes, when task step 1.3 in task group 1 is executed, if the indicator light turns yellow, task step 1.3, which has already been sent to the corresponding network device, continues to be implemented. However, task step 1.4, which has not yet been sent, as well as task groups 2 and 3, can be temporarily frozen and stopped from being sent. At the same time, the timing for task group 2 and task 3 is canceled. When the traffic light changes from yellow to green, unfinished task group 1 can be unfrozen (specifically, unexecuted task step 1.4 in task group 1 can be unfrozen), and task step 1.4 in task group 1 can continue to be executed. At the same time, the timers of task groups 2 and 3 that have not yet started will be automatically updated. The update rule is to automatically extend the timer based on the duration of the yellow light. For example, if the duration of the yellow light is 12 seconds, then the updated timers of task groups 2 and 3 will both become 02:12.

[0168] (ii) Red light (i.e., a signal light that displays a red color):

[0169] Since a red light generally indicates a network anomaly caused by current network changes, the system needs to respond quickly to restore network quality. Assuming network quality is restored, if the system corrects the red light to green, or if the red light is corrected to yellow and subsequently turns green again due to network recovery, the change process can be restarted, thereby increasing the success rate of the change. See also... Figure 6e As shown, considering that the task steps in the pre-change check and post-change check groups of the link expansion change task belong to the check phase, which only involves reading commands and will not cause network quality abnormalities, it is not necessary to configure the emergency operation procedures and emergency deactivation procedures for the red light for these task steps. That is, only the implementation task steps (such as the task steps in the uplink configuration and downlink configuration) need to be configured with the emergency operation procedures and emergency deactivation procedures for the red light, thereby saving memory space, reducing configuration operations, and improving configuration efficiency.

[0170] See Figure 6eAs shown: To quickly restore network quality, the emergency operation procedures corresponding to the red light can be divided into three levels. Level 1 and Level 2 emergency operation procedures involve automatic system handling of the anomaly, while Level 3 can be handled manually via telephone (i.e., notifying the network change implementer to go online and handle the relevant network anomaly via telephone). Additionally, the emergency deactivation procedure for the red light is designed to improve the success rate of changes, and it consists of two actions: reverse EOP and restart. Reverse EOP is further divided into two levels: Level 1 reverse EOP (i.e., the aforementioned deactivation rollback operation) and Level 2 reverse EOP (i.e., the aforementioned execution of device switchback). Level 1 reverse EOP corresponds to Level 1 emergency operation procedures, and Level 2 reverse EOP corresponds to Level 2 emergency operation procedures. It is understandable that since the Level 3 red light EOP (i.e., the Level 3 emergency operation procedure) is handled manually, the specific operation content is unpredictable, therefore, it is not necessary to configure the corresponding reverse EOP in advance. Furthermore, triggering the Level 3 red light EOP means that the red light has not been corrected, so in this case, it is also not necessary to initiate the emergency deactivation procedure.

[0171] The following details the emergency operation procedures and emergency cancellation procedures for red lights.

[0172] A) Emergency operating procedures for red lights:

[0173] ① Level 1 Red Light EOP (i.e., Level 1 Emergency Operation Procedure): Corresponds to the aforementioned rollback network change handling. See also... Figure 6f As shown: When the indicator light on a change order changes from green or yellow to red, it indicates that the network change corresponding to the change order has caused a network anomaly. Therefore, the system needs to revert the network configuration (such as network status) of the network devices to a stable state to quickly restore network quality. Understandably, the most recent stable state will differ depending on the different implementation steps of the change. Therefore, when creating change operation templates or operation plans, it is necessary to pre-configure differentiated Level 1 Red Light EOPs, i.e., configure corresponding Level 1 Red Light EOPs for different task steps.

[0174] ② Level 2 Red Light EOP (i.e., Level 2 Emergency Operation Procedure): Corresponds to the aforementioned fault self-healing process. See also... Figure 6fAs shown: When the Level 1 Red Light EOP is not executed or an error occurs during its execution, the Level 2 Red Light EOP can be triggered to assist in restoring service and network values. The Level 2 Red Light EOP can remove the fault point from the live network by isolating ports, boards, or the entire device, thereby restoring network quality. Optionally, considering that fault self-healing requires a certain degree of network redundancy, a risk assessment can be performed before triggering. If the risk assessment determines that the remaining capacity of the live network is sufficient after isolating the fault point (i.e., meeting network capacity requirements), fault self-healing can be triggered; otherwise, it will not be triggered. In addition, fault self-healing is related to factors such as the live network architecture and equipment type. These factors can be used to determine information such as the live network capacity. They are independent of the change operation template and task steps, so they do not need to be configured in the change operation template and operation plan, thereby saving memory and improving configuration efficiency.

[0175] ③ Level 3 Red Light EOP (i.e., Level 3 Emergency Operation Procedure): Corresponds to the aforementioned abnormal notification handling. See also... Figure 6f As shown, there are two triggering conditions for the Level 3 Red Light EOP: First, if both the Level 1 and Level 2 Red Light EOPs fail to execute or encounter errors, the Level 3 Red Light EOP can be triggered when the system reports an error (e.g., a phone call to escalate to manual intervention). Second, if both the Level 1 and Level 2 Red Light EOPs execute normally, but the network quality does not recover (i.e., the network anomaly persists) and the red light is not corrected to yellow, it can be determined that the pre-configured Level 1 and Level 2 Red Light EOPs are ineffective, and a phone call to escalate to manual intervention can be initiated. Optionally, since the Level 3 Red Light EOP is the last resort in the Level 3 emergency operation process, it is unrelated to changing the operation template and task steps. Therefore, it does not need to be configured within the operation template and operation plan, thus saving memory and improving configuration efficiency.

[0176] B) Emergency red light clearance procedure:

[0177] As described above, in the process of illuminating the traffic light, this embodiment of the application can perform two associations on the scanned network alarms and change orders. The first association is to ensure rapid light illumination, which may introduce some false alarms. After obtaining more information in the second association, the display color of the traffic light can be delayed and corrected based on this more information. After the corrected traffic light turns green after the network alarm is resolved, the system can automatically return to the main network change process through the emergency clearing procedure for the red light and restart the change, thereby improving the success rate of the change without manual intervention. Specifically, the emergency clearing procedure for the red light includes at least one of the following actions:

[0178] ① Reverse EOP: The system's return from the red-light EOP process to the main network change process depends on the reverse EOP. The reverse EOP has two levels and is the inverse operation of the red-light EOP:

[0179] 1) Level 1 Reverse EOP: This corresponds to the reverse operation of rolling back network change processing. Like the Level 1 Red Light EOP, it can be configured according to the change operation template and task steps. See, for example... Figure 6g As shown, the scenarios can be divided into the following three types:

[0180] Scenario 1: EOP Returns to Origin; that is, after the Level 1 Red Light EOP is triggered, the network device's network state returns to the initial state before the network change was performed. Since the initial state is part of the main network change process, network changes can be performed directly based on this initial state. Therefore, in this case, the Level 1 Reverse EOP is equivalent to the Level 1 Red Light EOP itself, and no additional operations are required. After the red light is corrected, the main network change process can be restarted directly.

[0181] Scenario 2: EOP returns to the previous stable state; that is, after the Level 1 red light EOP is triggered, the network device's network state returns to the previous stable state before the change (i.e., the network state before executing the previous task step). Since the previous stable state is also a state in the main network change process, network changes can be performed directly based on this previous stable state. Therefore, in this case, the Level 1 reverse EOP is equivalent to the Level 1 red light EOP itself, without the need for additional operations. However, the system needs to mark the previous stable state position of each Level 1 red light EOP so that after the red light is corrected, the breakpoint can be determined based on the recorded previous stable state, thereby directly starting the main network change process from the breakpoint.

[0182] Scenario 3: EOP Returns to the Most Recent Stable State; that is, after the Level 1 Red Light EOP is triggered, the network device's network state returns to the most recent stable state. Since the most recent stable state may not be a state in the main network change process—for example, the most recent stable state might be an isolated state, which cannot be directly used for network changes—the Level 1 Reverse EOP in this case is not the same as the Level 1 Red Light EOP. A Level 1 Reverse EOP needs to be executed to return to the network device's previous stable state, thus initiating the main network change process from that previous stable state. It is understandable that if the content of the Level 1 Red Light EOP differs for different task steps, then the Level 1 Reverse EOPs corresponding to these task steps may also differ.

[0183] 2) Secondary Reverse EOP: This corresponds to the reverse operation of device isolation in fault self-healing, i.e., device switchback. If the secondary red light EOP is port, board, or whole-machine isolation, then the secondary reverse EOP is port, board, or whole-machine switchback. Optionally, like the secondary red light EOP, the secondary reverse EOP is independent of the change operation template and task steps, and does not need to be configured in the change operation template and operation plan, thus saving memory and improving configuration efficiency.

[0184] ② Change Restart: Since the implementation of reverse EOP is relatively complex and requires adaptation to each change operation template or plan, change restart can be supported in a categorized manner during actual operation. Details are as follows:

[0185] 1) The operation template or operation plan has been configured with a first-level reverse EOP: In this case, the system can support network devices that have triggered a first-level red light EOP to return to the main network change process by executing the configured first-level reverse EOP. Therefore, the system can directly restart the main network change process (such as restarting the execution of each task step of the network change task on the network device based on the origin, or executing each task step that was not executed in the network change task on the network device based on the breakpoint).

[0186] See Figure 6h As shown, taking an unattended scheduled task as an example, assume there are 3 task groups, each containing at least one task step; where the timing for task group 1 is 01:30, the timing for task group 2 is 2:00, and the timing for task group 3 is 2:00. During network changes, when task step 1.3 is executed, if the indicator light turns red, task step 1.3, which has already been sent to the corresponding network device, continues to be implemented. However, task step 1.4, as well as task groups 2 and 3, which have not yet been sent, can be temporarily frozen and their sending stopped. Simultaneously, the red light EOP1.2 corresponding to task step 1.3 is activated to quickly roll back and restore network quality. Once the red light is corrected and turns green, the system can automatically start the reverse EOP1.2 corresponding to the red light EOP1.2, and simultaneously update the timings of task group 2 and task group 3, which have not yet started execution. The update rule is to automatically extend the original timings based on the duration of the red light. For example, if the red light duration is 12 seconds, the updated timings for both task group 2 and task group 3 will become 02:12. After the reverse EOP1.2 is completed, the system can automatically unfreeze the various task steps in the unfinished task groups and continue executing task step 1.4 and all task steps following task step 1.4 on the network devices to restart the main network change process.

[0187] 2) The change operation template or operation plan is not configured with a first-level reverse EOP: Since the system cannot support network devices that have triggered a first-level red light EOP to return to the main network change process in this situation, the corresponding network device can be kept in EOP state (i.e., the network state reached based on the triggered first-level red light EOP), and the task status of the corresponding network device or the task status of the batch to which the corresponding network device belongs should be marked as "implementation failed," awaiting handling by network operations personnel during the daytime. Optionally, to improve the success rate of network changes, if a subsequent red light is corrected to a green light, the system can automatically execute the next batch of network change tasks to complete as much of the change content as possible. This scenario is mainly suitable for batch changes, such as batch device upgrades. Change orders need to be implemented in batches according to risk control principles, with each batch corresponding to one or more devices. When a batch is confirmed to have been mistakenly killed, subsequent batches can automatically continue execution to improve the success rate of changes and reduce manual intervention.

[0188] As described above, this application embodiment, by using a traffic light system for network quality monitoring, pre-set red and yellow light emergency handling procedures, and emergency deactivation procedures, can achieve fully automated control of change implementation, pause, resumption, rollback, and restart. This automates the handling of abnormal change situations, improves anomaly handling efficiency, and ensures network quality. In cases where network anomaly judgment is incorrect, the change can be restarted, increasing the success rate. Furthermore, practical experience has shown that the solution proposed in this application embodiment can reduce the manual intervention rate in unattended network change scenarios from 13.13% to 1.17%, a reduction of over 90%. Moreover, change quality anomalies can trigger an Expiration Point (EOP) within seconds, thus compressing the average impact time of anomalies to less than one minute. Therefore, this application embodiment can respond to various anomalies during network change processes, improving the success rate of network changes; and, while ensuring network change quality, it significantly reduces labor costs.

[0189] The following is a detailed description of the system and corresponding methods proposed in the embodiments of this application using a practical example.

[0190] The specific case is as follows: The change management personnel received a network change request. This request indicated that the link bandwidth between the aggregation device and the core device within a module in a certain campus needs to be increased by 400G. The corresponding network architecture could be as follows: Figure 7a As shown. In this case, both the aggregation device and the core device are network devices.

[0191] In practical implementation, the risk management principle of network changes can be followed. Figure 7aThe aforementioned network change requirements and network architecture are broken down into four directions, identified by labels 1, 2, 3, and 4, resulting in multiple batches and network change tasks (i.e., link expansion tasks) for each batch. Furthermore, the personnel responsible for the changes can configure settings as required. Figure 7b The tasks are divided into batches, thus implementing them sequentially (i.e., performing network changes on network devices in each batch in turn). Each batch may include two network devices (an aggregation device within a campus and a core device within a module). Any network change task (i.e., a link expansion task) in any batch can be used to perform network changes on the two network devices in the corresponding batch. Furthermore, based on the same change operation template (i.e., the change operation template corresponding to the link expansion task), the operation plan for each batch can be automatically generated by inputting the device information and related parameters of the network devices in different batches.

[0192] Network changes to network devices in each batch can be performed according to the task steps in the corresponding operation plan. The task steps in each operation plan are the preset task steps in the change operation template. For example, see [link to example]. Figure 7c As shown, the change operation template for this link expansion task can include 6 task steps. Each task step can constitute a task group, and each task step has a task group number. The task steps can be executed strictly sequentially, or each task group can have a timer. When the timer for any task group arrives, the task steps in the corresponding task group are executed. Task steps 3 and 4 are configured with Level 1 emergency handling procedures (EOP1 and EOP2, respectively), but corresponding Level 1 emergency deactivation procedures are not configured. Note that since task steps 1, 2, 5, and 6 only involve viewing operations, they will not affect network quality and therefore will not cause the indicator lights to turn red. Therefore, it is not necessary to configure emergency handling procedures for red lights.

[0193] After configuring the operation plans for each batch, scheduled tasks can be further configured. It's understandable that when task groups are strictly implemented sequentially (i.e., the task steps in the previous task group must be completed before the task steps in the next task group can be executed), only the timing for the first task group needs to be configured. Alternatively, if the task groups do not require strict sequential implementation (i.e., the task steps in the next task group can be executed before the previous task group has finished), then timing can be configured for each task group separately. Furthermore, since a single batch involves only one link expansion task, one operation plan can be configured for each batch, which applies to each network device in the corresponding batch. And in the case of strict sequential implementation between task groups, one timing can be configured, i.e., a timing can be configured for task group 1 (i.e., the first task group); see, for example. Figure 7dAs shown: Since the planned time for this change is from 01:00:00 on July 11, 2024 to 06:00:00 on July 11, 2024, the timing for task group 1 within the first batch (i.e., batch 1) can be set to 01:00:00 on July 11, 2024, and this timing can be configured within the operation plan for batch 1. It is understandable that if it is a device OS upgrade task, a single batch may involve changes to multiple network devices, and the changes to each network device are independent of each other. In this case, a single batch involves executing multiple device OS upgrade tasks, therefore, a single batch needs to be configured with multiple operation plans. One operation plan applies to one network device in the corresponding batch, and task groups in different operation plans need to be set with separate timings.

[0194] After the scheduled task is set up, the work of the personnel involved in the change is basically complete. At 01:00:00 on July 11, 2024, the system can automatically determine the arrival time of task group 1 for batch 1 (i.e., the first batch). At this time, based on the operation plan for batch 1, the aforementioned six task steps can be executed on the network devices in batch 1 to perform network changes. Since the indicator lights are green throughout the entire task execution process of batch 1, and the device checks within the main network change process are all normal, it means that the change operation is normal (i.e., the network change did not cause network anomalies and there are no network anomalies within the scope of the change's impact). Therefore, there is no need to trigger the emergency operation procedure in this case. After the six task steps within the main network change process are executed sequentially, the system can automatically update the execution status of batch 1 to "Running Successfully," as shown below. Figure 7e As shown, the corresponding task execution log can be found in [link to log]. Figure 7f As shown.

[0195] Since Batch 1 has only one operation plan, it ends after executing six task steps on the corresponding network device based on that plan. At this point, the system can automatically update the implementation status of Batch 1 in the change order to "Implementation Completed" and the implementation result to "Implementation Successful." Furthermore, the system can continue to implement Batch 2 and record the start time of Batch 2's implementation. Figure 7g As shown.

[0196] At 01:48:24 on 2024-07-11, when the fourth task step was executed on the network devices in batch 2 based on the batch 2 operation plan, a yellow indicator light was detected. Figure 7h As shown. Since a yellow light indicates that the change is proceeding normally (i.e., the network change has not caused network anomalies), but network anomalies exist within the scope of the change's impact, to avoid introducing cumulative risks by continuing operations, the system can trigger a pause in the execution of the fourth task step and record the execution status of the fourth task step as "yellow light paused" in the corresponding task execution log, as shown. Figure 7i As shown.

[0197] At 01:52:58 on 2024-07-11, the traffic light was detected to change from yellow to green. Figure 7j As shown; at this point, it can be confirmed that the network alarm has been resolved, and the system can continue to execute the fourth task step. If there are remaining task groups in batch 2 at this time, and the remaining task groups are configured with timers, and the remaining task groups have not started when the yellow light is on, the system can also automatically update the timers of the remaining task groups, that is, extend them by 4 minutes and 34 seconds (the duration of the yellow light) on the original timer. Since no signal light was detected to turn red or yellow during the subsequent implementation of batch 2, and all checks in the main network change process were normal, batch 2 was ultimately successfully implemented. The corresponding task execution logs can be found in [link to log]. Figure 7k As shown. Additionally, the system can automatically update the execution status of batch 2 to "Running successfully," as shown. Figure 7l As shown; update the implementation status of batch 2 in the change order to "Implementation Completed" and the implementation result to "Implementation Successful", and start the implementation of batch 3 and record the implementation start time of batch 3, as follows. Figure 7m As shown.

[0198] At 02:28:35 on July 11, 2024, when the fourth task step was executed on the network devices in batch 3 based on the batch 3 operation plan, a red indicator light was detected. Figure 7n As shown. Since a red light indicates an error in the change execution (i.e., the network change caused a network error), to prevent network quality deterioration, the system can stop the fourth task step and initiate the corresponding EOP2 (Emergency Operation Procedure for Red Light) to revert network quality. The execution status of the fourth task step will be recorded as "Red Light Revert" in the corresponding task execution log, as shown. Figure 7o As shown. The execution record for EOP2 corresponding to the fourth task step can be found in [link to EOP2 execution log]. Figure 7p As shown.

[0199] Since EOP2, corresponding to the fourth task step, was executed successfully, the system did not trigger the level two emergency operation procedure (i.e., fault self-healing); in addition, it was detected that the red light was corrected to a yellow light at 02:29:40 on 2024-07-11. Figure 7q As shown, based on further alarm diagnostic information, it was determined that the network anomaly was unrelated to the current network changes, therefore the Level 3 emergency operation procedure (such as telephone manual upgrade) was not triggered. At 02:33:25 on 2024-07-11, the signal light was detected to change from yellow to green, as shown... Figure 7r As shown; at this point, it can be confirmed that the network alarm has been restored (e.g. Figure 7sAs shown), the system can automatically trigger a reverse EOP (i.e., emergency deactivation procedure). However, because the system detects that the reverse EOP corresponding to the fourth task step has not been pre-configured, it automatically terminates batch 3 and automatically updates the execution status of batch 3 to "running failed," as shown. Figure 7t As shown. Additionally, in the change order, the implementation result of batch 3 can be marked as "implementation failed" and the implementation status can be marked as "implementation completed," and the implementation of batch 4 can be started and the implementation start time of batch 4 can be recorded, such as... Figure 7u As shown.

[0200] During the implementation of batch 4, no signal lights were detected turning red or yellow, and all network device checks during the change process were normal. Therefore, the emergency operation procedure was not triggered. The corresponding task execution logs can be found in [link to log]. Figure 7v As shown, after batch 4 is completed, the execution status of batch 4 will be automatically updated to "run successfully", as shown. Figure 7w As shown. Additionally, in the change order, the implementation result of batch 4 can be marked as "Implementation Successful" and the implementation status can be marked as "Implementation Completed," as shown below. Figure 7x As shown.

[0201] Ultimately, three of the four batches involved in the change order were successfully implemented, while one batch failed. The change order was automatically closed, awaiting evaluation and handling of the failed batch by the change personnel the following day. Based on the above description, it can be seen that this change process required no human intervention throughout the evening. Even in the event of quality anomalies, the system could automatically respond and handle them, truly achieving unattended change management.

[0202] Based on the descriptions of the above method embodiments, this application also discloses a network change exception handling device; the network change exception handling device may be a computer program (including one or more instructions) running on a computer device, and the network change exception handling device may execute each step in any of the above method flows. Please refer to... Figure 8 The network change anomaly handling device can operate the following units:

[0203] The acquisition unit 801 is used to acquire the operation plan of the target network device. The operation plan is used to modify the network of the target network device according to the network change task. The operation plan includes: atomic templates for each task step of the network change task, and network exception handling corresponding to each task step.

[0204] The processing unit 802 is used to call the atomic template in the operation scheme to execute each task step of the network change task on the target network device; and to monitor network abnormal events during the execution of the network change task.

[0205] The processing unit 802 is further configured to, if the network abnormal event is detected, determine the task steps executed when the network abnormal event is detected as target task steps;

[0206] The processing unit 802 is further configured to obtain the network anomaly handling corresponding to the target task step from the operation scheme, and execute the obtained network anomaly handling.

[0207] In one embodiment, when acquiring the operation scheme of the target network device, the acquisition unit 801 may specifically be used for:

[0208] Obtain an operation template for a network change task. The operation template includes: information fields for filling in device information, atomic templates for executing each task step of the network change task, and network exception handling corresponding to each task step.

[0209] Obtain device information of the target network device to be executed for the network change task;

[0210] The device information of the target network device is filled into the information field of the operation template to obtain the operation plan of the target network device.

[0211] In another embodiment, the network change task is configured with a target change order, which indicates at least one group of network devices. Each group of network devices performs network changes according to the network change task, and the network changes performed on the at least one group of network devices constitute the network changes corresponding to the target change order. The target network device is any group of network devices indicated by the target change order. The target change order is configured with a signal light to indicate whether there is a network anomaly.

[0212] Accordingly, when monitoring network anomaly events during the execution of the network change task, the processing unit 802 may specifically be used to:

[0213] During the execution of the network change task, the display color of the signal light is monitored;

[0214] If the displayed color of the signal light is detected to be the base color, it is determined that no network anomaly event has been detected; wherein, the base color is used to indicate that the network change corresponding to the target change order has not caused a network anomaly, and there is no network anomaly within the scope of the change of the target change order;

[0215] If the displayed color of the signal light is detected to be the target color, then a network anomaly event is detected; wherein, the target color is different from the base color and is used to indicate at least one of the following: the network change corresponding to the target change order has caused a network anomaly, and there is a network anomaly within the scope of the change of the target change order.

[0216] In another embodiment, the target color is a first color or a second color; the first color is used to indicate that: the network change corresponding to the target change order has not caused network anomalies, and there are network anomalies within the scope of the change of the target change order; the second color is used to indicate that: the network change corresponding to the target change order has caused network anomalies.

[0217] The network anomaly handling corresponding to the task steps includes at least one of the following: pausing network change processing and rolling back network change processing; wherein, pausing network change processing is used to suspend the execution of the network change task, and rolling back network change processing is used to roll back the network state of the network device to a stable state.

[0218] When processing unit 802 is used to obtain the network anomaly handling corresponding to the target task step from the operation plan, it can be specifically used to: if the display color of the signal light is the first color, then obtain the pause network change handling corresponding to the target task step from the operation plan;

[0219] Accordingly, when the processing unit 802 is used to perform the acquired network anomaly handling, it can specifically be used for:

[0220] The remaining task steps are determined, including the task steps that follow the target task steps in each task step of the network change task performed on the target network device.

[0221] The remaining task steps are suspended for the target network device to suspend the network change task.

[0222] In another embodiment, when the processing unit 802 is used to obtain the network anomaly processing corresponding to the target task step from the operation plan, it can be specifically used to: if the display color of the signal light is the second color, then obtain the rollback network change processing corresponding to the target task step from the operation plan;

[0223] Accordingly, the processing unit 802 can also be used for:

[0224] If the obtained rollback network change processing fails, then perform fault self-healing processing on the network device indicated by the target change order.

[0225] The fault self-healing process is used to isolate the fault point from the device; the fault point refers to the network device that causes the network abnormality among the network devices indicated by the target change order.

[0226] In another embodiment, the processing unit 802 may also be used for:

[0227] If the fault self-healing process fails, an exception notification process is executed, which is used to notify the network change implementer to handle network exceptions.

[0228] In another embodiment, the operation scheme further includes: an exception handling resolution operation corresponding to each task step, wherein the exception handling resolution operation is used to resolve network exception handling of the corresponding task step.

[0229] Accordingly, the processing unit 802 can also be used for:

[0230] After executing the acquired network anomaly handling, monitor the network anomaly resolution event;

[0231] If the network anomaly resolution event is detected, the anomaly resolution operation corresponding to the target task step is obtained from the operation plan, and the obtained anomaly resolution operation is executed.

[0232] In another embodiment, the network change task is configured with a target change order, which indicates at least one group of network devices. Each group of network devices performs network changes according to the network change task, and the network changes performed on the at least one group of network devices constitute the network changes corresponding to the target change order. The target network device is any group of network devices indicated by the target change order. The target change order is configured with a signal light to indicate whether there is a network anomaly.

[0233] Accordingly, when the processing unit 802 monitors the network anomaly resolution event after performing the acquired network anomaly handling, it can specifically be used for:

[0234] After processing the acquired network anomaly, monitor the displayed color of the indicator light;

[0235] If the displayed color of the signal light is detected to be the base color, it is determined that a network anomaly resolution event has been detected; wherein, the base color is used to indicate that the network change corresponding to the target change order has not caused a network anomaly, and there is no network anomaly within the scope of the change of the target change order;

[0236] If the displayed color of the signal light is detected to be the target color, it is determined that no network anomaly resolution event has been detected. The target color is different from the base color and is used to indicate at least one of the following: the network change corresponding to the target change order has caused a network anomaly, and there is a network anomaly within the scope of the change of the target change order.

[0237] In another implementation, when network anomaly handling includes at least one of pausing network change processing and rolling back network change processing, the anomaly handling deactivation operation includes at least one of the following: a resume operation and a rollback deactivation operation; wherein:

[0238] The breakpoint resume operation is used to undo the paused network change processing. The execution process of the breakpoint resume operation includes: continuing to execute the breakpoint and the task steps located after the breakpoint. The breakpoint refers to the first task step in the currently paused task steps.

[0239] The rollback cancellation operation is used to cancel the rollback network change processing and trigger the network change process.

[0240] In another embodiment, when the processing unit 802 obtains the exception handling resolution operation corresponding to the target task step from the operation plan and executes the obtained exception handling resolution operation, it may specifically be used for:

[0241] If the pause network change processing corresponding to the target task step has been executed, then the breakpoint resume operation corresponding to the target task step is obtained from the operation plan, and the obtained breakpoint resume operation is executed on the target network device.

[0242] If the rollback network change processing corresponding to the target task step has been executed, then the rollback cancellation operation corresponding to the target task step is obtained from the operation plan, and the obtained rollback cancellation operation is executed on the target network device.

[0243] In another embodiment, the processing unit 802 may also be used for:

[0244] If the rollback operation corresponding to the target task step is not obtained from the operation plan, the network state of the target network device will be kept as the target stable state, and it will be determined that the network change task for the target network device has failed.

[0245] The target stable state refers to the stable state of the network of the target network device after the rollback network change processing corresponding to the target task step is performed on the target network device.

[0246] In another implementation, upon detecting the network anomaly resolution event, the processing unit 802 can also be used to:

[0247] If a network anomaly event is detected and the fault point is isolated, then in response to the network anomaly resolution event, the fault point is switched back to its original device. The device switchback refers to the reverse operation of the device isolation.

[0248] In another embodiment, the operation scheme includes at least one task group, each task group including at least one task step of the network change task, and each task group has a timer, the timer being used to indicate the start execution time of the task group.

[0249] Accordingly, the processing unit 802 can also be used for:

[0250] After detecting a network anomaly resolution event, the duration of the network anomaly event is determined; the duration is used to indicate the time interval between the time when the network anomaly event is detected and the time when the network anomaly event is resolved.

[0251] Determine the remaining task groups; the remaining task groups include: task groups that begin execution after the target task group is executed; the target task group refers to: the task group in which the target task step is located;

[0252] Based on the duration of the network anomaly event, the timing of the remaining task group is updated; wherein the updated timing is obtained by postponing the duration of the previous timing.

[0253] According to another embodiment of this application, Figure 8 The network change anomaly handling device shown can be composed of individual or combined units into one or more other units, or some of the units can be further divided into multiple functionally smaller units. This achieves the same operation without affecting the technical effects of the embodiments of this application. The above units are based on logical function division. In practical applications, the function of one unit can be implemented by multiple units, or the function of multiple units can be implemented by one unit. In other embodiments of this application, the network change anomaly handling device may also include other units. In practical applications, these functions can also be implemented with the assistance of other units, and can be implemented collaboratively by multiple units.

[0254] According to another embodiment of this application, a computer program (including one or more instructions) capable of performing the steps involved in any method embodiment can be run on a general-purpose computing device, such as a computer, which includes processing elements and storage elements such as a central processing unit (CPU), random access memory (RAM), and read-only memory (ROM), to construct a system such as... Figure 8The present invention describes an anomaly handling apparatus for network changes, and an anomaly handling method for network changes to implement embodiments of the present application. The computer program may be recorded on, for example, a computer-readable storage medium, loaded onto the aforementioned computing device via the computer-readable storage medium, and run therein.

[0255] It is worth noting that, in the embodiments of this application, the terms "module" or "unit" refer to a computer program or part of a computer program with a predetermined function, which works together with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can contain a portion of the overall module or unit's functionality.

[0256] This application embodiment can set atomic templates for each task step of performing network change tasks on the target network device, as well as corresponding network exception handling for each task step, in the operation plan of the target network device. This allows for automated network change execution by calling the atomic templates in the operation plan, reducing the risk of human error and improving the success rate of network changes. Furthermore, by monitoring network anomalies during the execution of network change tasks, and identifying the task step executed at the time of detection as the target task step, the corresponding network exception handling for the target task step is obtained from the operation plan and executed. This automates the handling of network anomalies detected during network changes, improving exception handling efficiency and further enhancing the success rate of network changes.

[0257] Based on the description of the above method and apparatus embodiments, this application also provides a computer device. Please refer to... Figure 9The computer device includes at least a processor 901, an input interface 902, an output interface 903, and a computer storage medium 904. The processor 901, input interface 902, output interface 903, and computer storage medium 904 within the computer device can be connected via a bus or other means. The computer storage medium 904 can be stored in the computer device's memory. The computer storage medium 904 is used to store a computer program, which includes one or more instructions. The processor 901 is used to execute one or more instructions from the computer program stored in the computer storage medium 904. The processor 901 (or CPU (Central Processing Unit)) is the computing and control core of the computer device, adapted to implement one or more instructions, specifically adapted to load and execute one or more instructions to achieve a corresponding method flow or function.

[0258] In one embodiment, the processor 901 described in this application can be used to perform a series of network change exception handling, specifically including: obtaining an operation plan for a target network device, the operation plan being used to change the network of the target network device according to a network change task; the operation plan including: atomic templates for executing each task step of the network change task, and network exception handling corresponding to each task step; calling the atomic templates in the operation plan to execute each task step of the network change task on the target network device; and monitoring network exception events during the execution of the network change task; if the network exception event is detected, determining the task step executed when the network exception event is detected as the target task step; obtaining the network exception handling corresponding to the target task step from the operation plan, and executing the obtained network exception handling, etc.

[0259] This application embodiment also provides a computer storage medium (Memory), which is a memory device in a computer device used to store computer programs and data. It is understood that the computer storage medium here can include both the built-in storage medium in the computer device and extended storage media supported by the computer device. The computer storage medium provides storage space that stores the operating system of the computer device. Furthermore, the storage space also stores a computer program, which includes one or more instructions suitable for loading and execution by the processor 901. These instructions can be one or more program codes. It should be noted that the computer storage medium here can be high-speed RAM or non-volatile memory, such as at least one disk storage device; optionally, it can also be at least one computer storage medium located remotely from the aforementioned processor.

[0260] In one embodiment, a processor may load and execute one or more instructions stored in a computer storage medium to implement the corresponding steps in any of the above method embodiments; specifically, one or more instructions in the computer storage medium may be loaded and executed by the processor in the following steps:

[0261] An operation plan for obtaining a target network device is provided, wherein the operation plan is used to modify the network of the target network device according to a network change task; the operation plan includes: atomic templates for executing each task step of the network change task, and network exception handling corresponding to each task step;

[0262] The atomic template in the operation scheme is invoked to execute each task step of the network change task on the target network device; and network anomaly events are monitored during the execution of the network change task.

[0263] If the network anomaly event is detected, the task steps executed when the network anomaly event is detected will be determined as the target task steps;

[0264] Obtain the network anomaly handling corresponding to the target task step from the operation plan, and execute the obtained network anomaly handling.

[0265] In one implementation, when acquiring the operation plan of the target network device, the one or more instructions can be loaded and executed by the processor:

[0266] Obtain an operation template for a network change task. The operation template includes: information fields for filling in device information, atomic templates for executing each task step of the network change task, and network exception handling corresponding to each task step.

[0267] Obtain device information of the target network device to be executed for the network change task;

[0268] The device information of the target network device is filled into the information field of the operation template to obtain the operation plan of the target network device.

[0269] In another embodiment, the network change task is configured with a target change order, which indicates at least one group of network devices. Each group of network devices performs network changes according to the network change task, and the network changes performed on the at least one group of network devices constitute the network changes corresponding to the target change order. The target network device is any group of network devices indicated by the target change order. The target change order is configured with a signal light to indicate whether there is a network anomaly.

[0270] Accordingly, during the execution of the network change task, when monitoring for abnormal network events, one or more instructions can be loaded and executed by the processor:

[0271] During the execution of the network change task, the display color of the signal light is monitored;

[0272] If the displayed color of the signal light is detected to be the base color, it is determined that no network anomaly event has been detected; wherein, the base color is used to indicate that the network change corresponding to the target change order has not caused a network anomaly, and there is no network anomaly within the scope of the change of the target change order;

[0273] If the displayed color of the signal light is detected to be the target color, then a network anomaly event is detected; wherein, the target color is different from the base color and is used to indicate at least one of the following: the network change corresponding to the target change order has caused a network anomaly, and there is a network anomaly within the scope of the change of the target change order.

[0274] In another embodiment, the target color is a first color or a second color; the first color is used to indicate that: the network change corresponding to the target change order has not caused network anomalies, and there are network anomalies within the scope of the change of the target change order; the second color is used to indicate that: the network change corresponding to the target change order has caused network anomalies.

[0275] The network anomaly handling corresponding to the task steps includes at least one of the following: pausing network change processing and rolling back network change processing; wherein, pausing network change processing is used to suspend the execution of the network change task, and rolling back network change processing is used to roll back the network state of the network device to a stable state.

[0276] When obtaining the network anomaly handling corresponding to the target task step from the operation plan, one or more instructions can be loaded and specifically executed by the processor: if the display color of the signal light is the first color, then obtain the pause network change handling corresponding to the target task step from the operation plan;

[0277] Accordingly, when executing the acquired network anomaly handling, the one or more instructions can be loaded and executed by the processor:

[0278] The remaining task steps are determined, including the task steps that follow the target task steps in each task step of the network change task performed on the target network device.

[0279] The remaining task steps are suspended for the target network device to suspend the network change task.

[0280] In another implementation, when obtaining the network anomaly handling corresponding to the target task step from the operation plan, the one or more instructions can be loaded and specifically executed by the processor: if the display color of the signal light is the second color, then obtain the rollback network change handling corresponding to the target task step from the operation plan;

[0281] Correspondingly, the one or more instructions can also be loaded and executed by the processor:

[0282] If the obtained rollback network change processing fails, then perform fault self-healing processing on the network device indicated by the target change order.

[0283] The fault self-healing process is used to isolate the fault point from the device; the fault point refers to the network device that causes the network abnormality among the network devices indicated by the target change order.

[0284] In another implementation, the one or more instructions may be loaded and executed by the processor:

[0285] If the fault self-healing process fails, an exception notification process is executed, which is used to notify the network change implementer to handle network exceptions.

[0286] In another embodiment, the operation scheme further includes: an exception handling resolution operation corresponding to each task step, wherein the exception handling resolution operation is used to resolve network exception handling of the corresponding task step.

[0287] Accordingly, the one or more instructions can be loaded and executed by the processor:

[0288] After executing the acquired network anomaly handling, monitor the network anomaly resolution event;

[0289] If the network anomaly resolution event is detected, the anomaly resolution operation corresponding to the target task step is obtained from the operation plan, and the obtained anomaly resolution operation is executed.

[0290] In another embodiment, the network change task is configured with a target change order, which indicates at least one group of network devices. Each group of network devices performs network changes according to the network change task, and the network changes performed on the at least one group of network devices constitute the network changes corresponding to the target change order. The target network device is any group of network devices indicated by the target change order. The target change order is configured with a signal light to indicate whether there is a network anomaly.

[0291] Accordingly, after executing the acquired network anomaly handling, when monitoring the network anomaly resolution event, the one or more instructions can be loaded and executed by the processor:

[0292] After processing the acquired network anomaly, monitor the displayed color of the indicator light;

[0293] If the displayed color of the signal light is detected to be the base color, it is determined that a network anomaly resolution event has been detected; wherein, the base color is used to indicate that the network change corresponding to the target change order has not caused a network anomaly, and there is no network anomaly within the scope of the change of the target change order;

[0294] If the displayed color of the signal light is detected to be the target color, it is determined that no network anomaly resolution event has been detected. The target color is different from the base color and is used to indicate at least one of the following: the network change corresponding to the target change order has caused a network anomaly, and there is a network anomaly within the scope of the change of the target change order.

[0295] In another implementation, when network anomaly handling includes at least one of pausing network change processing and rolling back network change processing, the anomaly handling deactivation operation includes at least one of the following: a resume operation and a rollback deactivation operation; wherein:

[0296] The breakpoint resume operation is used to undo the paused network change processing. The execution process of the breakpoint resume operation includes: continuing to execute the breakpoint and the task steps located after the breakpoint. The breakpoint refers to the first task step in the currently paused task steps.

[0297] The rollback cancellation operation is used to cancel the rollback network change processing and trigger the network change process.

[0298] In another implementation, when obtaining the exception handling resolution operation corresponding to the target task step from the operation plan and executing the obtained exception handling resolution operation, the one or more instructions can be loaded and specifically executed by the processor:

[0299] If the pause network change processing corresponding to the target task step has been executed, then the breakpoint resume operation corresponding to the target task step is obtained from the operation plan, and the obtained breakpoint resume operation is executed on the target network device.

[0300] If the rollback network change processing corresponding to the target task step has been executed, then the rollback cancellation operation corresponding to the target task step is obtained from the operation plan, and the obtained rollback cancellation operation is executed on the target network device.

[0301] In another implementation, the one or more instructions may be loaded and executed by the processor:

[0302] If the rollback operation corresponding to the target task step is not obtained from the operation plan, the network state of the target network device will be kept as the target stable state, and it will be determined that the network change task for the target network device has failed.

[0303] The target stable state refers to the stable state of the network of the target network device after the rollback network change processing corresponding to the target task step is performed on the target network device.

[0304] In another implementation, upon detecting the network anomaly resolution event, the one or more instructions can be loaded and executed by the processor:

[0305] If a network anomaly event is detected and the fault point is isolated, then in response to the network anomaly resolution event, the fault point is switched back to its original device. The device switchback refers to the reverse operation of the device isolation.

[0306] In another embodiment, the operation scheme includes at least one task group, each task group including at least one task step of the network change task, and each task group has a timer, the timer being used to indicate the start execution time of the task group.

[0307] Accordingly, the one or more instructions can be loaded and executed by the processor:

[0308] After detecting a network anomaly resolution event, the duration of the network anomaly event is determined; the duration is used to indicate the time interval between the time when the network anomaly event is detected and the time when the network anomaly event is resolved.

[0309] Determine the remaining task groups; the remaining task groups include: task groups that begin execution after the target task group is executed; the target task group refers to: the task group in which the target task step is located;

[0310] Based on the duration of the network anomaly event, the timing of the remaining task group is updated; wherein the updated timing is obtained by postponing the duration of the previous timing.

[0311] This application embodiment can set atomic templates for each task step of performing network change tasks on the target network device, as well as corresponding network exception handling for each task step, in the operation plan of the target network device. This allows for automated network change execution by calling the atomic templates in the operation plan, reducing the risk of human error and improving the success rate of network changes. Furthermore, by monitoring network anomalies during task execution and identifying the task step executed at the time of detection as the target task step, the corresponding network exception handling can be obtained from the operation plan and executed. This automates the handling of network anomalies detected during network changes, improving exception handling efficiency and further enhancing the success rate of network changes.

[0312] It should be noted that, according to one aspect of this application, a computer program product or computer program is also provided, comprising one or more instructions stored in a computer storage medium. A processor of a computer device reads one or more instructions from the computer storage medium and executes the one or more instructions, causing the computer device to perform the methods provided in various optional embodiments of the above-described methods. It should be understood that the above-disclosed embodiments are merely preferred embodiments of this application and should not be construed as limiting the scope of this application. Therefore, equivalent variations made according to the claims of this application are still within the scope of this application.

Claims

1. A method for handling network change anomalies, characterized in that, include: An operation plan for obtaining the target network device is provided, wherein the operation plan is used to modify the network of the target network device according to the network change task. The operation scheme includes: atomic templates for each task step of executing the network change task, and network exception handling corresponding to each task step; The atomic template in the operation scheme is invoked to execute each task step of the network change task on the target network device; and network anomaly events are monitored during the execution of the network change task. If the network anomaly event is detected, the task steps executed when the network anomaly event is detected will be determined as the target task steps; Obtain the network anomaly handling corresponding to the target task step from the operation plan, and execute the obtained network anomaly handling.

2. The method as described in claim 1, characterized in that, The operation scheme for acquiring the target network device includes: Obtain an operation template for a network change task. The operation template includes: information fields for filling in device information, atomic templates for executing each task step of the network change task, and network exception handling corresponding to each task step. Obtain device information of the target network device to be executed for the network change task; The device information of the target network device is filled into the information field of the operation template to obtain the operation plan of the target network device.

3. The method as described in claim 1 or 2, characterized in that, The network change task is configured with a target change order, which indicates at least one group of network devices. Each group of network devices performs network changes according to the network change task. The network changes performed on the at least one group of network devices constitute the network changes corresponding to the target change order. The target network device is any group of network devices indicated by the target change order. The target change order is configured with a signal light to indicate whether there is a network anomaly. The monitoring of abnormal network events during the execution of the network change task includes: During the execution of the network change task, the display color of the signal light is monitored; If the displayed color of the signal light is detected to be the base color, it is determined that no network anomaly event has been detected; wherein, the base color is used to indicate that the network change corresponding to the target change order has not caused a network anomaly, and there is no network anomaly within the scope of the change of the target change order; If the displayed color of the signal light is detected to be the target color, then a network anomaly event is detected; wherein, the target color is different from the base color and is used to indicate at least one of the following: the network change corresponding to the target change order has caused a network anomaly, and there is a network anomaly within the scope of the change of the target change order.

4. The method as described in claim 3, characterized in that, The target color is either a first color or a second color; the first color indicates that the network change corresponding to the target change order has not caused a network anomaly, and that a network anomaly exists within the scope of the change's impact; the second color indicates that the network change corresponding to the target change order has caused a network anomaly. The network anomaly handling corresponding to the task steps includes at least one of the following: pausing network change processing and rolling back network change processing; wherein, pausing network change processing is used to suspend the execution of the network change task, and rolling back network change processing is used to roll back the network state of the network device to a stable state.

5. The method as described in claim 4, characterized in that, The step of obtaining the network anomaly handling corresponding to the target task step from the operation plan includes: if the display color of the signal light is the first color, then obtaining the pause network change handling corresponding to the target task step from the operation plan; The execution of the acquired network anomaly handling includes: The remaining task steps are determined, including the task steps that follow the target task steps in each task step of the network change task performed on the target network device. The remaining task steps are suspended for the target network device to suspend the network change task.

6. The method as described in claim 4, characterized in that, The step of obtaining the network anomaly handling corresponding to the target task step from the operation plan includes: if the display color of the signal light is the second color, then obtaining the rollback network change handling corresponding to the target task step from the operation plan; The method further includes: If the obtained rollback network change processing fails, then perform fault self-healing processing on the network device indicated by the target change order. The fault self-healing process is used to isolate the fault point from the device; the fault point refers to the network device that causes the network abnormality among the network devices indicated by the target change order.

7. The method as described in claim 6, characterized in that, The method further includes: If the fault self-healing process fails, an exception notification process is executed, which is used to notify the network change implementer to handle network exceptions.

8. The method as described in claim 1, characterized in that, The operation plan also includes: an exception handling resolution operation corresponding to each task step, the exception handling resolution operation being used to resolve network exception handling for the corresponding task step. The method further includes: After executing the acquired network anomaly handling, monitor the network anomaly resolution event; If the network anomaly resolution event is detected, the anomaly resolution operation corresponding to the target task step is obtained from the operation plan, and the obtained anomaly resolution operation is executed.

9. The method as described in claim 8, characterized in that, The network change task is configured with a target change order, which indicates at least one group of network devices. Each group of network devices performs network changes according to the network change task. The network changes performed on the at least one group of network devices constitute the network changes corresponding to the target change order. The target network device is any group of network devices indicated by the target change order. The target change order is configured with a signal light to indicate whether there is a network anomaly. The step of monitoring network anomaly resolution events after executing the acquired network anomaly handling includes: After processing the acquired network anomaly, monitor the displayed color of the indicator light; If the displayed color of the signal light is detected to be the base color, it is determined that a network anomaly resolution event has been detected; wherein, the base color is used to indicate that the network change corresponding to the target change order has not caused a network anomaly, and there is no network anomaly within the scope of the change of the target change order; If the displayed color of the signal light is detected to be the target color, it is determined that no network anomaly resolution event has been detected. The target color is different from the base color and is used to indicate at least one of the following: the network change corresponding to the target change order has caused a network anomaly, and there is a network anomaly within the scope of the change of the target change order.

10. The method as described in claim 8, characterized in that, When network anomaly handling includes at least one of pausing network change processing and rolling back network change processing, the anomaly handling deactivation operation includes at least one of the following: a resume operation and a deactivation operation; wherein: The breakpoint resume operation is used to undo the paused network change processing. The execution process of the breakpoint resume operation includes: continuing to execute the breakpoint and the task steps located after the breakpoint. The breakpoint refers to the first task step in the currently paused task steps. The rollback cancellation operation is used to cancel the rollback network change processing and trigger the network change process.

11. The method as described in claim 10, characterized in that, The step of obtaining the exception handling resolution operation corresponding to the target task step from the operation plan and executing the obtained exception handling resolution operation includes: If the pause network change processing corresponding to the target task step has been executed, then the breakpoint resume operation corresponding to the target task step is obtained from the operation plan, and the obtained breakpoint resume operation is executed on the target network device. If the rollback network change processing corresponding to the target task step has been executed, then the rollback cancellation operation corresponding to the target task step is obtained from the operation plan, and the obtained rollback cancellation operation is executed on the target network device.

12. The method as described in claim 11, characterized in that, The method further includes: If the rollback operation corresponding to the target task step is not obtained from the operation plan, the network state of the target network device will be kept as the target stable state, and it will be determined that the network change task for the target network device has failed. The target stable state refers to the stable state of the network of the target network device after the rollback network change processing corresponding to the target task step is performed on the target network device.

13. The method as described in claim 8, characterized in that, In the event that the network abnormality is detected, the method further includes: If a network anomaly event is detected and the fault point is isolated, then in response to the network anomaly resolution event, the fault point is switched back to its original device. The device switchback refers to the reverse operation of the device isolation.

14. The method as described in claim 1, characterized in that, The operation scheme includes at least one task group, and each task group includes at least one task step of the network change task. Each task group has a timer, which is used to indicate the start execution time of the task group. The method further includes: After detecting a network anomaly resolution event, the duration of the network anomaly event is determined; the duration is used to indicate the time interval between the time when the network anomaly event is detected and the time when the network anomaly event is resolved. Identify the remaining task groups; the remaining task groups include: task groups that begin execution after the target task group is executed; the target task group refers to: the task group in which the target task step is located; Based on the duration of the network anomaly event, the timing of the remaining task group is updated; wherein the updated timing is obtained by postponing the duration of the previous timing.

15. A network change anomaly handling device, characterized in that, include: An acquisition unit is used to acquire an operation plan for a target network device, wherein the operation plan is used to modify the network of the target network device according to a network change task; The operation scheme includes: atomic templates for each task step of executing the network change task, and network exception handling corresponding to each task step; The processing unit is used to call the atomic template in the operation scheme to execute each task step of the network change task on the target network device; and to monitor network abnormal events during the execution of the network change task. The processing unit is further configured to, if the network anomaly event is detected, determine the task steps executed when the network anomaly event is detected as the target task steps; The processing unit is further configured to obtain the network anomaly handling corresponding to the target task step from the operation scheme, and execute the obtained network anomaly handling.

16. A computer device, comprising an input interface and an output interface, characterized in that, Also includes: Processor and computer storage media; The processor is adapted to implement one or more instructions, the computer storage medium stores one or more instructions, and the one or more instructions are adapted to be loaded by the processor and executed as described in any one of claims 1-14 for handling network change exceptions.

17. A computer storage medium, characterized in that, The computer storage medium stores one or more instructions, which are adapted to be loaded by a processor and executed by the network change exception handling method as described in any one of claims 1-14.

18. A computer program product, characterized in that, The computer program product includes one or more instructions; when one or more instructions in the computer program are executed by the processor, they implement the network change exception handling method as described in any one of claims 1-14.

Images