Code remote repair method and device based on production environment and storage medium

Abstract

The invention discloses a code remote repair method and device based on a production environment and a storage medium, relates to the technical field of code diagnosis, and mainly aims at improving the repair efficiency and the repair accuracy of codes and improving the user experience. Comprising the steps of establishing remote debugging connection with a target service instance in a production environment in response to a code repair request of a user, and collecting monitoring data of the target service instance under a multi-dimensional monitoring index in real time through a remote debugging interface based on an establishment success signal of the remote debugging connection; based on the monitoring data, performing anomaly detection on the target service instance by using multiple anomaly detection modes, and based on an anomaly detection result, performing anomaly code positioning in an original running service code corresponding to the target service instance; and determining a repair code corresponding to the abnormal code at the abnormal code positioning position, and performing hot replacement on the abnormal code in the target service instance continuously running in the production environment by using the repair code.

Description

Technical Field

[0001] This invention relates to the field of code diagnostic technology, and in particular to a method, apparatus and storage medium for remote code repair in a production environment. Background Technology

[0002] In modern distributed systems and microservice architectures, fault repair technology has become a crucial element in ensuring system stability and reliability.

[0003] Currently, code fixes are typically performed locally, and the fixed code is then deployed to the production environment. However, this approach involves a cumbersome process of local fix → testing → packaging → deployment, and also requires restarting the service, which is time-consuming and labor-intensive. Furthermore, the local environment may miss issues specific to the production environment, resulting in inaccurate code fixes that fail to effectively resolve user problems. Summary of the Invention

[0004] This invention provides a method, apparatus, and storage medium for remote code repair in a production environment, which mainly improves the efficiency and accuracy of code repair and enhances the user experience.

[0005] According to a first aspect of the present invention, a method for remote code repair in a production environment is provided, comprising: In response to a user's code repair request, a remote debugging connection is established with the target service instance in the production environment. Based on the successful establishment signal of the remote debugging connection, the monitoring data of the target service instance under multi-dimensional monitoring indicators is collected in real time through the remote debugging interface. Based on the monitoring data, anomaly detection is performed on the target service instance using multiple anomaly detection methods, and based on the anomaly detection results, the abnormal code is located in the original running service code corresponding to the target service instance. Determine the repair code corresponding to the exception code at the location of the exception code, and use the repair code to hot replace the exception code in the target service instance that is continuously running in the production environment.

[0006] Optionally, the step of collecting monitoring data of the target service instance in real time under multi-dimensional monitoring indicators through a remote debugging interface includes: Obtain the current load information of the running system corresponding to the target service instance, the business attribute information of the target service instance, and the real-time monitoring information and indicator feature data under the multi-dimensional monitoring indicators of the target service instance; Based on the current load information, the business attribute information, the real-time monitoring information, and the indicator feature data, set corresponding sampling frequencies and sampling resources for each of the multi-dimensional monitoring indicators; Based on the sampling frequency and the sampling resources, data under the corresponding monitoring indicators are collected through the remote debugging interface to obtain the monitoring data of the target service instance under the multi-dimensional monitoring indicators.

[0007] Optionally, after collecting monitoring data of the target service instance under multi-dimensional monitoring metrics in real time through a remote debugging interface, the method further includes: The target data relationship type of the monitoring data is determined, and a dimensionality reduction processing method corresponding to the target data relationship type is used to perform dimensionality reduction processing on the monitoring data. The method for performing dimensionality reduction processing on the monitoring data using a dimensionality reduction processing method corresponding to the target data relationship type includes: if the target data relationship type is a linear relationship type, then determining the data matrix corresponding to the monitoring data, determining the covariance matrix corresponding to the data matrix, performing eigenvalue decomposition on the covariance matrix to obtain eigenvalues ​​and eigenvectors corresponding to the eigenvalues, selecting principal component eigenvectors based on the eigenvalues, determining the data projection direction based on the principal component eigenvectors, projecting the monitoring data along the data projection direction, and using the projected monitoring data as the dimensionality-reduced monitoring data. The monitoring data after dimensionality reduction is processed using a preset sliding time window, and then the time-series processed monitoring data is standardized.

[0008] Optionally, the step of performing anomaly detection on the target service instance based on the monitoring data using multiple anomaly detection methods includes: The monitoring data is input into multiple preset anomaly detection models for parallel anomaly detection, and the initial anomaly detection results output by each preset anomaly detection model are obtained. The multiple preset anomaly detection models include a preset unsupervised anomaly detection model, a preset supervised anomaly detection model, and a preset semi-supervised anomaly detection model. The service dependencies and deployment environment information of the target service instance are determined, as well as the user's operation sequence on the target service instance. Based on the service dependencies, the deployment environment information, and the operation sequence, the initial anomaly detection result is corrected. Each of the corrected initial anomaly detection results is weighted and fused, and the anomaly detection result of the monitoring data is determined based on the weighted fusion result.

[0009] Optionally, the step of locating the abnormal code in the original running service code corresponding to the target service instance based on the anomaly detection result includes: Construct a causal relationship network graph among multi-dimensional monitoring indicators, wherein the multi-dimensional monitoring indicators represent nodes in the causal relationship network graph, and the causal influence relationship among the multi-dimensional monitoring indicators represents the edge between nodes in the causal relationship network graph; Based on the causal relationship network diagram, causal effect analysis is performed on the multi-dimensional monitoring indicators and the anomaly detection results. Based on the causal effect analysis results, the degree of influence of the multi-dimensional monitoring indicators on the occurrence of the anomaly detection results is determined. Each of the multi-dimensional monitoring metrics of the target service instance during the historical anomaly period is taken as a target monitoring metric X. Based on the target monitoring metric X, a counterfactual reasoning scenario is constructed for simulation. The counterfactual reasoning scenario simulates the system state corresponding to the target service instance when the target monitoring metric X does not occur during the historical anomaly period. Based on the simulation results of the counterfactual reasoning scenario, a counterfactual dataset is determined. Based on the counterfactual dataset, the counterfactual system state Y' corresponding to the target service instance in the counterfactual reasoning scenario is determined. The counterfactual dataset includes target intervention indicator data when the target monitoring indicator X does not occur abnormally and intervention indicator data under the remaining monitoring indicators determined based on the target intervention indicator data. The remaining monitoring indicators are the multi-dimensional monitoring indicators after removing the target monitoring indicator X. Based on the counterfactual system state Y' and the actual system state Y of the target service instance during the historical anomaly occurrence period, determine the necessity of the target monitoring indicator X for the occurrence of the anomaly detection result; Based on the degree of influence and necessity of the multi-dimensional monitoring indicators on the occurrence of the anomaly detection results, the root cause monitoring indicators that affect the anomaly detection results are determined from the multi-dimensional monitoring indicators. The call stack of the root cause monitoring metric is determined. Based on the call stack, similar stack matching is performed in a preset historical anomaly case library. Based on the matching result, the anomaly code is located in the original running service code corresponding to the target service instance.

[0010] Optionally, the step of hot-replacing the abnormal code in the target service instance that is continuously running in the production environment using the repair code includes: The repair code was subjected to compatibility verification and hot-swap execution verification in debug mode; The verified repair code is dynamically loaded into the production environment of the target system to which the target service instance belongs, forming a new version of service code that coexists with the original running service code corresponding to the target service instance; After hot-replacing the faulty code in the target service instance that is continuously running in the production environment using the repair code, the method further includes: In response to a service request from a target user, based on user visibility configuration rules, the target group to which the target user belongs is determined, and the service request is routed to the service code corresponding to the target group for execution, wherein the corresponding version of the service code is either the original running service code or the new version of the service code.

[0011] Optionally, after hot-replacing the faulty code in the target service instance that is continuously running in the production environment using the repair code, the method further includes: Start a preset monitoring thread to monitor the execution process of the new version service code obtained after hot replacement in real time, and obtain the performance indicators of the execution process of the new version service code based on the monitoring results; Based on the performance metrics, determine whether the preset code rollback condition is triggered. If so, terminate the execution of the new version of the service code and route all user requests to the original running service code for execution. Otherwise, continue to control the execution of the new version of the service code. The code repair process is shown to users through a visual debugging interface.

[0012] According to a second aspect of the present invention, a remote code repair device based on a production environment is provided, comprising: The acquisition unit is used to respond to the user's code repair request, establish a remote debugging connection with the target service instance in the production environment, and collect the monitoring data of the target service instance under multi-dimensional monitoring indicators in real time through the remote debugging interface based on the successful establishment signal of the remote debugging connection. The detection unit is used to perform anomaly detection on the target service instance based on the monitoring data using multiple anomaly detection methods, and to locate the abnormal code in the original running service code corresponding to the target service instance based on the anomaly detection results. The replacement unit is used to determine the repair code corresponding to the abnormal code at the location of the abnormal code, and to use the repair code to hot replace the abnormal code in the target service instance that is continuously running in the production environment.

[0013] According to a third aspect of the present invention, a computer-readable storage medium is provided having a computer program stored thereon that, when executed by a processor, implements the above-described remote code repair method based on a production environment.

[0014] According to a fourth aspect of the present invention, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the above-described remote code repair method based on a production environment.

[0015] According to the present invention, a method, apparatus, and storage medium for remote code repair in a production environment are provided. Compared with the current method of repairing code in a local environment and then deploying the repaired code to the production environment, the present invention establishes a remote debugging connection with a target service instance in the production environment in response to a user's code repair request. Based on the successful establishment signal of the remote debugging connection, monitoring data of the target service instance under multi-dimensional monitoring indicators is collected in real time through the remote debugging interface. Then, based on the monitoring data, anomaly detection is performed on the target service instance using various anomaly detection methods. Based on the anomaly detection results, the abnormal code is located in the original running service code corresponding to the target service instance. Finally, the repair code corresponding to the abnormal code at the anomaly code location is determined, and the repair code is used to hot-swap the abnormal code in the target service instance that is continuously running in the production environment. This enables real-time monitoring and operation of services in the production environment via remote debugging interfaces, improving the timeliness of code repair; by performing anomaly detection and location on target service instances through multiple methods, the source of faults can be accurately identified, thereby improving the accuracy of code repair; and by dynamically hot-replacing the service code that is continuously running in the production environment, it can be executed without restarting the system, ensuring that the system remains stable during the update process, reducing business interruptions caused by fault repair, and thus improving the user experience. Attached Figure Description

[0016] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this application, illustrate exemplary embodiments of the invention and, together with their description, serve to explain the invention and do not constitute an undue limitation thereof. In the drawings: Figure 1 This invention provides a flowchart of a remote code repair method based on a production environment. Figure 2 This invention provides a flowchart of another remote code repair method based on a production environment. Figure 3 This diagram illustrates the structure of a remote code repair device based on a production environment, according to an embodiment of the present invention. Figure 4 This invention provides a schematic diagram of another remote code repair device based on a production environment. Figure 5A schematic diagram of the physical structure of a computer device provided in an embodiment of the present invention is shown. Detailed Implementation

[0017] The present invention will be described in detail below with reference to the accompanying drawings and embodiments. It should be noted that, unless otherwise specified, the embodiments and features described in the present application can be combined with each other.

[0018] Currently, the common practice of fixing code locally and then deploying the fixed code to the production environment involves a cumbersome process and requires restarting services, which is time-consuming and labor-intensive. Furthermore, local environments may miss issues specific to the production environment, leading to inaccurate code fixes and failing to effectively resolve user problems.

[0019] To address the aforementioned problems, embodiments of the present invention provide a remote code repair method based on a production environment, such as... Figure 1 As shown, the method includes: 101. In response to a user's code repair request, establish a remote debugging connection with the target service instance in the production environment. Based on the successful establishment signal of the remote debugging connection, collect monitoring data of the target service instance under multi-dimensional monitoring indicators in real time through the remote debugging interface.

[0020] The target service instance can be a service in any scenario, such as payment services in a payment scenario, various chat programs, etc. The multi-dimensional monitoring metrics include application layer monitoring metrics, system layer monitoring metrics, and middleware layer monitoring metrics. The monitoring data under the application layer monitoring metrics include code execution path, execution time of key methods, input parameters, output parameters, context environment, etc. The monitoring data under the system layer monitoring metrics include system memory usage (such as CPU utilization, disk I / O, network traffic, Docker container resource limits, Kubernetes Pod status, etc.), garbage collection status, thread stack information, etc. The middleware layer monitoring metrics include SQL (Structured Query Language) execution status, connection status and lock contention, such as message flow, processing latency, system cache hit rate, expiration policy execution status, etc.

[0021] In this embodiment of the invention, a remote debugging connection is established with the target service instance via the HTTP protocol to ensure the security and reliability of the debugging process. The standard HTTP request and response mechanism simplifies the interaction process with the code. The remote debugging interface enables multi-dimensional data collection from the target service instance, detection and precise location of abnormal code, and dynamic hot-replacement of abnormal code. Before remote debugging via the interface, user authentication is required to ensure that only authorized users can perform debugging operations. During authentication, users must provide valid credentials (such as username and password) to pass the authentication mechanism. After successful authentication, developers are allowed to set breakpoints at critical locations in the code. Developers can specify breakpoint locations via the HTTP interface, and the system will set breakpoints in the running instance according to the request. Simultaneously, the remote debugging interface can also monitor variable information during code execution in real time and display relevant variable data from the perspective of a specified developer or developer group. Developers can obtain the current variable values ​​via HTTP requests, and the system will configure the variable status display based on the developer's permissions and perspective to help identify potential problems. Furthermore, the remote debugging interface also supports step-by-step execution of the code. Developers can send step instructions via the HTTP interface, and the system will execute the code step by step according to the instructions, providing detailed execution path and status information. Furthermore, developers can modify variable content during real-time monitoring via the remote debugging interface to test code behavior and responses, ensuring users can flexibly experiment and validate solutions. The remote debugging interface supports management and debugging of any instance in the current cluster; developers can select specific instances to operate on, and the system provides an instance list and status information to assist in the selection process. Through this process, the system implements an HTTP-based remote debugging interface, providing users with flexible debugging tools and real-time monitoring capabilities, supporting rapid and effective management and optimization of code in a distributed environment.

[0022] 102. Based on monitoring data, use multiple anomaly detection methods to perform anomaly detection on the target service instance, and based on the anomaly detection results, locate the abnormal code in the original running service code corresponding to the target service instance.

[0023] The original running service code is the service code corresponding to the target service instance before the repair.

[0024] In this embodiment of the invention, multiple anomaly detection methods, such as multiple anomaly detection models, are used for parallel anomaly detection. The detection results from these multiple methods are then fused to determine the final anomaly detection result. Based on this result, root cause analysis is performed, and the abnormal code is located within the original running service code. Through the joint detection of multiple anomaly detection methods, rapid and accurate fault location in distributed systems can be achieved, and the system can work in conjunction with remote debugging interfaces to further improve fault location efficiency.

[0025] 103. Determine the repair code corresponding to the exception code at the location of the exception code, and use the repair code to hot-replace the exception code in the target service instance that is continuously running in the production environment.

[0026] In this embodiment of the invention, a code hot-swap architecture is designed, which consists of components such as a code management module, a hot-swap engine, a user group filter, a status monitor, and a rollback manager. The code management module is responsible for code version control, metadata generation, and dependency management; the hot-swap engine is responsible for dynamically loading and replacing code; the user group filter is used to implement code visibility control for specific user groups; the status monitor is used to monitor the code replacement process and system status; and the rollback manager is used to perform code rollback when an exception occurs. Specifically, the code management module assigns a unique version identifier to the repair code, for example, in the format "major version number.minor version number.revision number-build number" (e.g., 1.2.3-456). It also records detailed information about abnormal code changes, including modified files, line numbers, and specific changes, storing the code change information in a version history database for easy subsequent querying and backtracking. Static code analysis tools are used to parse the code structure of the original running service code and the repair code, identifying the definitions of classes, methods, and properties, and extracting code behavior characteristics, including program entry points, event handling functions, and callback mechanisms. Based on this information, a code dependency graph is constructed to represent the call and data flow relationships between modules. The generated metadata, such as program entry points, event handling functions, and callback mechanisms, is stored in a preset format, such as JSON, and contains key code information. Furthermore, based on the stored code metadata, the repair code undergoes compatibility verification and hot-swap execution verification in debug mode. After successful verification, the original running service code in the production environment is hot-swapped using the repair code to obtain the new version of the service code. This embodiment of the invention, through dynamic hot-swapping of continuously running service code in the production environment, can be performed without restarting the system, ensuring stable system operation during the update process, reducing business interruptions caused by fault repair, and thus improving user experience.

[0027] According to the present invention, a remote code repair method based on a production environment, compared with the current method of repairing code in a local environment and then deploying the repaired code to the production environment, the present invention establishes a remote debugging connection with the target service instance in the production environment in response to the user's code repair request. Based on the successful establishment signal of the remote debugging connection, the present invention collects monitoring data of the target service instance under multi-dimensional monitoring indicators in real time through the remote debugging interface. Then, based on the monitoring data, the present invention performs anomaly detection on the target service instance using various anomaly detection methods, and based on the anomaly detection results, locates the abnormal code in the original running service code corresponding to the target service instance. Finally, the present invention determines the repair code corresponding to the abnormal code at the anomaly code location, and uses the repair code to hot-swap the abnormal code in the target service instance that is continuously running in the production environment. This enables real-time monitoring and operation of services in the production environment via remote debugging interfaces, improving the timeliness of code repair; by performing anomaly detection and location on target service instances through multiple methods, the source of faults can be accurately identified, thereby improving the accuracy of code repair; and by dynamically hot-replacing the service code that is continuously running in the production environment, it can be executed without restarting the system, ensuring that the system remains stable during the update process, reducing business interruptions caused by fault repair, and thus improving the user experience.

[0028] Furthermore, to better illustrate the process of remotely repairing code in a production environment, as a refinement and extension of the above embodiments, this invention provides another method for remotely repairing code in a production environment, such as... Figure 2 As shown, the method includes: 201. In response to a user's code repair request, establish a remote debugging connection with the target service instance in the production environment. Based on the successful establishment signal of the remote debugging connection, collect monitoring data of the target service instance under multi-dimensional monitoring indicators in real time through the remote debugging interface.

[0029] In this embodiment of the invention, after establishing a remote debugging connection with the target service instance in the production environment through a preset protocol (such as HTTP), in order to achieve service anomaly detection and abnormal code location, it is first necessary to collect monitoring data of the target service instance under multi-dimensional monitoring indicators in real time through the remote debugging interface. Based on this, step 201 specifically includes: obtaining the current load information of the running system corresponding to the target service instance, the business attribute information of the target service instance, the real-time monitoring information and indicator feature data under multi-dimensional monitoring indicators of the target service instance; setting corresponding sampling frequencies and sampling resources for the multi-dimensional monitoring indicators based on the current load information, the business attribute information, the real-time monitoring information and the indicator feature data; and collecting data under the corresponding monitoring indicators through the remote debugging interface based on the sampling frequency and the sampling resources to obtain the monitoring data of the target service instance under multi-dimensional monitoring indicators.

[0030] Among them, the current load information refers to the operating pressure and resource usage of the running system; the business attribute information refers to the business impact degree, anomaly sensitivity, historical anomaly correlation, core business, non-core business, etc. of the target service instance; the real-time monitoring information includes comprehensive data from the application layer, system layer, and middleware layer, such as the execution time of key methods, input and output parameter information, CPU utilization, disk I / O, network traffic, message flow and processing latency, etc.; the indicator feature data refers to the judgment result of whether the data is abnormal.

[0031] Specifically, for example, the system automatically adjusts the data collection frequency based on current load information. For instance, it reduces the sampling rate under high load to minimize performance impact. Simultaneously, the system can implement intelligent sampling based on anomaly detection. When a potential anomaly is detected in a monitoring indicator based on real-time detection information and indicator characteristic data, the sampling rate of that monitoring indicator is increased. The system designs and implements a tiered sampling strategy, maintaining a high sampling rate for core business processes and a low sampling rate for non-core business processes. Meanwhile, based on information such as the business impact, anomaly sensitivity, and historical anomaly correlation of each monitoring indicator, the system calculates the importance score for each monitoring indicator. Then, based on the importance score and the current system load, it dynamically allocates sampling resources to the corresponding monitoring indicators. Finally, based on the sampling frequency and sampling resources, data under the corresponding monitoring indicators is collected in real time. Furthermore, the system implements a sampling feedback mechanism, dynamically adjusting the sampling strategy based on the effectiveness of the sampling results, such as adjusting the sampling frequency and sampling resources. This embodiment of the invention, by setting the sampling frequency and sampling resources, can optimize the performance, cost, data accuracy, and response efficiency of data collection.

[0032] Furthermore, to ensure data quality, monitoring data collected under multi-dimensional monitoring indicators requires preprocessing such as dimensionality reduction. Based on this, the method includes: determining the target data relationship type of the monitoring data and performing dimensionality reduction processing on the monitoring data using a dimensionality reduction method corresponding to the target data relationship type. Specifically, the method for performing dimensionality reduction processing on the monitoring data using a dimensionality reduction method corresponding to the target data relationship type includes: if the target data relationship type is a linear relationship type, determining the data matrix corresponding to the monitoring data, determining the covariance matrix corresponding to the data matrix, performing eigenvalue decomposition on the covariance matrix to obtain eigenvalues ​​and corresponding eigenvectors, selecting principal component eigenvectors based on the eigenvalues, determining the data projection direction based on the principal component eigenvectors, projecting the monitoring data along the data projection direction, and using the projected monitoring data as the dimensionality-reduced monitoring data; performing time-series processing on the dimensionality-reduced monitoring data using a preset sliding time window, and standardizing the time-series processed monitoring data.

[0033] The target data relationship types include linear relationship types and non-linear relationship types.

[0034] Specifically, if the monitoring data exhibits a linear relationship, principal component analysis (PCA) is used to reduce the dimensionality of the monitoring data. This involves determining the covariance matrix corresponding to the monitoring data, finding the direction with the largest variance (principal component) within the covariance matrix, using eigenvectors to represent the direction of the principal component, and eigenvalues ​​to represent the variance magnitude along that direction. The variance contribution rate of each eigenvalue is then calculated, and the cumulative variance contribution rate is determined based on this rate. Principal components are selected for retention based on the cumulative variance contribution rate, and a data projection direction is constructed based on the eigenvectors corresponding to the retained principal components. The monitoring data is then projected onto the principal components according to this projection direction, resulting in a low-dimensional representation of the monitoring data. In another embodiment of the invention, if the monitoring data exhibits a non-linear relationship, an autoencoder model can be used to perform a non-linear transformation on the monitoring data to extract its latent features, or weights can be set based on the importance of the monitoring data, and importance indicators can be selected based on these weights. This embodiment of the invention can employ incremental dimensionality reduction, supporting real-time processing of online data streams while preserving the mapping relationship before and after dimensionality reduction, ensuring data interpretability.

[0035] Furthermore, after dimensionality reduction of the monitoring data, time-series processing is required, such as using a sliding time window mechanism to capture short-term fluctuations and long-term trends of indicators. Specifically, a preset sliding time window is designed, and its size can be dynamically adjusted according to the frequency of data changes. This dynamically adjusted window is used to perform time-series processing on the dimensionality-reduced monitoring data. Alternatively, multiple windows can be used to process the dimensionality-reduced monitoring data in parallel to improve the efficiency of time-series processing. Further, operations such as Z-score standardization are performed on the time-series processed monitoring data to eliminate dimensional differences between different monitoring data. Robust standardization methods based on historical quantiles can also be used to standardize the monitoring data to reduce the impact of outliers on the standardization process. The impact of business periodicity (such as weekdays / weekends, daytime / nighttime) can also be considered, and time-related standardization can be performed on the monitoring data. This embodiment of the invention, by performing dimensionality reduction on monitoring data, can reduce the number of data features, retain key information, and reduce computational complexity. By performing time-series processing and standardization on the monitoring data, data quality can be improved, thereby improving the quality of code repair.

[0036] 202. Based on monitoring data, use multiple anomaly detection methods to perform anomaly detection on the target service instance, and based on the anomaly detection results, locate the abnormal code in the original running service code corresponding to the target service instance.

[0037] In this embodiment of the invention, in order to perform code repair, abnormal code detection is first required. Based on this, step 202 specifically includes: inputting the monitoring data into multiple preset abnormal detection models for parallel abnormal detection, and obtaining the initial abnormal detection result output by each preset abnormal detection model. The multiple preset abnormal detection models include a preset unsupervised abnormal detection model, a preset supervised abnormal detection model, and a preset semi-supervised abnormal detection model; determining the service dependency relationship and deployment environment information of the target service instance, and determining the user's operation behavior sequence on the target service instance; correcting the initial abnormal detection result based on the service dependency relationship, the deployment environment information, and the operation behavior sequence; performing weighted fusion on each of the corrected initial abnormal detection results, and determining the abnormal detection result of the monitoring data based on the weighted fusion result.

[0038] Among them, service dependency refers to the strength of dependency and calling mode between service instances; deployment environment information refers to the operating version, JDK version, server configuration, etc. of the system to which the target service instance is deployed; operation behavior sequence contains the user's operation imprints on the target service instance, such as the number of clicks, page dwell time, etc.

[0039] Specifically, in the anomaly detection process of a pre-defined unsupervised anomaly detection model, density estimation models (such as LOF, DBSCAN) can be used to identify outliers based on data density; anomaly detection based on isolation forests (such as Isolation Forest) can be used to determine anomalies by assessing the difficulty of data segmentation; and boundary detection models based on single-class SVMs can be used to construct boundaries of normal data and identify outliers outside these boundaries. The detection result of the pre-defined unsupervised anomaly detection model can be determined based on the detection results of any one of the above models, or by comprehensively considering the detection results of at least two of the above models. In the anomaly detection process of a pre-defined supervised anomaly detection model, gradient boosting tree (XGBoost) models can be used to train the model using historically labeled anomaly data, and anomaly detection can be performed based on the trained model; deep neural network classifiers can be used to capture complex anomaly patterns through multilayer perceptrons; and LSTM-based temporal anomaly classifiers can be used to learn temporal patterns of anomaly occurrences and thus identify anomalies. The detection result of the pre-defined supervised anomaly detection model can be determined based on the detection results of any one of the above models, or by comprehensively considering the detection results of at least two of the above models. In the anomaly detection process of the pre-defined semi-supervised anomaly detection model, a semi-supervised learning model based on a small amount of labeled data combines the advantages of supervised and unsupervised learning for anomaly identification. Based on an active learning mechanism, the most informative samples are intelligently selected for manual annotation to train the model, and anomaly detection is performed based on the trained model. A pseudo-label-based self-trained model uses high-confidence predictions to expand the training data for further model training, and finally, anomaly detection is performed based on the trained model. The detection result of the pre-defined semi-supervised anomaly detection model can be determined based on the detection results of any one of the above models, or it can be determined by comprehensively considering the detection results of at least two of the above models.

[0040] Furthermore, a service call relationship graph is constructed to analyze the dependency strength and call patterns between services. Based on an anomaly propagation model using graph neural networks (such as GNNs), the propagation path of anomalies in the initial anomaly detection results is predicted among services. Considering both the service's own state and the health of dependent services, a service health score is determined. The correlation between user operation behavior sequences and anomaly occurrences is analyzed to identify user behavior patterns that may trigger anomalies, using user feedback as auxiliary information for anomaly detection. Deployment environment information is collected, and based on anomaly pattern recognition of environmental differences, environment-specific and general anomalies are distinguished. An environment change tracking mechanism is designed to correlate the temporal relationship between environment changes and anomaly occurrences. All of the above information is used to correct the initial anomaly detection results. Further, based on a voting method, weight coefficients for different initial anomaly detection results are determined, and multiple initial anomaly detection results are weighted and fused based on these weight coefficients to obtain the final anomaly detection result for the monitoring data. Alternatively, the performance of each model can be evaluated in real time, and the model weights can be dynamically adjusted based on the accuracy of the detection results. Then, the weighted fusion of detection results is performed based on the adjusted weights. During anomaly detection in the model, incremental learning algorithms can be designed to enable the model to continuously learn from newly emerging anomaly patterns. A model degradation detection mechanism can also be developed to promptly identify and replace models with degraded performance. Furthermore, during anomaly detection, a differentiated threshold strategy based on business importance can be implemented. For critical business operations, more sensitive anomaly detection thresholds can be used, such as designing time-aware threshold adjustments to consider different anomaly patterns during peak and off-peak periods, or dynamic thresholds based on the scope of anomaly impact, with stricter detection standards applied to large-scale anomalies. This can improve the accuracy of anomaly detection.

[0041] Furthermore, after determining the anomaly detection results, they need to be formatted for output. During formatting, key features of the anomaly detection results are first extracted, including anomaly type, severity, impact scope, and time characteristics. Then, an anomaly fingerprint is generated for rapid matching of similar historical anomalies, and a confidence score is calculated to assess the reliability of the detection results. Finally, the anomaly detection results are converted into a standard format, including fields such as anomaly ID, timestamp, affected components, and severity. To increase the comprehensiveness of the anomaly detection results, contextual information, such as relevant service status, environmental parameters, and user behavior data, can be added to the formatted information. An anomaly summary can also be generated to concisely describe the core characteristics of the anomaly.

[0042] In another embodiment of the present invention, after determining the anomaly detection result, it is also necessary to locate the abnormal code based on the anomaly detection result. Therefore, step 202 specifically includes: constructing a causal relationship network diagram among multi-dimensional monitoring indicators, wherein the multi-dimensional monitoring indicators represent nodes in the causal relationship network diagram, and the causal influence relationship between the multi-dimensional monitoring indicators represents the edges between nodes in the causal relationship network diagram; based on the causal relationship network diagram, performing causal effect analysis on the multi-dimensional monitoring indicators and the anomaly detection result respectively, and determining the degree of influence of the multi-dimensional monitoring indicators on the occurrence of the anomaly detection result based on the causal effect analysis results; taking any one of the multi-dimensional monitoring indicators of the target service instance during the historical anomaly occurrence period as a target monitoring indicator X, and constructing a counterfactual reasoning scenario for simulation based on the target monitoring indicator X, wherein the counterfactual reasoning scenario simulates the system state corresponding to the target service instance when the target monitoring indicator X did not occur during the historical anomaly occurrence period; and based on the simulation results of the counterfactual reasoning scenario... The process involves: determining a counterfactual dataset; determining the counterfactual system state Y' corresponding to the target service instance in the counterfactual reasoning scenario; wherein the counterfactual dataset includes target intervention indicator data when the target monitoring indicator X is not abnormal and intervention indicator data under the remaining monitoring indicators determined based on the target intervention indicator data, and the remaining monitoring indicators are the multi-dimensional monitoring indicators after removing the target monitoring indicator X; determining the necessity of the target monitoring indicator X for the occurrence of the anomaly detection result based on the counterfactual system state Y' and the actual system state Y of the target service instance during the historical anomaly occurrence period; determining the root cause monitoring indicator that affects the anomaly detection result based on the degree of influence and necessity of the multi-dimensional monitoring indicators on the occurrence of the anomaly detection result; determining the call stack of the root cause monitoring indicator; performing similar stack matching in a preset historical anomaly case library based on the call stack; and locating the anomaly code in the original running service code corresponding to the target service instance based on the matching result.

[0043] Specifically, the causal network diagram can be, but is not limited to, a Bayesian network diagram. Based on this causal network diagram, the dependencies between each monitoring indicator (variable) can be determined, and the influence strength of each monitoring indicator on the anomaly can be assessed based on causal effect analysis. Simultaneously, a counterfactual reasoning scenario is constructed: "If X did not occur, would Y still occur?" Based on this scenario, the system state of the target service instance is simulated when the monitoring metric X is not abnormal (system state includes both abnormal and normal states). The simulation results determine the counterfactual dataset, and based on this dataset, the counterfactual system state Y' corresponding to the target service instance in the counterfactual reasoning scenario is determined. This counterfactual system state Y' is compared with the actual state, and the necessity of the monitoring metric for the system anomaly is determined based on the comparison results. For example, taking an e-commerce system as an example, monitoring metrics include database response time, order processing time, and user order success rate. During a historical anomaly period, the observed real monitoring data for these multi-dimensional metrics are: database response time: 500ms (abnormal, normally 50ms); order processing time: 800ms (abnormal, normally 100ms); user order success rate: 60% (abnormal, normally 99%). Based on this real data, the system state Y = 1 (representing "abnormal"). Counterfactual analysis is then initiated to investigate "database response time." Is this the root cause? The counterfactual question is: "If the database response time hadn't slowed down at that time, would the system still be abnormal?" To answer this question, the database response time during the failure period was replaced from the real 500ms to a simulated normal value, such as 50ms. Order processing time and user order success rate are highly dependent on database response time. Even after the database response time returns to normal, order processing time and user order success rate should still be adjusted. For example, based on a database response time of 50ms, the order processing time is determined to be 100ms. Based on these two values, the user order success rate is determined to be 98.5%. This results in a counterfactual dataset consisting of a database response time of 50ms, an order processing time of 100ms, and a user order success rate of 98.5%. This counterfactual dataset is a self-consistent, hypothetical snapshot of data derived from modified and extrapolated real data. The counterfactual dataset is then input into a pre-built anomaly prediction model for system state prediction. The model outputs a normal system state Y' (Y' = 0, representing "normal"). Based on the above information, the result is: Real world: X anomaly → Y is abnormal (Y=1), counterfactual world: X is normal → Y' is normal (Y'=0).Conclusion: With normal database response time, no anomaly occurred, indicating that the database response time anomaly (X) is a "necessary" cause of the system anomaly (Y); that is, without X, Y would not occur. This allows us to determine the necessity of each monitoring indicator for the occurrence of system anomalies. Finally, based on the degree and necessity of the multi-dimensional monitoring indicators' influence on anomaly detection results, the root cause monitoring indicators affecting the anomaly detection results are identified among the multi-dimensional monitoring indicators. Furthermore, based on time-series dependency analysis using causal testing, the lead-lag relationship between monitoring indicators can be identified; based on information flow analysis using transfer entropy, the information transmission strength between monitoring indicators can be quantified; and based on dynamic time warping algorithms, time delays and distortions between different monitoring indicators can be handled, thereby correcting the root cause monitoring indicators. Furthermore, after identifying the root cause monitoring metrics, a deep stack analysis is performed on them. This analysis not only identifies the point where the root cause monitoring metrics throw an anomaly but also traces the anomaly propagation path. Then, the target call stack most similar to this call stack is matched against a pre-defined historical anomaly case database. The anomaly code information corresponding to this target call stack is used as the anomaly code information for the target service instance. Finally, anomaly code localization is performed within the target service instance based on this anomaly code information. The pre-defined historical anomaly case database stores various call stacks and their corresponding anomaly code information.

[0044] In another embodiment of the present invention, method-level performance profiling can be performed on the target service instance to identify methods with abnormal execution times. A hotspot scoring mechanism based on call frequency and execution time can highlight key bottlenecks. Code path coverage analysis can be performed to identify special execution paths under abnormal conditions. Historical comparative analysis of key variable values ​​can be conducted to identify variables deviating from the normal range. Variable impact analysis based on program slicing can trace the source of abnormal variable values. Path condition analysis based on symbolic execution can identify the input conditions leading to the anomaly. Anomaly localization is achieved through the above methods.

[0045] 203. Determine the repair code corresponding to the exception code at the location of the exception code, and use the repair code to hot replace the exception code in the target service instance that is continuously running in the production environment.

[0046] In this embodiment of the invention, after locating the abnormal code, the corresponding repair code is determined. Then, the abnormal code needs to be dynamically hot-swapped using the repair code. Based on this, step 203 specifically includes: performing compatibility verification and hot-swapping execution verification in debug mode on the repair code; dynamically loading the verified repair code into the production operation environment of the target system to which the target service instance belongs, forming a new version of service code that coexists with the original running service code corresponding to the target service instance.

[0047] Specifically, the system compares the interface definitions of the old and new code to ensure compatibility in method signatures, return types, and parameter lists. It verifies the integrity of all dependencies, ensures the new code does not reference non-existent classes or methods, and analyzes potential conflicts, such as inconsistencies caused by modifications to static variables. If the above checks fail, the system generates a detailed compatibility report and notifies the developers, terminating the hot-swap process. If the checks pass, the system enters the hot-swap execution phase. Before hot-swap execution, the system interface specifies the target user or user group, allowing filtering based on attributes such as user ID, role, department, and geographic location. A user group filter instance is created, and the filter configuration is stored in memory and associated with subsequent breakpoint settings. The system interface specifies the code location where breakpoints need to be set on the target service instance, down to the class, method, and line number. Breakpoint markers such as "where to" are inserted at the target location. The system associates the breakpoint information with the user group filter, creating breakpoint configurations. An isolated class loader is created to load the new version of the code. The class loader loads the modified class files but does not immediately replace the original classes, establishing a mapping between the old and new code to prepare for subsequent code switching. A heartbeat monitoring thread is started to periodically check the activity status of breakpoints. Heartbeat intervals and timeout thresholds are set. If no debugging activity occurs within the timeout period, the system will automatically clear the breakpoint marker to prevent prolonged suspension. The system waits for requests from the target user. When a request arrives, the system first checks if the user's identity matches the configured user group filtering conditions. If not, the system processes the request using the original code without triggering breakpoints. If the system triggers a breakpoint at a location marked with "where to," execution is suspended, and the execution context, including variable values, call stack, and environment state, is collected. This collected information is pushed to the debugging interface for developers to analyze. The system awaits debugging instructions from developers (such as continue execution, single-step debugging, variable modification, etc.). Based on these instructions, the system performs the corresponding operations. If a continue execution instruction is received, the system resumes execution, uses new code to handle subsequent logic, records debugging session information, updates the heartbeat status, and continues to wait for the next request. Through several tests like these, developers can confirm the effectiveness of the fix and verify whether the fixed code has passed hot-swap execution verification. If verification fails, hot replacement is prohibited. If verification succeeds, the faulty code is hot-replaced using the patched code to obtain the new version of the service code. During the hot replacement process, developers configure the visibility rules for code patches through the system interface, specifying which users or user groups can see the patched code. The visibility configuration is then stored in a distributed configuration center to ensure consistent access across all nodes in the cluster. The differences between the old and new code versions are analyzed to identify the actual modified parts and generate a detailed difference report, including the modified classes, methods, and line numbers. During the hot replacement process, the smallest replacement unit is determined to avoid unnecessary code replacement.The modified code is compiled to generate the corresponding bytecode. The bytecode is then processed using a bytecode manipulation library (such as ASM or Javassist). Class definitions are prepared, and a versioned class loader is created to load different versions of the code. The new version of the code is then injected into the production environment of the target system to which the target service instance belongs, resulting in the new version of the service code. Finally, a version routing mapping is established to record the correspondence between different versions of the code.

[0048] Furthermore, after using the repair code to hot-replace the abnormal code in the target service instance that is continuously running in the production environment, the method further includes: in response to the service request of the target user, determining the target group to which the target user belongs based on the user visibility configuration rules, and routing the service request to the service code corresponding to the version of the target group for execution, wherein the corresponding version of the service code is the original running service code or the new version of the service code.

[0049] Specifically, the system configures a request interceptor to block all requests entering the application. Routing rules (user visibility configuration rules, which map different users to different versions of service code) are set to determine which version of code to use based on the user's identity and visibility configuration. A version distribution mechanism is enabled to distribute requests to the corresponding version of code for processing.

[0050] 204. Start the preset monitoring thread to monitor the execution process of the new version service code obtained after hot replacement in real time, and obtain the performance indicators of the execution process of the new version service code based on the monitoring results.

[0051] 205. Based on performance metrics, determine whether the preset code rollback condition has been triggered. If so, terminate the execution of the new version of the service code and route all user requests to the original running service code for execution. Otherwise, continue to control the execution of the new version of the service code.

[0052] Performance metrics include, but are not limited to, runtime and runtime effects. Specifically, a pre-defined monitoring thread monitors the execution of the new version of the service code. If, based on performance metrics, the resulting anomalies exceed a pre-defined anomaly threshold, a pre-defined code rollback condition is triggered. In this case, user requests are routed to the original running service code (old version code) for execution. If the pre-defined code rollback condition is not triggered, user requests continue to be routed to the new version of the running service code for execution, thus ensuring the smooth execution of requests.

[0053] 206. Show users the code repair process through a visual debugging interface.

[0054] Specifically, the anomaly detection process, localization process, and hot replacement process in the code of this embodiment can all be completed through a visual debugging interface. Before completing the above processes using the visual prompt interface, interface configuration is required first: View adjustment: Adjust the view of the debugging interface according to user needs to optimize user experience. Improve the flexibility and operability of the debugging process through custom layout and theme settings. The visual debugging interface provides a real-time feedback mechanism to help users quickly understand the debugging results. Through visual charts and dynamic data updates, users can instantly see the impact of debugging and changes in system status. The visual debugging interface also allows service instance switching: Allows users to switch between different service instances during debugging to conduct comprehensive troubleshooting and performance optimization in a multi-instance environment. Users can select a specific instance to view detailed running status and log information. The visual debugging interface supports debugging from the perspective of a specific user or user group, helping to identify and resolve problems for a specific user group. By simulating user behavior and request paths, it provides in-depth analysis of user experience issues. Visual interface tracing: Provides a visual interface tracing function to help users intuitively track request flow and data flow. Uses a graphical method to display service call chains and data transmission paths to facilitate the identification of bottlenecks and anomalies. The visual debugging interface saves operation logs: recording user actions during the debugging process to support subsequent analysis and optimization. Operation logs can be used for auditing and backtracking, helping the development team understand decisions and steps taken during debugging. The visual debugging interface supports rollback functionality: providing a rollback function during debugging allows users to undo or reset debugging operations to restore the system to a previous state, ensuring the safety and controllability of the debugging process and preventing the impact of accidental operations. Through the above configurations and interactive functions, the visual debugging interface provides users with a flexible and intuitive debugging tool, supporting rapid troubleshooting and performance optimization, while ensuring the safety and traceability of the debugging process.

[0055] According to another code remote repair method based on a production environment provided by the present invention, compared with the current method of repairing code in a local environment and then deploying the repaired code to the production environment, the present invention establishes a remote debugging connection with the target service instance in the production environment in response to the user's code repair request. Based on the successful establishment signal of the remote debugging connection, the monitoring data of the target service instance under multi-dimensional monitoring indicators is collected in real time through the remote debugging interface. Then, based on the monitoring data, anomaly detection is performed on the target service instance using multiple anomaly detection methods, and based on the anomaly detection results, the abnormal code is located in the original running service code corresponding to the target service instance. Finally, the repair code corresponding to the abnormal code at the anomaly code location is determined, and the repair code is used to hot-swap the abnormal code in the target service instance that is continuously running in the production environment. This enables real-time monitoring and operation of services in the production environment via remote debugging interfaces, improving the timeliness of code repair; by performing anomaly detection and location on target service instances through multiple methods, the source of faults can be accurately identified, thereby improving the accuracy of code repair; and by dynamically hot-replacing the service code that is continuously running in the production environment, it can be executed without restarting the system, ensuring that the system remains stable during the update process, reducing business interruptions caused by fault repair, and thus improving the user experience.

[0056] Furthermore, as Figure 1 In specific implementation, embodiments of the present invention provide a remote code repair device based on a production environment, such as... Figure 3 As shown, the device includes: a data acquisition unit 31, a detection unit 32, and a replacement unit 33.

[0057] The acquisition unit 31 can be used to respond to a user's code repair request, establish a remote debugging connection with the target service instance in the production environment, and, based on the successful establishment signal of the remote debugging connection, collect monitoring data of the target service instance under multi-dimensional monitoring indicators in real time through the remote debugging interface.

[0058] The detection unit 32 can be used to perform anomaly detection on the target service instance based on the monitoring data using multiple anomaly detection methods, and to locate the abnormal code in the original running service code corresponding to the target service instance based on the anomaly detection results.

[0059] The replacement unit 33 can be used to determine the repair code corresponding to the abnormal code at the location of the abnormal code, and use the repair code to hot replace the abnormal code in the target service instance that is continuously running in the production environment.

[0060] In specific application scenarios, in order to collect monitoring data of target service instances under multi-dimensional monitoring metrics, such as... Figure 4 As shown, the acquisition unit 31 includes an acquisition module 311, a setting module 312, and an acquisition module 313.

[0061] The acquisition module 311 can be used to acquire the current load information of the running system corresponding to the target service instance, the business attribute information of the target service instance, the real-time monitoring information and indicator feature data under the multi-dimensional monitoring indicators of the target service instance.

[0062] The setting module 312 can be used to set the corresponding sampling frequency and sampling resources for multi-dimensional monitoring indicators based on the current load information, the business attribute information, the real-time monitoring information and the indicator feature data.

[0063] The acquisition module 313 can be used to acquire data under the corresponding monitoring indicators through a remote debugging interface based on the sampling frequency and the sampling resources, so as to obtain the monitoring data of the target service instance under the multi-dimensional monitoring indicators.

[0064] In specific application scenarios, the device further includes a processing unit 34 for preprocessing monitoring data.

[0065] The processing unit 34 can be used to determine the target data relationship type of the monitoring data and perform dimensionality reduction processing on the monitoring data using a dimensionality reduction processing method corresponding to the target data relationship type. The method for performing dimensionality reduction processing on the monitoring data using a dimensionality reduction processing method corresponding to the target data relationship type includes: if the target data relationship type is a linear relationship type, determining the data matrix corresponding to the monitoring data, determining the covariance matrix corresponding to the data matrix, performing eigenvalue decomposition on the covariance matrix to obtain eigenvalues ​​and corresponding eigenvectors, selecting principal component eigenvectors based on the eigenvalues, determining the data projection direction based on the principal component eigenvectors, projecting the monitoring data along the data projection direction, and using the projected monitoring data as the dimensionality-reduced monitoring data; performing time-series processing on the dimensionality-reduced monitoring data using a preset sliding time window, and performing standardization processing on the time-series processed monitoring data.

[0066] In specific application scenarios, in order to perform anomaly detection on target service instances, the detection unit 32 includes a detection module 321, a correction module 322, and a fusion module 323.

[0067] The detection module 321 can be used to input the monitoring data into multiple preset anomaly detection models for parallel anomaly detection, and obtain the initial anomaly detection result output by each preset anomaly detection model. The multiple preset anomaly detection models include a preset unsupervised anomaly detection model, a preset supervised anomaly detection model, and a preset semi-supervised anomaly detection model.

[0068] The correction module 322 can be used to determine the service dependencies and deployment environment information of the target service instance, as well as the user's operation behavior sequence on the target service instance, and correct the initial anomaly detection result based on the service dependencies, the deployment environment information, and the operation behavior sequence.

[0069] The fusion module 323 can be used to perform weighted fusion on each of the corrected initial anomaly detection results, and determine the anomaly detection result of the monitoring data based on the weighted fusion result.

[0070] In specific application scenarios, in order to locate abnormal codes, the detection unit 32 further includes a construction module 324, an analysis module 325, a determination module 326, and a location module 327.

[0071] The construction module 324 can be used to construct a causal relationship network graph among multi-dimensional monitoring indicators, wherein the multi-dimensional monitoring indicators represent nodes in the causal relationship network graph, and the causal influence relationship among the multi-dimensional monitoring indicators represents the edge between nodes in the causal relationship network graph.

[0072] The analysis module 325 can be used to perform causal effect analysis on the multi-dimensional monitoring indicators and the anomaly detection results based on the causal relationship network diagram, and determine the degree of influence of the multi-dimensional monitoring indicators on the occurrence of the anomaly detection results based on the causal effect analysis results.

[0073] The construction module 324 can also be used to take any one of the multi-dimensional monitoring indicators of the target service instance during the historical anomaly period as a target monitoring indicator X, and construct a counterfactual reasoning scenario based on the target monitoring indicator X for simulation. The counterfactual reasoning scenario simulates the system state corresponding to the target service instance when the target monitoring indicator X did not occur during the historical anomaly period.

[0074] The determining module 326 can be used to determine a counterfactual dataset based on the simulation results of the counterfactual reasoning scenario, and to determine the counterfactual system state Y' corresponding to the target service instance in the counterfactual reasoning scenario based on the counterfactual dataset. The counterfactual dataset includes target intervention indicator data when the target monitoring indicator X does not occur abnormally and intervention indicator data under the remaining monitoring indicators determined based on the target intervention indicator data. The remaining monitoring indicators are the multi-dimensional monitoring indicators after removing the target monitoring indicator X.

[0075] The determining module 326 can also be used to determine the necessity of the target monitoring indicator X for the occurrence of the anomaly detection result based on the counterfactual system state Y' and the real system state Y of the target service instance during the historical anomaly occurrence period.

[0076] The determining module 326 can also be used to determine the root cause monitoring indicators that affect the anomaly detection results based on the degree of influence and necessity of the anomaly detection results from the multi-dimensional monitoring indicators.

[0077] The positioning module 327 can be used to determine the call stack of the root cause monitoring indicator, perform similar stack matching in a preset historical anomaly case library based on the call stack, and locate the anomaly code in the original running service code corresponding to the target service instance based on the matching result.

[0078] In specific application scenarios, in order to hot replace the abnormal code in the target service instance, the replacement unit 33 includes a verification module 331 and a forming module 332.

[0079] The verification module 331 can be used to perform compatibility verification and hot-swap execution verification in debug mode on the repair code.

[0080] The forming module 332 can be used to dynamically load the verified repair code into the production operation environment of the target system to which the target service instance belongs, forming a new version of service code that coexists with the original running service code corresponding to the target service instance.

[0081] In specific application scenarios, the device further includes an execution unit 35 for code execution.

[0082] The execution unit 35 can be used to respond to a service request from a target user, determine the target group to which the target user belongs based on user visibility configuration rules, and route the service request to the service code corresponding to the version of the target group for execution, wherein the corresponding version of the service code is the original running service code or the new version of the service code.

[0083] In specific application scenarios, in order to monitor the execution process of the new version of service code, the device also includes a monitoring unit 36.

[0084] The monitoring unit 36 ​​can be used to start a preset monitoring thread to monitor the execution process of the new version service code obtained after hot replacement in real time, obtain the performance indicators of the execution process of the new version service code based on the monitoring results, determine whether the preset code rollback condition is triggered based on the performance indicators, if so, terminate the operation of the new version service code and route all user requests to the original running service code for execution, otherwise, continue to control the operation of the new version service code; and show the code repair process to the user through a visual debugging interface.

[0085] It should be noted that other corresponding descriptions of the functional modules involved in the remote code repair device based on a production environment provided in this embodiment of the invention can be found in [reference needed]. Figure 1 The corresponding description of the method shown will not be repeated here.

[0086] Based on the above, Figure 1 Accordingly, this embodiment of the invention also provides a computer-readable storage medium storing a computer program that, when executed by a processor, performs the following steps: responding to a user's code repair request, establishing a remote debugging connection with a target service instance in the production environment; based on a successful establishment signal of the remote debugging connection, collecting monitoring data of the target service instance under multi-dimensional monitoring indicators in real time through a remote debugging interface; based on the monitoring data, performing anomaly detection on the target service instance using multiple anomaly detection methods, and based on the anomaly detection results, locating the abnormal code in the original running service code corresponding to the target service instance; determining the repair code corresponding to the abnormal code at the anomaly code location, and using the repair code to hot-replace the abnormal code in the continuously running target service instance in the production environment.

[0087] Based on the above, Figure 1 The method shown and as Figure 3 The embodiment of the device shown in the invention also provides a physical structure diagram of a computer device, such as... Figure 5As shown, the computer device includes: a processor 41, a memory 42, and a computer program stored on the memory 42 and executable on the processor. Both the memory 42 and the processor 41 are mounted on a bus 43. When the processor 41 executes the program, it performs the following steps: In response to a user's code repair request, it establishes a remote debugging connection with a target service instance in the production environment; based on a successful remote debugging connection signal, it collects monitoring data of the target service instance in real time under multi-dimensional monitoring indicators through a remote debugging interface; based on the monitoring data, it performs anomaly detection on the target service instance using various anomaly detection methods, and based on the anomaly detection results, it locates the abnormal code in the original running service code corresponding to the target service instance; it determines the repair code corresponding to the abnormal code at the anomaly code location, and uses the repair code to hot-replace the abnormal code in the continuously running target service instance in the production environment.

[0088] Through the technical solution of this invention, in response to a user's code repair request, a remote debugging connection is established with the target service instance in the production environment. Based on the successful establishment signal of the remote debugging connection, monitoring data of the target service instance under multi-dimensional monitoring indicators is collected in real time through the remote debugging interface. Then, based on the monitoring data, anomaly detection is performed on the target service instance using various anomaly detection methods, and based on the anomaly detection results, the abnormal code is located in the original running service code corresponding to the target service instance. Finally, the repair code corresponding to the abnormal code at the anomaly code location is determined, and the repair code is used to hot-swap the abnormal code in the continuously running target service instance in the production environment. Thus, the service in the production environment can be monitored and operated in real time through the remote debugging interface, improving the timeliness of code repair; the anomaly detection and location of the target service instance through multiple methods can accurately identify the source of the fault, thereby improving the accuracy of code repair; and the dynamic hot-swap of the continuously running service code in the production environment can be performed without restarting the system, ensuring that the system remains stable during the update process, reducing business interruptions caused by fault repair, and thus improving the user experience.

[0089] It is obvious to those skilled in the art that the modules or steps of the present invention described above can be implemented using general-purpose computing devices. They can be centralized on a single computing device or distributed across a network of multiple computing devices. Optionally, they can be implemented using computer-executable program code, thereby storing them in a storage device for execution by a computing device. In some cases, the steps shown or described can be performed in a different order than those presented herein, or they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. Thus, the present invention is not limited to any particular combination of hardware and software.

[0090] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for remote repair of code based on a production environment, characterized by, The method comprises: in response to a user's code repair request, establishing a remote debugging connection with a target service instance in a production environment, based on a successful signal of the remote debugging connection, collecting monitoring data of the target service instance under multi-dimensional monitoring indicators in real time through a remote debugging interface; based on the monitoring data, using multiple anomaly detection methods to detect anomalies in the target service instance, and based on the anomaly detection result, performing anomaly code positioning in the original running service code corresponding to the target service instance; determine the repair code corresponding to the abnormal code at the anomaly code positioning, and use the repair code to hot replace the abnormal code in the target service instance continuously running in the production environment.

2. The method of claim 1, wherein, The method comprises: acquire the current load information of the running system corresponding to the target service instance, the business attribute information of the target service instance, the real-time monitoring information and the index characteristic data of the target service instance under multi-dimensional monitoring indicators; based on the current load information, the business attribute information, the real-time monitoring information and the index characteristic data, set corresponding sampling frequency and sampling resources for multi-dimensional monitoring indicators respectively; based on the sampling frequency and the sampling resources, collect data under the corresponding monitoring indicators through the remote debugging interface to obtain the monitoring data of the target service instance under the multi-dimensional monitoring indicators.

3. The method of claim 1, wherein, After collecting the monitoring data of the target service instance under the multi-dimensional monitoring indicators in real time through the remote debugging interface, the method further comprises: determine the target data relationship type of the monitoring data, and adopt a dimension reduction processing method corresponding to the target data relationship type to perform dimension reduction processing on the monitoring data, wherein the method of adopting a dimension reduction processing method corresponding to the target data relationship type to perform dimension reduction processing on the monitoring data comprises: if the target data relationship type is a linear relationship type, determining a data matrix corresponding to the monitoring data, determining a covariance matrix corresponding to the data matrix, performing eigenvalue decomposition on the covariance matrix to obtain eigenvalues and eigenvectors corresponding to the eigenvalues, selecting principal component eigenvectors in the eigenvectors based on the eigenvalues, determining a data projection direction based on the principal component eigenvectors, projecting the monitoring data along the data projection direction, and taking the projected monitoring data as the dimension-reduced monitoring data; adopt a preset sliding time window to perform time series processing on the dimension-reduced monitoring data, and perform standardization processing on the time series processed monitoring data.

4. The method of claim 1, wherein, The method comprises: input the monitoring data into multiple preset anomaly detection models for parallel anomaly detection to obtain initial anomaly detection results output by each preset anomaly detection model, wherein the multiple preset anomaly detection models include a preset unsupervised anomaly detection model, a preset supervised anomaly detection model, and a preset semi-supervised anomaly detection model; determine service dependency relationships and deployment environment information of the target service instance, and determine a sequence of operation behaviors of a user on the target service instance, correct the initial anomaly detection result based on the service dependency relationships, the deployment environment information, and the sequence of operation behaviors; perform weighted fusion on each of the corrected initial anomaly detection results, and determine an anomaly detection result of the monitoring data based on a weighted fusion result.

5. The method of claim 1, wherein, The anomaly code positioning in the original running service code corresponding to the target service instance based on the anomaly detection result comprises: constructing a causal relationship network graph among multi-dimensional monitoring indicators, wherein the multi-dimensional monitoring indicators represent nodes in the causal relationship network graph, and a causal influence relationship among the multi-dimensional monitoring indicators represents edges between nodes in the causal relationship network graph; performing causal effect analysis between multi-dimensional monitoring indicators and the anomaly detection result based on the causal relationship network graph, and determining an influence degree of the multi-dimensional monitoring indicators on the anomaly detection result based on a causal effect analysis result; taking any monitoring indicator in the multi-dimensional monitoring indicators of the target service instance in a historical abnormal occurrence period as a target monitoring indicator X, constructing a counterfactual reasoning scenario based on the target monitoring indicator X for simulation, wherein the counterfactual reasoning scenario simulates a system state of the target service instance corresponding to the target monitoring indicator X in the historical abnormal occurrence period without an abnormality; determining a counterfactual data set based on a simulation result of the counterfactual reasoning scenario, determining a counterfactual system state Y' of the target service instance in the counterfactual reasoning scenario based on the counterfactual data set, wherein the counterfactual data set includes target intervention indicator data when the target monitoring indicator X does not have an abnormality and intervention indicator data of remaining monitoring indicators determined based on the target intervention indicator data, the remaining monitoring indicators being the multi-dimensional monitoring indicators excluding the target monitoring indicator X; determining necessity of the target monitoring indicator X on the anomaly detection result based on the counterfactual system state Y' and a real system state Y of the target service instance in the historical abnormal occurrence period; determining a root cause monitoring indicator that has an impact on the anomaly detection result among the multi-dimensional monitoring indicators based on the influence degree of the multi-dimensional monitoring indicators on the anomaly detection result and the necessity; determining a call stack of the root cause monitoring indicator, performing similar stack matching in a preset historical abnormal case library based on the call stack, and performing anomaly code positioning in the original running service code corresponding to the target service instance based on a matching result.

6. The method of claim 1, wherein, The hot replacement of the abnormal code in the target service instance continuously running in the production environment by using the repair code comprises: performing compatibility verification and hot replacement execution verification in a debugging mode on the repair code; The verified repair code is dynamically loaded into a production running environment of a target system to which the target service instance belongs, forming a new version service code coexisting with the original running service code corresponding to the target service instance; After the abnormal code in the target service instance continuously running in the production environment is hot replaced by using the repair code, the method further comprises: In response to a service request of a target user, based on a user visibility configuration rule, a target group to which the target user belongs is determined, and the service request is routed to a corresponding version of service code for execution, wherein the corresponding version of service code is the original running service code or the new version service code.

7. The method of claim 1, wherein, After the abnormal code in the target service instance continuously running in the production environment is hot replaced by using the repair code, the method further comprises: Starting a preset monitoring thread to monitor the execution process of the new version service code obtained after hot replacement in real time, and obtaining performance indicators of the execution process of the new version service code based on the monitoring result; Based on the performance indicators, it is judged whether a preset code rollback condition is triggered, if yes, the running of the new version service code is terminated, and all user requests are routed to the original running service code for execution, otherwise, the running of the new version service code is continued; Through a visual debugging interface, the user is shown the repair process of the code.

8. A production environment-based code remote repair apparatus, characterized by comprising: Comprise: The acquisition unit is configured to, in response to a code repair request of a user, establish a remote debugging connection with a target service instance in a production environment, and based on a successful signal of the remote debugging connection, acquire monitoring data of the target service instance under multi-dimensional monitoring indicators in real time through a remote debugging interface; The detection unit is configured to, based on the monitoring data, detect the target service instance using multiple abnormal detection methods, and based on the abnormal detection result, locate the abnormal code in the original running service code corresponding to the target service instance; The replacement unit is configured to determine the repair code corresponding to the abnormal code at the location of the abnormal code, and hot replace the abnormal code in the target service instance continuously running in the production environment by using the repair code.

9. A computer readable storage medium having stored thereon a computer program, characterized in that, The computer program is executed by the processor to realize the steps of the method of any one of claims 1 to 7.

10. A computer device comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, characterized in that, The computer program is executed by the processor to realize the steps of the method of any one of claims 1 to 7.

Images