Abnormality processing method and device of application program, storage medium and electronic device

Abstract

This application discloses an exception handling method, apparatus, storage medium, and electronic device for an application. The method includes: responding to a received exception event, constructing a multi-dimensional causal relationship graph based on multi-source heterogeneous data integrating user behavior data and business indicator data; extracting the complete operation path of the target application when the exception event occurs based on key exception operation nodes in the multi-dimensional causal relationship graph; generating a dynamically replayable exception scene view sequence based on the complete operation path, the exception scene view sequence including a temporal state set of user behavior paths and interface element attributes reproducing the exception occurrence; parsing the exception scene view sequence to obtain a real-time exception graph structure; and obtaining an exception solution by matching the real-time exception graph structure with historical exception graph structures. This application solves the technical problem of low exception handling efficiency in applications.

Description

Technical Field

[0001] This application relates to the field of data analysis technology, and more specifically, to an application exception handling method and apparatus, storage medium and electronic device. Background Technology

[0002] The current application primarily relies on static baselines and single-dimensional threshold alerts for anomaly detection. For example, it aggregates event logs at fixed intervals, calculates statistical data such as the mean and variance of metrics, and triggers alerts when these values ​​exceed preset thresholds. Simultaneously, manual review of operation logs or static UI screenshots is used to assist in determining anomaly solutions.

[0003] However, the aforementioned static baseline alarm detection method cannot adapt to dynamic business changes such as new feature launches or large-scale promotional events. Furthermore, application anomalies are only passively presented as isolated indicators, making it difficult to determine which operation or interface caused the anomaly. In this situation, relying solely on manually checking operation logs or screenshots of interface states to locate the root cause of the anomaly and determine a solution would consume significant time and manpower, resulting in low anomaly handling efficiency for the target application.

[0004] There is currently no effective solution to the above problems. Summary of the Invention

[0005] This application provides an exception handling method and apparatus, storage medium and electronic device for applications, to at least solve the technical problem of low efficiency in the exception handling process of applications.

[0006] According to one aspect of the embodiments of this application, an exception handling method for an application is provided, comprising: responding to a received exception event, constructing a multi-dimensional causal relationship graph based on multi-source heterogeneous data that integrates user behavior data and business indicator data; extracting the complete operation path of the target application when the exception event occurs based on key exception operation nodes in the multi-dimensional causal relationship graph; generating a dynamically replayable exception scene view sequence based on the complete operation path, wherein the exception scene view sequence includes a temporal state set of user behavior paths and interface element attributes that reproduce the exception occurrence; parsing the exception scene view sequence to obtain a real-time exception graph structure for characterizing the causal relationship between user operation behavior and interface state changes in the exception event; and obtaining an exception solution by matching the real-time exception graph structure with a historical exception graph structure.

[0007] According to another aspect of the embodiments of this application, an exception handling apparatus for an application is also provided, comprising: a first processing unit, configured to, in response to a received exception event, construct a multi-dimensional causal relationship graph based on multi-source heterogeneous data that integrates user behavior data and business indicator data; an extraction unit, configured to, based on key exception operation nodes in the multi-dimensional causal relationship graph, extract the complete operation path of the target application when the exception event occurs; a second processing unit, configured to, based on the complete operation path, generate a dynamically replayable exception scene view sequence, wherein the exception scene view sequence includes a temporal state set of user behavior paths and interface element attributes that reproduce the exception occurrence; and a parsing unit, configured to, parse the exception scene view sequence to obtain a real-time exception graph structure characterizing the causal relationship between user operation behavior and interface state changes in the exception event, and obtain an exception solution by matching the real-time exception graph structure with a historical exception graph structure.

[0008] According to another aspect of the embodiments of this application, a computer-readable storage medium is also provided, wherein a computer program is stored in the computer program, and the computer program is used to execute the above-described application's exception handling method when the electronic device is running.

[0009] According to another aspect of the embodiments of this application, a computer program product is also provided, including a computer program that, when executed by a processor, implements the steps of the above-described method.

[0010] According to another aspect of the embodiments of this application, an electronic device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to execute an exception handling method of the application program through the computer program.

[0011] By employing the embodiments provided in this application, a multi-dimensional causal relationship graph is constructed to closely link front-end user operations with back-end business metrics, and the complete operation path at the time of an anomaly is obtained through key abnormal operation nodes. Based on this complete operation path, a reproducible sequence of anomaly scene views is generated, achieving millisecond-level accurate reproduction of the relationship between interface state and user operations. Finally, by parsing the anomaly scene view sequence, the reproduction results are structured into a real-time anomaly graph structure. By matching the real-time anomaly graph structure with historical anomaly graph structures, an anomaly solution capable of resolving the current anomaly event is quickly determined. In other words, by constructing a multi-dimensional causal relationship graph, reproducing the scene of the anomaly event, and quickly determining solutions through graph structure similarity comparison, the technical solution of this application provides a closed-loop intelligent decision-making process from problem discovery to solution provision, improving the accuracy of anomaly detection, shortening anomaly handling time, and achieving the technical effect of improving the anomaly handling efficiency of the target application. Attached Figure Description

[0012] The accompanying drawings, which are provided to further understand this application and constitute a part of this application, illustrate exemplary embodiments of this application and are used to explain this application, but do not constitute an undue limitation of this application.

[0013] Figure 1 This is a schematic diagram illustrating an application scenario of an optional exception handling method for an application according to an embodiment of this application;

[0014] Figure 2 This is a flowchart of an optional exception handling method for an application according to an embodiment of this application;

[0015] Figure 3 This is an overall schematic diagram of an optional application exception handling method according to an embodiment of this application;

[0016] Figure 4 This is a specific example of determining the complete operation path that needs to be reproduced based on the type of abnormal event;

[0017] Figure 5 This is a schematic diagram of the structure of an optional application exception handling device according to an embodiment of this application;

[0018] Figure 6 This is a schematic diagram of the structure of an optional electronic device according to an embodiment of this application. Detailed Implementation

[0019] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0020] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0021] The technical solutions in this application will comply with legal regulations during implementation. When operating according to the technical solutions in the embodiments, the data used will not involve user privacy, ensuring that the operation process is compliant and legal while guaranteeing data security. In addition, when the above embodiments of this application are applied to specific products or technologies, user permission or consent is required, and the collection, use, and processing of related data must comply with the relevant regulations and standards of the relevant countries or regions.

[0022] According to one aspect of the embodiments of this application, an exception handling method for an application is provided. As an optional implementation, the above-described exception handling method for an application can be applied to, but is not limited to, [examples of other methods]. Figure 1 The application scenarios shown are as follows. In, for example... Figure 1 In the application scenario shown, the target terminal 102 can communicate with the server 106 via network 104, but is not limited to this. The server 106 can perform operations on the database 108, such as write or read data operations. The target terminal 102 may include, but is not limited to, a human-computer interaction screen, a processor, and a memory. The human-computer interaction screen may be used to display, but is not limited to, the feedback anomaly detection results obtained after processing using the technical solution of this application on the target terminal 102. The processor may be used, but is not limited to, to respond to the human-computer interaction operation, execute the corresponding operation, or generate the corresponding instruction and send the generated instruction to the server 106. The memory is used to store relevant processing data, such as multidimensional causal relationship graphs, complete operation paths, and anomaly scene view sequences.

[0023] Optionally, in this embodiment, the target terminal can be a terminal configured with a target client, which may include, but is not limited to, at least one of the following: mobile phone (such as Android phone, iOS phone, etc.), laptop computer, tablet computer, PDA, MID (Mobile Internet Devices), PAD, desktop computer, smart TV, etc. The target client may be a video client, instant messaging client, browser client, educational client, etc. The network may include, but is not limited to, wired network and wireless network, wherein the wired network includes: local area network, metropolitan area network and wide area network, and the wireless network includes: Bluetooth, WIFI and other networks that enable wireless communication. The server may be a single server, a server cluster composed of multiple servers, or a cloud server.

[0024] The technical solution presented in this application is applicable to complex internet applications requiring high-precision anomaly location and intelligent operation and maintenance. Examples include online video streaming platforms, e-commerce promotional systems, financial transaction platforms, and equipment management platforms.

[0025] To address this problem, this application proposes an exception handling method for applications. Figure 2 This is a flowchart of an exception handling method for an application according to an embodiment of this application, the process including the following steps S202 to S208.

[0026] It should be noted that the exception handling method of the application shown in steps S202 to S208 can be executed by, but is not limited to, an electronic device. The electronic device can be, but is not limited to, a device that... Figure 1 The target terminal or server shown.

[0027] Step S202: In response to the received abnormal event, a multi-dimensional causal relationship graph is constructed based on multi-source heterogeneous data that integrates user behavior data and business indicator data.

[0028] Step S204: Based on the key abnormal operation nodes in the multidimensional causal relationship graph, extract the complete operation path when the abnormal event occurs in the target application;

[0029] Step S206: Based on the complete operation path, generate a sequence of abnormal scene views that can be dynamically replayed, wherein the sequence of abnormal scene views includes a set of time-series states of user behavior paths and interface element attributes that reproduce the occurrence of the abnormality.

[0030] Step S208: The abnormal scene view sequence is parsed to obtain a real-time abnormal graph structure that represents the causal relationship between user operation behavior and interface state changes in the abnormal event. By matching the real-time abnormal graph structure with the historical abnormal graph structure, an abnormal solution is obtained.

[0031] The abnormal scene view sequence is a set of temporal states that reproduce the user behavior path and interface element attributes when the abnormality occurs, with the structured interface state as the node and the operation sequence as the edge.

[0032] To facilitate understanding, let's first combine... Figure 3 The overall flowchart shown provides a brief overview of the implementation process of the exception handling method in the above application.

[0033] S302, real-time fusion and heterogeneous correlation of multi-dimensional user behavior data and business indicator data, and construction of multi-dimensional causal relationship graph;

[0034] For example, by using the embedded data in the target application to report user behavior data, backend business metrics (such as interface timeout, error rate, and conversion rate) and interface request logs in real time, and by using the four-level association key of user ID-device ID-session ID-request ID, combined with the entity recognition model and cosine similarity semantic matching algorithm, unstructured operation events are accurately mapped to structured business metrics, resulting in a multi-dimensional causal relationship graph of operation-metrics for dynamic fireworks.

[0035] S304, based on key abnormal operation nodes in the multidimensional causal relationship graph, determine the complete operation path when an abnormal event occurs;

[0036] After detecting an anomaly, the preceding operation nodes associated with the anomaly indicator are located in the multidimensional causal graph. Causal tests are then used to filter out user operation sequences that contribute significantly to the occurrence of the anomaly, thus determining a complete operation path with branching logic, no redundancy, and contextual information. Examples include: entering the settlement page, clicking the submit button, a pop-up window, clicking the submit button again within 0.5 seconds, and an API error. The timing and element ID of each operation are labeled.

[0037] In this embodiment, massive user operation logs are selectively reported using embedded data (usually a string of characters), such as only reporting data related to jump events, page load events, and user click events. The purpose is to save data processing resources.

[0038] S306, driven by the extracted complete operation path, calls the time-series anchored snapshot module to generate a structured, replayable sequence of abnormal scene views;

[0039] Each critical abnormal operation node is bound to a snapshot of the interface 200ms before its occurrence, and the snapshot abnormal block is compressed and stored using the Myers differential algorithm. At the same time, the UI interface is abstracted into a finite state machine, and the state transition is driven by the operation sequence (such as the submit button not being debounced → the barrage is displayed → the form value exceeds the limit).

[0040] S308: By parsing the abnormal scene view sequence, the real-time abnormal graph structure is obtained, and the real-time abnormal graph structure is matched with the historical abnormal graph structure to determine the final abnormal solution.

[0041] S310 injects the feedback from operations and maintenance personnel on the adoption of recommended anomaly solutions and the efficiency of anomaly resolution into the system, thereby enabling automatic optimization of the knowledge graph.

[0042] This embodiment proposes an anomaly detection and intelligent solution generation method based on multi-source heterogeneous data. Its core lies in constructing a closed-loop intelligent diagnostic logic encompassing anomaly perception, operation path extraction, scene reproduction, graph matching, and anomaly solution recommendation.

[0043] By integrating front-end event tracking data (such as clicks, inputs, and navigation actions) with back-end business metrics, a four-level association key is used to achieve precise cross-source data alignment. Furthermore, entity recognition and cosine similarity semantic matching are combined to establish semantic associations between unstructured operation descriptions (such as clicking the submit button) and abnormal business metrics (such as a sudden increase in payment interface latency). Ultimately, a multi-dimensional causal relationship graph containing the causal relationships between operations and metrics is constructed. This graph overcomes the limitations of traditional solutions that rely solely on a single-dimensional baseline, achieving a semantic-level mapping between front-end user actions and back-end business metric anomalies.

[0044] Granger causality tests are used to identify the time lag effect of operations on indicators (e.g., repeated clicks cause a sudden increase in time consumption after 3 seconds, p<0.05). Combined with SHAP (SHapley Additive exPlanations) values, the contribution of each user operation to the occurrence of abnormal events is quantified. Core nodes or key abnormal operation nodes with a high contribution value of the first preset threshold are selected. Then, a directed graph algorithm is used to splice discrete operations to form a complete path with branching logic, which solves the problem of root cause omission caused by operation fragmentation in traditional paths.

[0045] The system binds a snapshot of the interface 200ms before the occurrence of each operation node (NTP time synchronization error <100ms), and compresses and stores the snapshot differences through a differential algorithm. At the same time, the UI state is abstracted into a finite state machine, and the interface state transition is driven according to the operation sequence. Finally, a dynamic time sequence set with structured interface state as nodes and operation sequence as edges is generated, which supports frame-by-frame playback and element highlighting, and facilitates intuitive understanding of the abnormal scene view sequence.

[0046] The abnormal scene view sequence is transformed into a real-time abnormal graph structure. The GraphSAGE model is then used to learn node embeddings, and the structural similarity between the real-time abnormal graph structure and historical cases (i.e., historical abnormal graph structures of similar problems that occurred within a historical period and are similar to the abnormal event) is calculated. Based on the structural similarity, recommended solutions for solving the current abnormal event are matched from the solutions of historical cases. For example, the top 3 solutions are output.

[0047] By constructing a multi-dimensional causal relationship graph, front-end user actions are closely linked to back-end business metrics, and the complete operation path at the time of the abnormal event is obtained through key abnormal operation nodes. Based on this complete operation path, a reproducible abnormal scene view sequence is generated, achieving millisecond-level accurate reproduction of the relationship between interface state and user actions. Finally, by parsing the abnormal scene view sequence, the reproduction results are structured into a real-time abnormal graph structure. By matching the real-time abnormal graph structure with historical abnormal graph structures, an abnormal solution that can resolve the current abnormal event is quickly determined. In other words, by constructing a multi-dimensional causal relationship graph, reproducing the scene of the abnormal event, and quickly determining the solution through graph structure similarity comparison, this application's technical solution provides a closed-loop intelligent decision-making process from problem discovery to solution provision, improving the accuracy of anomaly detection, shortening anomaly handling time, and achieving the technical effect of improving the anomaly handling efficiency of the target application.

[0048] As an optional example, the above-mentioned multi-source heterogeneous data, which integrates user behavior data and business indicator data, is used to construct a multi-dimensional causal relationship graph, including:

[0049] Based on a combined identifier consisting of user account identifier, device identifier, session identifier, and API call request identifier, operation events are associated with API call records to obtain initial association pairs;

[0050] Extract key fields from the event tracking data and operation logs of the target application to complete or correct the abnormal identifiers in the initial association pair, and obtain a standardized association pair;

[0051] Target association pairs with a semantic similarity greater than a first preset threshold are selected from the standardized association pairs;

[0052] Based on the target association pairs, the operation nodes, business indicator nodes, and edges representing the causal relationship between user operation data and the business indicator data in the multidimensional causal relationship graph are determined.

[0053] This can be achieved, but is not limited to, by associating operation events in the user behavior data with interface call records in the business metric data to obtain initial association pairs. The aforementioned anomalies can include, but are not limited to, missing or incorrect identifiers.

[0054] When determining target association pairs, it is possible, but not limited to, to filter target association pairs from the standardized association pairs based on the semantic similarity between the operation semantic word vectors corresponding to the operation events and the indicator semantic word vectors corresponding to the business indicator data. The semantic similarity of these target association pairs is greater than a first preset threshold. Finally, using user operation data as operation nodes, business indicator data as business indicator nodes, and the causal relationship between the user operation data and the business indicator data as edges, the multidimensional causal relationship graph is constructed.

[0055] As can be seen from the description of the above embodiments, the technical solution of this application constructs an intelligent closed-loop system, which includes, but is not limited to, the following layers or processing branches:

[0056] Data layer: A linkage mechanism of dimension alignment, dynamic baseline and causal localization solves the problems of heterogeneous data association and localization drift;

[0057] Reproduction layer: Overcomes the problem of path-snapshot separation, and achieves accurate reproduction of the entire process operation and interface state;

[0058] Decision-making level: Based on knowledge graph + GNN model, anomaly presentation is upgraded to solution recommendation.

[0059] Systematic contribution: Forming a closed loop of anomaly perception → root cause localization → scenario reproduction → solution recommendation, shifting from passive problem-solving to proactive prevention.

[0060] Multi-dimensional Big Data Integration and Anomaly Detection: The system integrates all user behavior data and performs real-time aggregation calculations based on multiple preset dimensions according to business attributes (such as pages, functional modules, user groups, etc.) to generate a set of key business indicators. It employs an intelligent anomaly detection algorithm that dynamically identifies statistically significant abnormal fluctuations based on historical baselines, time series patterns, and indicator deviations. The system supports custom rules, enabling real-time monitoring and anomaly detection of statistical data from newly launched features or specific activities.

[0061] The data layer primarily implements a linkage mechanism combining dimensional alignment, dynamic baseline, and causal localization, which addresses the issues of heterogeneous data fragmentation and location drift. It overcomes the limitations of traditional single-dimensional anomaly detection by fusing multiple technologies to achieve accurate correlation and dynamic localization of heterogeneous data. The specific processing steps are as follows:

[0062] S11, Construction of Heterogeneous Data Unified Mapping and Multidimensional Causal Relationship Graph;

[0063] Its goal is to solve the data silo problem between front-end user actions and back-end business metrics, and to establish a precise correlation between actions and metrics.

[0064] S11-1 defines a four-level association key to connect multi-source data identifiers;

[0065] Association Key Design: Define a four-level association key: User ID, Device ID, Session ID, and Request ID, as a unified identifier for cross-origin data. Specifically, User ID is extracted from front-end event logs (e.g., the user_action table); Device ID is obtained from the client SDK as a unique device identifier; Session ID is generated from front-end sessionStorage as a unique session identifier (e.g., UUID), used throughout a single user operation; and Request ID is either trace_id or request_id from back-end API logs (e.g., the api_request table), associated with a single API call.

[0066] The association logic of the above four-level association keys is to connect the four-level association keys through SQL (Structured Query Language) table joins or graph databases. For example, user_id=U123→device_id=D456→session_id=S789→request_id=R012→association metric api_pay time=1200ms.

[0067] S11-2, Extracting related fields from the CRF entity recognition model;

[0068] Model training: Based on historical event logs (more than 100,000 records) and interface logs, key fields such as user ID and device ID are labeled. Through entity recognition model, related fields in unstructured logs (such as {"user":"U123","req_id":"R012"} in JSON format) are identified.

[0069] Field extraction: For front-end event tracking (such as click event {event:"click",user_id:"U123", session_id:"S789"}) and back-end logs (such as {request_id:"R012",trace_id:"T345", api:" / pay"}), extract four-level association keys using the CRF model and output standardized association records.

[0070] S11-3, Semantic similarity calculation (cosine similarity) matching of "operation-index" association pairs;

[0071] Semantic annotation: Semantic annotation is performed on behavioral data (such as clicking the submit button) and indicator data (such as a sudden increase in payment interface processing time) to extract the following core elements:

[0072] Behavioral elements: operation type (click / input / redirect), object (button / form / page), context (parent page ID, pop-up state);

[0073] Metric elements: Metric type (time spent / error rate / conversion rate), object (interface / functional module), anomaly direction (sudden increase / sudden decrease);

[0074] Vectorization and Similarity Calculation: Annotated elements are converted into word vectors (e.g., Word2Vec). The similarity of behavior-metric association pairs is calculated using cosine similarity (e.g., a threshold of 0.8). Example:

[0075] The behavior vector is [click: 0.9, submit button: 0.8, settlement page: 0.7], the indicator vector is [payment interface: 0.9, time spent: 0.8, sudden increase: 0.7], and the cosine similarity is 0.92. Since 0.92 > 0.8, it is determined to be a valid association pair.

[0076] S11-4, Construct an operation-indicator correlation graph, that is, construct a multidimensional causal correlation graph.

[0077] The graph structure uses operation nodes (such as clicking the submit button) and indicator nodes (such as payment interface time) as entities, and influence relationships (such as causing a sudden increase) as edges. It uses a graph database to store related pairs, and has cumulatively built a graph with more than 100,000 nodes and more than 500,000 relationships.

[0078] By using the graph construction method described above, the accuracy of the association between user operation behavior and business indicator data can be increased from 55% with traditional ETL splicing to 92%, and the positioning drift rate can be reduced from 38% to 8%.

[0079] In addition to constructing a multidimensional causal relationship graph, the data layer also performs the processing steps S12 to S14.

[0080] S12, adaptive threshold adjustment for business cycles, i.e., generation of dynamic baselines;

[0081] Its goal is to replace static thresholds, achieve dynamic adaptation of anomaly detection, and reduce false alarm rate.

[0082] S12-1, STL time series decomposition, extracting business cycle features;

[0083] Data input: Select business indicator data from the past 30 days (such as payment interface processing time, sampling frequency of 1 minute / time) to form a time series S={s1,s2,...,s...} n}

[0084] Decomposition process: Using the STL (Seasonal and Trend decomposition using Loess) algorithm, S is decomposed into the following terms:

[0085] Trend: Long-term changes (such as a slow increase in time consumption due to business growth);

[0086] Seasonal: Periodic fluctuations (e.g., daily peak from 9-18:00, with a weekly low at the weekend).

[0087] Residual term: random noise (such as occasional network jitter).

[0088] Periodic identification: Through seasonal Fourier transform, business cycles (such as a daily cycle of 24 hours or a weekly cycle of 7 days) are identified, and peak / off-peak periods (such as 9-18 on weekdays) are marked.

[0089] S12-2, LSTM (Long Short-Term Memory) prediction model predicts baseline shift during active period;

[0090] Model training: Based on historical event data, using the average of indicators in the 7 days before the event, event type (major promotion / new feature), and estimated promotional traffic as features, an LSTM prediction model is trained to predict the baseline shift during the event period (e.g., if the expected traffic increase is 300%, the baseline for the time consumption will be adjusted upward by 250%).

[0091] Dynamic updates: After the start of the event, the model will be fine-tuned every 6 hours using real-time data to correct prediction biases (e.g., if actual traffic exceeds expectations, the baseline will be adjusted upward by 10%).

[0092] S12-3, based on 3 The principle is to dynamically adjust the threshold;

[0093] Standard scenario threshold: For seasonal terms + residual terms, use 3. The dynamic threshold is calculated in principle (the normal range is the mean ± 3). ), and adjust according to periodic characteristics:

[0094] During peak hours (e.g., 9 to 18:00), the threshold is relaxed by 20% (e.g., the original threshold of 500ms is adjusted to 600ms); during off-peak hours (e.g., 00:00 to 06:00), the threshold is tightened by 10% (e.g., the original threshold of 500ms is adjusted to 450ms); for thresholds in characteristic scenarios, for example, during the event period, the threshold is pre-adjusted based on the LSTM prediction results (e.g., the threshold is increased by 250% during the promotion period), and custom rules are supported, such as a threshold of 50% for the monitoring period of newly launched features.

[0095] By adjusting the dynamic thresholds as described above, the false alarm rate of traditional static baselines is reduced, and the timeliness of anomaly detection is improved to the minute level.

[0096] S13, Causal correlation localization, i.e., quantitative modeling of abnormal propagation chains;

[0097] Its goal is to pinpoint the root cause of abnormal backend business metrics due to frontend user actions and to quantify the contribution of these actions.

[0098] S13-1, Granger causality test analysis of time lag relationships;

[0099] Variable selection: The front-end operation sequence (e.g., clicking submit → entering the amount → clicking submit again) is used as the independent variable X. t Backend metric fluctuations (such as payment interface latency) are the dependent variable Y. t .

[0100] Testing process: Granger causality test analysis of X. t For Y t+k (k is the time lag order, ranging from 1 to 5 seconds) causal significance, and filter out significant causal pairs that satisfy p < 0.05 (e.g., "time consumption suddenly increases 3 seconds after repeated clicks to submit", p = 0.02).

[0101] Lag order determination: Select the optimal lag order k=3 (that is, the effect of the operation on the indicator is manifested within 3 seconds).

[0102] S13-2, SHAP value quantification operation contribution;

[0103] Model construction: Using operation type (one-hot encoding), operation frequency, and object attributes as features, and the magnitude of abnormal indicators as the objective, an XGBoost regression model is trained.

[0104] Contribution calculation: The SHAP value is used to interpret the model prediction results and calculate the contribution of each operation to the index anomaly (the value range is [-1,1], positive values ​​indicate positive impact, and negative values ​​indicate negative impact).

[0105] Root cause identification: Operations with a contribution rate >50% are identified as core root causes (such as repeated clicks to submit with a contribution rate of 65%, and inputting amounts exceeding the limit with a contribution rate of 20%), and the identification time is reduced from 120 minutes to 15 minutes.

[0106] S14, Closed-loop verification of the linkage mechanism.

[0107] Data flow closed loop: Dimension alignment outputs association graph → Dynamic baseline generation generates anomaly detection results → Causal association localization outputs root cause operation → Results are fed back to association graph optimization (such as adding "repeated click" association rules).

[0108] Performance verification: Through testing in e-commerce promotional scenarios, the anomaly location accuracy rate is >90%, the false alarm rate is <12%, and the single location time is <15 minutes, meeting the needs of complex business scenarios.

[0109] By linking the above-mentioned dimensions (related data), dynamic baseline (anomaly detection), and causal localization (root cause identification), accurate correlation and dynamic localization of heterogeneous data can be achieved, providing core data-driven capabilities for intelligent operation and maintenance closed loop.

[0110] As an optional example, the complete operation path extracted from the target application when the abnormal event occurs, based on the key abnormal operation nodes in the multidimensional causal relationship graph, includes:

[0111] Determine the contribution of user operation data corresponding to each operation node in the multidimensional causal relationship graph to the abnormal business indicators when the abnormal event occurs.

[0112] Filter out target operation data whose contribution is greater than the second preset threshold from the user operation data;

[0113] Based on the key abnormal operation nodes determined by the target operation data, the complete operation path is extracted.

[0114] In this embodiment, the implementation mechanism of root cause localization is further refined. The main idea is to unfold in three steps: quantification of abnormal contribution, screening of key operation nodes, and precise extraction of path, which constitutes a precise mapping from macro-indicator anomalies to micro-operational root causes.

[0115] Specifically, the contribution of abnormal business indicators to abnormal events is not simply a statistical measure of indicator fluctuations. Instead, it is based on a regression model to perform nonlinear modeling of multidimensional operational characteristics (such as operation frequency, object type, and context state), and uses SHAP values ​​to perform interpretability decomposition of the causal contribution of each operation.

[0116] For example, in a scenario where payment interface latency suddenly increases, the system identifies three operations: repeated clicks to submit, exceeding the input amount limit, and a 2G network type. SHAP analysis shows that the first two contribute 65% and 20% respectively, while network factors account for only 5%. This process transforms the judgment of "which operations caused the anomaly" from an empirical one into a quantifiable numerical output, avoiding the mistaken assumption that occasional network jitter is the primary cause.

[0117] Secondly, filtering user operation data with a contribution exceeding a second preset threshold is a key filtering mechanism for root cause analysis. This threshold (e.g., 50%) is not a fixed value but is dynamically set based on the business scenario. For example, in financial transaction scenarios, due to high fault tolerance requirements, the threshold can be set to 70%; while in e-commerce scenarios, to capture complex root causes, it can be relaxed to 40%. The system only retains operations with a contribution exceeding the threshold (such as repeated clicks to submit), eliminating noisy or low-impact behaviors, thereby compressing the analysis focus from dozens of operations to 1-3 core abnormal operation nodes, significantly reducing the complexity of subsequent processing.

[0118] Finally, using the aforementioned key abnormal operation nodes as anchor points, and combining the structured information recorded in the enhanced tracking points, such as "preceding operation ID," "branch marker," and "session context," a directed graph traversal algorithm is used to backtrack and piece together a complete behavior chain containing branch logic. For example, when repeated clicks to submit are identified as key abnormal operation nodes, the system automatically backtracks its preceding steps: entering the settlement page, the first click to submit, and the pop-up display, and extends to its subsequent interface error, ultimately forming a complete operation path of entering the settlement page → first click → pop-up display → second click → interface error, fully reconstructing the abnormal chain caused by the "debouncing deficiency."

[0119] As an optional implementation, the extraction of the complete operation path based on the key abnormal operation nodes determined by the target operation data includes:

[0120] Starting from the key abnormal operation node, a directed graph traversal is performed along the preset temporal edges in the multidimensional causal relationship graph to obtain a user operation node sequence, wherein the user operation node sequence includes key user operation behaviors experienced from the start of the operation to the time when the abnormal event occurs.

[0121] Remove redundant operation nodes from the user operation node sequence caused by misoperation or repeated triggering, and generate the structured complete operation path based on the key abnormal operation nodes after removing the redundant operation nodes.

[0122] The sequence of user operation nodes is determined by using multiple data points from user behavior data.

[0123] The complete operation path for determining when an abnormal event occurs is achieved through the aforementioned reproduction layer. The processing procedure of the reproduction layer will be described in detail below.

[0124] The reproduction layer is mainly used for the generation of full-process behavior paths and dynamic UI snapshot reproduction system technology. Its goal is to overcome the problem of the separation between user operation paths and interface snapshots in traditional solutions.

[0125] S21, full-link data fusion, which generates a full-process behavior path with branches, that is, generates the complete operation path mentioned above.

[0126] S21-1, Enhanced event tracking design: Capturing operation context and branch information;

[0127] Enhanced event tracking fields: Embed enhanced event tracking at key front-end operation nodes (clicks, inputs, navigation, pop-up interactions, etc.). In addition to basic information (operation type, timestamp, element ID), the following content is added:

[0128] Context identifiers: parent page ID (e.g., page_id:"checkout_page"), popup state (popup_state:"visible / hidden"), scroll position (scroll_top:300px);

[0129] Branch marker: The type of branch triggered by the operation (e.g., branch_type: "Confirm / Cancel pop-up", condition: "Amount > 100 yuan").

[0130] Association ID: Associated with the action_id of the preceding operation (e.g., prev_action_id:"A123"), forming an operation chain.

[0131] Timing of data collection: Report in real time during operation to ensure that the context is not lost.

[0132] S21-2, Directed graph model splicing discrete operations to generate the entire process path;

[0133] Node and edge definition: A node is a graph node for each operation (such as clicking the submit button), and its attributes include operation type, element ID, and context identifier;

[0134] Edge: The jump relationship between operations, such as clicking a button → pop-up window is a one-way edge, and the weight is the operation interval time;

[0135] Path concatenation algorithm: Using a directed graph traversal algorithm, starting from the initial operation (such as entering the settlement page), concatenate operations along the edges to generate the main path (such as entering the settlement page → clicking submit → pop-up display);

[0136] For branch operations (such as entering a confirmation / cancel branch after a pop-up window appears), generate sub-paths with branches (such as pop-up window → click confirm → jump to payment page, pop-up window → click cancel → return to shopping cart);

[0137] By using a sequence alignment algorithm, duplicate operations (such as accidental touches and swipes) are removed, while the core path is preserved (the length is compressed by 30% while key information remains intact).

[0138] S22, time-series anchored snapshot, enables precise synchronization between user operation path and interface snapshot;

[0139] This solves the problems of asynchronous timestamps between interface snapshots and user operation paths, as well as storage redundancy, achieving millisecond-level synchronization of operations and interface states and reducing storage costs.

[0140] S22-1, High-precision timestamp synchronization based on NTP protocol;

[0141] Time synchronization mechanism: The front-end device, back-end server, and snapshot acquisition module are all connected to the NTP (Network Time Protocol) server to synchronize the system time (error < 100ms).

[0142] Record an absolute timestamp (t_action, accurate to milliseconds) for each action (such as clicking the submit button), and record a capture timestamp (t_snapshot) for snapshots.

[0143] Snapshot binding rule: Bind a snapshot of the interface 200ms before the event occurs for each operation (to avoid the instantaneous interface rendering delay during the operation), that is, t_snapshot=t_action-200ms, to ensure that the snapshot reflects the interface state before the operation.

[0144] S22-2, Myers differential algorithm for compressed storage of snapshots;

[0145] Incremental snapshot generation: Only the differences between the current snapshot and the previous snapshot (such as changes in DOM elements or updates to image regions) are saved, and the difference block (Longest Common Subsequence LCS) is calculated using the Myers difference algorithm.

[0146] Storage optimization: Difference blocks are stored in binary format (including coordinates and changed content), and the size of full snapshots is reduced by 70% (e.g., from 100KB / frame to 30KB / frame).

[0147] Quick Restore: When reproduction is required, the interface state at any point in time can be restored by overlaying the base snapshot (the first frame is fully stored) with the difference block.

[0148] S22-3, Synchronization Error Control and Effect Verification.

[0149] Synchronization error is reduced by binding the path and interface snapshot via NTP synchronization and the previous 200ms snapshot, decreasing the time synchronization error between the path and the interface snapshot from 5 seconds for traditional timed screenshots to 0.1 seconds. Reproduction accuracy: The matching accuracy between the interface snapshot and the user operation sequence reaches 98%. For example, clicking "Submit" will result in an interface snapshot showing "Submit button not clicked."

[0150] S23, State machine reproduction, that is, dynamically restoring the interface state of abnormal scenarios;

[0151] Its goal is to solve the problem that static snapshots cannot reproduce dynamic interface transitions. It uses operation sequences to drive interface state transitions and restore the complete context (including form values, pop-up display and hiding, etc.) when an exception occurs.

[0152] S23-1, abstract the UI into a finite state machine.

[0153] State definition: The UI interface is abstracted as a finite state machine. Nodes represent the interface state (such as the login page), and edges represent the state transition triggered by the operation (such as entering password → login successful); State attributes: Each state contains UI element attributes (such as input box values, button states) and context data (such as user ID, order amount).

[0154] S23-2, state transition driven by operation sequence.

[0155] State transition logic: Drive FSM state transitions according to the operation sequence in the entire process path.

[0156] Example: The operation sequence is: enter the login page → enter username → enter password → click login → redirect to the homepage;

[0157] FSM transfer: Initial state (empty) → Login page (update input box value after entering username) → Login page (update after entering password) → Homepage (redirect after successful login).

[0158] Dynamic rendering: Real-time rendering of state attributes (such as form input value username=test, popup:visible) to reproduce the interface state when an error occurs (such as when the form amount is empty when the payment page is submitted repeatedly).

[0159] S23-3, Verification of Reproducibility Accuracy.

[0160] By comparing the reproduced state with the actual operation recording, the reproduction accuracy rate reaches 98% (including dynamic elements such as loading animations and pop-up interactions); abnormal scene restoration: it supports the reproduction of complex scenarios such as form submission failure (amount exceeding the limit) and pop-up windows obscuring buttons, with interface element position error <2px.

[0161] S24, Collaborative Technology Closed-Loop Verification.

[0162] Data flow closed loop: Full-link data fusion generates path → Time-series anchored snapshot is used to bind interface state to path → State machine reproduces dynamic rendering scene → Reproduction result feedback optimizes path splicing (such as adding branch rules);

[0163] Scenario verification: In the scenario of repeated submission exception on the e-commerce checkout page, the reproduction path includes clicking submit → pop-up window (indicating that it is being processed) → clicking submit again → interface error. The snapshot synchronization error is 0.08 seconds. The state machine restores the form value to empty and the pop-up window to show / hide, accurately restoring the root cause of the exception (lack of front-end debouncing).

[0164] As an optional example, the above method also includes:

[0165] The user behavior data reported through the tracking data in the target application is obtained, wherein the tracking data is used to selectively report content from the user operation log and the data format of the reported content.

[0166] If, based on the user behavior data in the reported content, it is determined that the type of the abnormal event is a single type and contains multiple identical operation paths, then one complete operation path at the time of the abnormal event is reproduced; or if it is determined that the type of the abnormal event is a single type and contains multiple different operation paths, then at least two complete operation paths at the time of the abnormal event are reproduced; or if it is determined that the type of the abnormal event is multiple types, then multiple complete operation paths at the time of each type of abnormal event are reproduced.

[0167] The method of determining the complete operation path to be reproduced based on the type of abnormal event can also be implemented in the following ways: If the abnormal event is determined to be of a single type based on the user behavior data in the reported content, and multiple operation paths indicated by multiple data points in the user behavior data are the same, reproduce one complete operation path when the abnormal event occurred; or if the abnormal event is determined to be of a single type based on the user behavior data in the reported content, and multiple operation paths indicated by multiple data points in the user behavior data are different, reproduce at least two complete operation paths when the abnormal event occurred; or if the abnormal event is determined to be of multiple types based on the user behavior data in the reported content, reproduce at least one complete operation path when each type of abnormal event occurs.

[0168] In this embodiment, by using the user behavior data reported by the tracking data in the target application, it can be determined how many types of anomalies the currently occurring abnormal event includes. For example, it may only include redirection anomalies or only include page loading anomalies, or it may include both redirection anomalies and user click anomalies, or two or more types of abnormal events. This embodiment does not limit this.

[0169] like Figure 4As shown, if the reported event is determined to be of a single type (i.e., a redirection event), N user behavior data or N user operation paths corresponding to N accounts are obtained from the reported content. Then, it is determined whether the N user operation paths are the same. If they are the same, only one complete operation path needs to be reproduced; otherwise, if the N user operation paths contain M (e.g., M=2) different operation paths, then these two different complete operation paths need to be reproduced, where N is a positive integer greater than or equal to 1, and M is a positive integer greater than or equal to 1 and less than or equal to N.

[0170] When M is greater than or equal to 2, M abnormal scene view sequences need to be generated based on the reproduced M complete operation paths. These M abnormal scene view sequences are then parsed to obtain M real-time abnormal graph structures. For each real-time abnormal graph structure, its structural similarity to historical abnormal graph structures is calculated, and a final recommended abnormal solution is provided for each complete operation path, resulting in M ​​abnormal solutions.

[0171] In another optional example, assuming the occurrence of two or more exception events, such as redirection exceptions and page load exceptions, then for each type of exception event, the following actions are performed: Figure 4 The processing flow is shown, and the corresponding recommended exception solutions are determined. The specific processing procedure can be found in the description of the above embodiments, and will not be repeated here.

[0172] As an optional example, the above-described sequence of abnormal scene views that can be dynamically replayed, based on the complete operation path, includes:

[0173] Each user operation behavior is sequentially obtained from the complete operation path, and the timestamp of each user operation behavior is obtained.

[0174] Based on the timestamp, bind an interface snapshot within a preset time interval prior to the occurrence of the abnormal event;

[0175] Determine the incremental changes between adjacent interface snapshots, and generate an incremental snapshot sequence based on the incremental changes; wherein, the incremental changes include the position offset of interface elements, changes in text content, and updates to style attributes;

[0176] The complete operation path and the incremental snapshot sequence are synchronized in time, and the interface state is restored based on the synchronized abnormal scene view unit set to obtain the abnormal scene view sequence.

[0177] The interface snapshot includes snapshot data of the style attributes of the target application's interface and the state of interface elements. Each abnormal scenario view unit contains an atomic-level operation node and its bound incremental snapshot data.

[0178] The timestamps obtained for each user action mentioned above are not coarse-grained events like button clicks, but rather millisecond-level precise timestamps extracted from enhanced event tracking. These timestamps serve as the absolute time reference for subsequent UI state bindings, ensuring that subsequent UI snapshots are strictly aligned with user actions on the timeline.

[0179] The above-mentioned method of binding interface snapshots within a preset time interval before the occurrence of an abnormal event based on timestamps is essentially a causal pre-emptive approach. Instead of binding an interface snapshot at the instant of the operation, the system binds the interface state 200ms prior to the operation to avoid issues caused by rendering delays after the snapshot. This interface snapshot data not only includes the DOM structure but also records all style attributes (such as button color and transparency) and states (such as input box validation failure and whether a pop-up is displayed) of interface elements, ensuring that the complete context information just before the problem occurs can be restored when reproducing the issue.

[0180] Based on timestamps, each user action is time-sequentially aligned with its associated interface snapshot and incremental changes between adjacent interface snapshots, constructing a time-series sequence of operation instructions, state snapshots, and state changes. This creates a revisitable and accurately analyzable sequence of abnormal scenarios, allowing developers to pinpoint the cause of abnormal events as if viewing the scene of the incident. Examples include why a page didn't redirect or why page loading failed.

[0181] In other words, this embodiment uses timestamps as the driving force, a preset time window as the window, differential compression as the means, and a state machine as the engine to transform discrete operation logs into interactive, analyzable, and reproducible dynamic interface recordings, providing strong on-site evidence for root cause localization.

[0182] As an optional example, the above-described parsing of the abnormal scene view sequence yields a real-time anomaly graph structure representing the causal relationship between user actions and interface state changes in the abnormal event, including:

[0183] Each abnormal scene view in the abnormal scene view sequence is parsed to obtain the abnormal operation behavior, associated interface elements and interface state in each abnormal scene view.

[0184] The abnormal operation behavior, the associated interface element, and the interface state are sequentially identified as the abnormal operation node, the interface element node, and the state node.

[0185] Arrange the abnormal operation nodes in chronological order to obtain chronological edges; bind the abnormal operation nodes with the interface element nodes to obtain association edges; and associate the interface element nodes with the state nodes to obtain state edges.

[0186] The real-time anomaly graph structure is generated based on the abnormal operation node, the interface element node, the state node, the time sequence edge, the associated edge, and the state edge.

[0187] The decision layer is a path-snapshot-based anomaly solution recommendation algorithm, which mainly includes the following:

[0188] S31, Construct a knowledge graph, including defining the entity relationships between exceptions, operations, interfaces, and solutions;

[0189] Its goal is to build a structured knowledge base that stores the "problem characteristics-solution" relationships of historical anomaly cases, laying the foundation for recommending anomaly solutions.

[0190] S31-1, Define entities and relationships;

[0191] This embodiment includes a total of 4 core entity types: (1) Exception types: such as payment failure, interface timeout, form submission error, etc.; (2) Operation nodes: such as repeated clicks to submit, input amount exceeding the limit, jump logic error, etc.; (3) Interface elements: such as submit button, amount input box, pop-up prompt, etc.; (4) Solutions: such as anti-shake processing, input validation rules, interface expansion, etc.

[0192] The defined entity relationships include, but are not limited to, three types: (1) Causal chain relationship: exception type ← operation node ← interface element, such as payment failure ← duplicate submission ← submit button; (2) Resolution relationship: interface element → solution, such as submit button → debouncing processing; (3) Association relationship: exception type → solution, such as payment failure → interface retry mechanism.

[0193] S31-2, Knowledge Graph Construction Process;

[0194] (1) Data collection: Extract structured data (such as operation and maintenance logs) from historical operation and maintenance cases, including anomaly descriptions (such as payment failure caused by repeated submission on the settlement page), operation paths (such as clicking submit → pop-up window → clicking submit again), interface snapshots (such as submission button without debounce), and solutions (such as adding 300ms debounce).

[0195] (2) Entity extraction: Use the BERT+CRF model to perform entity recognition on the abnormal description text (such as extracting entities such as payment failure and duplicate submission from payment failure due to duplicate submission); UI elements are extracted through DOM parsing.

[0196] (3) Relationship extraction: including rule-driven: based on syntax templates and business logic to define relationships;

[0197] Model-assisted approach: Use the REBEL model to extract the relationships between UI elements → solutions and operation nodes ← UI elements from complex text (such as "The submit button lacks debouncing, causing duplicate submissions").

[0198] S31-3, Store and optimize the map.

[0199] It is possible, but not limited to, using Neo4j graph database to store entities and relationships, and build a knowledge graph with more than 100,000 nodes (more than 20,000 exception types, more than 30,000 operation nodes, more than 30,000 interface elements, and more than 20,000 solutions) and more than 500,000 relationships;

[0200] Regularly use graph algorithms to identify core operation nodes (such as high-frequency abnormal payment failures and high-value solution debouncing) to optimize query efficiency.

[0201] S32 uses a GNN recommendation model to intelligently match path-snapshot graph structures;

[0202] Its goal is to transform the path-snapshot features of real-time anomalies into a graph structure, learn node embeddings through GNN, match historical cases, and output the Top N solutions.

[0203] S32-1, Structured Processing Operation Path - Snapshot Graph Structure;

[0204] Define graph nodes: (1) Operation nodes: key operations in the abnormal path, such as clicking submit or entering the amount; (2) Interface element nodes: interface elements associated with the operation, such as the submit button or the amount input box; (3) Status nodes: key states in the interface snapshot, such as pop-up visibility or form value.

[0205] Define graph edges: (1) Temporal edge: Operation nodes are arranged in chronological order, such as clicking submit → pop-up window; (2) Association edge: Operation nodes are bound to interface element nodes, such as clicking submit ← submit button; (3) State edge: Interface element nodes are associated with state nodes, such as submit button → undebouncing state.

[0206] In a specific example, the graph structure of the "duplicate payment submission" exception in e-commerce is as follows: operation node (click submit) → interface element node (submit button) → status node (no debouncing) → operation node (click submit again) → exception type node (payment failed).

[0207] S32-2, learning node embeddings through the GraphSAGE model;

[0208] Model architecture: The GraphSAGE model is adopted, which learns low-dimensional embedding vectors (such as 128-dimensional) of nodes by sampling and aggregating neighbor nodes.

[0209] Sampling strategy: Sample 20 neighboring nodes for each node (balancing efficiency and information integrity).

[0210] Aggregation function: Uses the mean to aggregate and merge the features of neighboring nodes (such as operation type, interface element attributes, and state values);

[0211] Training objective: Minimize the cross-entropy loss between node embeddings and solution labels.

[0212] S32-3, Structural similarity calculation and scheme selection;

[0213] Similarity measurement: The structural similarity between the real-time anomaly graph (path-snapshot transformation) and the historical case graph in the knowledge graph is calculated using the following formula (1):

[0214] Sim(Gq,Gh)=∣v q |v h |v q v h (1)

[0215] Where v q Embed the mean value (v) into the nodes of the real-time anomaly graph. h The mean value is embedded into the nodes of the historical case graph, and the similarity threshold is set to 0.7.

[0216] Solution selection: Retrieve the top 10 similar historical cases from the knowledge graph and extract their related solutions; after deduplication, sort them by similarity score + solution adoption rate, and select the top 3 solutions (such as debouncing, interface idempotency modification, and front-end submission lock).

[0217] S33 enhances learning and knowledge accumulation through a feedback optimization mechanism;

[0218] Its goal is to optimize the model through feedback from operations and maintenance personnel, achieve automatic knowledge accumulation, and solve the problems of cold start and model aging.

[0219] S33-1, Feedback data collection;

[0220] Explicit feedback: Record the adoption status (adoption / rejection) of the recommended solution by the operations and maintenance personnel, and the effect of the solution (whether the problem is reproduced, the reduction in time).

[0221] Implicit feedback: Inferring from interface interaction behavior (e.g., a dwell time of more than 30 seconds on the solution details page is considered as interest, and copying code snippets is considered as acceptance).

[0222] S33-2, PPO reinforcement learning optimizes model weights;

[0223] Design a reward function as shown in the following formula (2):

[0224] R = w1 × adoption rate + w2 × solution effectiveness score - w3 × solution complexity (2)

[0225] Among them, w1=0.5 (adoption rate weight), w2=0.3 (performance score), and w3=0.2 (complexity penalty).

[0226] PPO algorithm optimization: The node embedding layer parameters of the GraphSAGE model are used as the policy network, with the reward function R as the objective, and the parameters are updated through the PPO (Proximal Policy Optimization) algorithm; the model is iterated once every 100 feedback data to optimize the recommendation weight of high-value solutions (high adoption rate, high effect).

[0227] S33-3, Cold start scenario processing (based on BERT semantic matching).

[0228] S33-4, Scenario: New anomaly type has no historical cases (cold start), and cannot be matched by GNN;

[0229] The solution involves using the BERT model to semantically encode the abnormal description text (such as "slow loading on the checkout page"), generating a 768-dimensional vector; calculating the semantic similarity (cosine similarity) with the abnormal type nodes in the knowledge graph, matching the top 3 similar abnormalities (such as slow homepage loading, delayed rendering of details page); reusing solutions for similar abnormalities (such as slow loading → optimized lazy loading of images), and labeling them with cold start recommendation tags.

[0230] S33-5, Knowledge Accumulation Optimization.

[0231] New case entry: After the operations and maintenance personnel adopt the solution and solve the problem, the path-snapshot-solution triple of this anomaly is automatically extracted, and transformed into knowledge graph nodes / relationships through entity extraction and relation extraction models, and then stored in the database.

[0232] S34, Closed-loop verification and effectiveness evaluation.

[0233] Data flow closed loop: Real-time anomaly → Path-snapshot graph → GNN recommends Top 3 solutions → Operations personnel feedback → PPO optimizes the model + automatically accumulates new knowledge → Updates the knowledge graph;

[0234] Scenario validation: In the case of e-commerce payment failure, a debounce handling solution was recommended (similarity 0.92). After the operation and maintenance team adopted it, the problem was solved and the feedback was good. After the model weight was optimized, the recommendation accuracy of similar anomalies was improved to 88%. Key indicators: recommendation accuracy 82%, adoption rate 75%, knowledge accumulation automation rate >90%, cold start scenario resolution rate 60%.

[0235] In other words, by deeply integrating front-end operation logs and interface snapshots, and combining enhanced event tracking contextual semantics with DOM parsing technology, the system identifies business-significant abnormal operations. For example, in a payment failure exception, if a view shows a user repeatedly clicking the submit button on the settlement page with empty input fields, the system parses the operation as "high-frequency repeated clicks of the submit button," the associated interface element as "submit button," and the interface state as "input field validation failure" (error = amount exceeded without notification). This exception is not determined by a threshold, but rather by intelligently identifying it using contextual semantics (such as repetition or lack of validation) and historical patterns (such as the button being repeatedly triggered in 90% of payment failure cases).

[0236] The aforementioned abnormal operation nodes, interface element nodes, and state nodes are the underlying semantic alignment for building the knowledge graph. These three nodes respectively carry the semantics of what action happened, which interface element it was applied to, and what state the system is in, forming the basic atomic units for building the subsequent graph structure.

[0237] Arranging operation nodes in chronological order forms temporal edges, binding operations to elements forms relational edges, and connecting elements to states forms state edges, thus realizing the transformation from data points to a network of relationships. Taking the scenario of repeated submissions in an e-commerce system as an example, suppose operation node A (first click) → temporal edge → operation node B (second click) → temporal edge → operation node C (third click), constructing a temporal trajectory of user behavior; operation node A is bound to the interface element node "submit button", forming a relational edge of "trigger" relationship; and the "submit button" node is further connected to the state node "debouncing not enabled", forming a state edge of cause relationship. These edges not only express connections but also imply causal semantics. For example, repeated clicks occur because the button is not debouncing, which in turn leads to the state of system non-response. This structured expression transforms the originally vague interface lag problem into a quantifiable graph structure relationship, improving the efficiency of root cause localization and solution formulation for abnormal events.

[0238] As an optional example, the above method of obtaining an anomaly solution by matching the real-time anomaly graph structure with the historical anomaly graph structure includes:

[0239] Determine the structural similarity between the real-time anomaly graph structure and the historical anomaly graph structure;

[0240] Identify at least one anomaly graph structure whose structural similarity is greater than a third preset threshold from the historical anomaly graph structures;

[0241] The anomaly solution is generated based on the historical solutions of the at least one anomaly graph structure.

[0242] In this embodiment, the entire operation sequence and interface state of the current abnormal event are transformed into a real-time abnormal graph structure with attributes. The graph nodes contain operation behaviors, interface elements, and dynamic states, while edges represent temporal associations and semantic bindings. For example, if a user clicks the submit button twice consecutively on the checkout page due to a lack of debouncing, causing the payment interface to time out, a real-time abnormal structure graph in the form of click → button (without debouncing) → click again → interface error will be generated. Then, this graph is compared with tens of thousands of historical abnormal case graphs in the knowledge graph for structural similarity calculation.

[0243] The structural similarity calculation is not based on coarse-grained comparison of the number of nodes or connections, but rather on learning the low-dimensional embedding vector of each node through the model, and then measuring the semantic consistency of the overall graph structure by the cosine similarity of the mean of the node embeddings.

[0244] Based on a third preset threshold, at least one anomalous graph structure with a structural similarity higher than the threshold is selected from historical anomalous graph structures. This at least one anomalous graph structure may be one of the top N historical anomalous graph structures in terms of structural similarity, such as the top three historical anomalous graph structures.

[0245] Obtain historical solutions from these three historical anomaly graph structures, deduplicate and weight them (based on historical adoption rate and failure rate), and generate customized suggestions based on the current context. For example, use `lodash.debounce` in the Button component to delay the execution of the submit function by 300ms, with a risk warning that this solution may affect the user experience of high-frequency users and recommends testing and verification.

[0246] Through the above methods, end-to-end intelligent recommendations are achieved from application data anomalies to providing solutions, which not only significantly reduces human judgment errors, but also allows operation and maintenance experience to be systematically accumulated and reused.

[0247] Compared with traditional solutions, the technical solution of this application has at least the following advantages:

[0248] (1) Closed-loop automation: It realizes full automation from monitoring and perception → anomaly detection → data backtracking → root cause analysis → visualization presentation → alarm push, forming a closed loop of operation and maintenance.

[0249] (2) Precise and intuitive positioning: By seamlessly linking macro data anomalies with micro user behavior paths and UI screenshots, it provides an extremely intuitive problem scene context, making root cause positioning more accurate and efficient than ever before.

[0250] (3) Cost reduction and efficiency improvement: The work that required hours of manual analysis was shortened to minutes and completed automatically, which significantly reduced the operation and maintenance costs and the reliance on expert experience.

[0251] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0252] According to another aspect of the embodiments of this application, as follows is also provided Figure 5 An exception handling apparatus for an application is shown, the apparatus comprising:

[0253] The first processing unit 502 is used to respond to received abnormal events and construct a multi-dimensional causal relationship graph based on multi-source heterogeneous data that integrates user behavior data and business indicator data.

[0254] Extraction unit 504 is used to extract the complete operation path of the target application when the abnormal event occurs, based on the key abnormal operation nodes in the multidimensional causal relationship graph.

[0255] The second processing unit 506 is used to generate a dynamically replayable abnormal scene view sequence based on the complete operation path, wherein the abnormal scene view sequence includes a set of time-series states of user behavior paths and interface element attributes that reproduce the occurrence of the abnormality.

[0256] The parsing unit 508 is used to parse the abnormal scene view sequence to obtain a real-time abnormal graph structure that represents the causal relationship between user operation behavior and interface state changes in the abnormal event. By matching the real-time abnormal graph structure with the historical abnormal graph structure, an abnormal solution is obtained.

[0257] Optionally, the first processing unit 502 includes:

[0258] The association module is used to associate operation events with interface call records based on a combination of user account identifier, device identifier, session identifier, and interface call request identifier to obtain initial association pairs.

[0259] The first extraction module is used to extract key fields from the tracking data and operation logs of the target application to complete or correct the abnormal identifiers in the initial association pair and obtain a standardized association pair.

[0260] The first filtering module is used to filter out target association pairs from the standardized association pairs, where the semantic similarity between the operation event and the business indicator data is greater than a first preset threshold.

[0261] The first processing module is used to determine, based on the target association pair, the operation node, the business indicator node, and the edge representing the causal relationship between the user operation data and the business indicator data in the multidimensional causal association graph.

[0262] Optionally, the extraction unit 504 includes:

[0263] The second processing module is used to determine the contribution of user operation data corresponding to each operation node in the multidimensional causal relationship graph to the abnormal business indicators when the abnormal event occurs.

[0264] The second filtering module is used to filter out target operation data from the user operation data whose contribution is greater than a second preset threshold.

[0265] The second extraction module is used to extract the complete operation path based on the key abnormal operation nodes determined by the target operation data.

[0266] Optionally, the second extraction module mentioned above includes:

[0267] The first traversal module is used to perform directed graph traversal along the preset temporal edges in the multidimensional causal relationship graph, starting from the key abnormal operation node, to obtain the user operation node sequence, wherein the user operation node sequence includes the key user operation behaviors experienced from the start operation to the time when the abnormal event occurs.

[0268] The removal module is used to remove redundant operation nodes in the user operation node sequence caused by misoperation or repeated triggering, and generate the structured complete operation path based on the key abnormal operation nodes after removing the redundant operation nodes.

[0269] Optionally, the above-mentioned device further includes:

[0270] The first acquisition unit is used to acquire the user behavior data reported through the tracking data in the target application, wherein the tracking data is used to selectively report content from the user operation log and the data format of the reported content.

[0271] The third processing unit is configured to, based on the user behavior data in the reported content, determine that the type of the abnormal event is a single type and contains multiple identical operation paths, reproduce one complete operation path when the abnormal event occurs; or, if the type of the abnormal event is determined to be a single type and contains multiple different operation paths, reproduce at least two complete operation paths when the abnormal event occurs; or, if the type of the abnormal event is determined to be multiple types, reproduce multiple complete operation paths when each type of abnormal event occurs.

[0272] Optionally, the second processing unit 506 includes:

[0273] The first acquisition module is used to sequentially acquire each user operation behavior from the complete operation path and acquire the timestamp of each user operation behavior;

[0274] The binding module is used to bind an interface snapshot within a preset time interval before the occurrence of the abnormal event, based on the timestamp.

[0275] The third processing module is used to determine the incremental changes between adjacent interface snapshots and generate an incremental snapshot sequence based on the incremental changes; wherein, the incremental changes include the position offset of interface elements, changes in text content, and updates to style attributes;

[0276] The fourth processing module is used to perform time synchronization processing on the complete operation path and the incremental snapshot sequence, and to restore the interface state based on the abnormal scene view unit set after synchronization processing, so as to obtain the abnormal scene view sequence.

[0277] Optionally, the above-mentioned parsing unit 508 includes:

[0278] The parsing module is used to parse each abnormal scene view in the abnormal scene view sequence to obtain the abnormal operation behavior, associated interface elements and interface state in each abnormal scene view.

[0279] The fifth processing module is used to sequentially determine the abnormal operation behavior, the associated interface element, and the interface state as an abnormal operation node, an interface element node, and a state node.

[0280] The sixth processing module is used to arrange the abnormal operation nodes in chronological order to obtain chronological edges; to obtain association edges by binding the abnormal operation nodes with the interface element nodes; and to obtain state edges by associating the interface element nodes with the state nodes.

[0281] The seventh processing module is used to generate the real-time anomaly graph structure based on the abnormal operation node, the interface element node, the state node, the time sequence edge, the association edge, and the state edge.

[0282] Optionally, the parsing unit 508 further includes:

[0283] The eighth processing module is used to determine the structural similarity between the real-time anomaly graph structure and the historical anomaly graph structure;

[0284] The ninth processing module is used to determine at least one anomaly graph structure from the historical anomaly graph structure whose structural similarity is greater than a third preset threshold.

[0285] The tenth processing module is used to generate the anomaly solution based on the historical solutions of the at least one anomaly graph structure.

[0286] It should be noted that the embodiments of the exception handling device for the application described above can refer to the embodiments of the exception handling method for the application described above, and will not be repeated here.

[0287] According to another aspect of the embodiments of this application, an electronic device for implementing the above-described exception handling method for the application is also provided. This electronic device may be... Figure 1 The target terminal or server is shown. This embodiment uses the electronic device as an example to illustrate the concept. Figure 6 As shown, the electronic device includes a memory 602 and a processor 604. The memory 602 stores a computer program, and the processor 604 is configured to execute the steps in any of the above method embodiments via the computer program.

[0288] Optionally, the aforementioned electronic device may be located in at least one of a plurality of network devices of the computer.

[0289] Optionally, the processor described above can be configured to perform the following steps via a computer program:

[0290] S1, in response to received abnormal events, constructs a multi-dimensional causal relationship graph based on multi-source heterogeneous data that integrates user behavior data and business indicator data;

[0291] S2, Based on the key abnormal operation nodes in the multidimensional causal relationship graph, extract the complete operation path when the abnormal event occurs in the target application;

[0292] S3. Based on the complete operation path, generate a sequence of abnormal scene views that can be dynamically replayed, wherein the sequence of abnormal scene views includes a set of time-series states of user behavior paths and interface element attributes that reproduce the occurrence of the abnormality.

[0293] S4. The abnormal scene view sequence is parsed to obtain a real-time abnormal graph structure that represents the causal relationship between user operation behavior and interface state changes in the abnormal event. By matching the real-time abnormal graph structure with the historical abnormal graph structure, an abnormal solution is obtained.

[0294] Alternatively, as those skilled in the art will understand, Figure 6 The structure shown is for illustrative purposes only. Figure 6 This does not limit the structure of the aforementioned electronic devices or electronic equipment. For example, electronic devices or electronic equipment may also include components that are more... Figure 6 The more or fewer components shown (such as network interfaces, etc.), or having the same Figure 6 The different configurations shown.

[0295] The memory 602 can be used to store software programs and modules, such as the program instructions / modules corresponding to the exception handling method and apparatus of the application in this embodiment. The processor 604 executes various functional applications and data processing by running the software programs and modules stored in the memory 602, thereby implementing the above-mentioned exception handling method of the application. The memory 602 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 602 may further include memory remotely located relative to the processor 604, and these remote memories can be connected to the terminal via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof. Specifically, the memory 602 may be used, but is not limited to, to store multidimensional causal relationship graphs, abnormal scene view sequences, and real-time abnormal graph structures. As an example, such as Figure 6 As shown, the memory 602 may include, but is not limited to, the first processing unit 502, the extraction unit 504, the second processing unit 506, and the parsing unit 508 in the exception handling device of the application. Furthermore, it may include, but is not limited to, other module units in the exception handling device of the application, which will not be elaborated upon in this example.

[0296] Optionally, the transmission device 606 described above is used to receive or send data via a network. Specific examples of the network described above may include wired networks and wireless networks. In one example, the transmission device 606 includes a Network Interface Controller (NIC), which can be connected to other network devices and a router via a network cable to communicate with the Internet or a local area network. In another example, the transmission device 606 is a Radio Frequency (RF) module, used for wireless communication with the Internet.

[0297] In addition, the above-mentioned electronic device also includes: a display 608 for displaying video of abnormal events occurring corresponding to a dynamically replayable abnormal scene view sequence; and a connection bus 610 for connecting various module components in the above-mentioned electronic device.

[0298] In other embodiments, the target terminal or server described above can be a node in a distributed system. This distributed system can be a blockchain system, formed by connecting multiple nodes through network communication. The nodes can form a point-to-point network, and any type of computing device, such as a server or target terminal, can become a node in the blockchain system by joining this point-to-point network.

[0299] According to another aspect of this application, a computer program product or computer program is provided, comprising computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform exception handling methods for the application provided in various optional implementations of the above-described server verification processing, wherein the computer program is configured to execute the steps in any of the above-described method embodiments at runtime.

[0300] Optionally, in this embodiment, the computer-readable storage medium described above may be configured to store a computer program for performing the following steps:

[0301] S1, in response to received abnormal events, constructs a multi-dimensional causal relationship graph based on multi-source heterogeneous data that integrates user behavior data and business indicator data;

[0302] S2, Based on the key abnormal operation nodes in the multidimensional causal relationship graph, extract the complete operation path when the abnormal event occurs in the target application;

[0303] S3. Based on the complete operation path, generate a sequence of abnormal scene views that can be dynamically replayed, wherein the sequence of abnormal scene views includes a set of time-series states of user behavior paths and interface element attributes that reproduce the occurrence of the abnormality.

[0304] S4. The abnormal scene view sequence is parsed to obtain a real-time abnormal graph structure that represents the causal relationship between user operation behavior and interface state changes in the abnormal event. By matching the real-time abnormal graph structure with the historical abnormal graph structure, an abnormal solution is obtained.

[0305] Optionally, in embodiments of this application, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0306] Optionally, in this embodiment, those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing the hardware related to the target terminal. The program can be stored in a computer-readable storage medium, which may include: flash drive, read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0307] The sequence numbers of the embodiments in this application are merely for description and do not represent the superiority or inferiority of the embodiments. If the integrated units in the above embodiments are implemented as software functional units and sold or used as independent products, they can be stored in the aforementioned computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause one or more computer devices (which may be personal computers, servers, or network devices, etc.) to execute all or part of the steps of the methods in the various embodiments of this application.

[0308] In the above embodiments of this application, the descriptions of each embodiment have their own emphasis. Parts not described in detail in a certain embodiment can be referred to in the relevant descriptions of other embodiments. It should be understood that the disclosed client can be implemented in other ways in the several embodiments provided in this application. The device embodiments described above are merely illustrative; for example, the division of units is only a logical functional division. In actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling or direct coupling or communication connection may be through some interfaces; the indirect coupling or communication connection of units or modules may be electrical or other forms.

[0309] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs. Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated units described above can be implemented in hardware or as software functional units.

[0310] The above are merely preferred embodiments of this application. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. An exception handling method for an application, characterized in that, include: In response to received abnormal events, a multi-dimensional causal relationship graph is constructed based on multi-source heterogeneous data that integrates user behavior data and business indicator data; Based on the key abnormal operation nodes in the multidimensional causal relationship graph, the complete operation path when the abnormal event occurs in the target application is extracted. Based on the complete operation path, a sequence of abnormal scene views that can be dynamically replayed is generated, wherein the sequence of abnormal scene views includes a set of time-series states of user behavior paths and interface element attributes that reproduce the occurrence of the abnormality. The abnormal scene view sequence is parsed to obtain a real-time abnormal graph structure that represents the causal relationship between user operation behavior and interface state changes in the abnormal event. By matching the real-time abnormal graph structure with the historical abnormal graph structure, an abnormal solution is obtained.

2. The method according to claim 1, characterized in that, The multi-source heterogeneous data, based on the fusion of user behavior data and business indicator data, constructs a multi-dimensional causal relationship graph, including: Based on a combined identifier consisting of user account identifier, device identifier, session identifier, and API call request identifier, operation events are associated with API call records to obtain initial association pairs; Extract key fields from the event tracking data and operation logs of the target application to complete or correct the abnormal identifiers in the initial association pair, and obtain a standardized association pair; Target association pairs with a semantic similarity greater than a first preset threshold are selected from the standardized association pairs; Based on the target association pairs, the operation nodes, business indicator nodes, and edges representing the causal relationship between user operation data and the business indicator data in the multidimensional causal relationship graph are determined.

3. The method according to claim 1, characterized in that, The extraction of the complete operation path of the target application when the abnormal event occurs, based on the key abnormal operation nodes in the multidimensional causal relationship graph, includes: Determine the contribution of user operation data corresponding to each operation node in the multidimensional causal relationship graph to the abnormal business indicators when the abnormal event occurs. Filter out target operation data whose contribution is greater than the second preset threshold from the user operation data; Based on the key abnormal operation nodes determined by the target operation data, the complete operation path is extracted.

4. The method according to claim 3, characterized in that, The extraction of the complete operation path from the key abnormal operation nodes determined based on the target operation data includes: Starting from the key abnormal operation node, a directed graph traversal is performed along the preset temporal edges in the multidimensional causal relationship graph to obtain a user operation node sequence, wherein the user operation node sequence includes key user operation behaviors experienced from the start of the operation to the time when the abnormal event occurs. Remove redundant operation nodes from the user operation node sequence caused by misoperation or repeated triggering, and generate the structured complete operation path based on the key abnormal operation nodes after removing the redundant operation nodes.

5. The method according to any one of claims 1 to 4, characterized in that, The method further includes: The user behavior data reported through the tracking data in the target application is obtained, wherein the tracking data is used to selectively report content from the user operation log and the data format of the reported content. If, based on the user behavior data in the reported content, it is determined that the type of the abnormal event is a single type and contains multiple identical operation paths, then one complete operation path at the time of the abnormal event is reproduced; or if it is determined that the type of the abnormal event is a single type and contains multiple different operation paths, then at least two complete operation paths at the time of the abnormal event are reproduced; or if it is determined that the type of the abnormal event is multiple types, then multiple complete operation paths at the time of each type of abnormal event are reproduced.

6. The method according to claim 1, characterized in that, The step of generating a dynamically replayable sequence of abnormal scene views based on the complete operation path includes: Each user operation behavior is sequentially obtained from the complete operation path, and the timestamp of each user operation behavior is obtained. Based on the timestamp, bind an interface snapshot within a preset time interval prior to the occurrence of the abnormal event; Determine the incremental changes between adjacent interface snapshots, and generate an incremental snapshot sequence based on the incremental changes; wherein, the incremental changes include the position offset of interface elements, changes in text content, and updates to style attributes; The complete operation path and the incremental snapshot sequence are synchronized in time, and the interface state is restored based on the synchronized abnormal scene view unit set to obtain the abnormal scene view sequence.

7. The method according to claim 1, characterized in that, The step of parsing the abnormal scene view sequence to obtain a real-time abnormal graph structure that characterizes the causal relationship between user operation behavior and interface state changes in the abnormal event includes: Each abnormal scene view in the abnormal scene view sequence is parsed to obtain the abnormal operation behavior, associated interface elements and interface state in each abnormal scene view. The abnormal operation behavior, the associated interface element, and the interface state are sequentially identified as the abnormal operation node, the interface element node, and the state node. Arrange the abnormal operation nodes in chronological order to obtain chronological edges; bind the abnormal operation nodes with the interface element nodes to obtain association edges; and associate the interface element nodes with the state nodes to obtain state edges. The real-time anomaly graph structure is generated based on the abnormal operation node, the interface element node, the state node, the time sequence edge, the associated edge, and the state edge.

8. The method according to claim 1, characterized in that, The process of obtaining an anomaly solution by matching the real-time anomaly graph structure with the historical anomaly graph structure includes: Determine the structural similarity between the real-time anomaly graph structure and the historical anomaly graph structure; Identify at least one anomaly graph structure whose structural similarity is greater than a third preset threshold from the historical anomaly graph structures; The anomaly solution is generated based on the historical solutions of the at least one anomaly graph structure.

9. An exception handling device for an application, characterized in that, include: The first processing unit is used to respond to received abnormal events and construct a multi-dimensional causal relationship graph based on multi-source heterogeneous data that integrates user behavior data and business indicator data. The extraction unit is used to extract the complete operation path of the target application when the abnormal event occurs, based on the key abnormal operation nodes in the multidimensional causal relationship graph. The second processing unit is used to generate a sequence of abnormal scene views that can be dynamically replayed based on the complete operation path, wherein the sequence of abnormal scene views includes a set of time-series states of user behavior paths and interface element attributes that reproduce the occurrence of the abnormality. The parsing unit is used to parse the abnormal scene view sequence to obtain a real-time abnormal graph structure that represents the causal relationship between user operation behavior and interface state changes in the abnormal event. By matching the real-time abnormal graph structure with the historical abnormal graph structure, an abnormal solution is obtained.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a stored program, wherein the program can be executed by a terminal device or computer at runtime as described in any one of claims 1 to 8.

11. An electronic device comprising a memory and a processor, characterized in that, The memory stores a computer program, and the processor is configured to perform the method as described in any one of claims 1 to 8 through the computer program.

Images