CN115834332A - Fault processing method, server and system - Google Patents

Abstract

The application provides a fault processing method, a server and a system. The method comprises the following steps: sending a data query request to a snapshot data server according to the acquired fault query request, so that the snapshot data server returns the data when querying that network element snapshot data and change logs corresponding to the identification of the user to be queried and the identification of the service to be queried exist according to the data query request; acquiring the current real-time data of the network element corresponding to the identifier of the user to be inquired from the network element corresponding to the identifier of the service to be inquired; analyzing and processing the obtained current real-time data of the network element, the network element snapshot data and the change log, obtaining fault information, and carrying the fault information in a fault query request response message for feedback processing. By the method, the fault information can be rapidly obtained and then fault processing can be carried out, the time for carrying out fault analysis on the fault service of the user to be inquired can be shortened, and the overall efficiency of fault processing is improved.

Description

Fault processing method, server and system

Technical Field

The present application relates to communications technologies, and in particular, to a fault handling method, a server, and a system.

Background

With the large-scale commercialization of 5G independent networking (5G standard, abbreviated as 5G SA), the mobile communication network architecture is further complicated. Under the existing complex network structure, if an operator receives a complaint that a user cannot use a service, professional workers are required to be sent to inquire and analyze the signed data of each network element related to the service of the user, and a corresponding solution is provided after a specific service fault point of the user is found out according to self experience.

However, in the current network structure, the network elements involved in the user service may belong to different providers, and need to log in different systems one by one for operation, which is inefficient in manual searching and troubleshooting.

Disclosure of Invention

The application provides a fault processing method, a server and a system, which are used for solving the technical problem that in the prior art, an experienced professional needs to log in different operating systems to check and the fault processing efficiency is low due to the fact that the user service has a fault according to the experience of the professional.

In a first aspect, the present application provides a fault handling method, including:

acquiring a fault query request, wherein the fault query request comprises an identifier of a user to be queried and an identifier of a service to be queried;

sending a data query request to a snapshot data server according to the fault query request, so that the snapshot data server queries whether network element snapshot data and change logs corresponding to the identifier of the user to be queried and the identifier of the service to be queried exist or not according to the data query request, and if yes, returning the network element snapshot data and the change logs corresponding to the identifier of the user to be queried and the identifier of the service to be queried;

acquiring the current real-time data of the network element corresponding to the identifier of the user to be inquired from the network element corresponding to the identifier of the service to be inquired;

analyzing and processing the current real-time data of the network element, the snapshot data of the network element and the change log, acquiring fault information, and carrying the fault information in a fault query request response message for feedback processing.

In a second aspect, the present application provides a fault handling method, including:

receiving a data query request sent by an application server, wherein the data query request comprises: the identification of the user to be inquired and the identification of the service to be inquired;

inquiring whether network element snapshot data and change logs corresponding to the identification of the user to be inquired and the identification of the service to be inquired exist or not according to the data inquiry request;

and if the network element snapshot data and the change log corresponding to the identifier of the user to be queried and the identifier of the service to be queried exist, sending the network element snapshot data and the change log to the application server, so that the application server performs fault analysis processing according to the obtained current real-time data of the network element corresponding to the identifier of the service to be queried, the network element snapshot data and the change log corresponding to the identifier of the service to be queried, obtaining fault information, and carrying the fault information in a fault query request response message for feedback processing.

The method further comprises the following steps:

when a service instruction is obtained, identifying the service instruction; the service instruction comprises a user identifier, a corresponding service identifier and service information;

when the service instruction is identified as a service change instruction, judging whether service information in the service change instruction meets the condition of capturing snapshot data or not by adopting a preset capturing model;

if the service information meets the condition of capturing snapshot data and the historical snapshot data record of the network element corresponding to the user identifier is not inquired, acquiring all network element snapshot data corresponding to the service identifier before the service identifier is changed, and recording a change log corresponding to the service processing according to the service change instruction;

or,

if the service information meets the condition of capturing snapshot data and a historical snapshot data record of a network element corresponding to the user identifier is found locally, network element snapshot data corresponding to the service identifier before the service corresponding to the service identifier is changed is obtained and updated, and a change log corresponding to service processing according to the service change instruction is recorded.

The method further comprises the following steps:

and if the service information does not meet the condition for capturing the snapshot data, recording a change log corresponding to service processing according to the service change instruction.

In a possible implementation manner, the determining, by using a preset capture model, whether the service information in the service change instruction meets a condition for capturing snapshot data includes:

acquiring a service result by adopting a preset capturing model according to a user grade corresponding to the user identifier in the service information, the complexity of a home network corresponding to the user identifier, the correlation between the service change instruction and a specific service, the utilization rate of network element performance resources related to the service identifier and the current time from the last time of capturing snapshot data corresponding to the user identifier;

if the service result is greater than or equal to a preset threshold value, the service information meets the condition of capturing snapshot data;

and if the service result is smaller than a preset threshold value, the service information does not meet the condition of capturing snapshot data.

In a possible implementation manner, the obtaining, by using a preset capture model, a service result according to a user level corresponding to the user identifier in the service information, complexity of a home network corresponding to the user identifier, a correlation between the service change instruction and a specific service, a network element performance resource usage rate related to the service identifier, and a current time from last time of capturing snapshot data corresponding to the user identifier includes:

according to a user level W corresponding to the user identifier in the service information, complexity X of a home network corresponding to the user identifier, correlation Y between the service change instruction and a specific service, a network element performance resource utilization rate Z related to the service identifier, and a current time t from last time of capturing snapshot data corresponding to the user identifier, adopting a formula in the preset capturing model:

E＝(α×W+β×X+γ×Y+δ×(1-Z)×10)×A(t)+B(t)

acquiring a service result E;

wherein A (t) and B (t) are both time adjustment coefficients; α, β, γ, δ are correlation coefficients, α + β + γ + δ =1.

In a third aspect, the present application provides an application server, comprising:

the first transceiver module is used for acquiring a fault query request, wherein the fault query request comprises an identifier of a user to be queried and an identifier of a service to be queried;

the first transceiver module is further configured to send a data query request to a snapshot data server according to the fault query request, so that the snapshot data server queries whether network element snapshot data and change logs corresponding to the identifier of the user to be queried and the identifier of the service to be queried exist according to the data query request, and if yes, returns the network element snapshot data and change logs corresponding to the identifier of the user to be queried and the identifier of the service to be queried;

the first transceiver module is further configured to acquire, from the network element corresponding to the identifier of the service to be queried, current real-time data of the network element corresponding to the identifier of the user to be queried;

and the fault processing module is used for analyzing and processing the current real-time data of the network element, the snapshot data of the network element and the change log, acquiring fault information and carrying the fault information in a fault query request response message for feedback processing.

In a fourth aspect, a snapshot data server includes:

a second transceiver module, configured to receive a data query request sent by an application server, where the data query request includes: the identification of the user to be inquired and the identification of the service to be inquired;

the query module is used for querying whether network element snapshot data and change logs corresponding to the identification of the user to be queried and the identification of the service to be queried exist or not according to the data query request;

and the second transceiver module is configured to send the network element snapshot data and the change log corresponding to the identifier of the user to be queried and the identifier of the service to be queried to the application server if the network element snapshot data and the change log exist, so that the application server performs fault analysis processing according to the network element current real-time data corresponding to the obtained identifier of the service to be queried, the network element snapshot data corresponding to the identifier of the service to be queried, and the change log, obtains fault information, and carries the fault information in a fault query request response message for feedback processing.

The snapshot data server further comprises:

the identification module is used for identifying the service instruction when the service instruction is obtained; the service instruction comprises a user identifier, a corresponding service identifier and service information;

the judging module is used for judging whether the service information in the service change instruction meets the condition of capturing snapshot data or not by adopting a preset capturing model when the service instruction is identified to be the service change instruction;

a snapshot data capturing module, configured to, if the service information satisfies the condition for capturing snapshot data and a historical snapshot data record of a network element corresponding to the user identifier is not queried, obtain all network element snapshot data corresponding to the service identifier before the service identifier is changed, and record a change log corresponding to service processing according to the service change instruction;

the snapshot data capturing module is further configured to, if the service information satisfies the condition for capturing snapshot data and a historical snapshot data record of a network element corresponding to the user identifier is found locally, obtain and update network element snapshot data corresponding to the service identifier before the service identifier corresponding to the service identifier is changed, and record a change log corresponding to service processing according to the service change instruction.

In addition, optionally, the snapshot data capturing module is further configured to record a change log corresponding to service processing according to the service change instruction if the service information does not satisfy the condition for capturing the snapshot data.

Optionally, the determining module is specifically configured to: acquiring a service result by adopting a preset capturing model according to a user grade corresponding to the user identifier in the service information, the complexity of a home network corresponding to the user identifier, the correlation between the service change instruction and a specific service, the utilization rate of network element performance resources related to the service identifier and the current time from the last time of capturing snapshot data corresponding to the user identifier;

if the service result is greater than or equal to a preset threshold value, the service information meets the condition of capturing snapshot data;

and if the service result is smaller than a preset threshold value, the service information does not meet the condition of capturing snapshot data.

Optionally, the determining module is specifically configured to: according to a user level W corresponding to the user identifier in the service information, a complexity X of a home network corresponding to the user identifier, a correlation Y between the service change instruction and a specific service, a network element performance resource utilization rate Z related to the service identifier, and a current time t from the last time of capturing snapshot data corresponding to the user identifier, a formula in the preset capturing model is adopted:

E＝(α×W+β×X+γ×Y+δ×(1-Z)×10)×A(t)+B(t)

acquiring a service result E;

wherein A (t) and B (t) are both time adjustment coefficients; α, β, γ, δ are correlation coefficients, α + β + γ + δ =1.

In a fifth aspect, the present application provides a fault handling system, comprising: a client, a network element, an application server according to the third aspect, and a snapshot data server according to the fourth aspect; wherein the snapshot data server is configured independently or integrally with the application server.

According to the fault processing method, the server and the system, the fault query request comprising the identification of the user to be queried and the identification of the service to be queried is obtained; sending a data query request to a snapshot data server according to the fault query request so as to enable the snapshot data server to query whether network element snapshot data and change logs corresponding to the identification of the user to be queried and the identification of the service to be queried exist or not according to the data query request, and if so, returning the network element snapshot data and the change logs corresponding to the identification of the user to be queried and the identification of the service to be queried; acquiring the current real-time data of the network element corresponding to the identifier of the user to be inquired from the network element corresponding to the identifier of the service to be inquired; analyzing and processing the obtained current real-time data of the network element, the network element snapshot data and the change log, obtaining fault information, and carrying the fault information in a fault query request response message for feedback processing. According to the method provided by the application, at the first time when a complaint of a user to be queried who has a fault is received, according to an obtained fault query request from a client side of a complaint processing center, the current real-time data of the network element corresponding to the identification of the user to be queried, the snapshot data of the network element corresponding to the identification of the user to be queried and the identification of a service to be queried and a change log are obtained, and fault information is obtained through rapid analysis of the obtained data to further perform fault processing, so that the time of analyzing the fault reason of the service to be queried can be effectively shortened, and the overall efficiency of fault processing is improved.

Drawings

In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings needed to be used in the description of the embodiments or the prior art will be briefly introduced below, and it is obvious that the drawings in the following description are some embodiments of the present application, and for those skilled in the art, other drawings can be obtained according to these drawings without inventive exercise.

Fig. 1 is a schematic flowchart of a first embodiment of a fault handling method provided in the present application;

fig. 2 is a schematic flowchart of a second embodiment of a fault handling method provided in the present application;

fig. 3 is a schematic flowchart of a third embodiment of a fault handling method provided in the present application;

fig. 4 is a schematic signaling flow diagram of a fourth embodiment of a fault handling method provided in the present application;

fig. 5 is a schematic structural diagram of an embodiment of an application server provided in the present application;

fig. 6 is a schematic structural diagram of an embodiment of a snapshot data server provided in the present application;

fig. 7 is a schematic structural diagram of an embodiment of a fault handling system provided in the present application.

Detailed Description

In order to make the objects, technical solutions and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are some embodiments of the present application, but not all embodiments. All other embodiments that can be made by one skilled in the art based on the embodiments in the present application in light of the present disclosure are within the scope of the present application.

The terms "first," "second," "third," "fourth," and the like in the description of the application and the above-described figures, if any, are used for distinguishing between similar elements and not necessarily for describing a particular sequential or chronological order. It should be understood that the data so used may be interchanged under appropriate circumstances such that embodiments of the application described herein may be implemented in sequences other than those illustrated or described herein. Furthermore, the terms "comprises," "comprising," and "having," and any variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, system, article, or apparatus that comprises a list of steps or elements is not necessarily limited to those steps or elements expressly listed, but may include other steps or elements not expressly listed or inherent to such process, method, article, or apparatus.

In the prior art, when an operator receives a complaint that a user cannot normally use a service, a professional network manager needs to be sent out to query network element subscription data corresponding to the user, and try to solve the problem after judging a fault reason according to experience. However, as the network structure is gradually complex, the network element devices related to one mobile network user may be supplied by different manufacturers, each network element has its own data query client, and network management personnel need to log in different clients to query and compare data of the failed user one by one when troubleshooting the failure cause, so as to find the failure cause. On the premise that the network management personnel in charge of investigation has a very strong professional background and is trained for a long time, the time of 10-15 minutes is still needed for inquiring and analyzing the data of one user. Therefore, in the prior art, the requirement on workers for troubleshooting of user service faults is high, the timeliness and the accuracy cannot be guaranteed, the automation degree is low, and the efficiency is low.

The technical idea of the application is as follows: how to enable an operator to quickly respond and quickly and accurately locate a fault reason when receiving a complaint that a user cannot use related services so as to improve the fault processing efficiency.

The technical solution of the present application will be described in detail below with reference to specific examples. It should be noted that the following specific embodiments may be combined with each other, and the same or similar concepts or processes may not be described in detail in some embodiments.

Fig. 1 is a schematic flowchart of a first embodiment of a fault handling method provided in the present application. Referring to fig. 1, the method includes:

step S101, a fault query request is obtained, wherein the fault query request comprises an identification of a user to be queried and an identification of a service to be queried.

In this embodiment, the fault query request is generally sent to the application server by a client of the operator complaint processing center when receiving a complaint that a user cannot use a certain service, where the fault query request includes an identifier of a user to be queried and an identifier of a service to be queried, where the identifier of the user to be queried may be a mobile phone number of the user, and the identifier of the service to be queried may be a service code corresponding to the service that the user cannot use in an operator database.

Step S102, according to the fault query request, sending a data query request to a snapshot data server, so that the snapshot data server queries whether network element snapshot data and change logs corresponding to the identifier of the user to be queried and the identifier of the service to be queried exist or not according to the data query request, and if yes, returning the network element snapshot data and the change logs corresponding to the identifier of the user to be queried and the identifier of the service to be queried.

In this embodiment, the application server first authenticates the acquired failure query request, and aims to authenticate the client initiating the failure query request, so as to prevent the client without permission from accessing the network element data of the user.

In this embodiment, the application server sends a data query request to the snapshot data server according to the identifier of the user to be queried and the identifier of the service to be queried, which are carried in the obtained fault query request, so that the snapshot data server queries whether there are network element snapshot data and change logs corresponding to the identifier of the user to be queried and the identifier of the service to be queried according to the data query request, and if so, returns the corresponding network element snapshot data and change logs to the application server. It should be noted that the network element snapshot data corresponding to the identifier of the user to be queried, which is stored in the snapshot data server, includes snapshot data of all network elements, but if the acquired fault query request only includes a certain service identifier of the user to be queried, only the network element snapshot data and change logs corresponding to the identifier of the user to be queried and the identifier of the service to be queried are acquired.

Step S103, obtaining the current real-time data of the network element corresponding to the identification of the user to be inquired from the network element corresponding to the identification of the service to be inquired.

In this embodiment, the service to be queried may be supported by one or more network elements on the operator side, and the current real-time data of the network element corresponding to the identifier of the user to be queried is obtained from the network elements corresponding to the identifier of the service to be queried. The network element current real-time data refers to the network element data after the service to be queried corresponding to the identifier of the user to be queried has been initiated a fault complaint by the user. And if the identification of the service to be inquired corresponds to a plurality of network elements, acquiring the current real-time data of the network element corresponding to the identification of the user to be inquired in a multithread synchronous acquisition mode, wherein the data acquisition time can be shortened to the second level.

And step S104, analyzing and processing the current real-time data, the network element snapshot data and the change log of the network element, acquiring fault information, and carrying the fault information in the fault query request response message for feedback processing.

In this embodiment, the obtained current real-time data of the network element and the corresponding snapshot data of the network element are compared and analyzed, a point with inconsistent data is positioned as a fault point, fault information is obtained according to the service change time recorded in the corresponding change log, the corresponding terminal identifier of the service change instruction and the execution result of the service change instruction, and the fault information is carried in the fault query request response message for feedback processing.

In this embodiment, according to a fault processing instruction which agrees to repair and is returned by the terminal corresponding to the identifier of the user to be queried based on the fault query request response message, a fault repair processing flow may be triggered, so that the application server performs fault repair processing according to a preset fault processing model. The fault processing model is obtained by taking historical fault information data and fault processing programs stored in an operator management platform as an input set and an output set of a training set and training a network model. Along with the accumulation of the failure processing times of the application server, each time of failure information data and failure processing programs can be added into a training set to iteratively train the failure processing model, so that the efficiency and the accuracy of the failure processing model are improved.

In the embodiment, a fault query request is obtained, wherein the fault query request comprises an identifier of a user to be queried and an identifier of a service to be queried; sending a data query request to a snapshot data server according to the fault query request so that the snapshot data server queries whether network element snapshot data and change logs corresponding to the identification of the user to be queried and the identification of the service to be queried exist or not according to the data query request, and if yes, returning the network element snapshot data and the change logs corresponding to the identification of the user to be queried and the identification of the service to be queried; acquiring the current real-time data of the network element corresponding to the identifier of the user to be inquired from the network element corresponding to the identifier of the service to be inquired; analyzing and processing the obtained current real-time data of the network element, the network element snapshot data and the change log, obtaining fault information, and carrying the fault information in a fault query request response message for feedback processing. By the method provided by the embodiment, the fault query request sent by the client of the complaint processing center can be obtained at the first time when complaints of the user to be queried are received, the current real-time data of the network element corresponding to the identifier of the user to be queried, the snapshot data of the network element corresponding to the identifier of the user to be queried and the identifier of the service to be queried and the change log are obtained after the authentication is passed, and the obtained data are rapidly analyzed to obtain the fault information for further fault processing. The time for analyzing the fault point of the fault service of the user to be inquired can be effectively shortened, and the overall efficiency of fault processing is improved.

Fig. 2 is a schematic flowchart of a second embodiment of a fault handling method provided in the present application. Referring to fig. 2, the method includes:

step S201, receiving a data query request sent by an application server, where the data query request includes: the method comprises the steps of identifying a user to be inquired and an identification of a service to be inquired;

step S202, inquiring whether network element snapshot data and change logs corresponding to the identification of the user to be inquired and the identification of the service to be inquired exist or not according to the data inquiry request;

step S203, if the information exists, the network element snapshot data and the change log corresponding to the identifier of the user to be queried and the identifier of the service to be queried are sent to the application server, so that the application server performs fault analysis processing according to the acquired current real-time data of the network element corresponding to the identifier of the service to be queried and the network element snapshot data and the change log corresponding to the identifier of the service to be queried, acquires fault information, and carries the fault information in the fault query request response message for feedback processing.

In this embodiment, after receiving a data query request sent by an application server, if there are network element snapshot data and change logs corresponding to an identifier of a user to be queried and an identifier of a service to be queried, the snapshot data server sends these data to the application server, so that the application server can perform fault analysis processing according to the network element current real-time data corresponding to the obtained identifier of the service to be queried, the network element snapshot data and the change logs corresponding to the identifier of the service to be queried, obtain fault information, and carry the fault information in a fault query request response message for feedback processing.

In this embodiment, the snapshot data server stores all the network element snapshot data corresponding to the identifier of the user to be queried, and the network element snapshot data stored in the snapshot data server is captured before the user performs the daily service change instruction, and is the network element snapshot data in which the service function corresponding to the identifier of the user to be queried is in the normal state.

In this embodiment, the network element snapshot data and the change log corresponding to the identifier of the user to be queried and the identifier of the service to be queried, which are stored in the snapshot data server, are sent to the application server, so that the application server analyzes and processes the fault service to be queried according to the network element snapshot data and the change log corresponding to the identifier of the user to be queried and the identifier of the service to be queried, which are acquired from the snapshot data server, and the network element current real-time data corresponding to the identifier of the user to be queried, which is acquired from the network element corresponding to the identifier of the service to be queried. The method provided by the embodiment can quickly respond when the user service fails, does not need to manually query one by one, and effectively improves the processing efficiency of the service failure.

Fig. 3 is a schematic flowchart of a third embodiment of a fault handling method provided in the present application. On the basis of the embodiment shown in fig. 2, referring to fig. 3, the method further includes:

step S301, when a service instruction is obtained, identifying the service instruction; the service instruction comprises a user identifier, a corresponding service identifier and service information.

In this embodiment, the snapshot data server may automatically obtain a service instruction sent by the mobile terminal or the business hall terminal in the daily service use process of the user. And identifying the type of the obtained service instruction. The type of the service instruction can be a service change instruction and a non-service change instruction. For example, the service change instruction may be an instruction for adding/deleting/modifying a familiarity number for the voice service corresponding to the user identifier, or handling a shutdown and number-saving service for an account corresponding to the user identifier, and the like, which changes the network element subscription data corresponding to the user identifier; the non-service change instruction may be a service instruction that pays a fee for an account corresponding to the user identifier, or queries a service corresponding to the user identifier, and the like, without affecting the network element subscription data corresponding to the user identifier.

Step S302, when the service instruction is identified as a service change instruction, a preset capturing model is adopted to judge whether the service information in the service change instruction meets the condition of capturing snapshot data.

In this embodiment, since the non-service change instruction does not affect the network element subscription data corresponding to the user identifier, if the service instruction is identified as the non-service instruction, snapshot data capture operation is not required. When the service instruction is identified as the service change instruction, in order to enable the snapshot data server to efficiently capture the necessary network element data snapshot and avoid overload of the server due to excessive captured snapshot data, the preset capture model is adopted to judge whether the service information in the service change instruction meets the condition of capturing the snapshot data when the service instruction is the service change instruction.

In a specific implementation manner, a specific method for judging whether service information in a service change instruction meets a condition for capturing snapshot data by using a preset capture model includes:

acquiring a service result by adopting a preset capturing model according to a user grade corresponding to a user identifier in service information, the complexity of a home network corresponding to the user identifier, the correlation between a service change instruction and a specific service, the utilization rate of network element performance resources related to the service identifier and the current time of the distance between the last time of capturing snapshot data corresponding to the user identifier and the current time; if the service result is greater than or equal to the preset threshold value, the service information meets the condition of capturing snapshot data; and if the service result is smaller than the preset threshold value, the service information does not meet the condition of capturing the snapshot data.

In a specific implementation manner, according to a user level W corresponding to a user identifier in service information, a complexity X of a home network corresponding to the user identifier, a correlation Y between a service change instruction and a specific service, a network element performance resource usage rate Z related to the service identifier, and a current time t from a last time of capturing snapshot data corresponding to the user identifier, a formula in a preset capturing model is adopted:

E＝(α×W+β×X+γ×Y+δ×(1-Z)×10)×A(t)+B(t)

and acquiring a service result E.

Wherein A (t) and B (t) are both time adjustment coefficients; α, β, γ, δ are correlation coefficients, α + β + γ + δ =1.

In this embodiment, the service information includes a user level W corresponding to the user identifier, a complexity X of a home network corresponding to the user identifier, a correlation Y between a service change instruction and a specific service, a network element performance resource usage rate Z related to the service identifier, and a current time t from a last time of capturing snapshot data corresponding to the user identifier.

In this embodiment, the user rank W corresponding to the user identifier may be marked according to the importance of the registered user. Optionally, the importance of the user may be the rating of the service management system of the operator based on the service life of the phone number to which the user identifier belongs, the current monthly package price, the historical monthly consumption amount, the government users/individual users, and other conditions. For example, the user identifier in the obtained service change instruction is used as a user mobile phone number for explanation, the user gets 2 points if the user belongs to a government-enterprise user, otherwise, the user does not get the points, and the corresponding service life, current monthly package price and historical monthly average consumption amount scores of the user mobile phone number can be obtained by querying according to the following table 1, table 2 and table 3. If the user belongs to a user of a government enterprise, the service life of the mobile phone number of the user is greater than 5 years, the package price in the current month is between 50 yuan and 200 yuan, and the consumption amount in the historical month is between 100 yuan and 300 yuan, the user level W corresponding to the user identifier can be marked as 2+4+ 1=8 cents.

TABLE 1, user mobile phone number service life corresponding score lookup table

Service life of user's mobile phone number	Score value
		Less than half a year	0
Half year to 1 year	1
		1 to 3 years	2
3 to 5 years old	3
		More than 5 years	4

Table 2, user mobile phone number monthly package price corresponding score inquiry table

Current monthly set price of user's mobile phone number	Score value
		Less than 50 yuan	0
50 yuan to 200 yuan	1
		Greater than 200 yuan	2

TABLE 3, historical monthly average consumption amount corresponding score lookup table for user mobile phone number

Historical monthly consumption amount of mobile phone number of user	Score value
		Less than 100 yuan	0
100 yuan to 300 yuan	1
		Greater than 300 yuan	2

In this embodiment, the complexity X of the home network corresponding to the user identifier included in the service information in the user service change instruction may also be marked by a score. For example, the label is 5 points if the home network corresponding to the subscriber identity is a 5G network, 5 points if the home network is a 4G network, and 0 points if the home network is a 2G/3G network.

In this embodiment, the correlation Y between the service change instruction and the specific service refers to the degree of influence of the service change instruction on the changed service. Illustratively, if the service change instruction is to turn off the voice function, the voice function of the user cannot be used after the change instruction is executed, the influence of the service change instruction on the voice service is decisive, and the relevance Y of the service change instruction to a specific service can be marked as 10 points; if the service change instruction is to cancel the familiarity number corresponding to the user identifier, after the service change instruction is executed, the service change instruction affects the voice service but the voice service corresponding to the user identifier can still be normally used, and at this time, the degree of correlation Y between the service change instruction and the specific service can be marked as 5.

In this embodiment, in order to ensure that the normal operation of each network element on the operator side is not affected by the processing of the fault, when determining whether the service information in the obtained service change instruction satisfies the condition of capturing snapshot data, the network element performance resource utilization rate Z related to the service identifier is also considered. The present resource utilization rate of the network element related to the service change instruction acquired by the snapshot data server represents the present processing capacity of the network element, and the data can be directly acquired from the network element related to the service change instruction, and the value is between 0% and 100%.

In this embodiment, a (t) and B (t) are both time adjustment coefficients, and exemplarily, for the same service change instruction: when t is more than or equal to 0 and less than or equal to 6h, A (t) and B (t) can be 0, which means that network element snapshot data corresponding to the same service change instruction cannot be frequently captured in a short time; when t is more than 6h and less than or equal to 24h, A (t) can be 0.1, B (t) can be 0, meaning that whether the network element snapshot data between 6h and 24h needs to be captured depends on a specific calculation value of a preset capture model, and B (t) does not interfere with the calculation result; and when t is greater than 24h, B (t) can be 1, which means that if the capture interval exceeds 24h, the network element corresponding to the service change instruction is used for capturing the data snapshot regardless of the scores of the indexes.

In this embodiment, according to the formula in the preset capture model:

E＝(α×W+β×X+γ×Y+δ×(1-Z)×10)×A(t)+B(t)

α+β+γ+δ＝1

acquiring a service result E, and if the E is greater than or equal to a preset threshold value, determining that service information in the acquired service change instruction meets the condition of capturing snapshot data; and if the E is smaller than the preset threshold value, the service information in the service change instruction is considered to not meet the condition of capturing snapshot data. Alternatively, the preset threshold may be 0.8. Alpha, beta, gamma and delta are respectively a user grade W corresponding to a user identifier, a complexity X of a home network corresponding to the user identifier, a correlation Y between a service change instruction and a specific service, and a correlation coefficient of a network element performance resource utilization rate Z related to the service identifier, and can be adjusted according to historical data of different operation areas to which the user to be inquired belongs and the importance degree of each index in the overall index, so that alpha + beta + gamma + delta =1.

Step S303, if the service information meets the condition of capturing snapshot data and the historical snapshot data record of the network element corresponding to the locally existing user identifier is not inquired, acquiring all network element snapshot data corresponding to the user identifier before the service corresponding to the service identifier is changed, and recording a change log corresponding to the service processing according to the service change instruction.

In this embodiment, if E is greater than or equal to the preset threshold and the history snapshot data record of the network element corresponding to the user identifier is not queried, that is, the snapshot data server has never performed a capture operation on the network element data corresponding to the user identifier, at this time, all network element snapshot data corresponding to the service identifier before the service is changed should be obtained, and a change log corresponding to the service processing according to the service change instruction is recorded.

In this embodiment, the change log includes: the snapshot data change record and change time of the network element corresponding to the user identifier, the service identifier carried by the service change instruction, and the change time and result corresponding to the service change instruction.

In this embodiment, a service change instruction is obtained and recognized, and whether a condition for capturing snapshot data is satisfied is determined according to a preset capture model by using a user level corresponding to a user identifier in service information included in the service change instruction, a complexity of a home network corresponding to the user identifier, a correlation between the service change instruction and a specific service, a network element performance resource utilization rate related to the service identifier, and a current time from a last time of capturing snapshot data corresponding to the user identifier, and a change log corresponding to service processing performed by the service change instruction is recorded. By the method provided by the embodiment, the user grade corresponding to the user identifier, the complexity of the home network corresponding to the user identifier, the correlation between the service change instruction and the specific service, the utilization rate of the network element performance resource related to the service identifier and the current time from the last time of capturing the snapshot data corresponding to the user identifier are taken into consideration comprehensively when the network element snapshot data is captured daily, so that the capturing of the network element snapshot data is more scientific and practical, the normal operation of the network element at the side of an operator is effectively ensured, and the fault processing efficiency is improved.

In addition, another specific implementation manner of step S303 is:

and if the service information meets the condition of capturing snapshot data and the historical snapshot data record of the network element corresponding to the locally-existing user identifier is inquired, acquiring and updating the network element snapshot data corresponding to the service identifier before the service is changed, and recording a change log corresponding to the service processing according to the service change instruction.

In this embodiment, if E is greater than or equal to the preset threshold, that is, the service information meets the condition of capturing snapshot data, and a historical snapshot data record of a network element corresponding to a locally-existing user identifier is queried, since all network element data snapshots corresponding to the user identifier are captured when the network element data snapshot is captured for the first time for the same user identifier, if the historical snapshot data record of the network element corresponding to the user identifier exists locally, only the network element snapshot data corresponding to the service identifier before the service identifier corresponding to the service change instruction is captured during the capturing of the network element snapshot so as to update the corresponding historical network element snapshot data, and a change log corresponding to service processing according to the service change instruction is recorded.

Further, another specific implementation manner of step S303 is:

and if the service information does not meet the condition of capturing the snapshot data, recording a change log corresponding to the service processing according to the service change instruction.

In this embodiment, if the service information included in the service change instruction calculates that the service result E is smaller than the preset threshold according to the preset capture model, that is, the condition for capturing snapshot data is not satisfied, only the change log corresponding to the service processing performed according to the service change instruction is stored for recording.

Fig. 4 is a schematic signaling flow diagram of a fourth embodiment of a fault handling method provided in the present application. On the basis of the embodiments shown in fig. 1 to 3, fig. 4 specifically shows the interaction between the components of the method:

step S401, the client sends a fault query request; the fault inquiry request comprises the identification of the user to be inquired and the identification of the service to be inquired.

Step S402, the application server receives the fault inquiry request, authenticates the request, and sends a data inquiry request to the snapshot data server and the network element corresponding to the identifier of the user to be inquired and the identifier of the service to be inquired after the authentication is passed; the data query request comprises the identification of the user to be queried and the identification of the service to be queried.

Step S403, the snapshot data server returns the network element snapshot data and the change log corresponding to the identifier of the user to be queried and the identifier of the service to be queried.

Step S404, the network element corresponding to the identifier of the user to be inquired and the identifier of the service to be inquired returns the current real-time data of the network element.

Step S405, analyzing and processing the obtained current real-time data of the network element, the network element snapshot data and the change log, obtaining fault information, and carrying the fault information in a fault query request response message and feeding the fault information back to the client.

Step S406, the client triggers the fault processing flow according to the fault inquiry request response message.

In this embodiment, after the application server obtains the fault query request from the client, after the authentication is passed, the application server may simultaneously obtain the current real-time data of the network element, the network element snapshot data, and the change log from the snapshot data server and one or more network elements corresponding to the identifier of the user to be queried and the identifier of the service to be queried, perform analysis processing, obtain fault information, and feed back the fault information to the client to trigger a fault processing procedure. By the method provided by the embodiment, the fault information can be acquired in the second-level reaction time when the fault complaint that the related service of the user cannot be used is received, and the automation degree and efficiency of fault processing are improved.

Fig. 5 is a schematic structural diagram of an embodiment of an application server provided in the present application. Referring to fig. 5, the application server 500 includes: a first transceiver module 501 and a fault handling module 502. A first transceiver module 501, configured to obtain a fault query request, where the fault query request includes an identifier of a user to be queried and an identifier of a service to be queried; the first transceiver module 501 is further configured to send a data query request to the snapshot data server according to the fault query request, so that the snapshot data server queries whether there are network element snapshot data and change logs corresponding to the identifier of the user to be queried and the identifier of the service to be queried according to the data query request, and if so, returns the network element snapshot data and change logs corresponding to the identifier of the user to be queried and the identifier of the service to be queried; the first transceiver module 501 is further configured to obtain, from the network element corresponding to the identifier of the service to be queried, current real-time data of the network element corresponding to the identifier of the user to be queried; and the fault processing module 502 is configured to analyze and process the current real-time data of the network element, the snapshot data of the network element, and the change log, acquire fault information, and carry the fault information in the fault query request response message for feedback processing.

The application server provided in the present application is configured to execute the technical solution in the foregoing method embodiment in fig. 1, and the implementation principle and the technical effect are similar, which are not described herein again.

Fig. 6 is a schematic structural diagram of an embodiment of a snapshot data server provided in the present application. Referring to fig. 6, the snapshot data server 600 includes: a second transceiver module 601, an inquiry module 602, an identification module 603, a judgment module 604, and a snapshot data capture module 605. The second transceiver module 601 is configured to receive a data query request sent by an application server, where the data query request includes: the identification of the user to be inquired and the identification of the service to be inquired; the query module 602 is configured to query whether network element snapshot data and change logs corresponding to the identifier of the user to be queried and the identifier of the service to be queried exist according to the data query request; the second transceiver module 601 is configured to send, if the query request message exists, the network element snapshot data and the change log corresponding to the identifier of the user to be queried and the identifier of the service to be queried to the application server, so that the application server performs fault analysis processing according to the obtained current real-time data of the network element corresponding to the identifier of the service to be queried, the network element snapshot data and the change log corresponding to the identifier of the service to be queried, obtains fault information, and carries the fault information in the fault query request response message for feedback processing.

The identifying module 603 is configured to identify a service instruction when the service instruction is obtained; the service instruction comprises a user identifier, a corresponding service identifier and service information.

The determining module 604 is configured to determine whether the service information in the service change instruction satisfies a condition for capturing snapshot data by using a preset capturing model when the service instruction is identified as the service change instruction.

A snapshot data capturing module 605, configured to, if the service information satisfies a condition for capturing snapshot data and a historical snapshot data record of a network element corresponding to a locally existing user identifier is not queried, obtain all network element snapshot data corresponding to the user identifier before a change of a service corresponding to the service identifier, and record a change log corresponding to service processing according to a service change instruction; the snapshot data capturing module 605 is further configured to, if the service information satisfies a condition for capturing snapshot data and a historical snapshot data record of a network element corresponding to a locally existing user identifier is queried, obtain and update network element snapshot data corresponding to a service identifier before a service identifier corresponding to the service identifier is changed, and record a change log corresponding to service processing according to a service change instruction.

In addition, optionally, the snapshot data capturing module 605 is further configured to record a change log corresponding to the service processing according to the service change instruction if the service information does not meet the condition of capturing the snapshot data.

Optionally, the determining module 604 is specifically configured to: acquiring a service result by adopting a preset capturing model according to a user grade corresponding to a user identifier in service information, the complexity of a home network corresponding to the user identifier, the correlation between a service change instruction and a specific service, the utilization rate of network element performance resources related to the service identifier and the current time of the distance between the last time of capturing snapshot data corresponding to the user identifier and the current time; if the service result is greater than or equal to the preset threshold value, the service information meets the condition of capturing snapshot data; and if the service result is smaller than the preset threshold value, the service information does not meet the condition of capturing the snapshot data.

Optionally, the determining module 604 is specifically configured to: according to a user grade W corresponding to a user identifier in the service information, complexity X of a home network corresponding to the user identifier, correlation Y of a service change instruction and a specific service, network element performance resource utilization rate Z related to the service identifier and current time t from the last time of capturing snapshot data corresponding to the user identifier, a formula in a preset capturing model is adopted:

E＝(α×W+β×X+γ×Y+δ×(1-Z)×10)×A(t)+B(t)

acquiring a service result E; wherein A (t) and B (t) are both time adjustment coefficients; α, β, γ, δ are correlation coefficients, α + β + γ + δ =1.

The snapshot data server provided in the present application is configured to execute the technical solutions in the foregoing method embodiments in fig. 2 and fig. 3, and the implementation principles and technical effects are similar, which are not described herein again.

Fig. 7 is a schematic structural diagram of an embodiment of a fault handling system provided in the present application. Referring to fig. 7, the fault handling system 700 includes: a client 701, a network element 702, an application server 500 as shown in fig. 5, and a snapshot data server 600 as shown in fig. 6; the snapshot data server and the application server are configured independently or integrally.

In this embodiment, the network element 702 is a network element or a cluster of multiple network elements corresponding to the identifier of the service to be queried.

The fault handling system provided by the present application is used for executing the technical solutions in any of the foregoing method embodiments, and the implementation principle and technical effects are similar, which are not described herein again.

Those of ordinary skill in the art will understand that: all or a portion of the steps of implementing the above-described method embodiments may be performed by hardware associated with program instructions. The program may be stored in a computer-readable storage medium. When executed, the program performs steps comprising the method embodiments described above; and the aforementioned storage medium includes: various media that can store program codes, such as ROM, RAM, magnetic or optical disks.

Finally, it should be noted that: the above embodiments are only used for illustrating the technical solutions of the present application, and not for limiting the same; although the present application has been described in detail with reference to the foregoing embodiments, it should be understood by those of ordinary skill in the art that: the technical solutions described in the foregoing embodiments may still be modified, or some or all of the technical features may be equivalently replaced; and the modifications or the substitutions do not make the essence of the corresponding technical solutions depart from the scope of the technical solutions of the embodiments of the present application.

Claims (13)

1. A method of fault handling, comprising:

acquiring a fault query request, wherein the fault query request comprises an identifier of a user to be queried and an identifier of a service to be queried;

sending a data query request to a snapshot data server according to the fault query request, so that the snapshot data server queries whether network element snapshot data and change logs corresponding to the identifier of the user to be queried and the identifier of the service to be queried exist or not according to the data query request, and if yes, returning the network element snapshot data and the change logs corresponding to the identifier of the user to be queried and the identifier of the service to be queried;

acquiring the current real-time data of the network element corresponding to the identifier of the user to be inquired from the network element corresponding to the identifier of the service to be inquired;

analyzing and processing the current real-time data of the network element, the snapshot data of the network element and the change log, acquiring fault information, and carrying the fault information in a fault query request response message for feedback processing.

2. A method of fault handling, comprising:

receiving a data query request sent by an application server, wherein the data query request comprises: the identification of the user to be inquired and the identification of the service to be inquired;

inquiring whether network element snapshot data and change logs corresponding to the identification of the user to be inquired and the identification of the service to be inquired exist or not according to the data inquiry request;

and if the network element snapshot data and the change log corresponding to the identifier of the user to be queried and the identifier of the service to be queried exist, sending the network element snapshot data and the change log to the application server, so that the application server performs fault analysis processing according to the obtained current real-time data of the network element corresponding to the identifier of the service to be queried, the network element snapshot data and the change log corresponding to the identifier of the service to be queried, obtaining fault information, and carrying the fault information in a fault query request response message for feedback processing.

3. The method of claim 2, further comprising:

when a service instruction is obtained, identifying the service instruction; the service instruction comprises a user identifier, a corresponding service identifier and service information;

when the service instruction is identified as a service change instruction, judging whether service information in the service change instruction meets the condition of capturing snapshot data or not by adopting a preset capturing model;

if the service information meets the condition of capturing snapshot data and the historical snapshot data record of the network element corresponding to the user identifier is not inquired, acquiring all network element snapshot data corresponding to the service identifier before the service identifier is changed, and recording a change log corresponding to the service processing according to the service change instruction;

or,

if the service information meets the condition of capturing snapshot data and a historical snapshot data record of a network element corresponding to the user identifier is found locally, network element snapshot data corresponding to the service identifier before the service corresponding to the service identifier is changed is obtained and updated, and a change log corresponding to service processing according to the service change instruction is recorded.

4. The method of claim 3, further comprising:

and if the service information does not meet the condition for capturing the snapshot data, recording a change log corresponding to service processing according to the service change instruction.

5. The method according to claim 3 or 4, wherein the determining whether the service information in the service change instruction satisfies a condition for capturing snapshot data by using a preset capture model comprises:

acquiring a service result by adopting a preset capturing model according to a user grade corresponding to the user identifier in the service information, the complexity of a home network corresponding to the user identifier, the correlation between the service change instruction and a specific service, the utilization rate of network element performance resources related to the service identifier and the current time from the last time of capturing snapshot data corresponding to the user identifier;

if the service result is greater than or equal to a preset threshold value, the service information meets the condition of capturing snapshot data;

and if the service result is smaller than a preset threshold value, the service information does not meet the condition of capturing snapshot data.

6. The method according to claim 5, wherein the obtaining a service result according to a user class corresponding to the user identifier in the service information, a complexity of a home network corresponding to the user identifier, a correlation between the service change instruction and a specific service, a network element performance resource usage rate related to the service identifier, and a current time from a last time of capturing snapshot data corresponding to the user identifier by using a preset capture model comprises:

according to a user level W corresponding to the user identifier in the service information, a complexity X of a home network corresponding to the user identifier, a correlation Y between the service change instruction and a specific service, a network element performance resource utilization rate Z related to the service identifier, and a current time t from the last time of capturing snapshot data corresponding to the user identifier, a formula in the preset capturing model is adopted:

E＝(α×W+β×X+γ×Y+δ×(1-Z)×10)×A(t)+B(t)

acquiring a service result E;

wherein A (t) and B (t) are both time adjustment coefficients; α, β, γ, δ are correlation coefficients, α + β + γ + δ =1.

7. An application server, comprising:

the first transceiver module is used for acquiring a fault query request, wherein the fault query request comprises an identifier of a user to be queried and an identifier of a service to be queried;

the first transceiver module is further configured to send a data query request to a snapshot data server according to the fault query request, so that the snapshot data server queries whether network element snapshot data and change logs corresponding to the identifier of the user to be queried and the identifier of the service to be queried exist according to the data query request, and if yes, returns the network element snapshot data and change logs corresponding to the identifier of the user to be queried and the identifier of the service to be queried;

the first transceiver module is further configured to acquire, from the network element corresponding to the identifier of the service to be queried, current real-time data of the network element corresponding to the identifier of the user to be queried;

and the fault processing module is used for analyzing and processing the current real-time data of the network element, the snapshot data of the network element and the change log, acquiring fault information and carrying the fault information in a fault query request response message for feedback processing.

8. A snapshot data server, comprising:

a second transceiver module, configured to receive a data query request sent by an application server, where the data query request includes: the identification of the user to be inquired and the identification of the service to be inquired;

the query module is used for querying whether network element snapshot data and change logs corresponding to the identification of the user to be queried and the identification of the service to be queried exist or not according to the data query request;

and the second transceiver module is configured to send the network element snapshot data and the change log corresponding to the identifier of the user to be queried and the identifier of the service to be queried to the application server if the network element snapshot data and the change log exist, so that the application server performs fault analysis processing according to the network element current real-time data corresponding to the obtained identifier of the service to be queried, the network element snapshot data corresponding to the identifier of the service to be queried, and the change log, obtains fault information, and carries the fault information in a fault query request response message for feedback processing.

9. The snapshot data server of claim 8, further comprising:

the identification module is used for identifying the service instruction when the service instruction is obtained; the service instruction comprises a user identifier, a corresponding service identifier and service information;

the judging module is used for judging whether the service information in the service change instruction meets the condition of capturing snapshot data or not by adopting a preset capturing model when the service instruction is identified as the service change instruction;

a snapshot data capturing module, configured to, if the service information satisfies the condition for capturing snapshot data and a historical snapshot data record of a network element corresponding to the user identifier is not queried, obtain all network element snapshot data corresponding to the service identifier before the service identifier is changed, and record a change log corresponding to service processing according to the service change instruction;

the snapshot data capturing module is further configured to, if the service information satisfies the condition for capturing snapshot data and a historical snapshot data record of a local network element corresponding to the user identifier is found, obtain and update network element snapshot data corresponding to the service identifier before the service identifier is changed, and record a change log corresponding to service processing according to the service change instruction.

10. The snapshot data server of claim 9, wherein the snapshot data capturing module is further configured to record a change log corresponding to service processing according to the service change instruction if the service information does not satisfy the condition for capturing snapshot data.

11. The snapshot data server of claim 9 or 10, wherein the determining module is specifically configured to:

acquiring a service result by adopting a preset capturing model according to a user grade corresponding to the user identifier in the service information, the complexity of a home network corresponding to the user identifier, the correlation between the service change instruction and a specific service, the utilization rate of network element performance resources related to the service identifier and the current time from the last time of capturing snapshot data corresponding to the user identifier;

if the service result is greater than or equal to a preset threshold value, the service information meets the condition of capturing snapshot data;

and if the service result is smaller than a preset threshold value, the service information does not meet the condition of capturing snapshot data.

12. The snapshot data server of claim 11, wherein the determining module is specifically configured to:

according to a user level W corresponding to the user identifier in the service information, complexity X of a home network corresponding to the user identifier, correlation Y between the service change instruction and a specific service, a network element performance resource utilization rate Z related to the service identifier, and a current time t from last time of capturing snapshot data corresponding to the user identifier, adopting a formula in the preset capturing model:

E＝(α×W+β×X+γ×Y+δ×(1-Z)×10)×A(t)+B(t)

acquiring a service result E;

wherein A (t) and B (t) are both time adjustment coefficients; α, β, γ, δ are correlation coefficients, α + β + γ + δ =1.

13. A fault handling system, comprising: a client, a network element, an application server according to claim 7 and a snapshot data server according to any of claims 8 to 12; wherein the snapshot data server is configured independently or integrally with the application server.

Images