Fault detection strategy verification method and device, computer equipment and storage medium

Abstract

The invention relates to a fault detection strategy verification method and device, computer equipment, a storage medium and a computer program product. The method comprises the following steps: acquiring a to-be-verified fault detection strategy and strategy verification configuration information; according to the strategy verification configuration information, obtaining equipment operation state data of at least one piece of equipment for strategy verification from historical operation state data of the data center; the equipment operation state data comprises a plurality of signals representing the equipment operation state; pushing the plurality of signals representing the equipment operation state of the at least one piece of equipment into a business sandbox according to a signal generation time sequence, and playing back the plurality of signals representing the equipment operation state of the at least one piece of equipment through the business sandbox to simulate an equipment operation scene of the at least one piece of equipment; and in the process of simulating the equipment operation scene, performing fault detection through the fault detection strategy to obtain a verification result of the fault detection strategy. By adopting the method, the verification accuracy of the fault detection strategy can be improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computer, in particular to a fault detection strategy verification method and device, computer equipment, storage medium and computer program product. BACKGROUND

[0002] With the development of computer technology, fault detection technology appears, which can detect faults of a system such as a data center based on a fault detection strategy. The data center refers to a facility for housing computer systems and related components, usually including redundant and backup power supplies, redundant data communication connections, environmental control (such as air conditioning, fire extinguishers) and various security devices.

[0003] In the prior art, before using a fault detection strategy, it is usually necessary to verify the function of the fault detection strategy to ensure its fault detection capability. The way to verify the function of the fault detection strategy is usually to manually build a fault scenario and use the manually built fault scenario to verify the function of the fault detection strategy.

[0004] However, the manually built fault scenario in the prior method cannot completely restore the fault scenario generated in the actual application process, resulting in low accuracy of the fault detection strategy verification and inability to guarantee the fault detection capability of the fault detection strategy. SUMMARY

[0005] Therefore, it is necessary to provide a fault detection strategy verification method, device, computer equipment, computer readable storage medium and computer program product capable of improving the accuracy of fault detection strategy verification to solve the above technical problems.

[0006] In a first aspect, the present application provides a fault detection strategy verification method. The method comprises:

[0007] obtaining a fault detection strategy to be verified and strategy verification configuration information;

[0008] According to the strategy verification configuration information, obtaining device running state data of at least one device for strategy verification from historical running state data of the data center; the device running state data comprises a plurality of signals representing device running states;

[0009] Pushing the plurality of signals representing device running states of the at least one device into a business sandbox according to the signal generation time sequence, and playing back the plurality of signals representing device running states of the at least one device through the business sandbox to simulate a device running scenario of the at least one device;

[0010] During the simulation of the device running scenario, performing fault detection through the fault detection strategy to obtain a fault detection result;

[0011] According to the fault detection result, a verification result of the fault detection strategy is obtained.

[0012] In a second aspect, the present application further provides a fault detection strategy verification device. The device comprises:

[0013] a strategy obtaining module, configured to obtain a fault detection strategy to be verified and strategy verification configuration information;

[0014] a data obtaining module, configured to obtain, according to the strategy verification configuration information, device running state data of at least one device for strategy verification from historical running state data of a data center; the device running state data comprises a plurality of signals representing device running states;

[0015] a data playback module, configured to push the plurality of signals representing device running states of the at least one device into a business sandbox according to signal generation time sequences, and play back the plurality of signals representing device running states of the at least one device through the business sandbox to simulate a device running scenario of the at least one device;

[0016] a fault detection module, configured to perform fault detection through the fault detection strategy during simulation of the device running scenario, and obtain a fault detection result;

[0017] a verification module, configured to obtain a verification result of the fault detection strategy according to the fault detection result.

[0018] In a third aspect, the present application further provides a computer device. The computer device comprises a memory and a processor, the memory stores a computer program, and the processor realizes the following steps when executing the computer program:

[0019] obtaining a fault detection strategy to be verified and strategy verification configuration information;

[0020] obtaining, according to the strategy verification configuration information, device running state data of at least one device for strategy verification from historical running state data of a data center; the device running state data comprises a plurality of signals representing device running states;

[0021] pushing the plurality of signals representing device running states of the at least one device into a business sandbox according to signal generation time sequences, and playing back the plurality of signals representing device running states of the at least one device through the business sandbox to simulate a device running scenario of the at least one device;

[0022] performing fault detection through the fault detection strategy during simulation of the device running scenario, and obtaining a fault detection result;

[0023] According to the fault detection result, a verification result of the fault detection strategy is obtained.

[0024] In a fourth aspect, the present application further provides a computer readable storage medium. The computer readable storage medium has a computer program stored thereon, and the computer program, when executed by a processor, implements the following steps:

[0025] obtaining a fault detection strategy to be verified and strategy verification configuration information;

[0026] According to the strategy verification configuration information, device running state data of at least one device used for strategy verification is obtained from historical running state data of the data center; the device running state data includes a plurality of signals representing device running states;

[0027] The plurality of signals representing device running states of the at least one device are pushed into a business sandbox according to signal generation timing, and the plurality of signals representing device running states of the at least one device are played back by the business sandbox to simulate a device running scenario of the at least one device;

[0028] In the process of simulating the device running scenario, fault detection is performed by the fault detection strategy to obtain a fault detection result;

[0029] According to the fault detection result, a verification result of the fault detection strategy is obtained.

[0030] In a fifth aspect, the present application further provides a computer program product. The computer program product includes a computer program, and the computer program, when executed by a processor, implements the following steps:

[0031] obtaining a fault detection strategy to be verified and strategy verification configuration information;

[0032] According to the strategy verification configuration information, device running state data of at least one device used for strategy verification is obtained from historical running state data of the data center; the device running state data includes a plurality of signals representing device running states;

[0033] The plurality of signals representing device running states of the at least one device are pushed into a business sandbox according to signal generation timing, and the plurality of signals representing device running states of the at least one device are played back by the business sandbox to simulate a device running scenario of the at least one device;

[0034] In the process of simulating the device running scenario, fault detection is performed by the fault detection strategy to obtain a fault detection result;

[0035] According to the fault detection result, a verification result of the fault detection strategy is obtained.

[0036] The fault detection strategy verification method, device, computer device, storage medium and computer program product can obtain device running state data of at least one device for strategy verification from historical running state data of the data center based on the obtained fault detection strategy to be verified and the strategy verification configuration information, the device running state data includes a plurality of signals representing device running states, and the plurality of signals representing device running states of the at least one device are pushed into the business sandbox according to the signal generation time sequence, so that the plurality of signals representing device running states of the at least one device are played back by the business sandbox. The device running scene of the at least one device can be simulated by signal playback, and then the fault detection strategy can be used for fault detection in the process of simulating the device running scene to obtain a fault detection result. According to the fault detection result, a verification result of the fault detection strategy is obtained. In the whole process, the device running state data in the real scene is used to verify the fault detection strategy by directly playing back the plurality of signals representing device running states of the at least one device. This not only avoids manually building a fault scene and improves the verification efficiency of the fault detection strategy, but also ensures the accuracy of the fault detection strategy verification by using real data for verification. BRIEF DESCRIPTION OF DRAWINGS

[0037] Figure 1 An application environment diagram of the fault detection strategy verification method in one embodiment;

[0038] Figure 2 A flowchart of the fault detection strategy verification method in one embodiment;

[0039] Figure 3 A structure diagram of a data center in one embodiment;

[0040] Figure 4 A diagram of pushing signals representing device running states into a business sandbox in one embodiment;

[0041] Figure 5 A diagram of obtaining device running state data through fault scene prediction in one embodiment;

[0042] Figure 6 A diagram of training a fault scene prediction model in one embodiment;

[0043] Figure 7 A flowchart of fault visualization in one embodiment;

[0044] Figure 8A deployment architecture diagram of the alarm playback platform in one embodiment;

[0045] Figure 9 A core logic diagram of the alarm playback platform in one embodiment;

[0046] Figure 10 A verification logic diagram of the fault detection strategy verification method in one embodiment;

[0047] Figure 11 A schematic diagram of the alarm strategy verification interface in one embodiment;

[0048] Figure 12 A schematic diagram of the fault scenario review data interface in one embodiment;

[0049] Figure 13 A structural block diagram of the fault detection strategy verification device in one embodiment;

[0050] Figure 14 An internal structure diagram of the computer device in one embodiment. DETAILED DESCRIPTION

[0051] In order to make the purposes, technical solutions and advantages of the present application clearer, the present application will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and do not limit the present application.

[0052] The fault detection strategy verification method provided by the embodiments of the present application can be applied in an application environment as shown in the figure. Figure 1 The data center 102 communicates with the server 104 through a network. The data storage system can store data required to be processed by the server 104. The data storage system can be integrated on the server 104, or placed on the cloud or other servers. The server 104 obtains a fault detection strategy to be verified and strategy verification configuration information, obtains device running state data of at least one device for strategy verification from historical running state data of the data center 102 according to the strategy verification configuration information, the device running state data includes a plurality of signals representing the device running state, pushes the plurality of signals representing the device running state of the at least one device to a business sandbox according to the signal generation time sequence, plays back the plurality of signals representing the device running state of the at least one device through the business sandbox to simulate a device running scene of the at least one device, detects a fault through the fault detection strategy in the process of simulating the device running scene, obtains a fault detection result, and obtains a verification result of the fault detection strategy according to the fault detection result.

[0053] The server 104 can be a stand-alone physical server, a server cluster composed of multiple physical servers, or a distributed system, and can also be a cloud server providing cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDNs, and basic cloud computing services such as big data and artificial intelligence platforms.

[0054] In one embodiment, as shown in Figure 2 A fault detection strategy verification method is provided, which can be executed by a terminal or a server alone or cooperatively by a terminal and a server. In the embodiments of the present application, the method is applied to the server, which includes the following steps:

[0055] In step 202, the fault detection strategy to be verified and the strategy verification configuration information are obtained.

[0056] The fault detection strategy refers to a strategy for detecting and determining the cause of a fault in a data center during operation of the equipment in the data center. For example, the fault detection strategy can be a strategy indicating a fault detection operation rule configured by a developer. It can be understood that the fault detection strategy in the embodiments can be obtained by updating an existing old fault detection strategy, or by combining multiple old fault detection strategies, or can be a new fault detection strategy completely different from the old fault detection strategy.

[0057] The strategy verification configuration information refers to information that needs to be configured when verifying the fault detection strategy to be verified. The device operation state data of at least one device used for strategy verification can be obtained through the strategy verification configuration information. For example, the strategy verification configuration information can be a playback time range, a device identifier, a strategy verification signal identifier, etc. The playback time range is used to specify the time range of the generated device operation state data to be obtained. The device identifier is used to specify the device operation state data of which device in the data center needs to be obtained. The strategy verification signal identifier is used to specify the signal type of the device operation state data to be obtained.

[0058] Specifically, when the fault detection strategy needs to be verified, the server can obtain the fault detection strategy to be verified and the strategy verification configuration information. In a specific application, when the fault detection strategy needs to be verified, the server receives a strategy verification request, and in response to the strategy verification request, the fault detection strategy to be verified and the strategy verification configuration information indicated by the strategy verification request can be determined. In a specific application, the strategy verification configuration information can be pre-configured by the developer according to the fault detection strategy to be verified, i.e., configured according to the actual application scenario.

[0059] It can be understood that the configured strategy verification configuration information is not completely the same for different fault detection strategies, and the strategy verification configuration information can specify a playback time range, at least one device for strategy verification, and specific device running state data, etc.

[0060] In step 204, according to the strategy verification configuration information, device running state data of at least one device for strategy verification is obtained from historical running state data of the data center; the device running state data includes a plurality of signals representing the running state of the device.

[0061] The data center refers to a facility for housing computer systems and related components, usually including redundant and backup power supplies, redundant data communication connections, environmental control (such as air conditioning, fire extinguishers) and various security devices. For example, as shown in Figure 3 The data center includes a plurality of modules (module 1, module 2, …, module N), each module including a plurality of devices (device 1, device 2, …, device n) for providing data services. The device here can be a server that provides data services.

[0062] The historical running state data refers to data collected during the operation of the data center to represent the running state of the data center. For example, the historical running state data can be measurement point data collected during the operation of the data center. The measurement point data refers to various key indicators and parameters collected during the operation of the data center, which can include temperature, power consumption, network traffic, storage utilization, air conditioning system efficiency, etc. of the device providing data services.

[0063] It can be understood that by analyzing these measurement point data, the health status, performance level and resource utilization of the data center can be evaluated for optimization and decision-making, so when the data center fails, there must be abnormal measurement point data, which can be determined by analyzing the measurement point data.

[0064] The device running state data refers to data collected during the operation of the device in the data center to represent the running state of the device. It can be understood that the device running state data of the device is included in the historical running state data of the data center. For example, the device running state data can be at least one of operating temperature, ambient temperature of the device, input current of the device, output current of the device, input voltage of the device, output voltage of the device, etc.

[0065] The device operation state data includes a plurality of signals representing device operation states, and each signal representing a device operation state indicates a device operation state. For example, the signal representing a device operation state can be a heat signal, such as a signal indicating the operating temperature of the device, a signal indicating the ambient temperature of the device, etc. For example, the heat signal can be a temperature value. For another example, the signal representing a device operation state can be an electrical signal, such as a signal indicating the input current of the device, a signal indicating the output current of the device, a signal indicating the input voltage of the device, a signal indicating the output voltage of the device, etc. For example, the electrical signal can be a current value, a voltage value, etc.

[0066] Specifically, the policy verification configuration information indicates a device for policy verification and device operation state data of the device. According to the policy verification configuration information, the server can determine the operation state data filtering condition, and then can obtain the device operation state data of the at least one device for policy verification from the historical operation state data of the data center according to the operation state data filtering condition. The device operation state data includes a plurality of signals representing device operation states.

[0067] It can be understood that if the fault detection policy to be verified is used to detect a fault scenario that has occurred, there is device operation state data that generates the fault scenario in the historical operation state data of the data center. Therefore, the server only needs to obtain the device operation state data of the at least one device for policy verification from the historical operation state data of the data center according to the operation state data filtering condition. If the fault detection policy to be verified is used to detect an unknown fault scenario, i.e., the fault detection policy is an unknown fault scenario prediction policy, there may be device operation state data that generates the unknown fault scenario in the historical operation state data of the data center, but it cannot be directly obtained according to the operation state data filtering condition. Therefore, the server needs to combine the fault detection policy and the operation state data filtering condition to filter the device operation state data of the at least one device for policy verification from the historical operation state data of the data center.

[0068] In specific applications, the operation state data filtering condition can include a time dimension filtering condition, such as a playback time range including a start time and an end time, and can also include a physical dimension filtering condition, such as a device identifier, a policy verification signal identifier, etc.

[0069] In step 206, the plurality of signals representing device operation states of the at least one device are pushed into the business sandbox according to the signal generation sequence, and the plurality of signals representing device operation states of the at least one device are played back by the business sandbox to simulate the device operation scenario of the at least one device.

[0070] The signal generation sequence refers to the time sequence of the plurality of signals representing the device running state of the at least one device generated in the running process of the data center. The business sandbox, also known as a business sandbox, is an isolated environment provided for a running program, and in this embodiment, it provides an isolated environment for verification of the fault detection strategy. The business sandbox can simulate the actual production environment, which is actually a copy of the production environment. When the business sandbox is created, all system configurations of the current production environment will be copied. It can be understood that the business sandbox and the production environment are completely independent of each other, and any operation performed in the business sandbox will not affect the production environment. In this embodiment, the production environment is the running environment of the data center, and the signal playback performed in the business sandbox will not affect the normal operation of the data center.

[0071] Specifically, after obtaining the device running state data of the at least one device for strategy verification, the server pushes the plurality of signals representing the device running state of the at least one device into the business sandbox according to the signal generation sequence. Through the business sandbox, the plurality of signals representing the device running state of the at least one device are played back in sequence according to the signal generation sequence to simulate the device running scenario of the at least one device.

[0072] In a specific application, the server can use a message middleware to push the plurality of signals representing the device running state of the at least one device into the business sandbox according to the signal generation sequence, that is, the server can first push the plurality of signals representing the device running state of the at least one device into the message middleware in sequence according to the signal generation sequence, and then push the plurality of signals representing the device running state of the at least one device into the business sandbox through the message middleware. It can be understood that since the plurality of signals representing the device running state of the at least one device are pushed into the message middleware in sequence according to the signal generation sequence, the receiving order of the plurality of signals representing the device running state of the at least one device received by the business sandbox is also the same as the signal generation sequence, that is, the message middleware can be used to realize the in-sequence pushing of the plurality of signals representing the device running state of the at least one device, so that the business sandbox can accurately simulate the device running scenario of the at least one device through signal playback.

[0073] In a specific application, it is assumed that the plurality of signals representing the device running state of the at least one device include signal 1, signal 2, signal 3, and signal 4, and the signal generation sequence is signal 1, signal 3, signal 4, and signal 2. The server will first push signal 1 to the message middleware, then push signal 3 to the message middleware, push signal 4 to the message middleware, and finally push signal 2 to the message middleware.

[0074] In a specific application, the business sandbox includes multiple sub-sandboxes corresponding to various business failure scenarios. When multiple signals representing the operating state of the at least one device are pushed into the business sandbox according to the signal generation time sequence, if the multiple signals representing the operating state of the device carry a business tag indicating a business failure scenario, the server will push each signal representing the operating state of the device into the sub-sandbox corresponding to the business failure scenario indicated by the business tag according to the signal generation time sequence based on the business tag. The signals representing the operating state of the device are played back in the sub-sandbox corresponding to the business failure scenario indicated by the business tag according to the signal generation time sequence to simulate the device operating scenario of the at least one device.

[0075] In a specific application, the business failure scenario can be an alarm scenario, an operation event scenario, a change scenario, etc. Among them, the alarm refers to when an abnormality or problem occurs in the data center, an alarm can be issued to notify the administrator or relevant personnel by detecting the change of the measurement point data. These alarms can involve device failure, temperature anomaly, power supply problem, etc. to ensure that problems can be handled in a timely manner to ensure the normal operation of the data center. The operation event refers to when the data center alarm occurs, the underlying reason may be classified as the same fault causing, and these one or more triggered alarms form an event scenario. The change refers to the planned modification or adjustment of the data center to improve performance, reliability, security or efficiency. This includes replacement of hardware devices, updating and upgrading of software, and adjustment of network configuration, etc. The purpose of the change is to ensure that the data center can adapt to changing needs and maintain good operating status.

[0076] It can be understood that according to the business failure scenario indicated by the fault detection strategy to be verified, the developer can pre-configure the business tag in the strategy verification configuration information. When the server obtains the device operating state data of the at least one device for strategy verification from the historical operating state data of the data center according to the strategy verification configuration information, the server will use the business tag to filter the historical operating state data of the data center, and filter out the device operating state data of at least one device associated with the business failure scenario indicated by the business tag. For example, the device operating state data of at least one device causing the business failure scenario indicated by the business tag.

[0077] In a specific application, if the service label is configured in the policy verification configuration information, the number of configured service labels can be one or multiple. In the case of multiple service labels, for each signal representing the running state of the device in the plurality of signals representing the running state of the device of the at least one device, the correspondence between the signal representing the running state of the device and the service label can be one-to-one or one-to-many. If the correspondence between the signal representing the running state of the device and the service label is one-to-one, when the signal representing the running state of the device is pushed into the service sandbox, the signal representing the running state of the device only needs to be pushed into the sub-sandbox of the service failure scenario indicated by the corresponding one service label. If the correspondence between the signal representing the running state of the device and the service label is one-to-many, when the signal representing the running state of the device is pushed into the service sandbox, the signal representing the running state of the device needs to be pushed into the sub-sandbox of the service failure scenario indicated by the corresponding multiple service labels respectively.

[0078] In a specific application, as shown in Figure 4 , assuming that the plurality of signals representing the running state of the device of the at least one device include signal 1, signal 2, signal 3, signal 4, signal 5, signal 6, signal 7, signal 8, and signal 9, the signal generation sequence is signal 1, signal 2, signal 3, signal 4, signal 5, signal 6, signal 7, signal 8, and signal 9, the service failure scenario indicated by the service label carried by signal 1 includes the change scenario and the alarm scenario, the service failure scenario indicated by the service label carried by signal 2 and signal 5 is the change scenario, the service failure scenario indicated by the service label carried by signal 3 and signal 6 is the alarm scenario, the service failure scenario indicated by the service label carried by signal 4 and signal 7 is the operation event scenario, and the service failure scenario indicated by the service label carried by signal 8 and signal 9 is the other scenario, the server will push the plurality of signals representing the running state of the device of the at least one device into the sub-sandbox of the corresponding service failure scenario in sequence according to the signal generation sequence. The other scenario refers to other scenarios in addition to the change scenario, the alarm scenario, and the operation event scenario, which can be configured according to actual application scenarios.

[0079] Further, as shown in Figure 4 , the message middleware further includes a global cache database that can cache the signals representing the running state of the device on demand. The signals representing the running state of the device can be cached, and the database can also pull the signals representing the running state of the device from the service sandbox as scenario signals for caching, so that when the scenario needs to be restored later, the service sandbox can directly pull the scenario signals from the database.

[0080] In one specific application, the server can utilize the message middleware to push the plurality of signals indicative of the device running state of the at least one device, and the message middleware comprises a data pushing pipeline corresponding to the service failure scenario indicated by each service tag. The server can sequentially push the plurality of signals indicative of the device running state of the at least one device to the corresponding data pushing pipeline in the message middleware according to the signal generation timing.

[0081] In step 208, the fault detection strategy is used to detect faults in the process of simulating the device running scenario, and a fault detection result is obtained.

[0082] The fault detection result refers to a fault alarm result obtained by using the fault detection strategy to detect faults in the process of simulating the device running scenario. For example, the fault detection result can include a fault device, a fault occurrence time, a fault type, and the like.

[0083] Specifically, in the process of simulating the device running scenario, the server can use the fault detection strategy to detect faults and obtain a fault detection result. In one specific application, the fault detection strategy indicates a fault detection operation rule. The server can determine the fault detection operation rule by analyzing the fault detection strategy, and then use the fault detection operation rule to detect faults. In one specific application, the fault detection operation rule can be configured according to an actual application scenario. For example, the fault detection operation rule can be a fault detection expression. By inputting the signal indicative of the device running state into the fault detection expression, the fault can be detected.

[0084] In step 210, a verification result of the fault detection strategy is obtained according to the fault detection result.

[0085] Specifically, the server can obtain the verification result of the fault detection strategy by analyzing the fault detection result. In one specific application, if there is real fault information corresponding to the device running state data of the at least one device, the server can analyze the fault detection result in combination with the real fault information to obtain the verification result of the fault detection strategy. If there is no real fault information, the server can compare the second fault type in the fault detection result with the third fault type in the fault detection strategy to obtain the verification result of the fault detection strategy.

[0086] The fault detection strategy verification method described above, on the basis of obtaining the fault detection strategy to be verified and the strategy verification configuration information, uses the strategy verification configuration information to obtain device running state data of at least one device for strategy verification from historical running state data of the data center. The device running state data includes a plurality of signals representing device running states. By pushing the plurality of signals representing device running states of at least one device into a business sandbox according to the signal generation time sequence, the business sandbox plays back the plurality of signals representing device running states of at least one device. The simulation of the device running scene of at least one device can be realized by signal playback. Then, the fault detection strategy can be used for fault detection in the process of simulating the device running scene, and the fault detection result is obtained. According to the fault detection result, the verification result of the fault detection strategy is obtained. In the whole process, the device running state data in the real scene is used to verify the fault detection strategy by directly playing back the plurality of signals representing device running states of at least one device. This not only avoids manually building a fault scene and improves the verification efficiency of the fault detection strategy, but also ensures the accuracy of the fault detection strategy verification by using real data for verification.

[0087] In one embodiment, pushing the plurality of signals representing device running states of at least one device into a business sandbox according to the signal generation time sequence, playing back the plurality of signals representing device running states of at least one device by the business sandbox, and simulating the device running scene of at least one device include:

[0088] According to the strategy verification configuration information, the speed-up clock ratio is determined;

[0089] The plurality of signals representing device running states of at least one device are pushed into the business sandbox according to the speed-up clock ratio and the signal generation time sequence;

[0090] The plurality of signals representing device running states of at least one device are played back at a speed-up rate by the business sandbox to simulate the device running scene of at least one device.

[0091] The speed-up clock ratio refers to a clock ratio for speed-up playback of signals representing the running state of the device based on a speed-up clock system. The speed-up clock system is a clock synchronization technology that improves the performance of a system by multiplying the clock frequency. Specifically, the speed-up clock system supports strategic time delay rules and fault device order preservation capabilities by scaling the entire timing system through time scaling similar to a map scale, and can play back the obtained signals representing the running state of the device of the at least one device, or play back all data of the historical running state data of the data center. In the speed-up clock system, the clock signal is accelerated or amplified to have a higher frequency than the original clock frequency. In this way, the system can complete more operations in the same time, thereby improving the running speed and performance of the system. In the present embodiment, the signals representing the running state of the device are accelerated or amplified to have a higher frequency than the original clock frequency, so that speed-up playback can be achieved.

[0092] The speed-up playback is a way to accelerate or slow down the alarm triggering speed, which allows the data center alarm to be faster or slower, so as to more efficiently verify or predict the running scenario of the data center within a certain time range. The speed-up playback involved in the present embodiment is mainly a way to accelerate the alarm triggering speed, and the order preservation processing is performed on the timers, delay strategies, sleep functions, interpolation algorithms, etc. involved in the signal playback process by adjusting the playback task execution speed and changing the triggering frequency of the timer. That is, during speed-up playback, each signal representing the running state of the device is generated according to the signal generation timing and the speed-up clock ratio, and the fault detection strategy for each signal representing the running state of the device is also speeded up.

[0093] Specifically, since the data amount of the signals representing the running state of the device of the at least one device is usually large, if the signal playback is performed according to the original clock system, the required signal playback time will be long, which will result in low signal playback efficiency of the business sandbox. Therefore, the clock ratio for speed-up playback of the signals representing the running state of the device, i.e., the speed-up clock ratio, is usually included in the strategy verification configuration information. After determining the speed-up clock ratio according to the strategy verification configuration information, the server can push the signals representing the running state of the device of the at least one device into the business sandbox according to the speed-up clock ratio and the signal generation timing, and the business sandbox can perform speed-up playback of the signals representing the running state of the device of the at least one device to simulate the device running scenario of the at least one device.

[0094] In a specific application, the server will perform timing design of the frequency multiplier according to the frequency multiplier clock ratio, so as to simulate a high-frequency clock signal by using the frequency multiplier to control the execution speed of the signal playback process, and ensure the stability, phase accuracy and timing consistency of the clock signal, that is, the server will use the frequency multiplier to push a plurality of signals representing the running state of at least one device into the service sandbox according to the frequency multiplier clock ratio and the signal generation timing. The frequency multiplier can be understood as a program that controls the execution speed of the signal playback process. It can be understood that, in order to meet the requirement of frequency multiplication playback, the server can control the execution speed of the signal playback process by means of priority scheduling, multithreading, multi-coroutine and other technical means, and can also adjust the frequency multiplication algorithm and the execution speed of the signal playback process in real time to improve the performance of signal playback.

[0095] In this embodiment, by determining the frequency multiplier clock ratio according to the policy verification configuration information, the frequency multiplier clock ratio can be used to control the frequency multiplication playback of the plurality of signals representing the running state of at least one device in the service sandbox, and the execution speed of the signal playback process can be improved by increasing the signal playback speed, so as to realize efficient signal playback and improve the verification efficiency of the fault detection strategy.

[0096] In one embodiment, according to the policy verification configuration information, the device running state data of at least one device used for policy verification is obtained from the historical running state data of the data center, including:

[0097] According to the policy verification configuration information, the playback time range is determined;

[0098] Based on the playback time range, the device running state data of at least one device used for policy verification is obtained from the historical running state data of the data center.

[0099] The playback time range is used to specify the generation time of the device running state data that needs to be played back, and can be configured according to the actual application scenario. For example, the playback time range can specifically include a specified start time and an end time. For another example, the playback time range can specifically be a difference from the current time. For example, the playback time range can be one day, two days, etc.

[0100] Specifically, when verifying the fault detection strategy, the playback time range needs to be specified in the policy verification configuration information, so that the server determines which time period of device running state data needs to be obtained based on the playback time range, and obtains the device running state data of at least one device used for policy verification from the historical running state data of the data center.

[0101] In a specific application, the playback time range can be understood as a filtering condition in the time dimension. If only the playback time range is included in the policy verification configuration information, the server directly filters the device running state data according to the playback time range. If the filtering condition in the physical dimension is also included in the policy verification configuration information, the server needs to combine the filtering condition in the physical dimension and the playback time range to filter the device running state data. The playback time range can be set by the developer according to the actual application scenario when configuring the policy verification configuration information.

[0102] In this embodiment, by determining the playback time range according to the policy verification configuration information, the device running state data of at least one device for policy verification can be obtained from the historical running state data of the data center by using the specified playback time range.

[0103] In one embodiment, based on the playback time range, the device running state data of at least one device for policy verification is obtained from the historical running state data of the data center, including:

[0104] When the fault detection policy is not the unknown fault scenario prediction policy, the device identifier and the policy verification signal identifier are determined according to the policy verification configuration information.

[0105] Based on the playback time range, the device identifier and the policy verification signal identifier, the device running state data of at least one device for policy verification is obtained from the historical running state data of the data center.

[0106] The unknown fault scenario prediction policy refers to a policy for predicting unknown fault scenarios. It can be understood that the unknown fault scenario refers to a fault scenario that may occur in the data center scenario. Here, the possibility of occurrence refers to a fault scenario that is not directly detected based on the existing fault detection policy. For example, if fault scenario A and fault scenario B are directly detected based on the existing fault detection policy, but there is no fault scenario that detects fault scenario A + fault scenario B, fault scenario A + fault scenario B can be understood as a possible fault scenario, that is, such a fault scenario may exist, so it needs to be predicted and output the corresponding response processing scheme in advance.

[0107] The device identifier is an identifier used to identify a device in the data center. It can be understood that the identifiers of different devices in the data center are different. For example, the device identifier can be a string used to identify a device in the data center. The policy verification signal identifier is an identifier of a signal type that needs to be played back when verifying the fault detection policy. It can be understood that the identifiers of different types of signals are not completely the same. For example, the policy verification signal identifier can be an identifier of a collected signal, which is an original signal collected from the data center. For example, the collected signal can be point data collected from the data center. For another example, the policy verification signal identifier can be an identifier of a dictionary signal, which is a signal processed from the original signal collected from the data center. For example, the dictionary signal can be data processed from the point data collected from the data center. Here, the processing of the point data can be a simple operation on the point data, such as superposition.

[0108] Specifically, when the fault detection policy is not the unknown fault scenario prediction policy, it means that the fault detection policy to be verified is mainly for fault detection of the detected fault scenario. The server will first determine the device identifier and the policy verification signal identifier according to the policy verification configuration information, and then obtain the device running state data of at least one device for policy verification from the historical running state data of the data center based on the playback time range, the device identifier, and the policy verification signal identifier.

[0109] In a specific application, the device identifier can be directly included in the policy verification configuration information, and the server can directly obtain the device identifier from the policy verification configuration information. The policy verification configuration information can also include a module identifier indicating a module in the data center. The server needs to determine the device identifier based on the module identifier. It can be understood that based on the module identifier, a specific module can be located, and then the device identifiers of the multiple devices included in the module can be determined.

[0110] In a specific application, the historical running state data of the data center can be divided into data based on collected signals and data based on dictionary signals, and stored in different databases. When the server obtains the device running state data of at least one device for policy verification, it needs to first determine which database to obtain data from based on the policy verification signal identifier, and then obtain data from the determined database based on the playback time range and the device identifier.

[0111] In one specific application, the data based on the collected signals can be stored in a point database, and the data based on the dictionary signals can be stored in an alarm database. Then, the server verifies the signal identifier according to the strategy, determines whether to obtain data from the point database or the alarm database, and obtains data from the determined database based on the playback time range and the device identifier.

[0112] In the embodiment, when the fault detection strategy is not the unknown fault scenario prediction strategy, the device identifier and the strategy verification signal identifier are determined according to the strategy verification configuration information. The device running state data of the at least one device for strategy verification can be obtained from the historical running state data of the data center by using the specified playback time range, the device identifier, and the strategy verification signal identifier.

[0113] In one embodiment, obtaining the device running state data of the at least one device for strategy verification from the historical running state data of the data center based on the playback time range comprises:

[0114] When the fault detection strategy is the unknown fault scenario prediction strategy, the historical running state data of the data center is classified into a plurality of historical fault scenarios, and the device running state data of each historical fault scenario is obtained.

[0115] The device running state data of the at least one device for strategy verification is selected from the device running state data of the plurality of historical fault scenarios according to the playback time range and at least two fault scenario types indicated by the unknown fault scenario prediction strategy.

[0116] The historical fault scenario refers to a fault scenario that has been detected in the data center. The fault scenario type refers to the type of the historical fault scenario.

[0117] Specifically, when the fault detection strategy is the unknown fault scenario prediction strategy, it means that the fault detection strategy to be verified is mainly for fault detection of possible fault scenarios. Therefore, the device running state data of the at least one device for strategy verification associated with the possible fault scenarios needs to be selected from the historical running state data of the data center. At this time, the server first classifies the historical running state data of the data center into a plurality of historical fault scenarios, and obtains the device running state data of each historical fault scenario. Then, the device running state data of each of the at least two fault scenario types is selected from the device running state data of the plurality of historical fault scenarios according to the playback time range and the at least two fault scenario types indicated by the unknown fault scenario prediction strategy. Finally, the device running state data of the at least one device for strategy verification is selected by using the device running state data of each of the at least two fault scenario types.

[0118] In a specific application, the server can classify the historical running state data of the data center through the pre-trained fault scenario classifier. The pre-trained fault scenario classifier can be trained according to an actual application scenario. By inputting the historical running state data into the pre-trained fault scenario classifier, the corresponding historical fault scenario of the historical running state data can be determined.

[0119] In the embodiment, when the fault detection strategy is the unknown fault scenario prediction strategy, the historical fault scenarios of the data center are classified, and the device running state data of each historical fault scenario is obtained. Then, the replay time range and the at least two fault scenario types indicated by the unknown fault scenario prediction strategy are used to select the real data associated with the unknown fault scenario prediction strategy from the device running state data of each historical fault scenario. The verification using the real data associated with the unknown fault scenario prediction strategy can ensure the accuracy of the fault detection strategy verification.

[0120] In one embodiment, selecting the device running state data of at least one device for strategy verification from the device running state data of each historical fault scenario according to the replay time range and the at least two fault scenario types indicated by the unknown fault scenario prediction strategy comprises:

[0121] According to the replay time range and the at least two fault scenario types indicated by the unknown fault scenario prediction strategy, the device running state data corresponding to each of the at least two fault scenario types is selected from the device running state data of each historical fault scenario.

[0122] Based on the device running state data corresponding to each of the at least two fault scenario types, a fault scenario prediction model is trained.

[0123] Through the fault scenario prediction model, the device running state data of at least one device for strategy verification is obtained from the historical running state data of the data center.

[0124] Specifically, based on the playback time range and at least two fault scenario types indicated by the unknown fault scenario prediction strategy, the server can select the corresponding device operating status data for each of the at least two fault scenario types from the device operating status data of multiple historical fault scenarios. Using the corresponding device operating status data for each of the at least two fault scenario types, a model can be trained. Using the unknown fault scenario as the prediction label, a fault scenario prediction model capable of accurately predicting unknown fault scenarios can be trained. This model can then be used to predict fault scenarios from the historical operating status data of the data center, determining the corresponding device operating status data for the unknown fault scenarios indicated by the unknown fault scenario prediction strategy. This device operating status data for the unknown fault scenarios is then used as the device operating status data for at least one device for strategy verification. The method for training the fault scenario prediction model and the model structure can be configured according to the actual application scenario.

[0125] In specific applications, such as Figure 5 As shown, by classifying the historical operational status data of the data center into fault scenarios, the device operational status data of each of the multiple historical fault scenarios can be obtained. Based on this, according to the playback time range and at least two fault scenario types indicated by the unknown fault scenario prediction strategy, the corresponding device operational status data of each of the at least two fault scenario types can be selected from the device operational status data of each of the multiple historical fault scenarios. Then, the corresponding device operational status data of each of the at least two fault scenario types can be used to train a fault scenario prediction model. Through the fault scenario prediction model, the device operational status data of at least one device for strategy verification can be obtained from the historical operational status data of the data center.

[0126] In one specific application, the at least two fault scenario types indicated by the unknown fault scenario prediction strategy are fault scenario A + fault scenario C, and the historical fault scenarios include fault scenario A, fault scenario B, fault scenario C, fault scenario D, and fault scenario E. By classifying the historical running state data of the data center according to fault scenarios, the device running state data of fault scenario A, fault scenario B, fault scenario C, fault scenario D, and fault scenario E can be obtained. According to the playback time range and the at least two fault scenario types (fault scenario A + fault scenario C) indicated by the unknown fault scenario prediction strategy, the device running state data of fault scenario A and fault scenario C can be selected. Then, the device running state data of fault scenario A and fault scenario C can be used to train a fault scenario prediction model. The historical running state data of the data center can be predicted according to the fault scenario prediction model to determine the device running state data corresponding to the unknown fault scenario (fault scenario A + fault scenario C) indicated by the unknown fault scenario prediction strategy. The device running state data corresponding to the unknown fault scenario (fault scenario A + fault scenario C) can be used as the device running state data of at least one device for strategy verification.

[0127] It can be understood that, when predicting the fault scenarios of the historical running state data of the data center according to the fault scenario prediction model, in order to improve the fault scenario prediction efficiency, the device running state data corresponding to the at least two fault scenario types can be predicted. That is, in the above application, after the fault scenario prediction model is trained, the device running state data of fault scenario A and fault scenario C can be predicted.

[0128] In this embodiment, the real data associated with the unknown fault scenario prediction strategy can be selected by first training the fault scenario prediction model according to the device running state data corresponding to the at least two fault scenario types, and then predicting the fault scenarios according to the fault scenario prediction model. The use of the real data associated with the unknown fault scenario prediction strategy for verification can ensure the accuracy of the fault detection strategy verification.

[0129] In one embodiment, the fault scenario prediction model is trained based on the device running state data corresponding to the at least two fault scenario types, including:

[0130] The device running state data corresponding to the at least two fault scenario types is mixed to obtain a mixed signal set.

[0131] The fault scenario prediction model is trained according to the mixed signal set.

[0132] Specifically, when training the fault scene prediction model, the server first mixes the signals representing the device running state in the device running state data corresponding to each of the at least two fault scene types by using the signal mixer to obtain a mixed signal set, and then trains the model according to the mixed signal set to obtain the fault scene prediction model.

[0133] In a specific application, when training the model according to the mixed signal set, the server splits the mixed signal set into a training signal set and a verification signal set, trains the model according to the training signal set and the verification signal set to obtain the fault scene prediction model. Specifically, the server can first train the fault scene prediction model according to the training signal set to obtain an initial scene prediction model, and then verify the initial scene prediction model by using the verification signal set. If the initial scene prediction model passes the verification, the initial scene prediction model that passes the verification is taken as the fault scene prediction model.

[0134] In one specific application, the process of training the fault scene prediction model can be as shown in Figure 6 The server first mixes the signals representing the device running state in the device running state data corresponding to each of the at least two fault scene types by using the signal mixer to obtain a mixed signal set, and then splits the mixed signal set into a training signal set and a verification signal set, and trains the model according to the training signal set and the verification signal set to obtain the fault scene prediction model.

[0135] In this embodiment, by mixing the signals representing the device running state in the device running state data corresponding to each of the at least two fault scene types, a mixed signal set can be obtained, and then the mixed signal set can be used for model training to obtain a fault scene prediction model that can accurately predict unknown fault scenes. Therefore, the fault scene prediction model can be used to select real data associated with the unknown fault scene prediction strategy, and the use of real data associated with the unknown fault scene prediction strategy for verification can ensure the accuracy of the fault detection strategy verification.

[0136] In one embodiment, the fault detection strategy verification method further comprises:

[0137] In response to the fault visualization request, the visual time range indicated by the fault visualization request is determined, and the speed clock ratio is determined according to the strategy verification configuration information. The time axis scale of the signal display time axis is determined based on the speed clock ratio.

[0138] In the process of playing back the plurality of signals representing the running state of the at least one device, when playing back the signals within the visual time range, a signal trend graph is generated and displayed based on the time axis scale of the signal display time axis and the signals within the visual time range.

[0139] Among them, the fault visualization refers to the process of displaying data changes in a time range through a time axis, highlighting the playback time period and fault impact information, and performing real-time data changes, accompanying fault scene changes, escalation, and diagnosis. The visual time range refers to a time range displayed through a time axis. The signal display time axis refers to a time axis for displaying signals representing the running state of the device. The time axis scale

[0140] Specifically, if fault visualization is needed, the developer can initiate a fault visualization request. After receiving the fault visualization request, the server will determine the visual time range indicated by the fault visualization request and verify the configuration information according to the strategy. The server will determine the speed clock ratio, determine the time axis scale of the signal display time axis using the signal frequency multiplier based on the speed clock ratio, and generate and display a signal trend graph based on the time axis scale of the signal display time axis and the signals within the visual time range when playing back the signals within the visual time range in the process of playing back the plurality of signals representing the running state of the at least one device. It can be understood that the fault situation can be intuitively displayed through data changes by the signal trend graph.

[0141] In specific applications, the server also provides services such as sliding window playback and fault scene timing switching when displaying the signal trend graph. The developer can better observe data changes through sliding window playback and fault scene timing switching to determine the fault situation.

[0142] In a specific application, the process of fault visualization can be as Figure 7 shown. The server will determine the visual time range indicated by the fault visualization request and verify the configuration information according to the strategy. The server will determine the speed clock ratio, perform real-time time axis conversion using the signal frequency multiplier based on the speed clock ratio, determine the time axis scale of the signal display time axis, generate a signal trend graph based on the time axis scale of the signal display time axis and the signals within the visual time range when playing back the signals within the visual time range in the process of playing back the plurality of signals representing the running state of the at least one device, and display the signals within the display time range indicated by the sliding window switching request in response to the sliding window switching request. In this way, dynamic display is performed during signal playback.

[0143] In this embodiment, in response to the fault visualization request, on the basis of determining the visual time range and the time axis scale of the signal display time axis based on the speed clock ratio, when the signal in the visual time range is played back, the signal trend graph is generated and displayed, the fault visualization can be realized, and the fault condition can be intuitively displayed through data changes.

[0144] In one embodiment, the fault detection strategy verification method further comprises:

[0145] When there is a signal triggering a fault in the signal in the visual time range, the fault information indicated by the signal triggering the fault is determined;

[0146] On the signal trend graph, the fault information indicated by the signal triggering the fault is marked.

[0147] Specifically, when there is a signal triggering a fault in the signal in the visual time range, the server determines the fault information indicated by the signal triggering the fault, and marks the fault information indicated by the signal triggering the fault on the signal trend graph. In this way, the developer can intuitively perceive the fault condition, and on this basis, the server can generate a solution corresponding to the fault information based on the fault information and display it to provide a reference for solving the fault to the developer.

[0148] In one embodiment, the verification result of the fault detection strategy is obtained according to the fault detection result, which comprises:

[0149] When there is real fault information corresponding to the device running state data of at least one device, the real fault information is compared with the fault detection result to obtain the verification result of the fault detection strategy.

[0150] The real fault information refers to information related to the generated fault scene. For example, the real fault information can be fault device information, fault occurrence time, fault type, and the like related to the generated fault scene.

[0151] Specifically, the device running state data of at least one device can be device running state data generated in a fault scene, and there can be real fault information corresponding to the device running state data of at least one device. If there is real fault information corresponding to the device running state data of at least one device, the server can evaluate the fault detection function of the fault detection strategy by comparing the real fault information with the fault detection result to obtain the verification result of the fault detection strategy.

[0152] In the embodiment, in the presence of real fault information, the evaluation of the fault detection function of the fault detection strategy can be realized by comparing the real fault information with the fault detection information, and an accurate verification result of the fault detection strategy is obtained.

[0153] In one embodiment, comparing the real fault information with the fault detection result to obtain the verification result of the fault detection strategy comprises:

[0154] comparing the first fault device information in the real fault information with the second fault device information in the fault detection result to obtain a fault device verification result;

[0155] When the first fault device information and the second fault device information indicate at least one same fault device, comparing the first fault occurrence time of the same fault device in the real fault information with the second fault occurrence time of the same fault device in the fault detection result to obtain a fault timeliness verification result;

[0156] According to the fault device verification result and the fault timeliness verification result, the verification result of the fault detection strategy is obtained.

[0157] The fault device information refers to the information of the device in the data center that has a fault. The fault occurrence time refers to the time when the fault device has a fault.

[0158] Specifically, when comparing the real fault information with the fault detection result, the server will first compare the first fault device information in the real fault information with the second fault device information in the fault detection result to determine whether the fault devices indicated by the two are the same, and obtain a fault device verification result. When the first fault device information and the second fault device information indicate at least one same fault device, the first fault occurrence time of the same fault device in the real fault information is compared with the second fault occurrence time of the same fault device in the fault detection result to determine whether the fault detection strategy can detect the fault in time, and obtain a fault timeliness verification result. Finally, according to the fault device verification result and the fault timeliness verification result, the verification result of the fault detection strategy is obtained.

[0159] In specific applications, the real fault information is compared with the fault detection result to verify whether the fault detection strategy can cover the original device fault. Therefore, the fault devices indicated by the first fault device information and the second fault device information should be the same. If the fault devices indicated by the two are the same, the fault device verification result can be verified as passed. If the fault devices indicated by the two are not the same, the fault device verification result can be determined as not passed.

[0160] In a specific application, in the case that the fault device verification result is verified, the server also needs to compare the first fault occurrence time in the real fault information and the second fault occurrence time in the fault detection result of the same fault device indicated by the first fault device information and the second fault device information, to determine whether the fault detection strategy can detect the fault in time. It can be understood that when the first fault occurrence time and the second fault occurrence time of the same fault device meet the time difference threshold, it is considered that the fault detection strategy can detect the fault in time. If the first fault occurrence time and the second fault occurrence time of the same fault device do not meet the time difference threshold, it is considered that the fault detection strategy cannot detect the fault in time. The time difference threshold can be configured according to the actual application scenario. For example, the time difference threshold can be N seconds, where N is a positive integer.

[0161] In a specific application, when the number of same fault devices is single, and the fault detection strategy can detect the fault of the same fault device in time, it can be determined that the fault timeliness verification result is verified. When the number of same fault devices is multiple, it is necessary to determine the fault timeliness verification result in combination with whether the fault detection strategy can detect the faults of the multiple same fault devices in time, respectively.

[0162] Specifically, if the fault detection strategy can detect the faults of the multiple same fault devices in time, respectively, it can be determined that the fault timeliness verification result is verified. If only a part of the same fault devices can be detected in time for the multiple same fault devices, the server calculates the ratio of the part of the same fault devices to the total number of the same fault devices to determine the timeliness coverage rate of the fault detection strategy. Only when the timeliness coverage rate reaches the timeliness coverage rate threshold, can it be determined that the fault timeliness verification result is verified. The timeliness coverage rate threshold can be configured according to the actual application scenario, which is not limited in this embodiment.

[0163] In a specific application, when the fault detection strategy verification result is obtained, when the fault device verification result is verified and the fault timeliness verification result is verified, the server can determine that the fault detection strategy verification result is verified. In addition, the server can further calculate the first fault type coverage rate and determine the fault detection strategy verification result in combination with the first fault type coverage rate.

[0164] In this embodiment, by comparing the first fault device information and the second fault device information, the fault detection strategy can be verified from the coverage of the fault device, and a fault device verification result is obtained. By comparing the first fault occurrence time in the real fault information and the second fault occurrence time in the fault detection result of the same fault device, the fault detection strategy can be verified from the timeliness of fault detection, and a fault timeliness verification result is obtained. Then, the fault detection strategy verification result can be obtained by combining the fault device verification result and the fault timeliness verification result, and the accurate verification of the fault detection strategy is realized.

[0165] In one embodiment, obtaining the verification result of the fault detection strategy according to the fault device verification result and the fault timeliness verification result comprises:

[0166] comparing the first fault type in the real fault information with the second fault type in the fault detection result to obtain a first fault type coverage rate;

[0167] obtaining the verification result of the fault detection strategy according to the fault device verification result, the fault timeliness verification result, and the first fault type coverage rate.

[0168] The fault type refers to the type of the generated fault.

[0169] Specifically, when comparing the real fault information with the fault detection result, in addition to determining the fault device verification result and the fault timeliness verification result, the server also compares the first fault type in the real fault information with the second fault type in the fault detection result to determine whether the fault detection strategy can detect the type of the fault that has occurred, obtains the first fault type coverage rate, and obtains the verification result of the fault detection strategy according to the fault device verification result, the fault timeliness verification result, and the first fault type coverage rate.

[0170] In specific applications, the server determines the number of same fault types in the first fault type and the second fault type, calculates the ratio of the number of same fault types to the number of first fault types to obtain the first fault type coverage rate, and determines that the first fault type coverage rate meets the demand when the first fault type coverage rate reaches a first fault type coverage rate threshold. When the fault device verification result and the fault timeliness verification result are both verified, and the first fault type coverage rate reaches the first fault type coverage rate threshold, it is determined that the verification result of the fault detection strategy is verified. The first fault type coverage rate threshold can be configured according to the actual application scenario.

[0171] In this embodiment, by comparing the first fault type and the second fault type, the fault detection strategy can be verified from the coverage of the fault type, the first fault type coverage is obtained, and then the fault detection strategy verification result can be obtained by combining the fault device verification result, the fault timeliness verification result and the first fault type coverage, so as to realize accurate verification of the fault detection strategy.

[0172] In one embodiment, the fault detection strategy verification method further comprises:

[0173] When there is no real fault information, the second fault type in the fault detection result is compared with the third fault type in the fault detection strategy to obtain the verification result of the fault detection strategy.

[0174] Specifically, when there is no real fault information, the server compares the second fault type in the fault detection result with the third fault type in the fault detection strategy to determine whether the fault detection strategy can detect the expected third fault type, and obtains the verification result of the fault detection strategy. In a specific application, the server determines the number of same fault types in the second fault type and the third fault type, calculates the ratio of the number of same fault types to the number of third fault types, and obtains the second fault type coverage. When the second fault type coverage reaches the second fault type coverage threshold, it is determined that the second fault type coverage meets the demand. When the second fault type coverage meets the demand, it is determined that the verification result of the fault detection strategy is verified. The second fault type coverage threshold can be configured according to the actual application scenario.

[0175] It should be noted that when there is real fault information, the server can combine the fault device verification result, the fault timeliness verification result, the first fault type coverage and the second fault type coverage to determine the verification result of the fault detection strategy. Specifically, when the fault device verification result and the fault timeliness verification result are both verified, the first fault type coverage reaches the first fault type coverage threshold, and the second fault type coverage reaches the second fault type coverage threshold, it is determined that the verification result of the fault detection strategy is verified.

[0176] In this embodiment, by comparing the second fault type and the third fault type, the fault detection strategy can be verified from the coverage of the fault type, the second fault type coverage is obtained, and then the verification result of the fault detection strategy can be obtained by using the second fault type coverage, so as to realize accurate verification of the fault detection strategy.

[0177] In an embodiment, the technical solution of the present application is described by taking the fault detection strategy verification method of the present application applied to an alarm playback platform as an example. It can be understood that in the case of applying the fault detection strategy verification method of the present application to the alarm playback platform, various operation automation capabilities such as fault detection strategy rationality, alarm convergence, automatic transfer, and change plan formulation can be verified by data playback on the data center scene, simulating the field change or fault environment.

[0178] First, the main key technical points involved in the fault detection strategy verification method of the present application are described below. The fault detection strategy verification method of the present application mainly involves three key technical points, namely clock system construction, fault scene prediction, and fault visualization.

[0179] Among them, the clock system construction refers to building a new clock system through the real data center scene data (i.e. historical running state data of the data center) provided by the data center, scaling the entire time sequence system through a time scale similar to a map scale, supporting the time delay rule on the strategy, the fault device preservation sequence capability, and performing alarm playback on part of the historical running state data, or simultaneously performing second-level full data playback on the entire historical running state data of the data center. For example, if the data center includes 100 modules and generates 10,000 measurement point data per day, the 100 modules can be quickly played back according to a time scale of 100,000:1 for the entire year.

[0180] Among them, the fault scene prediction refers to generating a series of data center possible fault scene models after data analysis and machine learning on the existing fault scene data of the data center, and performing playback verification on the generated fault scene data, i.e. data playback verification and drilling in the data center.

[0181] Among them, the fault visualization refers to replaying the historical or unknown fault scene in the data center based on the clock system, visualizing the image, time range, etc. according to the machine room dimension, time sequence system, and providing the data change, characteristics, etc. of the fault point at each time node.

[0182] The inventor believes that although there is a way to verify the fault detection strategy through a test verification platform in the traditional technology, the current test verification platform mainly verifies the strategy by simulating random values or real scenes. Among them, the simulation of random values is efficient but cannot fully present the demand of real scenes, resulting in low accuracy of fault detection strategy verification and inability to guarantee the fault detection capability of the fault detection strategy. The real scene test needs manual operation of equipment and other cooperation, which is time-consuming and labor-intensive, and the efficiency is low.

[0183] Based on this, the application provides a fault detection strategy verification method capable of improving the verification efficiency of the fault detection strategy and the accuracy of the fault detection strategy verification. By collecting and saving historical real data, using appropriate tools and technologies, the past device running scenarios can be played back at double speed to perform fault detection, obtain fault detection results, and compare and analyze the real fault information and the fault detection results to detect the triggering conditions of alarms in various data center service scenarios.

[0184] In one embodiment, in the case of applying the fault detection strategy verification method of the application to the alarm playback platform, the developer can use the frequency multiplier of the double-speed clock system, set the measurement points or alarm data (signals representing the device running state) in the specified time range, and then push or pull the measurement points or alarm data to the service sandbox in the alarm playback platform according to the double-speed clock ratio of the frequency multiplier through the program. The service sandbox will generate corresponding alarm outputs according to the historical time sequence (signal generation timing), and generate new events and change the fault scene in the corresponding user interface of the alarm playback platform, facilitating the operation personnel to verify or quickly review the historical fault. If the fault detection strategy is an unknown fault scene prediction strategy, fault scene prediction needs to be performed, that is, a data set is created through massive data training, verification, etc., and then feature engineering classification and model training are performed on the actual fault data. The operation personnel can generate at least one data stream of the unknown fault scene through the user interface, and the alarm or event output generated by the data stream through the alarm playback platform, so as to achieve the purpose of fault prediction and diagnose and operate the unknown fault scene in advance.

[0185] In one embodiment, in the case of applying the fault detection strategy verification method of the application to the alarm playback platform, the deployment architecture of the alarm playback platform can be as shown in Figure 8 .

[0186] First, the alarm playback platform is connected with a data platform, a strategy configuration center and a service platform. The data platform provides second-level massive measurement point data of all devices in the data center, the strategy configuration center provides at least one fault detection strategy to be verified in the data center, and the service platform is used to receive the verification result (i.e., the verification result of the fault detection strategy) of the alarm playback platform, judge the service effect, propose optimization requirements, etc.

[0187] As shown in Figure 8 , the data platform includes an A scheme based on collected signals and a B scheme based on dictionary signals, that is, the data platform provides data of two types of signals, and the alarm playback platform can filter out signals of the corresponding type according to the signal identifier configured in the configuration center.

[0188] The policy configuration center can configure signal identification, service label, effective range, device information, and operation rule, etc., wherein the signal identification is the policy verification signal identification, the effective range is the playback time range, the device information is the device identification, and the operation rule is the fault detection policy to be verified. In addition, as shown in Figure 8 , the policy configuration center can also configure historical rules, baseline rules, baseline modules, etc., wherein the baseline module refers to a module that needs to obtain device running state data. After the user completes the configuration in the policy configuration center, the policy configuration center generates policy verification configuration information and issues a policy verification task carrying the policy verification configuration information and the fault detection policy to be verified to the alarm playback platform (i.e. Figure 8 task issuing in ) so that the alarm playback platform can verify the fault detection policy through playback calculation to obtain the verification result of the fault detection policy.

[0189] When verifying the fault detection policy through playback calculation, the alarm playback platform obtains the device running state data of at least one device for policy verification based on the policy verification configuration information, utilizes message middleware (such as Figure 8 including kafka, interface bucket, global redis, and local cache), pushes the data to the business sandbox according to the signal generation time sequence, and performs playback on multiple signals representing the device running state of the at least one device through the business sandbox to simulate the device running scene of the at least one device. In the process of simulating the device running scene, the fault detection policy is used for fault detection to obtain a fault detection result, and the verification result of the fault detection policy is obtained according to the fault detection result. The business sandbox is generated by business cloning, which clones the actual production environment of the data center. After obtaining the fault detection result, the fault detection result can be analyzed through manual comparison, automatic comparison, effect statistics, etc. to obtain the verification result of the fault detection policy. The business cloning can provide alarm effectiveness verification, dcops cold machine, change, automatic transfer, and other business services.

[0190] Secondly, the alarm playback platform provides a service cloning component, including micro-service cloning and data cloning. The micro-service cloning mainly includes data services, configuration services, and alarm analysis in the live network deployment, which are the main services that the data center can provide, including IDCDB (IDC database), physical model, and topology service components. The data cloning mainly includes dependent dictionary mapping data, measurement point data standardization, and device relationship, which are the main static configuration data including IDCDB (IDC database), physical model, and topology service components.

[0191] Secondly, the alarm playback platform further includes middleware isolation, i.e., the middleware is isolated from the live network alone, and data is completely output through the alarm playback platform, without affecting the deployment of the live network. The middleware isolation part includes components such as redis (Remote Dictionary Server), mysql (relational database management system), etc.

[0192] It can be understood that, through the unified data base (i.e., standard dictionary configuration + alarm data + test point data) and the decoupled deployment of the alarm playback module, the alarm playback platform can interface with multiple data sources, output analysis results, reports, robot message notifications, etc., realize multi-channel aggregation, and adapt to various business scenarios. Through business decoupling, the test cases can be reused, and the services can be isolated, so as to avoid affecting the production environment and achieve the effect of 0 impact on the production environment. Through real simulation, the business code can be modified without modification. In addition, the version record can be made for the effective playback scenario, a set of knowledge system can be standardized and deposited, and stored in a scenario deposition knowledge base and applied to different data centers. It can be understood that, through the knowledge deposition method, the use case data in the fault detection strategy verification process can be deposited, the analysis results can be accumulated, and the verification experience can be replicated.

[0193] In one embodiment, as shown in FIG. 1, Figure 9 The core logic of the alarm playback platform includes system interfacing, speed playback, task concurrency, speed clock system, fault scenario prediction, and fault visualization, etc.

[0194] Firstly, in the system interfacing part, the alarm playback platform interfaces with a data platform and a strategy configuration center, sorts massive test point data through modules, strategy verification signal identifiers, etc., cleans up data that does not meet the conditions, improves data quality, and finally obtains verification results and analysis reports by different businesses. As shown in FIG. 2, Figure 9 The strategy verification configuration information can be divided into physical dimension configuration information and time dimension configuration information, wherein the physical dimension configuration information includes a module (i.e., a device identifier), a signal (i.e., a strategy verification signal identifier), and a business label (which can be absent), and the time dimension configuration information includes start / end time (i.e., a playback time range) and time speed (i.e., a speed clock ratio). In the case of obtaining the strategy verification configuration information, the alarm playback platform can obtain device running state data of at least one device for strategy verification from historical running state data of the data center in combination with the configuration based on the dictionary table.

[0195] As shown in FIG. 3, Figure 9As shown, data based on acquired signals can be stored in a point database, while data based on dictionary signals can be stored in an alarm database. The alarm playback platform, by verifying signal identifiers according to the strategy, can first determine whether to retrieve data from the point database or the alarm database, and then retrieve the data from the determined database based on the playback time range and device identifier. Furthermore, the alarm playback platform also interfaces with scenario hot data, which is fault scenario data generated by version recording of valid playback scenarios and can be used directly. It is understandable that the alarm playback platform can also directly use this fault scenario data to verify fault detection strategies.

[0196] Secondly, in the speed-up playback section, the alarm playback platform pushes or retrieves measurement point data at a certain time ratio to complete rapid playback within a certain time range, and restores the alarms after playback according to the time ratio for use by business users.

[0197] Secondly, regarding task concurrency, to address the issue of high throughput from massive amounts of measurement point data within a short period, it is necessary to significantly improve the processing performance of the alarm service. The alarm playback platform, through improvements in on-demand data caching, preloading, index design, concurrent processing, and physical dimension time-series guarantees, can achieve performance enhancements for large-scale, high-frequency analysis services. For example... Figure 9 As shown, the alarm playback platform provides multiple pods ( Figure 9 The diagram shows pod1 and pod2, used to perform fault detection strategy verification. The process of fault detection strategy verification can be summarized as data classification, cloning and cleaning, assembly and integration, and playback simulation. Data classification involves analyzing parameters and generating configurations to obtain multiple signals representing the operating status of at least one device. Cloning and cleaning refers to cloning multiple signals representing the operating status of at least one device and cleaning the obtained signals to remove abnormal signals. Assembly and integration refers to tagging the signals representing the operating status of at least one device with specific fault scenarios to achieve classification and assembly. Playback simulation refers to replaying the signals representing the operating status of at least one device to simulate the device's operating scenario. Time conversion can be performed during playback simulation, and frequency synchronization and order preservation are required.

[0198] Secondly, regarding the speed-up clock system, this is a clock synchronization technique that improves system performance by doubling the clock frequency. In a speed-up clock system, the clock signal is accelerated or amplified, making its frequency higher than the original clock frequency. This allows the system to complete more operations in the same amount of time, thereby improving system speed and performance. Specifically, it mainly includes the following three parts:

[0199] First, frequency multiplier design: according to the frequency clock demand of the alarm playback platform, the timing design of the frequency multiplier is carried out, the speed of the alarm program execution is controlled to simulate the high-frequency clock signal, and the stability, phase accuracy and timing consistency of the clock signal are ensured.

[0200] Second, speed playback: by adjusting the task execution speed and changing the trigger frequency of the timer, the alarm program of the alarm playback platform is processed in sequence, such as timer, delay strategy, sleep function, interpolation algorithm, etc.

[0201] Third, performance optimization: according to the speed demand of the alarm playback platform, the task speed is controlled through priority scheduling, multi-threading, multi-coroutine and other technical means, and the speed algorithm and task execution speed need to be adjusted in real time to achieve the best system performance.

[0202] Secondly, in the fault scene prediction part, it mainly involves generating a set of possible fault scenes in the data center scene through a large model, the purpose is to predict and output the corresponding response processing scheme in advance, which includes the following steps:

[0203] 1. Training data acquisition: from the data center.

[0204] 2. Feature engineering processing: process the original data of the data center, select the most relevant and typical fault scenes from the historical alarm data, analyze the combination and mutual influence between scenes, and generate new features (i.e. mixed signal set).

[0205] 3. Fault scene training: extract positive and negative training and validation data from the data set (i.e. mixed signal set), then follow up the type and data of the historical fault scene, train and verify the model through the neural network, and finally generate new fault scenes based on the historical real fault, cross or mutual influence, gradually iterate, and have generalization ability and reliability for different input data.

[0206] Secondly, in the fault visualization part, it mainly involves displaying the data changes in a certain time range through the time axis, highlighting the playback time period and fault impact information, and real-time data changes, accompanying fault scene changes, upgrading, diagnosis process, which involves the following aspects:

[0207] 1. Design signal display time axis: create a signal display time axis, but the time axis scale is generated by clock proportion conversion.

[0208] 2. Real-time curve drawing: According to the data within the visible time range, the corresponding data curve is drawn on the signal display time axis, that is, the signal trend chart, which shows the fault condition through data changes, can be dynamically refreshed at any time, and the corresponding solution of the fault scene is displayed.

[0209] 3. Other interactive functions: Provide sliding window playback, fault scene timing switching and other simulation capabilities to enable users to better observe.

[0210] In one embodiment, the verification logic of the fault detection strategy verification method of the present application can be illustrated as Figure 10 , taking the playback strategy A as an example.

[0211] Specifically, as Figure 10 shown, after the server obtains the playback strategy A to be verified and the strategy verification configuration information, when the playback strategy A is not an unknown fault scene prediction strategy, the server can determine the playback time range, device identifier and strategy verification signal identifier (i.e. the example in Figure 10 : {door open state} 1:43200 (acquire signal: door open state)) according to the strategy verification configuration information, in combination with the playback time range, device identifier (not shown in Figure 10 ) and strategy verification signal identifier, obtain signal set fragments (i.e. device running state data of at least one device for strategy verification, i.e. multiple signals representing device running state of at least one device) from the historical signal set (historical running state data of the data center), determine the speed clock ratio according to the strategy verification configuration information, process the multiple signals representing device running state of at least one device through the signal frequency multiplier according to the speed clock ratio, push the multiple signals representing device running state of at least one device processed by the signal frequency multiplier into the business sandbox according to the signal generation timing, and perform speed playback on the multiple signals representing device running state of at least one device through the business sandbox to simulate the device running scene of at least one device. In the process of simulating the device running scene, the fault detection strategy is parsed through the expression operation engine to obtain the alarm kernel coroutine pool (including alarm program), the fault detection is performed through the alarm kernel coroutine pool to obtain the fault detection result, and the fault detection result can be specifically an alarm trigger queue. Comparing the alarm trigger queue with the playback strategy A can obtain the verification result of the fault detection strategy.

[0212] It should be noted that since the signal frequency multiplier is used to process the multiple signals representing device running state of at least one device, the timing controller needs to be combined to restore the real alarm trigger time when outputting the alarm trigger queue.

[0213] In specific applications, as Figure 10As shown, when playback strategy A is a fault scenario A prediction strategy, the acquired device operating status data of at least one device is actually the playback signal set of fault scenario A. Based on this, upon receiving a fault visualization request, the server can first determine the visible time range indicated by the fault visualization request, extract the fault scenario signal from the playback signal set, and perform real-time time axis conversion using a signal frequency multiplier based on the clock speed ratio to determine the time axis scale of the signal display time axis. Based on the time axis scale of the signal display time axis and the signals within the visible time range, a signal trend graph is generated and displayed. Furthermore, this embodiment also provides a sliding window switching function. In response to a sliding window switching request, signals within the display time range indicated by the sliding window switching request will be displayed. In this way, dynamic display is performed during signal playback.

[0214] In practical applications, when replay strategy A is an unknown fault scenario prediction strategy, it is necessary to obtain the device operating status data of at least one device for strategy verification through fault scenario prediction. Specifically, the server uses a fault scenario classifier to classify the fault scenarios of historical signal machines (i.e., multi-module historical signal sets, i.e., historical operating status data of the data center) in data center 1, 2, ... N, obtaining the device operating status data of each of the multiple historical fault scenarios. Based on the replay time range and at least two fault scenario types indicated by the unknown fault scenario prediction strategy, fault scenario signals (i.e., device operating status data of at least one device for strategy verification) are extracted from the device operating status data of each of the multiple historical fault scenarios. The fault scenario signals are then obfuscated using a signal obfuscator to obtain a mixed signal set. This mixed signal set is split into a training signal set and a verification signal set (i.e., the mixed signal set) for model training, resulting in a fault scenario prediction model (e.g., ...). Figure 10 As shown, it can be a model for predicting the failure scenario after at least two failure scenarios from failure scenario A to failure scenario N are superimposed. The failure scenario prediction model is used to predict the scenario and obtain the device operation status data of at least one device for policy verification from the historical operation status data of the data center.

[0215] In a specific application, when the verification result of the fault detection strategy is obtained based on the fault detection results, the server can display the fault detection strategy verification interface on the user interface to achieve intuitive verification of the fault detection strategy.

[0216] The following is an example Figure 11 The alarm policy verification interface shown below will be used as an example for explanation. Figure 11 As shown, when there is real fault information corresponding to the equipment operating status data of at least one device, the alarm strategy verification results can be compared with the real fault information to achieve intuitive verification of the fault detection strategy.

[0217] The verification comparison is mainly to verify whether the fault detection strategy can cover the device fault. The specific verification includes three parts: first, verification of the strategy, that is, verifying whether the newly triggered device and the alarm strategy type in the fault detection result are the same as those in the real fault information, and whether the fault detection strategy meets the operation requirements can be observed through the signal trend chart. Second, comparison of alarm speed, that is, verifying whether the timeliness of the fault detection strategy meets the requirements by comparing the triggering time of the new and old strategies. Finally, batch verification can be performed, that is, the server can perform batch verification to meet the strategy verification requirements of multiple devices and multiple strategies in the data center.

[0218] As shown in Figure 11 , the alarm original occurrence time (that is, the first fault occurrence time), the original alarm type (that is, the first fault type), the original level, the original alarm details, the original alarm duration, the new occurrence time (that is, the second fault occurrence time), the new alarm type (the second fault type), and the new level are displayed on the alarm strategy verification interface. The verification result of the fault detection strategy can be obtained by comparison. The original alarm type indicates the first fault device information (that is, the engine, humidity sensor, water pump, etc. in Figure 11 ), and the new alarm type indicates the second fault device information (that is, the engine, humidity sensor, water tank, etc. in Figure 11 ).

[0219] In a specific application, when the verification result of the fault detection strategy is obtained according to the fault detection result, the server can display the scene review data interface on the user interface to realize intuitive verification of the fault detection strategy.

[0220] The following will be described taking the fault scene review data interface as shown in Figure 12 as an example. As shown in Figure 12 , in the case that there is real fault information corresponding to the device running state data of at least one device, the real fault information can be compared with the fault detection result in the alarm strategy verification result to realize intuitive verification of the fault detection strategy.

[0221] The verification comparison is mainly to verify whether the fault detection strategy can cover such a fault scene. The specific verification includes three parts: first, verification of strategy coverage, that is, verifying whether the newly triggered device and the alarm strategy type in the fault detection result are the same as those in the real fault information, to verify whether the fault detection strategy can cover the coverage rate of the old fault detection strategy. Second, verification of alarm convergence, that is, verifying whether the alarm triggered in the fault detection strategy can meet the fine correspondence of the event scene and does not affect the judgment and automatic transfer of the event. Finally, verification of alarm performance, that is, verifying whether the timeliness of the fault detection strategy meets the requirements by comparing the triggering time of the new and old fault detection strategies.

[0222] As Figure 12 shown, in the fault scenario review data interface, the present network device number (first fault device information), the present network alarm type (first fault type), the present network occurrence time (first fault occurrence time), the present network level, the present network alarm duration, the present network alarm address, the sandbox device number (second fault device information), the sandbox alarm type (second fault type), the sandbox occurrence time (second fault occurrence time), the sandbox level, and the sandbox alarm duration are displayed. It can be understood that the sandbox device in the business sandbox is used to simulate the present network device with the same number.

[0223] It can be understood that the fault detection strategy verification method of the present application has the following advantages:

[0224] First, it improves the operation professionalism. Through the fault detection strategy verification method of the present application, the operation personnel can use historical data to simulate the changes and events in the actual environment, so as to more comprehensively understand the operation of the data center. This all-round scene playback can make the operation personnel better understand and cope with various situations, improve their experience and response ability. This helps to reduce the dependence on manual experience, improve the consistency and reliability of operation.

[0225] Second, it improves the decision accuracy. Through the fault detection strategy verification method of the present application, the operation personnel can help to make more accurate response measures and change plans. By observing the playback of historical data, the decision maker can make more targeted response measures and change plans through the verification results of the fault detection strategy. This will improve the accuracy of change decision and reduce the operation errors and failures caused by uncertainty and unknown risks.

[0226] Finally, it reduces the cost and increases the benefit. Through the fault detection strategy verification method of the present application, the all-round scene playback and more accurate response measures provided by the operation personnel can better cope with the changes and challenges in actual operation, thereby reducing the operation cost. The operation personnel can more quickly identify and solve problems, reduce the requirement for personnel, and improve the reliability and efficiency of data center operation.

[0227] In summary, the fault detection strategy verification method of the present application can provide unified security protection, increase operation experience and complementary measures, and provide the operation personnel with the most realistic on-site event changes, so as to establish more accurate response measures and simplify clear change plans, and finally reduce the operation risk and cost.

[0228] It should be understood that although each step in the flowchart involved in the embodiments described above is shown in sequence according to the direction of the arrow, these steps are not necessarily executed in the order indicated by the arrow. Unless otherwise specified herein, there is no strict order limitation for the execution of these steps, and these steps can be executed in other orders. Moreover, at least part of the steps in the flowchart involved in the embodiments described above can include multiple steps or multiple stages, which are not necessarily executed at the same time, but can be executed at different times, and the execution order of these steps or stages is not necessarily sequential, but can be executed alternately or alternately with at least part of other steps or steps or stages in other steps.

[0229] Based on the same inventive concept, the embodiments of the present application also provide a fault detection strategy verification device for implementing the above-mentioned fault detection strategy verification method. The implementation scheme for solving the problem provided by the device is similar to the implementation scheme described in the above method, so the specific limitations in one or more fault detection strategy verification device embodiments provided below can refer to the limitations of the fault detection strategy verification method in the above text, which will not be repeated here.

[0230] In one embodiment, as shown in Figure 13 a fault detection strategy verification device is provided, comprising: a strategy acquisition module 1302, a data acquisition module 1304, a data playback module 1306, a fault detection module 1308 and a verification module 1310, wherein:

[0231] The strategy acquisition module 1302 is configured to acquire a fault detection strategy to be verified and strategy verification configuration information;

[0232] The data acquisition module 1304 is configured to acquire device running state data of at least one device for strategy verification from historical running state data of the data center according to the strategy verification configuration information; the device running state data includes a plurality of signals representing device running states;

[0233] The data playback module 1306 is configured to push the plurality of signals representing the device running states of the at least one device to a business sandbox according to the signal generation time sequence, and play back the plurality of signals representing the device running states of the at least one device through the business sandbox to simulate a device running scenario of the at least one device;

[0234] The fault detection module 1308 is configured to perform fault detection through the fault detection strategy during simulation of the device running scenario to obtain a fault detection result;

[0235] The verification module 1310 is configured to obtain a verification result of the fault detection strategy according to the fault detection result.

[0236] The fault detection strategy verification apparatus described above, on the basis of obtaining the fault detection strategy to be verified and the strategy verification configuration information, can obtain, by using the strategy verification configuration information, device running state data of at least one device used for strategy verification from historical running state data of the data center, the device running state data including a plurality of signals representing device running states. By pushing the plurality of signals representing device running states of the at least one device into the business sandbox according to the signal generation time sequence, and replaying the plurality of signals representing device running states of the at least one device by the business sandbox, the device running scene of the at least one device can be simulated by means of signal replaying. Then, in the process of simulating the device running scene, the fault detection strategy can be used for fault detection to obtain a fault detection result. According to the fault detection result, a verification result of the fault detection strategy can be obtained. In the whole process, by directly replaying the plurality of signals representing device running states of the at least one device, the device running state data in a real scene is used to verify the fault detection strategy. This not only avoids manually building a fault scene and improves the verification efficiency of the fault detection strategy, but also ensures the accuracy of the fault detection strategy verification by using real data for verification.

[0237] In one embodiment, the data playback module is further configured to determine a speed-up clock ratio according to the strategy verification configuration information, push the plurality of signals representing device running states of the at least one device into the business sandbox according to the speed-up clock ratio and the signal generation time sequence, and replay the plurality of signals representing device running states of the at least one device at a speed-up rate by the business sandbox to simulate the device running scene of the at least one device.

[0238] In one embodiment, the data acquisition module is further configured to determine a playback time range according to the strategy verification configuration information, and acquire the device running state data of the at least one device used for strategy verification from the historical running state data of the data center based on the playback time range.

[0239] In one embodiment, when the fault detection strategy is not the unknown fault scene prediction strategy, the data acquisition module is further configured to determine a device identifier and a strategy verification signal identifier according to the strategy verification configuration information, and acquire the device running state data of the at least one device used for strategy verification from the historical running state data of the data center based on the playback time range, the device identifier, and the strategy verification signal identifier.

[0240] In an embodiment, the data obtaining module is further configured to, when the fault detection strategy is the unknown fault scenario prediction strategy, perform fault scenario classification on the historical operation state data of the data center to obtain device operation state data of a plurality of historical fault scenarios, and select, from the device operation state data of the plurality of historical fault scenarios, device operation state data of at least one device used for strategy verification according to the replay time range and at least two fault scenario types indicated by the unknown fault scenario prediction strategy.

[0241] In an embodiment, the data obtaining module is further configured to, according to the replay time range and at least two fault scenario types indicated by the unknown fault scenario prediction strategy, select, from the device operation state data of the plurality of historical fault scenarios, device operation state data corresponding to the at least two fault scenario types respectively, and train a fault scenario prediction model based on the device operation state data corresponding to the at least two fault scenario types respectively to obtain, from the historical operation state data of the data center, device operation state data of at least one device used for strategy verification through the fault scenario prediction model.

[0242] In an embodiment, the data obtaining module is further configured to mix a plurality of signals representing device operation states in the device operation state data corresponding to the at least two fault scenario types respectively to obtain a mixed signal set, and train the fault scenario prediction model according to the mixed signal set.

[0243] In an embodiment, the fault detection strategy verification apparatus further comprises a display module, which is configured to, in response to a fault visualization request, determine a visual time range indicated by the fault visualization request, determine a speed-up clock ratio according to the strategy verification configuration information, determine a time axis scale of a signal display time axis based on the speed-up clock ratio, and generate and display a signal trend chart based on the time axis scale of the signal display time axis and the signals in the visual time range in a process of replaying a plurality of signals representing device operation states of at least one device.

[0244] In an embodiment, the display module is further configured to, when there is a signal triggering a fault in the signals in the visual time range, determine fault information indicated by the signal triggering the fault, and mark the fault information indicated by the signal triggering the fault on the signal trend chart.

[0245] In an embodiment, the verification module is further configured to, when there is real fault information corresponding to the device operation state data of the at least one device, compare the real fault information with the fault detection result to obtain a verification result of the fault detection strategy.

[0246] In one embodiment, the verification module is further configured to compare the first fault device information in the real fault information with the second fault device information in the fault detection result to obtain the fault device verification result. When the first fault device information and the second fault device information indicate that there is at least one identical fault device, the first fault occurrence time of the identical fault device in the real fault information and the second fault occurrence time in the fault detection result are compared to obtain the fault timeliness verification result. Based on the fault device verification result and the fault timeliness verification result, the verification result of the fault detection strategy is obtained.

[0247] In one embodiment, the verification module is further configured to compare the first fault type in the real fault information with the second fault type in the fault detection result to obtain the first fault type coverage, and obtain the verification result of the fault detection strategy based on the fault equipment verification result, the fault timeliness verification result and the first fault type coverage.

[0248] In one embodiment, the verification module is further configured to compare the second fault type in the fault detection result with the third fault type in the fault detection strategy when no real fault information exists, so as to obtain the verification result of the fault detection strategy.

[0249] Each module in the aforementioned fault detection strategy verification device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in the processor of a computer device in hardware form or independent of it, or stored in the memory of a computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0250] In one embodiment, a computer device is provided, which can be a server or a terminal. Taking the computer device as a server as an example, its internal structure diagram can be as follows. Figure 14 As shown, this computer device includes a processor, memory, input / output interfaces (I / O), and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The database stores historical operational status data and other data. The I / O interfaces are used for information exchange between the processor and external devices. The communication interface is used for communication with external terminals via a network connection. When the computer program is executed by the processor, it implements a fault detection strategy verification method.

[0251] Those skilled in the art can understand that, Figure 14 Those skilled in the art can understand that,

[0252] In an embodiment, a computer device is also provided, including a memory and a processor, the memory stores a computer program, and the processor executes the computer program to implement the steps in the above method embodiments.

[0253] In an embodiment, a computer readable storage medium is provided, which stores a computer program, and the computer program is executed by a processor to implement the steps in the above method embodiments.

[0254] In an embodiment, a computer program product is provided, which includes a computer program, and the computer program is executed by a processor to implement the steps in the above method embodiments.

[0255] It should be noted that the data (including but not limited to data for analysis, stored data, displayed data, etc.) involved in the present application is all data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data need to comply with relevant regulations.

[0256] Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiment methods can be completed by instructing the relevant hardware through a computer program. The computer program can be stored in a non-volatile computer readable storage medium, and when the computer program is executed, the processes of the above-mentioned embodiments of the methods can be included. Any reference to memory, database or other medium used in the embodiments provided in the present application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical storage, high-density embedded non-volatile memory, resistive memory (ReRAM), magnetoresistive random access memory (MRAM), ferroelectric memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. As an illustration but not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM), etc. The database involved in the embodiments provided in the present application can include at least one of a relational database and a non-relational database. The non-relational database can include a distributed database based on a block chain, etc., without being limited thereto. The processor involved in the embodiments provided in the present application can be a general-purpose processor, a central processing unit, a graphics processing unit, a digital signal processor, a programmable logic device, a data processing logic device based on quantum computing, etc., without being limited thereto.

[0257] Any combination of the technical features of the above embodiments can be made. In order to make the description simple, all possible combinations of the technical features in the above embodiments are not described, however, as long as the combination of the technical features does not exist, it should be considered as the scope of the present application.

[0258] The above embodiments only express several implementation manners of the present application, and the description is more specific and detailed, but it should not be understood as a limitation on the scope of the patent of the present application. It should be pointed out that for ordinary skilled in the art, without departing from the concept of the present application, a number of modifications and improvements can be made, which are within the scope of protection of the present application. Therefore, the protection scope of the present application should be subject to the appended claims.

Claims

1. A fault detection strategy verification method, characterized in that, The method comprises: obtaining a fault detection strategy to be verified and strategy verification configuration information; obtaining, according to the strategy verification configuration information, device running state data of at least one device for strategy verification from historical running state data of a data center; the device running state data comprises a plurality of signals representing device running states; pushing the plurality of signals representing device running states of the at least one device to a business sandbox according to signal generation timing, playing back the plurality of signals representing device running states of the at least one device through the business sandbox to simulate a device running scenario of the at least one device; detecting faults through the fault detection strategy during simulation of the device running scenario to obtain a fault detection result; obtaining a verification result of the fault detection strategy according to the fault detection result.

2. The method of claim 1, wherein, The pushing of the plurality of signals representing device running states of the at least one device to the business sandbox according to the signal generation timing, the playback of the plurality of signals representing device running states of the at least one device through the business sandbox, and the simulation of the device running scenario of the at least one device comprise: determining a speed-up clock ratio according to the strategy verification configuration information; pushing the plurality of signals representing device running states of the at least one device to the business sandbox according to the speed-up clock ratio and the signal generation timing; speeding up the playback of the plurality of signals representing device running states of the at least one device through the business sandbox to simulate the device running scenario of the at least one device.

3. The method of claim 1, wherein, The obtaining of the device running state data of the at least one device for strategy verification from the historical running state data of the data center according to the strategy verification configuration information comprises: determining a playback time range according to the strategy verification configuration information; obtaining the device running state data of the at least one device for strategy verification from the historical running state data of the data center based on the playback time range.

4. The method of claim 3, wherein, The obtaining of the device running state data of the at least one device for strategy verification from the historical running state data of the data center based on the playback time range comprises: when the fault detection strategy is not an unknown fault scenario prediction strategy, determining a device identifier and a strategy verification signal identifier according to the strategy verification configuration information; obtaining the device running state data of the at least one device for strategy verification from the historical running state data of the data center based on the playback time range, the device identifier, and the strategy verification signal identifier.

5. The method of claim 3, wherein, The obtaining of the device running state data of the at least one device for strategy verification from the historical running state data of the data center based on the playback time range comprises: when the fault detection strategy is an unknown fault scenario prediction strategy, classifying historical fault scenarios of the historical running state data of the data center to obtain device running state data of each of the historical fault scenarios; According to the replay time range and at least two fault scene types indicated by the unknown fault scene prediction strategy, device running state data of at least one device for strategy verification is selected from device running state data of each of the plurality of historical fault scenes.

6. The method of claim 5, wherein, The selecting of the device running state data of the at least one device for strategy verification from the device running state data of each of the plurality of historical fault scenes according to the replay time range and the at least two fault scene types indicated by the unknown fault scene prediction strategy comprises: According to the replay time range and at least two fault scene types indicated by the unknown fault scene prediction strategy, device running state data of the at least two fault scene types respectively corresponding thereto is selected from device running state data of each of the plurality of historical fault scenes; A fault scene prediction model is trained based on the device running state data of the at least two fault scene types respectively corresponding thereto; Device running state data of at least one device for strategy verification is obtained from historical running state data of the data center by the fault scene prediction model.

7. The method of claim 6, wherein, The training of the fault scene prediction model based on the device running state data of the at least two fault scene types respectively corresponding thereto comprises: Mixing a plurality of signals representing device running states in the device running state data of the at least two fault scene types respectively corresponding thereto to obtain a mixed signal set; The fault scene prediction model is trained according to the mixed signal set.

8. The method according to any one of claims 1 to 7, characterized in that, The method further comprises: In response to a fault visualization request, determining a visual time range indicated by the fault visualization request, and determining a speed clock ratio according to the strategy verification configuration information, and determining a time axis scale of a signal display time axis based on the speed clock ratio; In the process of replaying the plurality of signals representing device running states of the at least one device, when replaying signals within the visual time range, a signal trend graph is generated and displayed based on the time axis scale of the signal display time axis and the signals within the visual time range.

9. The method of claim 8, wherein, The method further comprises: When there is a signal triggering a fault in the signals within the visual time range, determining fault information indicated by the signal triggering the fault; On the signal trend graph, the fault information indicated by the signal triggering the fault is labeled.

10. The method according to any one of claims 1 to 7, characterized in that, The obtaining of the verification result of the fault detection strategy according to the fault detection result comprises: When there is real fault information corresponding to the device running state data of the at least one device, the real fault information is compared with the fault detection result to obtain a verification result of the fault detection strategy.

11. The method of claim 10, wherein, The comparison of the real fault information with the fault detection result to obtain the verification result of the fault detection strategy comprises: The first fault device information in the real fault information is compared with the second fault device information in the fault detection result to obtain a fault device verification result. When the first fault device information and the second fault device information indicate at least one same fault device, a first fault occurrence time of the same fault device in the real fault information and a second fault occurrence time of the same fault device in the fault detection result are compared to obtain a fault timeliness verification result; According to the fault device verification result and the fault timeliness verification result, a verification result of the fault detection strategy is obtained.

12. The method of claim 11, wherein, The method further comprises: When the real fault information does not exist, a second fault type in the fault detection result is compared with a third fault type in the fault detection strategy to obtain a verification result of the fault detection strategy. The apparatus comprises:

13. The method of claim 10, wherein, A policy obtaining module is configured to obtain a fault detection strategy to be verified and policy verification configuration information; A data obtaining module is configured to obtain, according to the policy verification configuration information, device running state data of at least one device for policy verification from historical running state data of a data center; the device running state data comprises a plurality of signals representing device running states; 14. A fault detection strategy verification apparatus characterized by, A data playback module is configured to push the plurality of signals representing device running states of the at least one device to a business sandbox according to signal generation time sequences, and play back the plurality of signals representing device running states of the at least one device through the business sandbox to simulate a device running scenario of the at least one device; A fault detection module is configured to perform fault detection through the fault detection strategy in the process of simulating the device running scenario to obtain a fault detection result; A verification module is configured to obtain a verification result of the fault detection strategy according to the fault detection result. The processor executes the computer program to implement the steps of the method in any one of claims 1 to 13. The computer program is executed by the processor to implement the steps of the method in any one of claims 1 to 13. The computer program is executed by the processor to implement the steps of the method in any one of claims 1 to 13.

15. A computer device comprising a memory and a processor, the memory storing a computer program, characterized in that, ​ 16. A computer readable storage medium having stored thereon a computer program, characterized in that, ​ 17. A computer program product comprising a computer program, characterized in that, ​

Images