Intelligent office remote operation and maintenance system

Abstract

The invention discloses a smart office remote operation and maintenance system, which belongs to the technical field of computer application and comprises an exception simulation test module, a dynamic baseline generation module, a real-time monitoring module, a debugging self-healing module and a test verification module. The abnormity simulation test module comprises a simulation unit and a generation unit; the dynamic baseline generation module is used for generating a dynamic baseline based on the historical operation data of the office equipment and the behavior instruction; the real-time monitoring module is used for monitoring the abnormity simulation test module and the dynamic baseline generation module in real time; the debugging self-healing module is used for performing tracking analysis according to the alarm instruction; and the test verification module is used for verifying the feasibility of the repair strategy. According to the invention, the dynamic baseline generation module is combined with the historical operation data and the real-time behavior instruction to dynamically adjust the threshold value of each index, so that the dynamic baseline parameter changes along with the equipment load.

Description

Technical Field

[0001] The present invention relates to the field of computer application technology, and in particular to a smart office remote operation and maintenance system. Background Art

[0002] The rapid development of computer network technology has brought about tremendous social changes, affecting every aspect of people's work and life. With the booming development of smart office and smart campus services, a large number of IoT devices and wireless network equipment are being used in these services.

[0003] A search revealed Chinese patent publication number CN117768293A, which discloses a device management method comprising: scanning all IP addresses within a gateway's IP segment; obtaining a response from each IP address, identifying a first device connected to the gateway, and obtaining first type information for the first device; and, based on the first type information, matching a first object identifier of the first device from a management information database. A device management system and cloud platform are also provided.

[0004] Although the above solution has the advantages of notifying operation and maintenance personnel when the alarm level exceeds the predetermined threshold and can remotely operate and maintain the equipment, it uses fixed threshold warnings, lacks dynamic baseline adjustment capabilities, and has a high false alarm rate.

[0005] Therefore, there is an urgent need to provide a smart office remote operation and maintenance system to solve the above problems. Summary of the Invention

[0006] The technical problem to be solved by the present invention is to overcome the shortcomings of the above-mentioned existing technology that adopts fixed threshold warning, lacks dynamic baseline adjustment capability, and has a high false alarm rate, and provide a smart office remote operation and maintenance system.

[0007] To solve the above technical problems, the present invention adopts a technical solution: providing a smart office remote operation and maintenance system, including an abnormality simulation test module, a dynamic baseline generation module, a real-time monitoring module, a debugging and self-healing module, and a test verification module; An abnormality simulation test module, comprising a simulation unit and a generation unit, wherein the simulation unit is used to perform a stress test on the office equipment by injecting simulated fault data packets, and the generation unit is used to generate corresponding behavioral instructions according to the test results; A dynamic baseline generation module, which generates a dynamic baseline by dynamically adjusting the behavior threshold of the software in the office equipment through a preset processing unit based on the historical operation data of the office equipment and the behavior instruction; A real-time monitoring module, which is used to monitor the abnormal simulation test module and the dynamic baseline generation module in real time, and preset an analysis unit to match the dynamic baseline with the error pattern in the analysis unit and generate an alarm instruction; A debugging and self-healing module, wherein the debugging and self-healing module is used to track and analyze the alarm instructions and generate corresponding repair strategies; A test verification module is used to verify the feasibility of the repair strategy and, after the verification is completed, re-run the abnormal simulation test module to determine whether the service availability of the office equipment has been restored.

[0008] The present invention is further configured such that communication connections are established among the dynamic baseline generation module, the abnormal simulation test module, the real-time monitoring module, the debugging and self-healing module, and the test verification module.

[0009] The present invention is further configured as follows: the abnormal simulation test module performs stress testing on office equipment, which includes a multi-level fault injection strategy: Hardware fault simulation uses virtualization technology to generate scenarios such as CPU overload, memory exhaustion, and disk bad sectors in office equipment software. System-level fault simulation to create software system service crashes, driver conflicts, and permission anomalies in office equipment; Application layer fault simulation, including software database deadlocks in office equipment, middleware message accumulation, and microservice call chain breaks; Network layer fault simulation: set bandwidth limitation, packet loss, and DNS hijacking test scenarios, and record the cascading impact path of faults at each layer.

[0010] The present invention is further configured such that: the generating unit is configured to generate corresponding behavioral instructions according to the test results, the steps of which include: S1. When the simulation unit injects a simulated fault data packet into the software of the office equipment, the generation unit collects multi-dimensional parameter data in real time during the software operation process, including process response delay, service call success rate, and memory usage fluctuation value; pre-processes the collected multi-dimensional parameter data, eliminates instantaneous noise interference through sliding window mean calculation, and extracts abnormal characteristic parameters; S2. Match the extracted abnormal characteristic parameters with the preset fault model library, and generate an intermediate instruction containing the fault type and impact level according to the matching results; S3. Generate executable behavioral instructions based on the fault type and impact level of the intermediate instructions; The behavior instruction is transmitted to the dynamic baseline generation module through a preset interface.

[0011] The present invention is further configured as follows: the specific steps of generating a dynamic baseline in the dynamic baseline generating module are as follows: M1. The processing unit in the dynamic baseline generation module collects historical operating data of office equipment within a preset time period, including the process response time, service call success rate, and memory usage change trend of the software in the office equipment, and simultaneously receives the behavior instruction output by the generation unit, extracts the fault type and impact level recorded in the behavior instruction, aligns the historical operating data with the behavior instruction along the timeline, eliminates invalid data segments caused by office equipment downtime maintenance or external interference, and forms a standardized data set; M2. Extract core indicators of office equipment software behavior from the standardized data set, analyze the fluctuation range of software process response time in the office equipment under different load conditions, determine the normal fluctuation range, and statistically analyze the distribution characteristics of the service call success rate of the software in the office equipment during the fault-free period to determine the lower limit of normal fluctuation. Calculate the average daily change in the memory usage of the software in the office equipment, identify the reasonable growth range caused by software updates, and generate an initial reference baseline for each indicator based on the above analysis results; M3. The processing unit dynamically modifies the initial reference baseline based on the fault type in the behavior instruction. If the behavior instruction contains a high-frequency transient fault record, the upper limit of the normal fluctuation range is expanded. If the behavior instruction indicates a memory leak fault, the daily growth threshold of the memory usage rate is reduced. Based on the decrease in the service call success rate during the fault period, the lower limit of the fluctuation of the service call success rate is dynamically adjusted. A dynamic threshold set is formed through iterative optimization. M4. By associating and adapting the dynamic threshold set with the operating environment of office equipment, the allowable range of process response time is automatically expanded during high-load periods, and the maximum allowable value of memory usage is adjusted quarterly according to the aging degree of device hardware, and finally a dynamic baseline is generated and pushed to the real-time monitoring module.

[0012] The present invention is further configured as follows: the steps of generating the alarm instruction in the real-time monitoring module are as follows: Q1. The analysis unit collects data on software process response time, service call success rate, and memory usage during the operation of office equipment in real time, and forms a standardized monitoring data stream after eliminating environmental noise interference; Q2. Compare the standardized monitoring data stream with the normal fluctuation range in the dynamic baseline item by item. When the software process response time exceeds the upper limit of the range for three consecutive times, the service call success rate decreases simultaneously, and the memory usage fluctuation range exceeds twice the historical average for two sampling periods, calculate the comprehensive deviation of the current data from the dynamic baseline; Q3. When the comprehensive deviation reaches a preset threshold, the fault cases with the same fluctuation characteristics are retrieved from the error pattern database in the analysis unit, and combined with the abnormal event records in the office equipment operation log, an alarm instruction containing fault location information and urgency classification is generated.

[0013] The present invention is further configured such that: the debugging self-healing module performs tracking analysis according to the alarm instruction and generates a corresponding repair strategy, and the specific steps include: H1. The debugging and self-healing module parses the fault location information in the alarm instruction, extracts the abnormal process identifier and service call path of the office equipment, and synchronously retrieves the operation log data 2 minutes before the fault occurs to form a diagnostic context; H2. Match the diagnostic context with a preset repair strategy database: If there is a historical repair record for the same failure mode, prioritize the service restart instructions or resource allocation plan in the corresponding strategy; if it is a new failure mode, automatically generate process isolation instructions based on the service call path and allocate a backup resource pool; H3. After performing the repair operation, collect office equipment operating status data in real time to verify the repair effect: when the service call success rate returns to above the dynamic baseline threshold and remains stable for 5 minutes, the fault is marked as eliminated; if a second alarm occurs after the repair, the fault level is upgraded, triggering the remote expert diagnosis process and generating an in-depth equipment inspection task.

[0014] The present invention is further configured as follows: the abnormal process identifier of the office equipment in step H1 assigns a unique identification code to each abnormal process in the system of the office equipment, including the process name, process ID and the name of the service to which it belongs, for quickly locating the faulty process instance; the service call path is a complete flow link for recording the service request when the exception occurs, including the called microservice node, API interface sequence and dependent database table, for tracing the fault propagation path.

[0015] The present invention is further configured as follows: the test verification module verifies the feasibility of the repair strategy, and after the verification is completed, re-runs the abnormality simulation test module to determine whether the service availability of the office equipment is restored. The specific steps include: K1. Loading the repair strategy in the virtual test environment of the test verification module, simulating the execution of service restart and resource allocation operations, synchronously collecting the software process response time and service call success rate of office equipment, and generating a repair effect evaluation report; K2. Compare the operating indicators in the repair effect evaluation report with the dynamic baseline. If the fluctuation range of the process response time drops to within 10% and the service call success rate reaches more than 95% for 5 consecutive minutes, the repair strategy is determined to be effective. If any indicator does not meet the standard, return to the debugging and self-healing module to trigger the expert remote supplementary diagnosis process; K3. After the repair strategy is verified to be effective, it will be deployed to the actual operating environment, and the service instance replacement and abnormal process termination operations will be executed. The operating status of the office equipment will be continuously monitored for 30 minutes. If no new alarm instructions are triggered during this period, the service availability will be confirmed to be restored. If related anomalies are detected, the backup repair plan will be activated and the policy database will be updated. K4. After completing the actual environment verification, re-trigger the multi-level fault injection strategy of the abnormal simulation test module, compare the difference rate of service availability indicators before and after repair, and generate a final recovery confirmation instruction if the difference rate is less than 3%. The verification result is associated with the equipment operation history database for the subsequent dynamic baseline optimization.

[0016] The beneficial effects of the present invention are as follows: 1. This invention uses a dynamic baseline generation module to combine historical operating data with real-time behavior instructions to dynamically adjust the thresholds of various indicators, achieving adaptive matching of dynamic baseline parameters with changes in device load, hardware aging, and software versions; 2. This invention uses an abnormal simulation test module to expose potential risks in advance through multi-dimensional fault injection from the hardware layer to the network layer. The test verification module uses a closed-loop mechanism of virtual environment pre-verification and actual environment secondary testing to ensure the effectiveness of the repair strategy. 3. The present invention realizes a second-level response to high-frequency faults by setting up a debugging self-healing module, automatically matching the repair strategy based on the fault location information, and combining the deviation calculation of the real-time monitoring module. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] Figure 1 is a system flow chart of the present invention; Figure 2 A flow chart of the behavioral instruction generating method of the present invention; Figure 3 This is a flow chart of a method for generating a dynamic baseline according to the present invention; Figure 4 Flowchart of the method for generating an alarm instruction of the present invention; In the figure: 1. Abnormal simulation test module; 2. Dynamic baseline generation module; 3. Real-time monitoring module; 4. Debugging and self-healing module; 5. Test verification module. DETAILED DESCRIPTION

[0018] The preferred embodiments of the present invention are described in detail below with reference to the accompanying drawings so that the advantages and features of the present invention can be more easily understood by those skilled in the art, thereby making a clearer and more precise definition of the protection scope of the present invention.

[0019] See also Figures 1-4A smart office remote operation and maintenance system includes an abnormality simulation test module 1, a dynamic baseline generation module 2, a real-time monitoring module 3, a debugging and self-healing module 4, and a test verification module 5. Communication connections are established among the dynamic baseline generation module 2, the abnormality simulation test module 1, the real-time monitoring module 3, the debugging and self-healing module 4, and the test verification module 5; Anomaly simulation test module 1, comprising a simulation unit and a generation unit, wherein the simulation unit is used to perform stress testing on office equipment by injecting simulated fault data packets, and the generation unit is used to generate corresponding behavioral instructions according to the test results; The abnormal simulation test module 1 performs stress testing on office equipment, which includes a multi-level fault injection strategy: Hardware fault simulation uses virtualization technology to generate scenarios such as CPU overload, memory exhaustion, and disk bad sectors in office equipment software. System-level fault simulation to create software system service crashes, driver conflicts, and permission anomalies in office equipment; Application layer fault simulation, including software database deadlocks in office equipment, middleware message accumulation, and microservice call chain breaks; Network layer fault simulation: set bandwidth limitation, packet loss, and DNS hijacking test scenarios, and record the cascading impact path of faults at each layer.

[0020] Through a multi-level fault injection strategy, we simulate multi-dimensional faults from the hardware layer to the network layer, comprehensively covering the software and hardware anomaly scenarios that may occur in office equipment, and exposing potential risks in advance; accurately verifying the operating stability of equipment under extreme loads, resource exhaustion and network attacks, reducing the actual failure rate; and recording the cascading impact path of faults to provide data support for system architecture optimization and shorten fault location and recovery time.

[0021] The generating unit is used to generate corresponding behavioral instructions according to the test results, and the steps include: S1. When the simulation unit injects a simulated fault data packet into the software of the office equipment, the generation unit collects multi-dimensional parameter data in real time during the software operation process, including process response delay, service call success rate, and memory usage fluctuation value; pre-processes the collected multi-dimensional parameter data, eliminates instantaneous noise interference through sliding window mean calculation, and extracts abnormal feature parameters: The number of consecutive times that the process response delay exceeds the standard (the delay exceeds the baseline value 3 times or more); The decrease in the service call success rate per unit time (a decrease of more than 20% within 5 minutes); Non-periodic sudden changes in memory usage (the difference between adjacent sampling points is greater than twice the historical average fluctuation value); The collected multi-dimensional parameter data is pre-processed in step S1, including: sliding window mean filtering: using a mean calculation with a window size of 3 sampling periods to eliminate instantaneous noise interference; S2. Match the extracted abnormal characteristic parameters with a preset fault model library, which contains the following types and judgment rules: Transient anomaly: If the single process response delay exceeds the limit and the service call success rate does not decrease, it is determined to be a low-priority fault; Persistent fault: If the memory usage rate changes suddenly and the service call success rate continues to decrease for three consecutive sampling periods, it is considered a medium priority fault. System crash: If the process response delay exceeds the limit for more than 5 times cumulatively and the memory usage rate suddenly increases by more than 50%, it is considered a high-priority fault. Generates intermediate instructions based on the matching results, including the fault type (code level, resource level, service level) and impact level (low / medium / high); S3. Generate executable behavioral instructions based on the fault type and impact level of the intermediate instructions: Generate monitoring enhancement instructions for low-priority faults, increase the sampling frequency of the fault process to once per second and extend the monitoring time to 30 minutes; Generate resource isolation instructions for medium-priority faults, limit the maximum memory quota of the faulty process, and start a backup service instance; Generate self-healing trigger instructions for high-priority faults, forcibly terminate abnormal processes, release occupied resources, and trigger full service status checks; The behavior instruction is transmitted to the dynamic baseline generation module 2 through a preset interface.

[0022] A dynamic baseline generation module 2, which generates a dynamic baseline by dynamically adjusting the behavior threshold of the software in the office equipment through a preset processing unit based on the historical operation data of the office equipment and the behavior instruction; The specific steps of generating a dynamic baseline in the dynamic baseline generating module 2 are as follows: M1, the processing unit in the dynamic baseline generation module 2 collects historical operating data of office equipment within a preset time period, including the process response time, service call success rate and memory usage change trend of the software in the office equipment, and simultaneously receives the behavior instruction output by the generation unit, extracts the fault type and impact level recorded in the behavior instruction, aligns the historical operating data with the behavior instruction according to the timeline, eliminates invalid data segments caused by the office equipment downtime maintenance or external interference, and forms a standardized data set; The historical operation data of office equipment within a preset time period includes the time series distribution of software process response time, the fluctuation range of service call success rate, the daily / weekly change curve of memory usage, and the downtime time period mark in the equipment maintenance log, which is used to reflect the normal operation characteristics of the equipment; Fault type and level extraction: Parse the fault code field in the behavioral instruction, identify preset keywords (such as "memory leak" and "service avalanche"), and classify them by priority label (low / medium / high) and store them in a structured database; Fault type classification: Code level: internal logic errors in the software process (such as dead loops and null pointer exceptions); Resource level: hardware resource exceptions (memory leaks, CPU overloads, and disk overflows); Service level: service call chain breaks (API timeouts and microservice communication failures); Impact level classification: Low: affects only a single process, service availability is not affected (such as a short delay); Medium: causes partial service degradation (such as resource usage exceeding the limit but can be self-recovered); High: causes system-level crash or business interruption (such as process deadlock and unrecoverable); M2. Extract core indicators of office equipment software behavior from the standardized data set, analyze the fluctuation range of software process response time in the office equipment under different load conditions, determine the normal fluctuation range, and statistically analyze the distribution characteristics of the service call success rate of the software in the office equipment during the fault-free period to determine the lower limit of normal fluctuation. Calculate the average daily change in the memory usage of the software in the office equipment, identify the reasonable growth range caused by software updates, and generate an initial reference baseline for each indicator based on the above analysis results; The steps for calculating the daily average change in the memory usage of software in office equipment are as follows: taking the difference between the daily peak and valley values of memory usage, calculating the average of the absolute values of the difference between two consecutive days, and calculating the trend slope over five consecutive days to identify abnormal growth periods; Initial reference baseline generation: Based on the fluctuation range of software process response time in office devices (e.g., 200-800ms), the lower limit of service success rate (e.g., ≥95%), and the average daily memory increase threshold (e.g., ≤5%), normal ranges for each indicator are defined. M3. The processing unit dynamically modifies the initial reference baseline based on the fault type in the behavior instruction. If the behavior instruction contains high-frequency transient fault records, the upper limit of the normal fluctuation range is extended. If the behavior instruction indicates a memory leak fault, the daily growth threshold of the memory usage rate is reduced. Based on the decrease in the service call success rate during the fault period, the fluctuation lower limit of the service call success rate is dynamically adjusted. A dynamic threshold set is formed through iterative optimization. The threshold set is iteratively optimized: the upper limit of the response time is extended according to high-frequency fault records (e.g., 800ms→1000ms), the daily growth threshold is tightened according to memory leak events (5%→3%), and the correction is cyclically performed until the false alarm rate meets the standard. M4. By associating and adapting the dynamic threshold set with the operating environment of the office equipment, the allowable range of the process response time is automatically expanded during high-load periods, and the maximum allowable value of the memory occupancy rate is adjusted quarterly according to the aging degree of the equipment hardware. Finally, a dynamic baseline is generated and pushed to the real-time monitoring module 3 as a benchmark for generating alarm instructions.

[0023] The dynamic baseline is finally generated by expanding the response time range based on load conditions (+200ms for high loads), adjusting the memory threshold based on hardware aging (+0.2% per month), and outputting a dynamic baseline parameter group linked to the environment.

[0024] Example 1 After an enterprise deploys a smart office remote operation and maintenance system, the dynamic baseline generation module 2 operates according to the following process: Data collection and cleaning: Dynamic baseline generation module 2 collects three months of office computer operation data (e.g., WPS process response time concentrated between 300-900ms, OA system service call success rate of 92%-99%, and daily average memory usage peak of 1.2-2.4GB). This is combined with operation and maintenance records to eliminate abnormal data during system upgrades to form a standardized data set. Initial baseline setting: Analysis found that a daily fluctuation of memory usage ≤ 0.3GB is normal. The initial baseline was set as follows: response time ≤ 800ms, service success rate ≥ 95%, and daily memory usage increase ≤ 5%. Dynamic correction: When a high-frequency "memory leak" alarm is detected (behavior instruction marked with high priority), the module tightens the daily memory increase threshold to 3% and extends the response time limit to 1000ms to adapt to load fluctuations; Environmental Adaptation: For older devices that are three years old, the memory usage threshold is automatically increased by 0.2% per month (for example, from 2.4GB to 2.6GB). The response time limit is dynamically relaxed to 1200ms during peak business hours (9:00-11:00 AM). After two weeks of iterative optimization, the system's false alarm rate dropped from 15% to 3%. A dynamic baseline group was generated: response time (500-1200ms), service success rate ≥ 93%, and memory ≤ 2.6GB (daily increase ≤ 3%). This baseline is pushed to the real-time monitoring module 3 in real time for precise alerting.

[0025] A real-time monitoring module 3 is configured to monitor the abnormal simulation test module 1 and the dynamic baseline generation module 2 in real time, and to preset an analysis unit to match the dynamic baseline with an error pattern in the analysis unit and generate an alarm instruction; The steps for generating the alarm instruction in the real-time monitoring module 3 are as follows: Q1. The analysis unit collects data on software process response time, service call success rate, and memory usage during the operation of office equipment in real time, and forms a standardized monitoring data stream after eliminating environmental noise interference; Among them, the steps for forming the standardized monitoring data stream in step Q1 are: Q11. The analysis unit acquires raw operational data of office equipment at a frequency of seconds, including millisecond-level measurements of software process response time, percentage values of service call success rates, and real-time capacity values of memory usage in office equipment, forming a multi-dimensional data stream. Q12. Perform sliding window filtering on the raw data, using a mean filter to eliminate instantaneous spike noise, and automatically remove abnormal data points caused by external network fluctuations based on the environmental interference threshold preset in the dynamic baseline (e.g., filtering is triggered when network jitter is greater than 50ms); Q13. Normalize the denoised data according to the baseline parameters defined in the dynamic baseline. Map the process response time to the interval [0, 1] (0 represents the lower limit of the dynamic baseline, 1 represents the upper limit). Convert the service call success rate to the standard achievement rate (actual value / baseline target value). Scale the memory usage as a percentage of the device's total memory capacity. Finally, generate a standardized monitoring data stream with aligned timestamps. Q2. Compare the standardized monitoring data stream with the normal fluctuation range in the dynamic baseline item by item. When the software process response time exceeds the upper limit of the range for three consecutive times, the service call success rate decreases simultaneously, and the memory usage fluctuation range exceeds twice the historical average for two sampling periods, calculate the comprehensive deviation of the current data from the dynamic baseline; Calculation method of comprehensive deviation in step Q2: The comprehensive deviation score is calculated using a weighted summation formula: the normalized deviation values of the software process response time, service success rate, and memory usage of the office equipment are multiplied by preset weight coefficients (such as 0.5, 0.3, and 0.2), and additional penalty factors are added to indicators that exceed the dynamic baseline range based on the excess rate. The final cumulative score is the comprehensive deviation score. Specifically, 0.1 points are added for every 10% excess of response time, 0.2 points are deducted for every 1% decrease in service success rate, and the memory excess value is calculated by multiplying the coefficient by the percentage of the daily average increase in excess. Q3. When the comprehensive deviation reaches a preset threshold, the fault cases with the same fluctuation characteristics are retrieved from the error pattern database in the analysis unit, and combined with the abnormal event records in the office equipment operation log, an alarm instruction containing fault location information and urgency classification is generated.

[0026] Example 2 After a company deployed a real-time monitoring module, it detected an abnormality in the financial system server one day: Data standardization: The module collects data on a per-second basis: the server process response time (suddenly increasing to 1200ms), service success rate (decreasing to 88%), and memory usage (daily increase of 8%). This data is filtered through a sliding window to remove network jitter interference and normalized to obtain standardized data (response time 1.2, success rate 0.88, memory usage rate 1.6). Deviation calculation: Weighted calculation of comprehensive deviation = 1.2 × 0.5 + (1-0.88) × 100 × 0.2 + 1.6 × 0.3 = 0.6 + 2.4 + 0.48 = 3.48 (threshold 2.5); Alarm generation: A search of the error pattern library revealed a match with the "memory leak" signature (fluctuation similarity of 92%). Combined with logs, the system detected a continuous increase in JVM heap memory usage, generating a high-priority alarm: "Finance system memory leak (process ID: JVM1024). Immediate garbage collection and service instance isolation are recommended." The system automatically triggered the debugging and self-healing module to free up memory. Five minutes later, the service success rate returned to 95%, and the alarm was resolved.

[0027] Debugging self-healing module 4, the debugging self-healing module 4 is used to track and analyze according to the alarm instruction and generate a corresponding repair strategy; The debugging self-healing module 4 performs tracking analysis according to the alarm instruction and generates a corresponding repair strategy. The specific steps include: H1, the debugging self-healing module 4 parses the fault location information in the alarm instruction, extracts the abnormal process identifier and service call path of the office equipment, and synchronously retrieves the operation log data 2 minutes before the fault occurs to form a diagnostic context; H2. Match the diagnostic context with a preset repair strategy database: If there is a historical repair record for the same failure mode, prioritize the service restart instructions or resource allocation plan in the corresponding strategy; if it is a new failure mode, automatically generate process isolation instructions based on the service call path and allocate a backup resource pool; H3. After performing the repair operation, collect office equipment operating status data in real time to verify the repair effect: when the service call success rate returns to above the dynamic baseline threshold and remains stable for 5 minutes, the fault is marked as eliminated; if a second alarm occurs after the repair, the fault level is upgraded, triggering the remote expert diagnosis process and generating an in-depth equipment inspection task.

[0028] Among them, the abnormal process identifier of the office equipment in step H1 assigns a unique identification code to each abnormal process in the system of the office equipment, which includes the process name, process ID and the name of the service to which it belongs, and is used to quickly locate the fault process instance; the service call path is a complete flow link that records the service request when the exception occurs, including the called microservice node, API interface sequence and dependent database table, which is used to trace the fault propagation path.

[0029] Accurately locate the source of faults through abnormal process identifiers and service call paths, shortening problem troubleshooting time (70% reduction on average); based on historical policy matching and automated resource allocation, high-frequency faults can be repaired in seconds (such as service restart ≤ 10 seconds), reducing the risk of business interruption; a closed-loop verification mechanism (success rate threshold + continuous monitoring) ensures the effectiveness of repairs, and a secondary alarm escalation mechanism prevents fault escalation and reduces the need for manual intervention; the ability to trace fault propagation paths provides data support for system architecture optimization and reduces the occurrence of faults in the long term.

[0030] The test verification module 5 is used to verify the feasibility of the repair strategy, and after the verification is completed, re-run the abnormal simulation test module 1 to determine whether the service availability of the office equipment is restored.

[0031] The test verification module 5 verifies the feasibility of the repair strategy and, after the verification is completed, reruns the abnormal simulation test module 1 to determine whether the service availability of the office equipment is restored. The specific steps include: K1, loading the repair strategy in the virtual test environment of the test verification module 5, simulating the execution of service restart and resource allocation operations, synchronously collecting the software process response time and service call success rate of office equipment, and generating a repair effect evaluation report; K2. Compare the operating indicators in the repair effect evaluation report with the dynamic baseline. If the fluctuation range of the process response time drops to within 10% and the service call success rate reaches more than 95% for 5 consecutive minutes, the repair strategy is determined to be effective. If any indicator does not meet the standard, return to the debugging and self-healing module 4 to trigger the expert remote supplementary diagnosis process; K3. After the repair strategy is verified to be effective, it will be deployed to the actual operating environment, and the service instance replacement and abnormal process termination operations will be executed. The operating status of the office equipment will be continuously monitored for 30 minutes. If no new alarm instructions are triggered during this period, the service availability will be confirmed to be restored. If related anomalies are detected, the backup repair plan will be activated and the policy database will be updated. K4. After completing the actual environment verification, re-trigger the multi-level fault injection strategy of the abnormal simulation test module 1, compare the difference rate of service availability indicators before and after repair, and generate a final recovery confirmation instruction if the difference rate is less than 3%. The verification result is associated with the equipment operation history database for the subsequent dynamic baseline optimization.

[0032] Pre-verify repair strategies in a virtual test environment to isolate risks and assess the safety of repair plans, avoiding secondary failures caused by direct operation of the production environment. A closed-loop verification mechanism (virtual testing → actual deployment → continuous monitoring → secondary simulation testing) is used to ensure the effectiveness of repair strategies and system stability, reducing the false positive rate to below 5%. Dynamically compare service availability indicators before and after repairs to quantitatively verify the recovery effect (difference rate <3%), providing accurate data support for dynamic baseline optimization. Correlation anomaly monitoring and backup plan triggering mechanisms improve the fault tolerance of complex failures, shortening the average system recovery time by 60%. Verification results are linked to historical databases to continuously iterate and optimize the repair strategy library and dynamic baseline parameters, forming a self-performing operation and maintenance system.

[0033] The system builds a four-layer collaborative architecture based on the cloud platform, including: The perception layer deploys multiple types of sensors to collect equipment operation data, including temperature sensors to monitor the heat dissipation status of office equipment hardware, software process status sensors to track software service activity, and network protocol sensors to capture TCP / UDP packet characteristics. The transport layer uses a low-latency communication protocol to achieve encrypted data transmission, supports the MQTT protocol and HTTP / 2 dual-channel redundant transmission mechanism, and configures an adaptive bandwidth allocation module to dynamically adjust the priority of data packets; The cloud platform layer includes a distributed storage cluster and a streaming computing engine, which enables collaborative computing of historical data batch processing and real-time data window analysis. The built-in data cleaning module normalizes multi-source heterogeneous data. The application layer integrates a visual monitoring interface and an automated operation and maintenance strategy engine, supporting the display of three-dimensional heat maps of equipment status and the generation of fault root cause tracing trees.

[0034] The above descriptions are merely embodiments of the present invention and are not intended to limit the patent scope of the present invention. Any equivalent structure or equivalent process transformation made using the contents of the present invention's description and drawings, or directly or indirectly applied in other related technical fields, are also included in the patent protection scope of the present invention.

Claims

1. A smart office remote operation and maintenance system, characterized by: It includes an abnormal simulation test module (1), a dynamic baseline generation module (2), a real-time monitoring module (3), a debugging and self-healing module (4), and a test verification module (5); An abnormality simulation test module (1), the abnormality simulation test module (1) comprises a simulation unit and a generation unit, the simulation unit is used to perform a stress test on the office equipment by injecting a simulated fault data packet, and the generation unit is used to generate corresponding behavioral instructions according to the test result; A dynamic baseline generation module (2), the dynamic baseline generation module (2) dynamically adjusts the behavior threshold of the software in the office equipment through a preset processing unit based on the historical operation data of the office equipment and the behavior instruction, thereby generating a dynamic baseline; A real-time monitoring module (3), the real-time monitoring module (3) is used to monitor the abnormal simulation test module (1) and the dynamic baseline generation module (2) in real time, and preset an analysis unit to match the dynamic baseline with the error pattern in the analysis unit to generate an alarm instruction; A debugging self-healing module (4), the debugging self-healing module (4) is used to perform tracking analysis according to the alarm instruction and generate a corresponding repair strategy; A test verification module (5) is used to verify the feasibility of the repair strategy and, after the verification is completed, re-run the abnormal simulation test module (1) to determine whether the service availability of the office equipment has been restored.

2. The smart office remote operation and maintenance system according to claim 1, characterized in that: Communication connections are established among the dynamic baseline generation module (2), the abnormal simulation test module (1), the real-time monitoring module (3), the debugging and self-healing module (4), and the test verification module (5).

3. The smart office remote operation and maintenance system according to claim 2, characterized in that: The abnormal simulation test module (1) performs stress testing on office equipment, which includes a multi-level fault injection strategy: Hardware fault simulation uses virtualization technology to generate scenarios such as CPU overload, memory exhaustion, and disk bad sectors in office equipment software. System-level fault simulation to create software system service crashes, driver conflicts, and permission anomalies in office equipment; Application layer fault simulation, including software database deadlocks in office equipment, middleware message accumulation, and microservice call chain breaks; Network layer fault simulation: set bandwidth limitation, packet loss, and DNS hijacking test scenarios, and record the cascading impact path of faults at each layer.

4. The smart office remote operation and maintenance system according to claim 3, characterized in that: The generating unit is used to generate corresponding behavioral instructions according to the test results, and the steps include: S1. When the simulation unit injects a simulated fault data packet into the software of the office equipment, the generation unit collects multi-dimensional parameter data in real time during the software operation process, including process response delay, service call success rate, and memory usage fluctuation value; pre-processes the collected multi-dimensional parameter data, eliminates instantaneous noise interference through sliding window mean calculation, and extracts abnormal characteristic parameters; S2. Match the extracted abnormal characteristic parameters with the preset fault model library, and generate an intermediate instruction containing the fault type and impact level according to the matching results; S3. Generate executable behavioral instructions based on the fault type and impact level of the intermediate instructions; The behavior instruction is transmitted to the dynamic baseline generation module (2) through a preset interface.

5. The smart office remote operation and maintenance system according to claim 4, characterized in that: The specific steps of generating a dynamic baseline in the dynamic baseline generation module (2) are as follows: M1, the processing unit in the dynamic baseline generation module (2) collects historical operation data of office equipment within a preset time period, including the process response time, service call success rate and memory usage change trend of the software in the office equipment, and simultaneously receives the behavior instruction output by the generation unit, extracts the fault type and impact level recorded in the behavior instruction, aligns the historical operation data with the behavior instruction according to the time axis, eliminates invalid data segments caused by the office equipment downtime maintenance or external interference, and forms a standardized data set; M2. Extract core indicators of office equipment software behavior from the standardized data set, analyze the fluctuation range of software process response time in the office equipment under different load conditions, determine the normal fluctuation range, and statistically analyze the distribution characteristics of the service call success rate of the software in the office equipment during the fault-free period to determine the lower limit of normal fluctuation. Calculate the average daily change in the memory usage of the software in the office equipment, identify the reasonable growth range caused by software updates, and generate an initial reference baseline for each indicator based on the above analysis results; M3. The processing unit dynamically modifies the initial reference baseline based on the fault type in the behavior instruction. If the behavior instruction contains a high-frequency transient fault record, the upper limit of the normal fluctuation range is expanded. If the behavior instruction indicates a memory leak fault, the daily growth threshold of the memory usage rate is reduced. Based on the decrease in the service call success rate during the fault period, the lower limit of the fluctuation of the service call success rate is dynamically adjusted. A dynamic threshold set is formed through iterative optimization. M4. By associating and adapting the dynamic threshold set with the operating environment of the office equipment, the permissible range of the process response time is automatically extended during high-load periods, and the maximum permissible value of the memory usage rate is adjusted quarterly according to the aging degree of the equipment hardware, and finally a dynamic baseline is generated and pushed to the real-time monitoring module (3).

6. The smart office remote operation and maintenance system according to claim 5, characterized in that: The steps for generating the alarm instruction in the real-time monitoring module (3) are as follows: Q1. The analysis unit collects data on software process response time, service call success rate, and memory usage during the operation of office equipment in real time, and forms a standardized monitoring data stream after eliminating environmental noise interference; Q2. Compare the standardized monitoring data stream with the normal fluctuation range in the dynamic baseline item by item. When the software process response time exceeds the upper limit of the range for three consecutive times, the service call success rate decreases simultaneously, and the memory usage fluctuation range exceeds twice the historical average for two sampling periods, calculate the comprehensive deviation of the current data from the dynamic baseline; Q3. When the comprehensive deviation reaches a preset threshold, the fault cases with the same fluctuation characteristics are retrieved from the error pattern database in the analysis unit, and combined with the abnormal event records in the office equipment operation log, an alarm instruction containing fault location information and urgency classification is generated.

7. The smart office remote operation and maintenance system according to claim 6, characterized in that: The debugging self-healing module (4) performs tracking analysis according to the alarm instruction and generates a corresponding repair strategy. The specific steps include: H1, the debugging self-healing module (4) analyzes the fault location information in the alarm instruction, extracts the abnormal process identifier and service call path of the office equipment, and synchronously retrieves the operation log data 2 minutes before the fault occurs to form a diagnostic context; H2. Match the diagnostic context with a preset repair strategy database: If there is a historical repair record for the same failure mode, prioritize the service restart instructions or resource allocation plan in the corresponding strategy; if it is a new failure mode, automatically generate process isolation instructions based on the service call path and allocate a backup resource pool; H3. After performing the repair operation, collect office equipment operating status data in real time to verify the repair effect: when the service call success rate returns to above the dynamic baseline threshold and remains stable for 5 minutes, the fault is marked as eliminated; if a second alarm occurs after the repair, the fault level is upgraded, triggering the remote expert diagnosis process and generating an in-depth equipment inspection task.

8. The smart office remote operation and maintenance system according to claim 7, characterized in that: The abnormal process identifier of the office equipment in step H1 assigns a unique identification code to each abnormal process in the system of the office equipment, including the process name, process ID and the name of the service to which it belongs, which is used to quickly locate the faulty process instance; the service call path is a complete flow link that records the service request when the exception occurs, including the called microservice node, API interface sequence and dependent database table, which is used to trace the fault propagation path.

9. The smart office remote operation and maintenance system according to claim 8, characterized in that: The test verification module (5) verifies the feasibility of the repair strategy, and after the verification is completed, re-runs the abnormal simulation test module (1) to determine whether the service availability of the office equipment is restored. The specific steps include: K1, loading the repair strategy in the virtual test environment of the test verification module (5), simulating the execution of service restart and resource allocation operations, synchronously collecting the software process response time and service call success rate of office equipment, and generating a repair effect evaluation report; K2, comparing the operating indicators in the repair effect evaluation report with the dynamic baseline. If the fluctuation range of the process response time drops to within 10% and the service call success rate reaches more than 95% for 5 consecutive minutes, the repair strategy is determined to be effective; if any indicator does not meet the standard, return to the debugging self-healing module (4) to trigger the expert remote supplementary diagnosis process; K3. After the repair strategy is verified to be effective, it will be deployed to the actual operating environment, and the service instance replacement and abnormal process termination operations will be executed. The operating status of the office equipment will be continuously monitored for 30 minutes. If no new alarm instructions are triggered during this period, the service availability will be confirmed to be restored. If related anomalies are detected, the backup repair plan will be activated and the policy database will be updated. K4. After completing the actual environment verification, re-trigger the multi-level fault injection strategy of the abnormal simulation test module (1) to compare the difference rate of service availability indicators before and after repair. If the difference rate is less than 3%, generate a final recovery confirmation instruction and associate the verification result with the equipment operation history database for subsequent dynamic baseline optimization.

Images