WO2024037345A1 - Fault processing method and apparatus, and storage medium - Google Patents

Abstract

The present application provides a fault processing method and apparatus, and a storage medium. The method comprises: acquiring service intention information (S110); performing standardization processing on the service intention information to obtain a fault diagnosis scenario of a target network device and a processing priority of the fault diagnosis scenario (S120); and performing fault processing on the fault diagnosis scenario according to the processing priority (S130).

Description

Troubleshooting method, device and storage medium thereof

Cross-references to related applications

This application is filed based on a Chinese patent application with application number 202210994855.5 and a filing date of August 18, 2022, and claims the priority of the Chinese patent application. The entire content of the Chinese patent application is hereby incorporated by reference into this application.

Technical field

The embodiments of the present application relate to, but are not limited to, the field of communication technology, and in particular, to a fault handling method, device, and storage medium thereof.

Background technique

In some cases, the business operation and maintenance system and the professional operation and maintenance system are usually deployed separately. The professional operation and maintenance system can analyze, diagnose and repair network faults. When the business operation and maintenance personnel discover a business problem, they need to feed back the business intention of the business problem to the professional operation and maintenance system. The professional operation and maintenance system handles the fault according to the business intention, and then confirms with the business operation and maintenance system whether the business problem is solve. Based on this, if the business operation and maintenance personnel in the business operation and maintenance system cannot accurately describe the business problem, there will be multiple fault location situations, which will lead to a reduction in fault handling efficiency.

Contents of the invention

Embodiments of the present application provide a fault handling method, device, and storage medium.

In the first aspect, embodiments of the present application provide a fault processing method, which includes: obtaining business intent information; performing standardized processing on the business intent information to obtain a fault diagnosis scenario and the processing priority of the fault diagnosis scenario; according to the Perform fault processing on the fault diagnosis scenario according to the above processing priority.

In a second aspect, embodiments of the present application also provide a fault handling device, including: a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, Troubleshooting methods as described above.

In a third aspect, embodiments of the present application also provide a computer-readable storage medium that stores computer-executable instructions, and the computer-executable instructions are used to execute the fault handling method as described above.

In a fourth aspect, embodiments of the present application further provide a computer program product, which includes a computer program or computer instructions. The computer program or computer instructions are stored in a computer-readable storage medium. The processor of the computer device obtains the information from the computer program or computer instructions. The computer-readable storage medium reads the computer program or the computer instructions, and the processor executes the computer program or the computer instructions, so that the computer device performs the fault handling method as described above.

Description of drawings

Figure 1 is a schematic diagram of a fault processing device for performing a fault processing method provided by an embodiment of the present application;

Figure 2 is a flow chart of a fault handling method provided by an embodiment of the present application;

Figure 3 is a flow chart of a method in step S120 in Figure 2;

Figure 4 is a flow chart of a method in step S220 in Figure 3;

Figure 5 is a flow chart of a fault handling method provided by another embodiment of the present application;

Figure 6 is a flow chart of a fault handling method provided by another embodiment of the present application;

Figure 7 is a schematic diagram of an application scenario in which a fault handling device provided by an embodiment of the present application is deployed in a business operation and maintenance system;

Figure 8 is a flow chart of a fault handling method provided by another embodiment of the present application;

Figure 9 is a schematic diagram of an application scenario in which a fault handling device for executing a fault handling method provided by an embodiment of the present application is deployed in a business operation and maintenance system;

Figure 10 is a schematic diagram of the movement scenario of an AGV automatic guided transport vehicle provided by an embodiment of the present application.

Figure 11 is a schematic diagram of a fault processing device provided by another embodiment of the present application.

Detailed ways

In order to make the purpose, technical solutions and advantages of the present application more clear, the present application will be further described in detail below with reference to the drawings and embodiments. It should be understood that the embodiments described here are only used to explain the present application and are not used to limit the present application.

It should be noted that although a logical sequence is shown in the flowchart, in some cases, the steps shown or described may be performed in an order different from that in the flowchart. In the description of the specification, claims and the above drawings, plural (or multiple) means two or more, greater than, less than, exceeding, etc. are understood to exclude the number, and above, below, within, etc. are understood to include the number. If there are descriptions of "first", "second", etc., they are only used for the purpose of distinguishing technical features and cannot be understood as indicating or implying the relative importance or implicitly indicating the number of technical features indicated or implicitly indicating the indicated technical features. The sequence relationship of technical features.

Embodiments of this application include: obtaining business intent information; performing standardized processing on the business intent information to obtain the fault diagnosis scenario of the target network device and the processing priority of the fault diagnosis scenario; performing fault processing on the fault diagnosis scenario according to the processing priority, that is, That is to say, through the standardized processing of business intent information, the target network device and its fault diagnosis scenario can be accurately located, and the fault diagnosis scenario can be fault processed according to the processing priority, which improves the fault processing efficiency. Therefore, the embodiment of the present application can Accurately locate faults and improve fault handling efficiency.

As shown in Figure 1, Figure 1 is a schematic diagram of a fault processing device for executing a fault processing method provided by an embodiment of the present application. In the embodiment of FIG. 1 , the fault handling device at least includes an intent sensor 110 , an intent translator 120 , a knowledge manager 130 , a delimitation locator 150 , a fault forwarder 140 and an intent verifier 160 , where the intent sensor 110. The intent translator 120, the knowledge manager 130, the intent verifier 160, the delimitation locator 150 and the fault handler 140 are communicatively connected in sequence, and the intent translator 120 is also communicatively connected with the delimitation locator 150.

The intent sensor 110 can obtain the user's service perception indicator requirements, and then convert the user's service perception indicator requirements and other business intention information into processing statements, such as delay guarantee requirements, bandwidth guarantee requirements, etc., through business intention input in voice, text, etc. Process statements. Taking the scenario of terminal automatic assembly business at a certain workstation in a certain workshop as an example, the intent sensor 110 can convert the business intention information into the service delay of a certain workstation in a certain workshop, the network jitter of a certain workstation in a certain workshop, and the network jitter of a certain workstation in a certain workshop. Terminal failure and other handling statements.

In addition, the intent sensor 110 can also obtain service monitoring faults in real time and automatically sense the service intent information of the service monitoring faults. It can be understood that in a campus scenario, the possible business intentions expressed by users in business statements can be enumerated, and there are no specific restrictions here.

The intention translator 120 is one of the core components of the fault processing device. The intention translator 120 can receive the business intention information from the intention sensor 110, standardize the business intention information, and obtain the fault diagnosis scenario and fault The processing priority of diagnostic scenarios. For example, assuming that the target terminal is a campus terminal that has experienced a service failure, its business intent information is input into the intent translator 120. The intent translator 120 performs standardized sentence processing on the business intent information to obtain the network attribute information of the campus terminal. According to the network attribute information, The first target network device, then the intent translator 120 obtains the current network topology information and static network topology information of the campus terminal, and performs correlation analysis on the static network topology information and the current network topology information to obtain multiple The second target network device the device is associated with. In addition, the intent translator 120 can also dynamically query the current operation and maintenance data information (such as network characteristic data information, alarm data information, performance data information of related equipment, etc.) in real time, thereby intuitively obtaining the information corresponding to the business fault. Fault diagnosis scenarios (such as equipment failure), or the current operation and maintenance data information can also be input into the similarity model from the knowledge manager 130, and then translated to obtain multiple fault diagnosis scenarios and the processing priorities of the fault diagnosis scenarios, where , the fault causes of multiple fault diagnosis scenarios may be different. It can be understood that when the fault diagnosis scenario is a professional operation and maintenance fault diagnosis scenario, the business intention information and the fault diagnosis scenario can be sent to the professional operation and maintenance system.

The knowledge manager 130 can be used to save and provide the knowledge and experience required by the fault handling device, such as unified processing statements expressing business intent (that is, processing statements that perform standardized statement processing on business intent information), historical operation and maintenance data information , historical business data information, result information after business intention information conversion (such as network attribute information), processing priority of fault diagnosis scenarios, information related to business intention information such as typical faults and indicator degradation, for example, video in a certain area Monitor the bandwidth fault information, corresponding network equipment, fault diagnosis scenario information and other information related to the business intention information of the service guarantee; another example is the delay fault information that is strongly related to the business intention information of the automatic assembly service guarantee of a certain station in a certain workshop, etc. . The knowledge manager 130 can also be used to store different fault diagnosis scenarios under the professional operation and maintenance system (such as fault diagnosis scenarios of possible causes of equipment failure or indicator degradation), as well as fault diagnosis instructions, etc. In addition, the business operation and maintenance system (or professional operation and maintenance system) can inject historical business data information and historical operation and maintenance data information of the business operation and maintenance system (or professional operation and maintenance system) into the knowledge manager 130, and use the knowledge manager 130 to Historical business data and historical operation and maintenance data are used for training to obtain a similarity model.

It is worth noting that the formation and interface of the database, knowledge base or operation and maintenance knowledge graph in the knowledge manager 130 are very important in an intelligent fault diagnosis system.

The delimitation locator 150 may be used to provide automated diagnosis capabilities for one or more fault diagnosis scenarios output by the intent translator 120 (such as network device failure or network performance index degradation and other fault diagnosis scenarios). The delimitation locator 150 obtains fault diagnosis instructions for fault diagnosis scenarios such as network equipment failure or network performance index degradation from the knowledge manager 130, and performs fault processing on the fault diagnosis scenarios from the intent translator 120 according to the fault diagnosis instructions. Taking the fault processing device installed in the business operation and maintenance system as an example, if the fault diagnosis scenario is a business operation and maintenance fault diagnosis scenario, that is, when the fault diagnosis scenario can be delimited and positioned in the business operation and maintenance system, the delimitation locator 150 starts from Fault diagnosis instructions are obtained in the knowledge manager 130, and fault diagnosis scenarios are performed according to the fault diagnosis instructions; when the fault diagnosis scenario is a professional operation and maintenance fault diagnosis scenario, that is, the fault diagnosis scenario can be defined and positioned in the professional operation and maintenance system. , the fault switcher 140 needs to be called, and the business intention information and fault diagnosis scenario are forwarded to the professional operation and maintenance system through the fault switcher 140, and the professional operation and maintenance system performs fault processing on the fault diagnosis scenario.

It is worth noting that whether it is the delimitation locator 150 of the business operation and maintenance system or the delimitation locator 150 of the professional operation and maintenance system, the fault location involves complex diagnostic processes such as fault diagnosis tree, repeated diagnosis, multi-step diagnosis, delay Diagnosis etc.

The fault transferor 140 is used to transfer the business intention information and fault diagnosis scenarios to the professional operation and maintenance system or the business operation and maintenance system, so that the professional operation and maintenance system or the business operation and maintenance system can perform fault processing on the fault diagnosis scene (i.e., perform fault diagnosis on the fault diagnosis scene). analysis, fault diagnosis and fault self-healing), and receive fault reports from professional operation and maintenance systems or business operation and maintenance systems. Troubleshooting results of diagnostic scenarios. For example, when the fault switch 140 is set in the business operation and maintenance system, and the fault diagnosis scenario is a professional operation and maintenance fault diagnosis scenario, then the fault switch 140 needs to transfer the business intention information and fault diagnosis scenario to the professional operation and maintenance system, and then receive The professional operation and maintenance system obtains the fault processing result based on the business intention information and the fault diagnosis scenario; conversely, when the fault switch 140 is set in the professional operation and maintenance system, and the fault diagnosis scenario is a professional operation and maintenance fault diagnosis scenario, then the fault switch 140 needs to The business intent information and fault diagnosis scenarios can be transferred to the business operation and maintenance system. Afterwards, the receiving business operation and maintenance system obtains the fault processing results based on the business intent information and fault diagnosis scenarios. There are no specific restrictions here.

The intent verifier 160 is used to evaluate the fault processing result of the delimitation locator 150, that is, to evaluate the fault processing result of the fault diagnosis scenario to obtain the evaluation result. Finally, the intent verifier 160 also updates the evaluation results to the knowledge manager 130 to continuously optimize and improve the accuracy of the intent translation.

In one embodiment, when the network status recovers, the service returns to normal and user perception recovers, the evaluation result is that the fault processing is effective, and the fault processing process can be closed in a closed loop; when the network status cannot be restored or the service status cannot be restored, the evaluation result It means that the fault diagnosis scenario has not been repaired, so it needs to be transferred to manual processing, or the fault processing device can re-obtain the business intent information and standardize the business intent information again.

It can be understood that the fault handling device can be deployed in the business operation and maintenance system or in the professional operation and maintenance system, and can also be set up in the business operation and maintenance system and the professional operation and maintenance system. There is no specific restriction here.

The fault handling device and application scenarios described in the embodiments of the present application are for the purpose of explaining the technical solutions of the embodiments of the present application more clearly, and do not constitute a limitation on the technical solutions provided by the embodiments of the present application. Those skilled in the art will know that with the failure With the evolution of processing devices, business operation and maintenance systems, or professional operation and maintenance systems and the emergence of new application scenarios, the technical solutions provided by the embodiments of this application are also applicable to similar technical problems.

Those skilled in the art can understand that the fault processing device shown in Figure 1 does not limit the embodiments of the present application, and may include more or less components than shown, or combine certain components, or use different Component placement.

Based on the above fault handling device, the embodiments of the present application will be further described below in conjunction with the accompanying drawings.

Referring to Figure 2, Figure 2 is a flow chart of a fault processing method provided by an embodiment of the present application. The fault processing method can be applied to a fault processing device, such as the fault processing device shown in Figure 1, and the fault processing device can be provided in in the business operation and maintenance system. The fault handling method may include but is not limited to step S110, step S120 and step S130.

Step S110: Obtain business intent information.

In a feasible implementation manner, the business intention information may be delay intention information or other business intention information, which will not be listed here.

Step S120: Standardize the business intent information to obtain the fault diagnosis scenario and the processing priority of the fault diagnosis scenario.

In a feasible implementation, there may be multiple fault diagnosis scenarios, and the multiple fault diagnosis scenarios may be different, where the fault diagnosis scenarios may include alarm diagnosis scenarios and performance diagnosis scenarios.

Step S130: Perform fault processing on the fault diagnosis scenario according to the processing priority.

In this embodiment, by adopting the fault processing method including the above-mentioned steps S110 to S130, the business intention information can first be obtained, and then the business intention information can be standardized to obtain the fault diagnosis scenario and the processing priority of the fault diagnosis scenario. Finally, Troubleshooting fault diagnosis scenarios according to processing priority, that is, through standardized processing of business intent information, accurately locate the target network device and its fault diagnosis scenario, and be able to perform fault processing on the fault diagnosis scenario according to processing priority, Improved fault handling efficiency, therefore, the embodiment of the present application can accurately determine fault, and at the same time can improve the efficiency of fault handling.

It is worth noting that in related technologies, operation and maintenance operators or users can express desired business intentions to the intent recognition model, and perform fault analysis, fault diagnosis and fault self-healing on network faults through the intent recognition model. However, the intent identification model often relies on network data such as the topology of the entire network, network configuration tasks, or policies. Therefore, the execution and verification process of the business intent usually requires additional network overhead and resource overhead. And because, in the business operation and maintenance system, due to resource limitations and network characteristics, there is no complete network data, and in the actual system operation, the enterprise network topology often changes, therefore, it will not be possible to control the business operation and maintenance system. Enterprise business failures can be quickly and automatically handled.

In addition, because the 5G communication network provides the core capabilities of basic information channels in ToB applications, enterprises are more concerned about how to rely on the 5G network to carry out various business production activities. However, for specific network failures, enterprise operation and maintenance personnel cannot Handle it professionally. Therefore, how to manage and maintain network faults from a business perspective is an urgent problem to be solved. Among them, ToB is to use the enterprise as the service subject in the enterprise business to provide platforms, products or services to enterprise customers. business model, therefore, this ToB is also called enterprise service.

Based on the above analysis, in one embodiment, as shown in FIG. 3 , step S120 is further described. Step S120 may include but is not limited to step S210, step S220, and step S230.

Step S210: Perform standardized sentence processing on the service intent information to obtain network attribute information of the target terminal.

In a feasible implementation, the network attribute information may include physical location information, card number information, etc., which are not specifically limited here.

A feasible implementation method is that the target terminal (such as a park terminal) is a work station in the park with a built-in number card, a gantry crane, an industrial camera or an AGV (Automated Guided Vehicle) car, etc. And all target terminals have a common feature, that is, they are registered to the 5G private network through a number card, and the network automatically controls them to perform automated operations or automated monitoring. There are no specific restrictions here.

Step S220: Obtain the static network topology information of the target terminal and the current network topology information of the target terminal, and obtain multiple candidate network devices based on the network attribute information, static network topology information, and current network topology information.

In a feasible implementation, the static network topology information includes a static physical network topology and a static logical network topology. The static physical network topology includes the longitude of the static network topology and the latitude of the static network topology. The static logical network topology includes the information related to the target terminal. Logical links between various network devices, etc. Similarly, the current network topology information includes the current physical network topology and the current logical network topology. The current physical network topology includes the physical location topology information, the longitude of the current network topology, the latitude of the current network topology, etc., and the current logical network topology includes information related to the target. The logical links between various network devices related to the terminal are not specifically limited here.

In a feasible implementation, candidate network equipment may be CPE (Customer Premise Equipment, customer terminal equipment) required to form a 5G (5th Generation, fifth generation mobile communication system) private network, or it may be communication equipment such as base stations. There are no specific restrictions on this.

Step S230: Determine the current operation and maintenance data information of each candidate network device, and obtain the fault diagnosis scenario and the processing priority of the fault diagnosis scenario based on the current operation and maintenance data information.

In a feasible implementation, the current operation and maintenance data information includes alarm data information, performance data information and other operation and maintenance data information. The alarm data information can be delay alarm information, out-of-service alarm information and other alarm information. Performance data information It can be latency performance data, etc., which are not listed here. For example, assuming that the candidate network device is a base station, when there is base station out-of-service alarm information in the base station, the alarm diagnosis scenario of the out-of-service alarm is obtained based on the base station out-of-service alarm information. And the processing priority of this alarm diagnosis scenario is the highest; for another example, when the end-to-end user perception indicator data of the internal network of the candidate network device is deteriorated, that is, the performance data information is the end-to-end user perception indicator data of the internal network. According to this The performance data information is obtained from the performance diagnosis scenario, that is, the device parameter configuration check, which is not specifically limited in this embodiment.

In one embodiment, the current operation and maintenance data information and business intent information can be input into the similarity model to obtain the fault diagnosis scenario and the processing priority of the fault diagnosis scenario. Among them, the similarity model can be obtained by obtaining historical operation and maintenance data information and historical business data information, and then training the historical operation and maintenance data information and historical business data information.

In one embodiment, similarity calculation can be performed on the current operation and maintenance data information and the business intention information to obtain the fault diagnosis scenario and the processing priority of the fault diagnosis scenario, wherein the Euclidean distance, cosine similarity algorithm, Manhattan distance or Similarity algorithms such as Chebyshev distance perform similarity calculations on current operation and maintenance data information and business intent information, and there are no specific restrictions here.

It can be understood that the current operation and maintenance data information and business intention information can be input into the similarity model to obtain the fault diagnosis scenario and the processing priority of the fault diagnosis scenario. That is to say, the current operation and maintenance data information and the processing priority of the fault diagnosis scenario can be obtained through the similarity model. The business intent information is used for similarity calculation. Therefore, the fault diagnosis scenario is the diagnostic scenario corresponding to the current operation and maintenance data information that is relevant to the business intent information, and the processing priority of the fault diagnosis scenario is the diagnostic scenario corresponding to the fault diagnosis scenario. The correlation sorting between the current operation and maintenance data information and the business intention information, where the correlation sorting is the sorting from high to low relevance, which can be determined according to the actual fault diagnosis scenario, and is not specifically limited here.

For example, assuming that there are a large number and variety of alarm data information in the candidate network equipment, all the alarm data information and business intent information can be input into the similarity model, that is, the alarm data information can be analyzed through the similarity model. Similarity calculation is performed with the business intent information to obtain multiple alarm diagnosis scenarios and the processing priority of each alarm diagnosis scenario, that is, the correlation order between the causes of multiple alarms and the causes of each alarm and the business intent information. Then, fault processing can be performed on each alarm generating cause in sequence according to the correlation sorting (ie, processing priority), or a part of the alarm generating causes can be selected for fault processing according to the correlation sorting, which is not specifically limited here.

As an example, assume that the business intent information is delay intent, and the current operation and maintenance data information includes alarm data information and performance data information, where the alarm data information is end-to-end device fault information, and the performance data information is delay performance data. According to the correlation sorting between the current operation and maintenance data information and the business intention information, it can be seen that the performance diagnosis scenario corresponding to the delay performance data has the highest processing priority, and the performance diagnosis scenario corresponding to the end-to-end device fault information has the second highest processing priority. Therefore, , fault processing can be performed on the performance diagnosis scenarios corresponding to the delay performance data and the performance diagnosis scenarios corresponding to the end-to-end device fault information in sequence according to the processing priority, and there are no specific restrictions here.

In another embodiment, when the current operation and maintenance data information (such as alarm data information and performance data information) of each candidate network device is normal, the historical business data information of each candidate network device can be obtained, and the historical business data information and current operation data information can be obtained. Perform correlation analysis on dimensional data information to obtain fault diagnosis scenarios and processing priorities of fault diagnosis scenarios. Correlation analysis can be performed by calculating the similarity between historical business data information and current operation and maintenance data information. For example, assuming that the alarm data and performance data of each candidate network device are normal, the intent translator can obtain the historical business data of each candidate network device, perform correlation analysis on the historical business data and current operation and maintenance data, and determine Whether the increase in other business volumes preempting network resources has caused the network performance indicators of this business to fail to meet standards. Therefore, we can obtain the possible reasons for the degradation of key indicators of the candidate network equipment (i.e., performance diagnosis scenarios) and the possible reasons for the degradation of the key indicators and business data. The information is sorted by relevance (i.e., the processing priority of the performance diagnosis scenario), and then the possible causes of the degradation of the key indicators are sequentially processed based on the relevance sorting. There are no specific restrictions here.

In this embodiment, by adopting the fault handling method including the above steps S210 to S230, first, it is possible to Perform standardized statement processing on the business intent information to obtain the network attribute information of the target terminal, and then obtain the static network topology information of the target terminal and the current network topology information of the target terminal. Based on the network attribute information, static network topology information, and current network topology information, Obtain multiple candidate network devices, and finally determine the current operation and maintenance data information of each candidate network device. Based on the current operation and maintenance data information, obtain the fault diagnosis scenario and the processing priority of the fault diagnosis scenario. That is to say, in the enterprise's business operation and maintenance system Even if the enterprise network topology changes, the current network topology information can be obtained in real time, multiple candidate network devices can be determined based on network attribute information, static network topology information and current network topology information, and fault diagnosis can be performed on each candidate network device. This facilitates troubleshooting in fault diagnosis scenarios in subsequent steps. Therefore, the embodiments of the present application can quickly and automatically handle enterprise business faults when the network topology changes from a business perspective.

In one embodiment, as shown in FIG. 4 , step S220 is further described. This step S220 may include but is not limited to step S310, step S320 and step S330.

Step S310: Obtain the first target network device according to the network attribute information.

In a feasible implementation, the first target network device is a network device registered by the target terminal. The number of the first target network devices may be multiple, and there is no specific limitation here.

Step S320: Perform correlation analysis on the static network topology information and the current network topology information to obtain a plurality of second target network devices associated with the first target network device.

In a possible implementation, the second target network device may be a network device registered with the first target network device, or a network device accessed by the first target network device, or a network device with other associated relationships with the first target network device. , no specific restrictions are made here.

In a feasible implementation, the static network topology information may be physical location topology information, etc., which will not be listed here.

Step S330: Use the first target network device and the plurality of second target network devices as candidate network devices.

In a feasible implementation, the first target network equipment, the second target network equipment and the candidate network equipment may all be CPE (Customer Premise Equipment, customer) required to form a 5G (5th Generation, fifth generation mobile communication system) private network. Terminal equipment), or communication equipment such as base stations, which are not specifically limited here.

In this embodiment, by adopting the fault handling method including the above steps S310 to S330, the first target network device can be obtained according to the network attribute information, and then the static network topology information and the current network topology information are correlated and analyzed to obtain A plurality of second target network devices associated with the first target network device use the first target network device and the second target network device as candidate network devices, so that the service fault can be accurately delimited in subsequent steps.

In one embodiment, when the fault diagnosis scenario is a business operation and maintenance fault diagnosis scenario, fault diagnosis instructions are obtained, and fault processing is performed on the fault diagnosis scenario according to the fault diagnosis instructions and processing priority. If the fault diagnosis scenario is a business operation and maintenance fault diagnosis scenario, that is, when the fault diagnosis scenario can be delimited and located in the business operation and maintenance system, the delimitation locator can obtain fault diagnosis instructions from the knowledge manager, and the business operation and maintenance system The fault diagnosis instruction is received, and fault processing is performed on the fault diagnosis scenario according to the fault diagnosis instruction and processing priority. This embodiment of the present application does not impose specific limitations on this.

It can be understood that the business operation and maintenance fault diagnosis scenario is the fault diagnosis scenario that the business operation and maintenance system can diagnose. For example, the end-to-end delay performance data corresponds to the performance diagnosis scenario for delays caused by misconfiguration of connection service parameters. Therefore, the business operation and maintenance system only needs to modify the parameters to complete the troubleshooting of this fault diagnosis scenario. No need to Call professional operation and maintenance system.

In another embodiment, as shown in FIG. 5 , the fault handling method may also include but is not limited to step S410 and step S420.

Step S410: When the fault diagnosis scenario is a professional operation and maintenance fault diagnosis scenario, send the business intention information and the fault diagnosis scenario to the professional operation and maintenance system.

It can be understood that professional operation and maintenance fault diagnosis scenarios are fault diagnosis scenarios that need to be transferred to the professional operation and maintenance system for delimitation and positioning, such as faults that the business operation and maintenance system fails to locate or that require professional operation and maintenance system processing. For example, when the current operation and maintenance data information is base station out-of-service alarm information, the fault diagnosis scenario corresponding to the base station out-of-service alarm information is a professional operation and maintenance fault diagnosis scenario. Therefore, it is necessary to use the fault switch to combine the business intention information and the fault diagnosis scenario. Transfer it to the professional operation and maintenance system for processing, and use the mature delimitation and positioning capabilities of the professional operation and maintenance system to perform fault analysis, fault diagnosis and fault self-healing.

Step S420: Receive the fault processing results from the professional operation and maintenance system. The fault processing results are obtained by the professional operation and maintenance system based on the business intent information and fault diagnosis scenarios.

In this embodiment, by adopting the fault handling method including the above steps S410 to S420, when the fault diagnosis scenario is a professional operation and maintenance fault diagnosis scenario, the fault switcher in the business operation and maintenance system can automatically combine the business intention information with The fault diagnosis scenario is sent to the professional operation and maintenance system, and then the business operation and maintenance system can receive the fault processing results obtained by the professional operation and maintenance system based on the business intention information and the fault diagnosis scenario. Therefore, this embodiment can combine the business operation and maintenance system and the professional operation and maintenance system. The system is associated with the maintenance system, and the automation technology and the professional technology of the professional operation and maintenance system are used to delimit and locate the fault, thereby improving the automated processing capabilities of business faults.

In an embodiment, as shown in Figure 6, the fault handling method may also include but is not limited to step S510 and step S520.

Step S510: Determine the fault processing results of the fault diagnosis scenario, perform evaluation processing on the fault processing results, and obtain the evaluation results.

In one embodiment, the fault processing results of the fault diagnosis scenario by the business operation and maintenance system or the fault processing results of the fault diagnosis scenario by the professional operation and maintenance system can be input into the intent verifier, and the intent verifier passes the business fault recovery situation and manual feedback In this case, the fault processing result is evaluated and processed to obtain the evaluation result. Therefore, this embodiment can determine the validity and accuracy of the fault processing result through the evaluation result.

It is understandable that recovery of network status does not necessarily mean recovery of business failure. Therefore, manual or business monitoring is required to determine whether the current business failure has been recovered. If the business fault is restored, that is, the network status is restored and user perception is restored, the intent verifier evaluates that the network fault processing based on the business intent information is effective; if the fault diagnosis scenario is not repaired, that is, the intent verifier evaluates that the fault processing cannot be resolved. If there is a problem, the next business fault diagnosis is required, or further manual intervention is required.

Step S520: When the evaluation result indicates that the fault diagnosis scenario has not been repaired, re-obtain the business intent information.

In this embodiment, by adopting the fault processing method including the above steps S510 to S520, it is possible to determine the fault processing results of the fault diagnosis scenario, evaluate the fault processing results, and obtain the evaluation results. When the evaluation results represent the fault diagnosis The scenario has not been repaired, and the business intent information is reacquired, that is, the business intent information is re-standardized to obtain the fault diagnosis scenario and the processing priority of the fault diagnosis scenario, and the fault diagnosis scenario is fault processed according to the processing priority. The embodiment does not specifically limit this.

In another embodiment, when the evaluation result indicates that the fault diagnosis scenario has not been repaired, the service fault corresponding to the business intent information can be processed through manual intervention. This embodiment does not impose specific restrictions on this.

In an embodiment, the evaluation results, business intent information, and fault diagnosis scenarios may be stored. Assessment results, business intent information, and troubleshooting scenarios can be updated together to the knowledge manager. In addition, for the intent validator to evaluate effective network fault handling based on business intent information, the processing priority of its fault diagnosis scenario can be updated to the knowledge management In the processor; for network fault handling based on business intent information where the intent verifier evaluation is invalid, the business intent information and fault diagnosis scenarios can be optimized. For example, when the evaluation results indicate that the fault diagnosis scenario has not been repaired, the knowledge management can be optimized fault diagnosis scenarios for this service in the device to continuously improve the automated processing capabilities and intelligent processing capabilities of this fault handling device. Finally, manual confirmation of the information in the automatically updated knowledge manager is performed, and closed-loop feedback of the fault handling results is performed to iteratively optimize the accuracy of the information in the knowledge manager.

The fault handling method provided by the above embodiment is described in detail below with examples:

Example one:

Referring to Figures 7 and 8, in one embodiment, assuming that the fault handling device 100 is deployed in the business operation and maintenance system 300, the intent sensor obtains the business intent information, and identifies the network quality corresponding to the business intent information according to the business intent information. Expectations, such as network quality expectations in terms of delay guarantee requirements and bandwidth guarantee requirements. Then, the intent translator will receive the business intent information from the intent sensor and translate the corresponding business issues through the business intent information, such as network equipment. Failure and network quality degradation, then the intent translator will obtain one or more fault diagnosis scenarios and the processing priority of the fault diagnosis scenario through the similarity model of the knowledge manager, and assign the processing priority of the fault diagnosis scenario and the fault diagnosis scenario to The priority is sent to the delimitation locator, which delimits and locates the fault diagnosis scene, and then determines whether the fault diagnosis scene needs to be processed by the professional operation and maintenance system 400. When the fault diagnosis scene is a professional operation and maintenance fault diagnosis scene, The delimitation locator sends the business intention information and fault diagnosis scenarios to the professional operation and maintenance system 400 through the fault forwarder, and uses the mature delimitation and locating capabilities of the professional operation and maintenance system 400 to perform fault analysis, fault diagnosis and fault self-healing. Finally, the fault processing results of the professional operation and maintenance system 400 are evaluated through the intent verifier to evaluate whether the business fault has been repaired. When the business returns to normal, that is, user perception is restored and the network status is restored, the evaluation results of the evaluation process represent the results of the evaluation based on Network troubleshooting of business intent information is effective. At the same time, the evaluation results are updated in the knowledge manager.

In some embodiments, referring to Figure 9, a scenario of automatic assembly of terminals at a certain station in a workshop is taken as an example, and this scenario has requirements for network assurance. The intent sensor will identify the network quality expectations corresponding to the business intent information based on the business intent information, such as network quality expectations in terms of delay guarantee requirements and bandwidth guarantee requirements. Then, the intent translator will receive the time information from the intent sensor. Delay intention information is used to translate the corresponding business problems through the delay intention information. When the current operation and maintenance data is performance data of degraded network quality, and the business failure caused by this performance data is the automatic assembly operation of a terminal at a certain station in a workshop If hysteresis occurs, that is, the business problem is network quality degradation, the possible causes of network quality degradation (ie, fault diagnosis scenarios) can be analyzed through the following intent translation process (ie, standardized processing of business intent information), namely:

Step 1: Obtain the card number information of the faulty workstation from the business operation and maintenance system 300 through the physical location information of a certain workshop and the physical location information of a certain workstation, that is, obtain the first target network device according to the network attribute information;

Step 2: Query the dynamic registration information of the faulty station based on the number card information, obtain the network device currently connected to the faulty station's number card (i.e., the second target network device) from the professional operation and maintenance system 400, and then obtain The longitude of the current network topology, the latitude of the current network topology and the physical location topology information of the faulty station (i.e. static network topology information), combine the longitude of the current network topology, the latitude of the current network topology and the physical location of the faulty station By inputting the topology information into the similarity model of the knowledge manager, candidate network device A and candidate network device B can be obtained, where candidate network device A and candidate network device B are both network devices that may fail;

Step 3: Query the delay alarm information and delay performance data (that is, the current operation and maintenance data information) of candidate network device A related to the delay intention information, and input the delay alarm information, delay performance data, and delay intention information into Similarity model performs correlation analysis on delay alarm information, delay performance data and delay intention information to obtain possible network faults, that is, assuming Equipment failure 1 and equipment failure 2; Similarly, perform similar query and analysis on candidate network equipment B to obtain the possible network failure, that is, equipment failure 3;

At this point, the translation of the delay intent information into multiple network faults on candidate network device A and multiple network faults on candidate network device B is completed, that is, the first phase of the intent translation process is completed;

Step 4. If in step 3, neither candidate network device A nor candidate network device B has delay alarm information and delay performance data corresponding to equipment failure 1, equipment failure 2, and equipment failure 3, that is, candidate network equipment A’s If the current operation and maintenance data information and the current operation and maintenance data information of candidate network device B are normal, then step 4 will be to compare the historical business data information and historical operation data of candidate network device A and candidate network device B registered on the business operation and maintenance system 300. Dimensional data information (i.e., historical alarm data information and other performance data information except delay performance data) are trained to obtain a similarity model, and the current operation and maintenance data information (i.e., current alarm data information and performance data information) and The business intent information is input into the similarity model, and the device fault C corresponding to candidate network device A is determined, and the device fault D corresponding to candidate network device B is determined, and the monitoring indicator E, monitoring indicator F and monitoring indicator G are determined to be degraded performance indicators. , and then it can be known from the knowledge manager that cause 1, cause 2, cause 3, cause 4 and cause 5 are different fault diagnosis scenarios, and cause 1, cause 2 and cause 4 are fault causes. The highest possibility (that is, the highest processing priority). At this point, the second stage of the intention translation process is completed.

Step 5: Call the professional operation and maintenance system 400 to perform fault analysis, fault diagnosis and fault self-healing capabilities for each fault diagnosis scenario, that is, according to the processing priority, equipment fault 1, device fault 2 and device fault 3 in step 3 are sequentially performed. Perform fault processing to obtain the fault processing result; or, according to the processing priority, perform fault processing on cause 1, cause 2, cause 3, cause 4, and cause 5 in step 4 in sequence, and obtain the fault processing result.

Step 6. If the professional operation and maintenance system 400 fault processing result is that equipment failure 1 caused a business failure of "the automatic assembly operation of a certain station terminal in a certain workshop is lagging behind", and equipment failure 1 has been repaired, then intent verification is required. The server verifies the business failure recovery situation and manual feedback to confirm that the business has returned to normal. In addition, if the business returns to normal, that is, the network status is restored and user perception is restored, the evaluation results, business intent information and fault diagnosis scenarios corresponding to this business failure will be updated to the knowledge manager; if the fault diagnosis scenario or the business has not been restored, If it is normal, the next business fault diagnosis needs to be performed, or further manual intervention is required.

It can be understood that in the above embodiment, the fault is delimited and located within the business operation and maintenance system 300 first. If the fault cannot be recovered, it is transferred to the professional operation and maintenance system 400 for processing.

Example two:

In one embodiment, as shown in Figure 10, the service intention information is the delay intention information of the factory park, and the delay guarantee service failure of the AGV car caused by the failure of the third base station is taken as an example. The target terminal AGV car moves from the first moving position of the positioning coordinates to the second moving position of the positioning coordinates through the connected business network (i.e., I5GC (Industry 5th-Generation Core, Industry 5G Core Network)). However, in order to meet the needs of safe production, the communication delay of the entire moving process of the AGV car needs to have relatively strict network guarantee requirements. For example, 99.999% of the delay is less than 10 milliseconds in one month. During this process, the network coverage will change due to distance and other factors. Therefore, the AGV car will switch to the network at least once to access the new network. In some embodiments, when the AGV car moves to the first moving position of the positioning coordinates, it accesses through the first target network device, that is, the second base station. When it moves to the second moving position of the positioning coordinates, it needs to switch networks. During the process of switching networks In this case, due to the failure of the third base station, the network can only be accessed through the weak coverage network equipment, that is, the fourth base station. However, in the long run, this scenario will not be able to guarantee the delay requirements. Therefore, the fault diagnosis scenario of the third base station needs to be handled through the following intent translation process (i.e., standardized processing of business intent information) to ensure delay requirements, namely:

Step 1: The intent sensor learns the business intent information of the business monitoring failure through the obtained business monitoring failure (that is, the key perception indicator of the delay in connecting the business monitoring becomes worse), that is, the AGV car moves from the first position of the positioning coordinate to the positioning coordinate. The delay in the second mobile position exceeds 10 milliseconds;

Step 2: The intent sensor transmits the business intent information of the business monitoring failure to the intent translator;

Step 3: The intent translator learns the card number information of the target terminal AGV car from the business intent information, and learns that the AGV car is currently at the second base station and the fourth base station based on the card number information and the current network topology information (i.e., real-time network data). Registered on the base station;

Step 4: The intent translator obtains the current operation and maintenance data information of the second base station and the current operation and maintenance data information of the fourth base station through the knowledge manager, where the current operation and maintenance data information of the second base station and the current operation and maintenance data information of the fourth base station are obtained. The dimension data information can be operation and maintenance data information such as alarm data information, performance data information, etc., to initially determine whether the second base station and the fourth base station are faulty. Finally, it is determined that the current operation and maintenance data information (such as alarm data information and performance data information) of each candidate network device is normal, that is, neither the second base station nor the fourth base station has failed, so there is no fault diagnosis scenario;

Step 5: Perform a similarity algorithm on the coordinate information of the AGV car, the coordinate information of the second base station and the coordinate information of the fourth base station to obtain the second target network device, that is, the third base station. Among them, the third base station is the most likely to cause the service Faulty network equipment;

Step 6: Determine the current operation and maintenance data information (such as alarm data information) of the third base station, and obtain the alarm diagnosis scenario of the out-of-service alarm of the third base station based on the current operation and maintenance data information;

Step 7: Send the alarm diagnosis scenario of the out-of-service alarm of the third base station to the professional operation and maintenance system. The professional operation and maintenance system will perform delimitation and positioning to ultimately ensure the fault recovery of the third base station, that is, to ensure that the AGV car is in the second station. Mobile locations can access the third base station with a greater probability, ultimately ensuring delay requirements.

It can be understood that through the above steps, that is, the first stage of the intent translation process, the candidate network equipment that has failed is obtained, the business intent information is translated into the alarm fault diagnosis scenario of the base station out-of-service alarm, and it is transferred to the professional operation and maintenance system for troubleshooting. process.

Example three:

Based on Example 2, in one embodiment, as shown in Figure 10, taking the AGV car movement scenario as an example, if the third base station of the network device does not fail, but when the AGV car applies for air interface resources from the third base station, Due to the shortage of air interface resources, resource allocation is not timely, resulting in increased latency; or, the AGV car registers with the fourth base station with weak coverage, resulting in increased latency.

In some embodiments, assuming the first-stage intent translation process in Example 2, it is difficult to accurately find a specific network device that causes a service failure, because the candidate network device associated with the connection service is the second base station, the third base station, and the third base station. Neither the base station nor the fourth base station is faulty, but the fifth base station may be faulty. However, correlation analysis shows that the physical location of the fifth base station is not within the connection service, that is, the failure of the fifth base station will not affect the connection service. Based on this, in this embodiment, the second stage of intent translation will combine the historical business data information and current operation and maintenance data information in the knowledge manager to analyze each candidate network device in turn, for example, the AGV car registered to The probability analysis of the third base station and the fourth base station shows that the number of times the AGV car is registered to the fourth base station increases; for another example, the number of other terminals registered on the third base station increases significantly, resulting in resource constraints. From this, the candidate network can be judged Failures caused by the equipment's third base station are most likely to cause delays. Further, by combining the current performance data information of the third base station, the performance diagnosis scenario of the third base station is obtained. Through the delimitation and positioning of the business operation and maintenance system and the delimitation and positioning of the professional operation and maintenance system, the diagnosis result of this scenario (i.e., performance Diagnosis scenario) is the delay caused by incorrect configuration parameters and insufficient air interface resources. For this, the solution is to dynamically adjust the configuration parameters or check the candidate network equipment. The third base station is expanded to ensure the delay requirements of this service.

It is understandable that the above three examples are network fault location and fault rectification from a business perspective. In addition, the two-stage intent translation design can be applied to network fault delineation and location in different industries and various campus scenarios. Especially in the digital transformation process of enterprise campuses, which use 5G private networks as new infrastructure, this fault handling device can realize automated and intelligent processing of overall network faults, thereby reducing reliance on manual processing and improving Improve fault handling efficiency and improve system robustness.

In addition, it is worth noting that the fault handling method includes the entire diagnosis process of ToB network faults, that is, from business fault intent identification, intent translation, delimitation and positioning (including transferring to a professional operation and maintenance system for fault delimitation and positioning) to business fault diagnosis remediation, and the entire process of intent verification, which improves user network perception and overall satisfaction. This fault handling method can be applied to enterprise campuses, that is, "digital campuses" or "smart mines" supported by communications, computing power, etc., which is conducive to rapid recovery of business and operation and maintenance faults in enterprise campuses; in addition, this fault handling method The method can also be applied to operator networks to facilitate rapid delineation and location of operation and maintenance faults, and is not specifically limited here.

In addition, referring to Figure 11, one embodiment of the present application also provides a fault handling device. The fault handling device 200 includes a memory 202, a processor 201, and a computer program stored in the memory 202 and executable on the processor 201. .

The processor 201 and the memory 202 may be connected through a bus or other means.

As a non-transitory computer-readable storage medium, the memory 202 can be used to store non-transitory software programs and non-transitory computer executable programs. In addition, the memory 202 may include high-speed random access memory and may also include non-transitory memory, such as at least one magnetic disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, the memory 202 may include memory located remotely relative to the processor 201, and these remote memories may be connected to the processor 201 through a network. Examples of the above-mentioned networks include but are not limited to the Internet, intranets, local area networks, mobile communication networks and combinations thereof.

It should be noted that the fault processing device 200 in this embodiment can be, for example, the fault processing device in the embodiment shown in Figure 1. These embodiments all belong to the same inventive concept, so these embodiments have the same implementation principles and The technical effects will not be detailed here.

The non-transitory software programs and instructions required to implement the fault handling method of the above embodiment are stored in the memory 202. When executed by the processor 201, the fault handling method in the above embodiment is executed, for example, the above described Figure 2 is executed. The method steps S110 to S130 in FIG. 3 , the method steps S210 to S230 in FIG. 3 , the method steps S310 to S330 in FIG. 4 , the method steps S410 to S420 in FIG. 5 , and the method steps S510 to S520 in FIG. 6 .

The device embodiments described above are only illustrative, and the units described as separate components may or may not be physically separate, that is, they may be located in one place, or they may be distributed to multiple network units. Some or all of the modules can be selected according to actual needs to achieve the purpose of the solution of this embodiment.

In addition, one embodiment of the present application also provides a computer-readable storage medium that stores computer-executable instructions, and the computer-executable instructions are executed by a processor or controller, for example, executing the above The method steps S110 to S130 in Fig. 2, the method steps S210 to S230 in Fig. 3, the method steps S310 to S330 in Fig. 4, the method steps S410 to S420 in Fig. 5 and the method steps S510 to S510 in Fig. 6 are described. S520.

In addition, an embodiment of the present application also provides a computer program product, including a computer program or computer instructions. The computer program or computer instructions are stored in a computer-readable storage medium. The processor of the computer device reads the computer program from the computer-readable storage medium. The computer program or computer instructions are obtained, and the processor executes the computer program or computer instructions, so that the computer device performs the fault handling method in the above embodiment, for example, performs the method step S110 in Figure 2 described above. to S130, method steps S210 to S230 in Figure 3, method steps S310 to S330 in Figure 4, method steps S410 to S420 in Figure 5, and method steps S510 to S520 in Figure 6.

Embodiments of this application include: obtaining business intent information; performing standardized processing on the business intent information to obtain the fault diagnosis scenario of the target network device and the processing priority of the fault diagnosis scenario; performing fault processing on the fault diagnosis scenario according to the processing priority, that is, That is to say, through the standardized processing of business intent information, the target network device and its fault diagnosis scenario can be accurately located, and the fault diagnosis scenario can be fault processed according to the processing priority, which improves the fault processing efficiency. Therefore, the embodiment of the present application can Accurately locate faults and improve fault handling efficiency.

Those of ordinary skill in the art can understand that all or some steps and systems in the methods disclosed above can be implemented as software, firmware, hardware, and appropriate combinations thereof. Some or all of the physical components may be implemented as software executed by a processor, such as a central processing unit, a digital signal processor, or a microprocessor, or as hardware, or as an integrated circuit, such as an application specific integrated circuit . Such software may be distributed on computer-readable media, which may include computer storage media (or non-transitory media) and communication media (or transitory media). As is known to those of ordinary skill in the art, the term computer storage media includes volatile and nonvolatile media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. removable, removable and non-removable media. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, Digital Versatile Disk (DVD) or other optical disk storage, magnetic cassettes, tapes, disk storage or other magnetic storage devices, or may Any other medium used to store the desired information and that can be accessed by a computer. Additionally, it is known to those of ordinary skill in the art that communication media typically embodies computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism, and may include any information delivery media .

Claims (12)

1. A troubleshooting method including:

   Obtain business intent information;

   Standardize the business intent information to obtain the fault diagnosis scenario and the processing priority of the fault diagnosis scenario;

   Perform fault processing on the fault diagnosis scenario according to the processing priority.
2. The fault handling method according to claim 1, wherein the standardized processing of the business intent information to obtain the fault diagnosis scenario and the processing priority of the fault diagnosis scenario includes:

   Perform standardized sentence processing on the business intent information to obtain the network attribute information of the target terminal;

   Obtain static network topology information of the target terminal and current network topology information of the target terminal, and obtain multiple candidate network devices based on the network attribute information, the static network topology information, and the current network topology information;

   The current operation and maintenance data information of each candidate network device is determined, and the fault diagnosis scenario and the processing priority of the fault diagnosis scenario are obtained according to the current operation and maintenance data information.
3. The fault processing method according to claim 2, wherein said obtaining the fault diagnosis scenario and the processing priority of the fault diagnosis scenario according to the current operation and maintenance data information includes:

   Input the current operation and maintenance data information and the business intention information into the similarity model to obtain the fault diagnosis scenario and the processing priority of the fault diagnosis scenario.
4. The fault handling method according to claim 3, wherein the similarity model is obtained through the following steps:

   Obtain historical operation and maintenance data information and historical business data information;

   The historical operation and maintenance data information and the historical business data information are trained to obtain the similarity model.
5. The fault processing method according to claim 2, wherein said obtaining the fault diagnosis scenario and the processing priority of the fault diagnosis scenario according to the current operation and maintenance data information includes:

   When the current operation and maintenance data information of each candidate network device is normal, obtain the historical business data information of each candidate network device, perform a correlation analysis on the historical business data information and the current operation and maintenance data information, and obtain The fault diagnosis scenario and the processing priority of the fault diagnosis scenario.
6. The fault handling method according to claim 2, wherein a plurality of candidate network devices are obtained based on the network attribute information, the static network topology information and the current network topology information, including:

   Obtain the first target network device according to the network attribute information;

   Perform correlation analysis on the static network topology information and the current network topology information to obtain a plurality of second target network devices associated with the first target network device;

   The first target network device and the plurality of second target network devices are used as the candidate network devices.
7. The fault processing method according to claim 1, wherein performing fault processing on the fault diagnosis scenario according to the processing priority includes:

   When the fault diagnosis scenario is a business operation and maintenance fault diagnosis scenario, a fault diagnosis instruction is obtained, and fault processing is performed on the fault diagnosis scenario according to the fault diagnosis instruction and the processing priority.
8. The fault handling method according to claim 1, wherein the fault handling method further includes:

   When the fault diagnosis scenario is a professional operation and maintenance fault diagnosis scenario, send the business intent information and the fault diagnosis scenario to the professional operation and maintenance system;

   Receive fault processing results from the professional operation and maintenance system, where the fault processing results are obtained by the professional operation and maintenance system based on the business intent information and the fault diagnosis scenario.
9. The fault handling method according to claim 1, wherein the fault handling method further includes:

   Determine the fault processing results of the fault diagnosis scenario, evaluate the fault processing results, and obtain the evaluation results;

   When the evaluation result indicates that the fault diagnosis scenario has not been repaired, the business intent information is reacquired.
10. The fault handling method according to claim 9, wherein the fault handling method further includes:

    The evaluation results, the business intent information and the fault diagnosis scenario are stored.
11. A fault handling device, including: a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements any one of claims 1 to 10. Troubleshooting methods described above.
12. A computer-readable storage medium stores computer-executable instructions, and the computer-executable instructions are used to execute the fault handling method described in any one of claims 1 to 10.