WO2019153505A1 - Procédé de publication d'un paquet de données de récupération après défaillance et serveur - Google Patents

Procédé de publication d'un paquet de données de récupération après défaillance et serveur Download PDF

Info

Publication number
WO2019153505A1
WO2019153505A1 PCT/CN2018/083288 CN2018083288W WO2019153505A1 WO 2019153505 A1 WO2019153505 A1 WO 2019153505A1 CN 2018083288 W CN2018083288 W CN 2018083288W WO 2019153505 A1 WO2019153505 A1 WO 2019153505A1
Authority
WO
WIPO (PCT)
Prior art keywords
fault
data packet
type
user terminal
information
Prior art date
Application number
PCT/CN2018/083288
Other languages
English (en)
Chinese (zh)
Inventor
陈颖聪
Original Assignee
平安科技（深圳）有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 平安科技（深圳）有限公司 filed Critical 平安科技（深圳）有限公司
Publication of WO2019153505A1 publication Critical patent/WO2019153505A1/fr

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • H04L41/0631—Management of faults, events, alarms or notifications using root cause analysis; using analysis of correlation between notifications, alarms or events based on decision criteria, e.g. hierarchy, tree or time analysis
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • H04L41/0654—Management of faults, events, alarms or notifications using network fault recovery
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • H04L41/069—Management of faults, events, alarms or notifications using logs of notifications; Post-processing of notifications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/55—Push-based network services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H04L67/62—Establishing a time schedule for servicing the requests
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/16—Threshold monitoring

Definitions

  • the present application belongs to the technical field of fault repair, and in particular, to a method and a server for releasing a fault repair data packet.
  • Fault repair packets such as patches
  • the existing fault repair data packet is distributed in a global unified push release manner, that is, a software update is uniformly performed to all the user terminals of the application or the system that is required to be repaired by the fault repair data package to modify the software.
  • the vulnerability exists in it.
  • the fault repair data packet it is required to push the fault repair data packet to all user terminals at the same time, the amount of instantaneous concurrent data is large, and the hardware requirements and bandwidth resources of the server are relatively high. Moreover, if some user terminals do not have a fault condition, and the fault repair data packet needs to be downloaded, the data traffic of the part of the user is wasted, resulting in waste of resources, and a new fault condition may be caused by installing the fault repair data packet. Reduce the user experience and the stability of the software.
  • the embodiment of the present application provides a method for releasing a fault repair data packet and a server, to solve the method for distributing the fault repair data packet, and the hardware requirements and bandwidth resources of the server are high, and A user terminal that does not have a fault condition causes waste of resources and reduces stability of the terminal.
  • a method for issuing a fault repair data package provided by the application includes:
  • fault information included in each of the user terminals includes: a fault module identifier, a terminal software version, and a fault response manner;
  • the embodiment of the present application pushes the fault repair data packet to the user terminal having the corresponding fault type, which reduces the instantaneous data volume of the server and reduces the hardware and bandwidth requirements of the server.
  • the embodiment of the present application is a directed release process, and the user terminal that does not have the corresponding fault type does not push the fault repair data packet, thereby avoiding waste of resources and improving the stability of the user terminal. User experience.
  • FIG. 1 is a flowchart of an implementation of a method for issuing a fault repair data packet according to a first embodiment of the present application
  • FIG. 2 is a specific implementation flowchart of a method for issuing a fault repair data packet S103 according to the second embodiment of the present application;
  • FIG. 3 is a specific implementation flowchart of a method for issuing a fault repair data packet S105 according to the third embodiment of the present application;
  • FIG. 4 is a specific implementation flowchart of a method for issuing a fault repair data packet S102 according to the fourth embodiment of the present application;
  • FIG. 5 is a flowchart of an implementation of a method for issuing a fault repair data packet according to a fourth embodiment of the present application
  • FIG. 6 is a structural block diagram of a server according to an embodiment of the present application.
  • FIG. 7 is a schematic diagram of a server according to another embodiment of the present application.
  • FIG. 1 is a flowchart of an implementation of a method for issuing a fault repair data packet according to a first embodiment of the present application, which is described in detail as follows:
  • the server performs communication connection with each user terminal, and the user terminal may send a device operation log to the server by using a preset rule. Specifically, during the running process, the user terminal may send a device running log to the server at a preset time interval. The preset time interval may be performed by the user himself or by the server for all user terminals.
  • the user terminal After receiving the shutdown command, the user terminal can also create a log uploading process in the background, and send the device running log to the server through the process, and enter the state to be shut down; the intended shutdown state is specifically: the user terminal is shut down and the uploading device running log is All modules and processes that are irrelevant, for example, the user terminal only keeps the communication module and the process of log uploading, and closes all other processes to reduce the power consumption of the user terminal.
  • the server may be used to repair a fault condition generated by an application.
  • the server corresponding to each application is simultaneously connected, and The device running logs generated when the user operates each application are respectively sent to the corresponding server.
  • the server may create a corresponding database for the different user terminals, and store the device running log in the database of the user terminal corresponding to the terminal identifier according to the terminal identifier carried in the received device running log. After the storage is completed, the related operations of S102 are performed.
  • the fault information included in each of the user terminals is determined according to a device operation log uploaded by each of the user terminals, and the fault information includes: a fault module identifier, a terminal software version, and a fault response manner.
  • the server determines, by using a preset fault information identification rule, whether the device running log uploaded by the user terminal has a fault condition, and if yes, based on The device running log generates a fault message.
  • the fault information includes the faulty module identifier, the faulty software version, and the fault response mode.
  • the method for determining the faulty module identifier is specifically: identifying a device module that performs an operation in the device running log, and identifying the identifier of the device module as a faulty module.
  • the method for determining the faulty software version is specifically: obtaining an application that responds to the request operation in the running log of the device, and installing the version number of the application on the user terminal, and using the version number as the terminal software version.
  • the fault response modes include but are not limited to: forced exit, downtime, terminal restart, and response timeout.
  • each device running log since each device running log records a response module that responds to the current operation, if the server identifies that the device running log is a fault running log, the identifier of the response module in the device running log may be used as The faulty module identifier of the fault information.
  • the device running log records the start time and the end time. You can compare the running time with the average running time to determine whether the current operation is a timeout response. You can also obtain the device running log. The ending mode of the running process, thereby determining the fault response mode in the fault information by using the above two aspects.
  • the environment software identifier of the request operation can be directly extracted from the device running log as the terminal software version of the fault information.
  • the user terminal may send the device running record corresponding to the current operation to the server when the fault condition is detected, and the server only needs to receive the device running log sent by the terminal device.
  • the abnormality of the user terminal can be identified, and the fault information is directly extracted from the device running log.
  • one fault information may include multiple fault module identifiers, and different fault module identifiers may be divided into multiple fault information for recording.
  • one fault information may include multiple terminal software identifiers; or one fault information may be independently generated for different terminal software identifiers for recording.
  • the fault information is classified according to the faulty module identifier, the terminal software version, and the fault response manner, and the fault type of the fault information is determined.
  • the server classifies the fault module identifier, the terminal software version, and the fault response manner included in each fault information. Because the above three feature items are used, the fault information indicated by each fault information can be identified. Whether the fault conditions are the same or similar to determine whether they are caused by the same cause. For example, the server receives the first fault information and the second fault information, where the three characteristic items in the first fault information are respectively (WIFI module, Ver1, connection timeout); the third feature items in the second fault information are respectively ( WIFI module, Ver1, high packet loss rate), it can be seen that the first fault information and the second fault information have the same fault module identifier and terminal software version number, and the fault response mode is similar, which is common for WIFI connection faults. In response, the first fault information and the second fault information can be identified as the same fault type. In the above manner, different fault information uploaded by different user terminals can be classified into multiple fault types.
  • the same fault type may contain multiple fault information from different faulty terminals.
  • the type of fault that has been identified and identified can also be recorded in the database of the server.
  • the server can match the fault information with the existing fault type to determine whether there is a corresponding fault type that has been created. If yes, the matched fault type is used as the fault type of the fault information, and the fault is The user terminal identifier corresponding to the information is added to the correspondence table pre-stored by the fault type. If the fault type corresponding to the fault information does not exist in the database, create a fault type, and match the created fault type with other received fault information to determine whether other fault information received this time belongs to the fault type. Thereby completing the classification operation of the fault information.
  • a correspondence between the fault type and the user terminal is established according to the user terminal corresponding to the fault information included in the fault type, and the fault information corresponds to at least one of the user terminals.
  • the server after determining the fault type of each fault information, the server identifies the fault information included in each fault type, and establishes a correspondence between the fault type and the user terminal based on the user terminal corresponding to each fault information. Relationship, for example, the fault correspondence is shown in Table 1. Referring to Table 1, the server can configure a fault number for each fault type, configure a fault description segment for the fault type, and use the communication address of the user terminal as the identifier of the user terminal.
  • the server may send the fault type and the fault information included in the fault type to the fault repair administrator, so that the fault repair administrator determines the corresponding fault repair scheme according to the fault type. And generating a fault repair data packet for repairing the fault type; of course, if the fault repair algorithm is stored in the server, a plurality of simulated user terminals can be built by using each fault information in the fault type, by changing the software version of the terminal. Each parameter, and the output feedback of the modified user terminal after modification, determines whether the fault type has been repaired, and if so, generates a fault repair data packet according to each parameter of the terminal software corresponding to the repaired fault type.
  • the fault repair data packet for repairing the fault type is acquired, the fault repair data packet is sent to the user terminal corresponding to the fault type based on the correspondence relationship.
  • the server may generate a fault repair data packet locally through an administrator or a fault repair algorithm, and may also receive a fault repair data packet sent from another device, for example, receiving the fault repair data sent by the administrator terminal or the upper server. package. Since the fault repair has a certain hysteresis, that is, the fault information fed back by the user terminal is received, and after the fault type is determined, there is a certain time difference between the fault repair data packets, and therefore, the server does not realize the fault information immediately after receiving the fault information. After the fault repair data packet is released, the fault repair data packet is pushed to the user terminal corresponding to the fault type after receiving the fault repair data packet.
  • the server determines the fault type used by the fault repair data packet for repair, and queries the user terminal that has the fault type based on the corresponding relationship generated in S104. Which, in turn, sends the fault repair data packet to the user terminal to achieve the purpose of redirecting the fault to the user terminal.
  • the terminal identifier of the user terminal may be deleted from the corresponding relationship or a sent identifier may be added.
  • the newly detected user terminal may be added to the corresponding relationship of the fault type. in.
  • the server pushes the fault repair data packet to the user terminal currently existing in the corresponding relationship table; if the added identifier is added In the manner of distinguishing the user terminals, the server sends the fault repair data packet to the user terminal that has sent the identifier to be empty.
  • the method for distributing the fault repair data packet collects the device operation log of the user terminal, and identifies the fault information included in the user terminal, and then classifies the fault information, and determines the The type of fault that the user terminal contains.
  • the fault repair data packet of a fault type is obtained, the fault repair data packet is sent to all user terminals that have the fault type, and the purpose of the fault repair data packet is released.
  • the embodiment of the present application pushes the fault repair data packet to the user terminal having the corresponding fault type, instead of the global unified push, thereby reducing the instantaneous data volume of the server and reducing the amount of data.
  • the hardware and bandwidth requirements for the server is a directed release process, and the user terminal that does not have the corresponding fault type does not push the fault repair data packet, thereby avoiding waste of resources and improving the stability of the user terminal. User experience.
  • FIG. 2 is a flowchart showing a specific implementation of a method for issuing a fault repair data packet S103 according to the second embodiment of the present application.
  • S103 includes S1031 to S1033, and the details are as follows:
  • the S is a matching degree between the fault information and the fault type; the A 1 , A 2 , and A 3 are respectively a fault module identifier of the fault information, the terminal software version, and the The parameter value of the fault response mode; the B 1 , B 2 , and B 3 are respectively the fault module identifier of the fault type, the terminal software version, and the parameter value of the fault response mode; the e is a natural constant.
  • a fault repairing library is stored in the server, and the fault repairing library includes multiple fault types, and the fault type may be a fault type collected and classified in the process of directly collecting the terminal device, or may be The type of fault discovered by the administrator during the test can also be the type of fault sent by the host server or distributed server to synchronize the faulty database.
  • different servers may divide the user terminals according to different regions or different types of managed terminals, and different servers are used to manage different types of user terminals, and each server may pre-empt The set time interval synchronizes the fault type in the fault repair library, thereby reducing the situation of repeatedly specifying the fault repair data packet, reducing the repair pressure of the administrator, and improving the efficiency of fault repair.
  • the server when receiving the fault information fed back by the user terminal, the server may determine, according to the faulty module identifier, the terminal version number, and the fault response manner included in the fault information, whether the fault information belongs to the recorded fault type. One of them is therefore based on the above three parameters and the failure type calculation in the fault repair library. Calculate the degree of difference between each feature item, that is, calculate
  • the server numbers each module based on the association between the modules, and the smaller number difference indicates that the functions between the two modules are relatively similar and the correlation is relatively large.
  • the communication module can be classified into the third category, and the Bluetooth module is the first subclass of the large class, and the WIFI module is the second subclass of the large class, and the number of the Bluetooth module can be 31, WIFI.
  • the module number can be 32, so the difference between the two is 1; while the display module belongs to the 8th category, and the touch screen in the display module belongs to the first subclass, the module number of the touch screen is 81.
  • the difference between the touch screen module and the Bluetooth module is 50, so that based on the difference between the faulty module identifiers, it can be determined whether the fault information matches the fault type.
  • the fault response manner can also be numbered in the above manner, and will not be described one by one.
  • the software version numbers are numbered one by one based on the order in which the version is generated, directly calculating the difference between the version numbers can determine the degree of difference between the two software versions, that is, as a factor for calculating the matching degree. one.
  • the pre-stored fault type is used as a fault type of the fault information, and the pre-stored fault is A type of fault repair data packet is sent to the user terminal to which the fault information belongs.
  • the server if the server finds that the matching degree between the pre-stored fault type and the currently obtained fault information is greater than a preset matching threshold, the server identifies the pre-stored fault type as the fault corresponding to the fault information.
  • the type in particular, if there is a plurality of pre-stored fault types and the matching degree of the fault information is greater than a preset matching degree threshold, the one of the pre-stored fault types with the highest matching degree is selected as the fault type of the fault information.
  • each pre-stored fault type corresponds to a fault repair data packet for modifying the pre-stored fault type. Therefore, after determining that the fault information belongs to the pre-stored fault type, the server may directly send the pre-stored fault to the faulty terminal. The fault repair packet corresponding to the fault type, thereby achieving the purpose of fault repair.
  • the faulty module identifier, the terminal software version, and the fault response manner carried according to the fault information are used. Create a fault type and use the type of fault created as the fault type for the fault information.
  • the fault information is newly generated fault information, and the server is the fault.
  • the repair is performed. Therefore, based on the faulty module representation, the terminal software version, and the fault response mode carried in the fault information, a fault type is created, and the fault type is stored in the fault repair library, and the created fault type is identified as The failure type of the failure information is then performed in S104 and S105.
  • FIG. 3 is a specific implementation flowchart of a method for issuing a fault repair data packet S105 according to the third embodiment of the present application. As shown in FIG. 3, in the method for issuing the fault repair data packet provided by the embodiment, S105 further includes S1051 to S1053, which are specifically described as follows:
  • the server before sending the fault repair data packet, the server first determines the data amount of the fault repair data packet, and compares the data amount with a preset data volume threshold, and the fault repair data packet data. If the amount is less than the preset data amount threshold, the operation of S1052 is performed; otherwise, if the data amount is greater than or equal to the preset data amount threshold, the operation of S1053 is performed.
  • the data volume threshold of the embodiment may be manually set by an administrator, or may be automatically adjusted by the server according to the bandwidth resource of the network.
  • the server sets the estimated duration of sending a fault repair packet to 4 seconds, and the occupied bandwidth resource cannot exceed 50%.
  • the main thread is set to the serial operation mode, and the main thread corresponds to each user terminal corresponding to the fault type. Send the fault repair packet.
  • the server determines that the data amount of the fault repair data packet is less than a preset data amount threshold, it indicates that the data amount of the fault repair data packet is small, and the time required for sending a data packet is short. There is no case that the data packet is sent due to the transmission failure repair, and the transmission is not sent after the preset duration is exceeded. On this basis, the transmission efficiency of the fault repair data packet through the main thread is high.
  • the server Since the main thread can call the hardware resources and the bandwidth resources are more, the efficiency of sending the data packet is also higher, but since the server detects the main thread running, it sets a maximum response duration, if the response duration exceeds the preset In response to the threshold, the main thread is identified as being in an abnormal state, and the operation of the main thread is terminated and the response is resumed. Therefore, if the amount of data of the fault repair packet is large, the server will recognize that the main thread is in an abnormal state of response, and repeatedly terminates and resends, resulting in waste of resources and failure to transmit the faulty data packet. Therefore, when the amount of data of the faulty packet is small, data can be released through the main thread.
  • the server when the server determines to send the fault repair data packet to each user terminal through the main thread, the server may send the fault repair data packet according to the order in which the user terminal uploads the fault information.
  • the server determines that the fault repair data packet is greater than or equal to the data amount threshold, it indicates that the data amount of the fault repair data packet is large, and if the main thread is serially transmitted, the foregoing sending is easily generated. Timeout situation. Therefore, in this case, the fault repair data packet will be transmitted to each user terminal in a parallel manner by the child threads.
  • the server queries the number of terminals of the user terminal in the corresponding relationship of the fault type, and creates the number of child threads equal to the number of the terminal under the main thread, and runs the sub-threads.
  • the mode is set to the asynchronous parallel mode, so that each sub-thread is controlled to communicate with each user terminal, and each sub-thread sends a fault repair data packet to each user terminal.
  • the server selects an appropriate transmission mode to perform data transmission according to the data volume of the fault repair data packet, thereby improving the transmission efficiency and the success rate of the transmission.
  • FIG. 4 is a specific implementation flowchart of a method for issuing a fault repair data packet S102 according to the fourth embodiment of the present application.
  • a method for issuing a fault repair data packet S102 provided by this embodiment includes: S1021 to S1023, which are specifically described as follows:
  • the running time of the running log is determined according to the start time and the ending time of the device running log.
  • each device operation log records the start time and the end time of the current service response operation
  • the server may determine the running time required by the user terminal to respond to the service based on the difference between the start time and the end time.
  • the server may query a time threshold corresponding to the service type based on the service type. Since different service types require different response times, they have corresponding duration thresholds.
  • the server may extract the service type included in the running log of the device, and then determine the duration threshold of the fault type, and then compare the running duration obtained by the current collection with the duration threshold.
  • the server may determine an average running time of the service type based on a device running log of the service type that is repeatedly fed back by the user terminal, and use the average running time as a duration threshold.
  • the server detects that the running time is less than the preset duration threshold, it indicates that the current response is abnormal, and the device running log is identified as a normal running log; otherwise, if the running time is greater than the preset duration threshold Then, the operation of S1022 is performed to further confirm whether the device running log is a fault running log.
  • the running time is greater than the preset duration threshold, it indicates that the current service response belongs to the timeout response, and therefore the resource status of the user terminal consumed during the current service is obtained.
  • the hardware resources of the user terminal are generally occupied. Therefore, based on the size of the resource consumption parameter, it is determined whether the device running log is a fault running log.
  • the resource consumption parameter may be a value occupied by the terminal memory, or may be a percentage of the operation resource of the operation module.
  • the server compares the consumption resource parameter in the device running log with a preset consumption threshold. If the preset consumption threshold is not exceeded, the device running log is identified as a normal running log; otherwise, if the preset consumption threshold is exceeded, the fault running log is identified, and the operation of S1023 is performed.
  • the device running log is identified as a fault running log, and the fault information is generated based on the fault running log.
  • the server when the server determines that the resource consumption parameter of the user terminal required to respond to the current service exceeds a preset consumption threshold, the server indicates that the operation consumes a large amount of resources of the user terminal, and determines the process of responding to the service. There is a fault condition and a fault message is generated.
  • the purpose of automatically identifying and extracting fault information is achieved, and the efficiency of fault repair is improved.
  • FIG. 5 is a specific implementation flowchart of a method for issuing a fault repair data packet according to a fifth embodiment of the present application.
  • a method for issuing a fault repair data packet according to the present embodiment is based on the corresponding relationship, and the user terminal corresponding to the fault type is Before sending the fault repair data packet, the method further includes: S501 and S502, which are specifically described as follows:
  • the server may send a network state acquisition request to the user terminal to determine the network state of the current user terminal.
  • the network status is a specific connection method for communicating with the Internet, and is through a wired network, a wireless local area network, or a mobile network.
  • the user terminal generates a network status result and returns it to the server based on the current network state communicated with the server.
  • the server determines that the network status of the current user terminal is a preset data packet download status, the server sends a fault repair data packet to the user terminal.
  • the packet download status is: wireless local area status or wired network status.
  • the server determines that the current network status does not meet the preset data packet download status, set a retransmission timer, and after the count value of the retransmission timer is greater than the retransmission count value, return to the related operation of S501 until The network status of the user terminal satisfies the preset data packet download status, and then the download operation is performed.
  • the user terminal may enter a download waiting state when determining that the current state does not satisfy the preset data packet downloading state, and when detecting that the network state of the user terminal meets the data packet downloading state, , actively send a packet acquisition request to the server to start the packet download operation.
  • FIG. 6 is a structural block diagram of a server according to an embodiment of the present application, where each unit included in the server is used to execute each step in the embodiment corresponding to FIG. 1.
  • each unit included in the server is used to execute each step in the embodiment corresponding to FIG. 1.
  • please refer to the related description in the embodiment corresponding to FIG. 1 and FIG. For the convenience of explanation, only the parts related to the present embodiment are shown.
  • the server includes:
  • the device operation log receiving unit 61 is configured to receive a device operation log uploaded by each user terminal;
  • the fault information obtaining unit 62 is configured to determine, according to the device running logs uploaded by each of the user terminals, fault information included in each of the user terminals, where the fault information includes: a fault module identifier, a terminal software version, and a fault response manner;
  • the fault type determining unit 63 is configured to classify the fault information based on the faulty module identifier, the terminal software version, and the fault response manner, and determine a fault type of the fault information.
  • the correspondence determining unit 64 is configured to establish, according to the user terminal corresponding to the fault information that is included in the fault type, a correspondence between the fault type and the user terminal, where the fault information corresponds to at least one user. terminal;
  • the fault data packet sending unit 65 is configured to: if the fault repair data packet for repairing the fault type is acquired, send the fault repair data packet to the user terminal corresponding to the fault type based on the correspondence relationship.
  • the fault type determining unit 63 includes:
  • a matching degree calculation unit configured to calculate, according to the faulty module identifier, the terminal software version, and the fault response manner, a matching degree between each fault information and a pre-stored fault type included in a preset fault repair library;
  • the model for calculating the matching degree is specifically:
  • the S is a matching degree between the fault information and the fault type;
  • the A 1 , A 2 , and A 3 are respectively a fault module identifier of the fault information, the terminal software version, and the a parameter value of the fault response mode;
  • the B 1 , B 2 , and B 3 are respectively a fault module identifier of the fault type, the terminal software version, and a parameter value of the fault response manner;
  • the e is a natural constant;
  • a pre-stored fault type determining unit configured to use the pre-stored fault type as the fault type of the fault information if there is a matching degree of the pre-stored fault type and the fault information is greater than a preset matching degree threshold
  • the fault repair data packet of the pre-stored fault type is sent to the user terminal to which the fault information belongs;
  • a fault type creation unit configured to: if the matching degree of any of the pre-stored fault types and the fault information is less than or equal to a preset matching degree threshold, the fault module identifier, the terminal software version, and the version of the terminal software carried according to the fault information In the fault response mode, a fault type is created, and the fault type created is used as the fault type of the fault information.
  • the fault data packet sending unit 65 includes:
  • a data amount determining unit configured to acquire a data amount of the fault repair data packet
  • a serial sending unit configured to: if the data volume of the fault repairing data packet is less than a preset data amount threshold, set the main thread to a serial running mode, and respectively correspond to the fault type by the main thread Each user terminal sends the fault repair data packet;
  • a parallel sending unit configured to create a plurality of asynchronous parallel child threads in the main thread if the data amount of the fault repair data packet is greater than or equal to the data amount threshold, and respectively use each of the child threads to Each user terminal corresponding to the fault type sends the fault repair data packet; the number of the child threads is the same as the number of user terminals included in the fault type.
  • the fault information obtaining unit 62 includes:
  • a running time calculation unit configured to determine a working duration of the running log according to a start time and an ending time of the device running log
  • a resource consumption determining unit configured to acquire a resource consumption parameter of the device running log, if the running time is greater than a preset duration threshold
  • the fault running log determining unit is configured to: if the resource consumption parameter exceeds a preset consumption threshold, identify the device running log as a fault running log, and generate the fault information based on the fault running log.
  • the server further includes:
  • a network status obtaining unit configured to acquire a network status of the user terminal
  • a network status determining unit configured to: if the network status meets a preset data packet download status, perform the operation of releasing the fault repair data packet to the user terminal corresponding to the fault type based on the corresponding relationship
  • the server provided by the embodiment of the present application can also push the fault repair data packet only to the user terminal having the corresponding fault type, thereby reducing the instantaneous concurrent data volume of the server and reducing the hardware and bandwidth requirements of the server.
  • the embodiment of the present application is a directed release process, and the user terminal that does not have the corresponding fault type does not push the fault repair data packet, thereby avoiding waste of resources and improving the stability of the user terminal. User experience.
  • FIG. 7 is a schematic diagram of a server according to another embodiment of the present application.
  • the server 7 of this embodiment includes a processor 70, a memory 71, and computer readable instructions 72 stored in the memory 71 and executable on the processor 70, such as a fault repair packet. Release program.
  • the processor 70 executes the computer readable instructions 72, the steps in the embodiment of the method for issuing the respective fault repair data packets are implemented, such as S101 to S105 shown in FIG. 1.
  • the processor 70 when executing the computer readable instructions 72, implements the functions of the various units in the various apparatus embodiments described above, such as the functions of modules 61 through 65 shown in FIG.
  • the computer readable instructions 72 may be partitioned into one or more units, the one or more units being stored in the memory 71 and executed by the processor 70 to complete the application.
  • the one or more units may be a series of computer readable instruction instructions segments capable of performing a particular function for describing the execution of the computer readable instructions 72 in the server 7.
  • the computer readable instructions 72 may be divided into a device operation log receiving unit, a failure information acquisition unit, a failure type determination unit, a correspondence relationship determination unit, and a failure data packet transmission unit, each of which has a specific function as described above.
  • the server 7 can be a computing device such as a desktop computer, a notebook, a palmtop computer, and a cloud server.
  • the server may include, but is not limited to, a processor 70, a memory 71. It will be understood by those skilled in the art that FIG. 7 is only an example of the server 7, and does not constitute a limitation on the server 7, and may include more or less components than those illustrated, or combine some components, or different components, such as
  • the server may also include an input and output device, a network access device, a bus, and the like.
  • the processor 70 may be a central processing unit (CPU), or may be other general-purpose processors, a digital signal processor (DSP), an application specific integrated circuit (ASIC), Field-Programmable Gate Array (FPGA) or other programmable logic device, discrete gate or transistor logic device, discrete hardware components, etc.
  • the general purpose processor may be a microprocessor or the processor or any conventional processor or the like.
  • the memory 71 may be an internal storage unit of the server 7, such as a hard disk or a memory of the server 7.
  • the memory 71 may also be an external storage device of the server 7, such as a plug-in hard disk equipped with the server 7, a smart memory card (SMC), and a Secure Digital (SD) card. Flash card, etc.
  • the memory 71 may also include both an internal storage unit of the server 7 and an external storage device.
  • the memory 71 is configured to store the computer readable instructions and other programs and data required by the server.
  • the memory 71 can also be used to temporarily store data that has been output or is about to be output.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

La présente invention se rapporte au domaine technique de la récupération après défaillance et concerne un procédé de publication d'un paquet de données de récupération après défaillance et un serveur, le procédé comprenant : la réception de journaux d'opération de dispositif téléversés par chaque terminal utilisateur ; la détermination d'informations de défaillance contenues dans chacun des terminaux utilisateur respectivement en fonction de chacun des journaux d'opération de dispositif ; la classification des informations de défaillance, et la détermination d'un type de défaillance pour les informations de défaillance ; l'établissement d'une correspondance entre le type de défaillance et les terminaux utilisateur en fonction d'un terminal utilisateur correspondant aux informations de défaillance contenues dans le type de défaillance ; si un paquet de données de récupération après défaillance utilisé pour réparer le type de défaillance est acquis, envoi du paquet de données de récupération après défaillance au terminal utilisateur correspondant au type de défaillance en fonction de la correspondance. La présente invention ne pousse le paquet de données de récupération après défaillance que vers un terminal utilisateur présentant un type de défaillance correspondant, ce qui permet la réduction du volume de données instantanément en concurrence par un serveur et la réduction des exigences matérielles et de bande passante pour le serveur.
PCT/CN2018/083288 2018-02-07 2018-04-17 Procédé de publication d'un paquet de données de récupération après défaillance et serveur WO2019153505A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201810121899.0 2018-02-07
CN201810121899.0A CN108322345B (zh) 2018-02-07 2018-02-07 一种故障修复数据包的发布方法及服务器

Publications (1)

Publication Number Publication Date
WO2019153505A1 true WO2019153505A1 (fr) 2019-08-15

Family

ID=62902145

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2018/083288 WO2019153505A1 (fr) 2018-02-07 2018-04-17 Procédé de publication d'un paquet de données de récupération après défaillance et serveur

Country Status (2)

Country Link
CN (1) CN108322345B (fr)
WO (1) WO2019153505A1 (fr)

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110704093A (zh) * 2019-09-18 2020-01-17 上海麦克风文化传媒有限公司 一种运营反馈的线上故障的处理方法及系统
CN112732520A (zh) * 2020-12-30 2021-04-30 中国人民解放军32181部队 一种装备运行监控软件的故障处理方法及系统
CN112988437A (zh) * 2019-12-17 2021-06-18 深信服科技股份有限公司 一种故障预测方法、装置及电子设备和存储介质
CN113051112A (zh) * 2021-03-16 2021-06-29 北京经纬恒润科技股份有限公司 一种ecu故障信息的获取方法及系统
CN113190370A (zh) * 2021-05-08 2021-07-30 京东数字科技控股股份有限公司 一种应用的应急响应方法及装置
CN113692056A (zh) * 2021-08-25 2021-11-23 维沃移动通信有限公司 资源共享方法和装置
CN114294778A (zh) * 2021-12-27 2022-04-08 深圳市兴特能源科技有限公司 一种教室灯具的空气循环消毒净化方法及系统
CN114722029A (zh) * 2022-04-18 2022-07-08 苏州浪潮智能科技有限公司 一种修复monitor数据库的方法、系统、设备和存储介质

Families Citing this family (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109254864A (zh) * 2018-09-11 2019-01-22 北京奇艺世纪科技有限公司 一种应用程序故障修复方法、装置及电子设备
CN109144559B (zh) * 2018-09-26 2022-02-01 深圳壹账通智能科技有限公司 一种更新数据包的推送方法及服务器
CN111385613B (zh) * 2018-12-29 2022-07-08 深圳Tcl数字技术有限公司 一种电视系统修复方法、存储介质及应用服务器
CN109933465B (zh) * 2019-03-12 2021-12-10 北京同城必应科技有限公司 异常处理方法、装置、服务器和存储介质
CN111786804B (zh) 2019-04-04 2023-06-30 华为技术有限公司 一种链路故障监控方法及装置
CN110191003A (zh) * 2019-06-18 2019-08-30 北京达佳互联信息技术有限公司 故障修复方法、装置、计算机设备及存储介质
CN110633099A (zh) * 2019-09-05 2019-12-31 北京无限光场科技有限公司 应用程序的修复方法、装置、设备和可读介质
CN111026572A (zh) * 2019-11-15 2020-04-17 北京金山云网络技术有限公司 分布式系统的故障处理方法、装置及电子设备
CN111190630B (zh) * 2020-01-02 2023-06-16 竞技世界（北京）网络技术有限公司 一种终端应用的更新方法及服务器
CN111664543B (zh) * 2020-05-25 2022-12-13 海信空调有限公司 一种空调器及其控制方法
CN111897683A (zh) * 2020-07-10 2020-11-06 广东小天才科技有限公司 电子设备及其故障修复方法和装置
CN112104497A (zh) * 2020-09-11 2020-12-18 北京达佳互联信息技术有限公司 终端管理方法、装置、系统、服务器、终端及存储介质
CN112328422A (zh) * 2020-11-06 2021-02-05 深圳市锐尔觅移动通信有限公司 异常修复方法、装置、电子设备及存储介质
CN112733369B (zh) * 2021-01-13 2023-06-13 青岛海尔科技有限公司 智能设备检修方法、终端及系统、电子设备
CN113033889B (zh) * 2021-03-19 2022-12-20 国网河北省电力有限公司邢台供电分公司 高压输电线路故障预测方法、装置及终端设备
CN113255454A (zh) * 2021-04-26 2021-08-13 广西电网有限责任公司桂林供电局 一种电网自适应故障定位的方法及相关设备
CN113808725B (zh) * 2021-09-06 2024-06-28 武汉联影医疗科技有限公司 设备预警系统和方法
CN114138720A (zh) * 2021-11-27 2022-03-04 浙江中控技术股份有限公司 日志处理方法、装置、电子装置和存储介质
CN114338765B (zh) * 2021-12-10 2024-03-22 青岛海尔科技有限公司 设备连接异常识别方法与系统、电子装置及存储介质
CN113986603B (zh) * 2021-12-28 2022-04-15 深圳市明源云科技有限公司 页面加载异常原因的确定方法、装置及存储介质

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102045181A (zh) * 2009-10-10 2011-05-04 中国移动通信集团公司 一种终端脱网故障的处理方法和装置
CN105335277A (zh) * 2014-06-27 2016-02-17 可牛网络技术（北京）有限公司 一种故障信息处理方法及装置、终端
CN106161079A (zh) * 2015-04-28 2016-11-23 小米科技有限责任公司 故障反馈方法和装置
WO2017070587A1 (fr) * 2015-10-21 2017-04-27 Brocade Communications Systems, Inc. Fourniture répartie de règles dans un pont étendu

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101115264B (zh) * 2006-07-24 2010-09-01 中兴通讯股份有限公司 通讯终端故障监控系统及其实现方法
CN102857365A (zh) * 2012-06-07 2013-01-02 中兴通讯股份有限公司 网管系统中故障预防及智能修复方法和装置
US10367699B2 (en) * 2016-04-25 2019-07-30 Cisco Technology, Inc. Network architecture for predictive services management in cable network environments
CN106685744A (zh) * 2017-03-13 2017-05-17 福建中金在线信息科技有限公司 一种故障排除方法、装置及系统
CN107357730B (zh) * 2017-07-17 2021-03-19 苏州浪潮智能科技有限公司 一种系统故障诊断修复方法及装置

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102045181A (zh) * 2009-10-10 2011-05-04 中国移动通信集团公司 一种终端脱网故障的处理方法和装置
CN105335277A (zh) * 2014-06-27 2016-02-17 可牛网络技术（北京）有限公司 一种故障信息处理方法及装置、终端
CN106161079A (zh) * 2015-04-28 2016-11-23 小米科技有限责任公司 故障反馈方法和装置
WO2017070587A1 (fr) * 2015-10-21 2017-04-27 Brocade Communications Systems, Inc. Fourniture répartie de règles dans un pont étendu

Cited By (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110704093A (zh) * 2019-09-18 2020-01-17 上海麦克风文化传媒有限公司 一种运营反馈的线上故障的处理方法及系统
CN112988437B (zh) * 2019-12-17 2023-12-29 深信服科技股份有限公司 一种故障预测方法、装置及电子设备和存储介质
CN112988437A (zh) * 2019-12-17 2021-06-18 深信服科技股份有限公司 一种故障预测方法、装置及电子设备和存储介质
CN112732520A (zh) * 2020-12-30 2021-04-30 中国人民解放军32181部队 一种装备运行监控软件的故障处理方法及系统
CN112732520B (zh) * 2020-12-30 2024-04-12 中国人民解放军32181部队 一种装备运行监控软件的故障处理方法及系统
CN113051112A (zh) * 2021-03-16 2021-06-29 北京经纬恒润科技股份有限公司 一种ecu故障信息的获取方法及系统
CN113190370A (zh) * 2021-05-08 2021-07-30 京东数字科技控股股份有限公司 一种应用的应急响应方法及装置
CN113692056A (zh) * 2021-08-25 2021-11-23 维沃移动通信有限公司 资源共享方法和装置
CN113692056B (zh) * 2021-08-25 2024-01-19 维沃移动通信有限公司 资源共享方法和装置
CN114294778A (zh) * 2021-12-27 2022-04-08 深圳市兴特能源科技有限公司 一种教室灯具的空气循环消毒净化方法及系统
CN114294778B (zh) * 2021-12-27 2023-11-14 深圳市兴特能源科技有限公司 一种教室灯具的空气循环消毒净化方法及系统
CN114722029A (zh) * 2022-04-18 2022-07-08 苏州浪潮智能科技有限公司 一种修复monitor数据库的方法、系统、设备和存储介质
CN114722029B (zh) * 2022-04-18 2024-01-09 苏州浪潮智能科技有限公司 一种修复monitor数据库的方法、系统、设备和存储介质

Also Published As

Publication number Publication date
CN108322345B (zh) 2020-08-21
CN108322345A (zh) 2018-07-24

Similar Documents

Publication Publication Date Title
WO2019153505A1 (fr) Procédé de publication d'un paquet de données de récupération après défaillance et serveur
CN109144559B (zh) 一种更新数据包的推送方法及服务器
WO2021129367A1 (fr) Procédé et appareil de surveillance de système de stockage décentralisé
CN108600029B (zh) 一种配置文件更新方法、装置、终端设备及存储介质
CN107689953B (zh) 一种面向多租户云计算的容器安全监控方法及系统
US10108411B2 (en) Systems and methods of constructing a network topology
WO2021169064A1 (fr) Procédé et appareil de traitement d'anomalie basé sur un réseau périphérique
WO2021012568A1 (fr) Procédé de traitement de données et dispositif associé
JP4760491B2 (ja) イベント処理システム、イベント処理方法、イベント処理装置、及び、イベント処理プログラム
CN109495306B (zh) 一种业务网络的扩容方法及设备
CN109714202B (zh) 一种客户端离线原因判别方法和集群式安全管理系统
CN105049268A (zh) 分布式计算资源分配系统和任务处理方法
CN107783829B (zh) 任务处理方法、装置、存储介质和计算机设备
CN113051019A (zh) 流程任务执行管控方法、装置以及设备
TWI603203B (zh) 分散式計算之運算參數與叢集系統組態的推薦方法與系統
WO2019148728A1 (fr) Dispositif électronique, procédé d'affectation de tâche d'exécution pour système distribué, et support d'informations
CN111641524A (zh) 监控数据处理方法、装置、设备和存储介质
CN108847995A (zh) 一种基于私有云的配置运维告警模板的方法及设备
CN108737499A (zh) 服务器配置方法和装置
US11153183B2 (en) Compacted messaging for application performance management system
US20120072589A1 (en) Information Processing Apparatus and Method of Operating the Same
CN110290166A (zh) 跨集群数据交互方法、系统、装置及可读存储介质
CN104780062A (zh) 一种快速获取bmc管理网口ip地址的方法
WO2020098266A1 (fr) Procédé et dispositif en cas de réponse anormale
CN109697117B (zh) 终端控制方法、装置以及计算机可读存储介质

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 18905610

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 03/11/2020

122 Ep: pct application non-entry in european phase

Ref document number: 18905610

Country of ref document: EP

Kind code of ref document: A1