Operation and maintenance work order flow management system based on large language model

Abstract

The application relates to the technical field of intelligent operation and maintenance and work order management, in particular to an operation and maintenance work order flow transfer management system based on a large language model; the system comprises a data receiving module, which is used for receiving real-time work order data, system topology graph data and processing entity state data; a semantic and time sequence clustering module, which is used for performing semantic vectorization processing on the real-time work order data, combining preset time windows for clustering and generating associated work order clusters; a topology penetration and root cause prediction module, which is used for determining a root cause node and a target processing entity; a cognitive load evaluation module, which is used for determining a queue overflow risk state; a dynamic scheduling and synthesis module, which is used for switching between an independent distribution mode and a multi-work order folding and synthesizing mode, generating a global collaborative work order and performing flow transfer scheduling, so that repeated distribution is reduced, cross-team concurrent overload response is inhibited and a global recovery path is shortened.

Description

Technical Field

[0001] This invention relates to the field of intelligent operation and maintenance and work order management technology, specifically to an operation and maintenance work order flow management system based on a large language model. Background Technology

[0002] In the operation and maintenance of financial-grade online payment, clearing, and large-scale internet business platforms, monitoring systems, log systems, and duty consoles continuously generate a large number of alarms and abnormal work orders. These work orders typically correspond to multiple business and infrastructure nodes such as order services, payment services, account services, risk control services, databases, and middleware. When complex systems experience cascading failures, different services often simultaneously exhibit symptoms such as timeouts, failures, and write-back anomalies within a short period of time. Therefore, the efficiency of operation and maintenance work order processing depends on the system's ability to identify anomalies from the same source, its ability to judge the relationship of fault propagation, and its ability to perceive the workload of the processing team.

[0003] In the traditional approach, the operations and maintenance platform typically dispatches real-time alarms or work orders to the corresponding teams as individual events. There is a lack of correlation analysis between work orders based on semantics, time windows, and topological dependencies. In the case of major failures, it is easy to treat a large number of superficial work orders triggered by the same underlying root cause as independent problems. This leads to the database group, business application group, or middleware group repeatedly receiving and processing a large amount of similar information, resulting in queue congestion, repeated troubleshooting across teams, and decreased response efficiency. Therefore, the stability of global failure recovery remains low. Summary of the Invention

[0004] The purpose of this invention is to provide an operation and maintenance work order flow management system based on a large language model, addressing the following technical problems: Existing operation and maintenance platform work order flow technologies have significant shortcomings in analyzing the correlation of common anomalies when facing complex system cascading failures and in dynamically scheduling work orders based on the processing team's workload. There is an urgent need to propose an operation and maintenance work order flow management system based on a large language model that can accurately trace the root cause of fault propagation, dynamically assess the team's cognitive load, and synthesize globally collaborative work orders to suppress concurrent overload. The purpose of this invention can be achieved through the following technical solutions:

[0005] The data receiving module is used to receive real-time work order data, configuration management database data, link tracing data, and processing entity status data corresponding to the operation and maintenance terminal; and to generate system topology data based on the configuration management database data and the link tracing data.

[0006] The semantic and temporal clustering module is used to call a pre-configured large language model to perform semantic vectorization processing on the real-time work order data, and to perform clustering based on a preset time window dynamically generated based on historical alarm frequency to generate associated work order clusters.

[0007] The topology penetration and root cause prediction module is used to map the associated work order cluster to the system topology graph data, extract the node features and edge weights contained in the system topology graph data to construct an input feature vector matrix, and calculate the propagation path through a preset graph neural network to determine the root cause node and the target processing entity corresponding to the root cause node.

[0008] The cognitive load assessment module is used to calculate the current concurrent processing capacity of the target processing entity based on the processing entity status data, and to determine the queue overflow risk status based on the current concurrent processing capacity.

[0009] The dynamic scheduling and synthesis module is used to switch between independent distribution mode and multi-work order folding synthesis mode based on the queue overflow risk status. In the multi-work order folding synthesis mode, the module calls the large language model to extract information from the root cause node and the associated work order cluster to generate the corresponding global collaborative work order and perform flow scheduling.

[0010] Optionally, the semantic and temporal clustering module includes:

[0011] The semantic vectorization unit is used to extract the textual description features of the real-time work order data through the word embedding technology of the large language model, and to convert the textual description features into semantic vectors.

[0012] The density clustering unit is used to perform clustering analysis on the semantic vector within the preset time window based on the density clustering algorithm, so as to identify the related work order clusters with the same root cause features.

[0013] Optionally, the topology penetration and root cause prediction module includes:

[0014] The mapping unit is used to extract feature nodes from the associated work order cluster and align the feature nodes with the topology nodes contained in the system topology graph data;

[0015] A spatial convolutional unit is used to extract features from the aligned system topology graph data using a preset spatial graph convolutional network to generate a topology feature representation.

[0016] The reverse tracing unit is used to calculate the transition probability of the topological nodes based on a preset random walk algorithm, and to calculate the root cause probability score of each topological node in combination with the topological feature representation, and to determine the topological node with the highest root cause probability score as the root cause node.

[0017] Optionally, the cognitive load assessment module includes:

[0018] The capacity calculation unit is used to calculate the current concurrent processing capacity of the target processing entity based on a preset queuing theory model and the processing entity state data. The processing entity state data includes historical processing efficiency, current number of unclosed work orders, and a cognitive load matrix composed of historical processing time and manpower time consumption characteristics of different types of work orders.

[0019] The risk determination unit is used to determine the queue overflow risk state as a high-risk state when the number of work orders in the associated work order cluster is greater than the current concurrent processing capacity; and to determine the queue overflow risk state as a low-risk state when the number of work orders in the associated work order cluster is less than or equal to the current concurrent processing capacity.

[0020] Optionally, the dynamic scheduling and synthesis module includes:

[0021] The normal distribution unit is used to trigger the independent distribution mode and independently route the work orders in the associated work order cluster when the queue overflow risk status is the low-risk status.

[0022] The cascading interception unit is used to trigger the multi-work order folding and synthesis mode and intercept all work orders in the associated work order cluster when the queue overflow risk state is the high-risk state.

[0023] The collaborative work order synthesis unit is used to call the large language model to read the root cause node and the intercepted associated work order cluster in the multi-work order folding synthesis mode, so as to synthesize the global collaborative work order.

[0024] Optionally, the collaborative work order synthesis unit is further configured to:

[0025] The large language model is guided to generate situational awareness text by using a preset prompt word template that includes slots for speculative root cause information, slots for affected surface information, and slots for collaborative action instructions.

[0026] The situational awareness text is encapsulated into the global collaborative work order, wherein the situational awareness text includes inferred root cause information, affected surface information, and collaborative action instructions that each processing entity needs to cooperate with.

[0027] Optionally, the dynamic scheduling and synthesis module further includes:

[0028] The intelligent routing unit is used to send the global collaborative work order to the target processing entity corresponding to the root cause node, and to copy the global collaborative work order to the affected business entities obtained by parsing the tag information contained in the topology node corresponding to the associated work order cluster, so as to synchronize the fault status and prevent the affected business entities from performing independent troubleshooting actions.

[0029] Optionally, the data receiving module includes:

[0030] The streaming data parsing unit is used to receive real-time alarm streaming data and extract error codes and timestamps from the real-time alarm streaming data to generate the real-time work order data;

[0031] The topology building unit is used to receive configuration management database data and link tracing data, and to build the system topology map data based on the configuration management database data and the link tracing data.

[0032] Optionally, the system further includes:

[0033] The status update module is used to receive the closed-loop processing result of the target processing entity for the global collaborative work order, and update the status data of the processing entity based on the closed-loop processing result, so as to adjust the evaluation benchmark of the cognitive load assessment module in subsequent time periods.

[0034] Compared with the prior art, the present invention has the following beneficial effects:

[0035] 1. This system uses a semantic and temporal clustering module to call a pre-configured large language model to perform semantic vectorization processing on real-time work order data, and combines it with a preset time window dynamically generated based on historical alarm frequency to perform clustering, thereby generating related work order clusters. This mechanism effectively solves the technical defects of traditional operation and maintenance platforms, which lack semantic and time window correlation analysis and are prone to treating a large number of representative work orders triggered by the same underlying root cause as independent problems. It can accurately identify and collect common anomalies in cascading faults in a short time.

[0036] 2. This system maps the aforementioned clusters of related work orders to system topology graph data through the topology penetration and root cause prediction modules. It then uses preset graph neural networks, spatial graph convolutional networks, and random walk algorithms to extract topological feature representations and perform reverse tracing. Based on the calculated root cause probability scores, it determines the final root cause node and its corresponding target processing entity. This design overcomes the limitation of traditional platforms lacking topology dependency judgment, and can effectively penetrate apparent nodes along the real system dependency links to accurately pinpoint the source of the fault.

[0037] 3. This system uses a cognitive load assessment module to calculate the current concurrent processing capacity of the target processing entity based on the processing entity's status data and a preset queuing theory model, and uses this as a benchmark to determine the queue overflow risk status. This mechanism overcomes the shortcomings of traditional methods in terms of insufficient perception of the processing team's load status, and can identify the load bottleneck of the operation and maintenance team in advance when there are massive concurrent alarms, effectively preventing queue congestion and decreased processing efficiency caused by repeatedly dispatching a large number of similar work orders to the target processing entity.

[0038] 4. This system, through a dynamic scheduling and synthesis module, triggers a multi-work order folding and synthesis mode when facing high-risk situations. It calls a large language model and combines it with preset prompt word templates to generate a global collaborative work order containing situational awareness text. The intelligent routing unit then sends the work order to the target processing entity and simultaneously copies it to the affected business entities. This scheduling switching and synthesis mechanism changes the inefficient mode of traditional independent dispatch of single events. By uniformly synchronizing fault status and collaborative action instructions, it effectively prevents affected business entities from performing invalid independent troubleshooting actions, eliminates duplicate troubleshooting across teams, and improves the stability of global fault recovery. Attached Figure Description

[0039] Figure 1 This is a structural diagram of the system of the present invention. Detailed Implementation

[0040] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to specific embodiments.

[0041] Example 1:

[0042] Please see Figure 1 A maintenance work order workflow management system based on a large language model, the system includes:

[0043] The data receiving module is used to receive real-time work order data, configuration management database data, link tracing data, and processing entity status data corresponding to the operation and maintenance terminal; and to generate system topology data based on configuration management database data and link tracing data.

[0044] The semantic and temporal clustering module is used to call a pre-configured large language model to perform semantic vectorization processing on real-time work order data, and to perform clustering based on a preset time window dynamically generated according to historical alarm frequency to generate related work order clusters.

[0045] The topology penetration and root cause prediction module is used to map the associated work order clusters to the system topology graph data, extract the node features and edge weights contained in the system topology graph data to construct the input feature vector matrix, and calculate the propagation path through a preset graph neural network to determine the root cause node and the target processing entity corresponding to the root cause node.

[0046] The cognitive load assessment module is used to calculate the current concurrent processing capacity of the target processing entity based on the processing entity status data, and to determine the queue overflow risk status based on the current concurrent processing capacity.

[0047] The dynamic scheduling and synthesis module is used to switch between independent distribution mode and multi-work order folding synthesis mode based on the queue overflow risk status. In the multi-work order folding synthesis mode, it calls the large language model to extract information from the root cause node and related work order clusters to generate the corresponding global collaborative work order and execute the flow scheduling.

[0048] This embodiment provides an operation and maintenance work order flow management mechanism based on a large language model. Specifically, this mechanism is deployed in the operation and maintenance middleware of a financial-grade online payment and settlement platform. The platform includes at least order access service, payment routing service, account service, discount verification service, risk control verification service, message bus, and distributed database cluster. The system continuously receives alarm, link, configuration, and personnel status data. When a major failure occurs, each apparent work order is no longer treated as an independent troubleshooting task. Instead, it first determines whether these anomalies originate from the same underlying failure, and then, based on the topology propagation range and the target team's carrying capacity, decides whether to adopt an independent distribution or folding synthesis handling strategy.

[0049] To elaborate, the data receiving module acquires three types of basic information. The first type is real-time work order data, which can come from monitoring platforms, log platforms, or manual reports from the duty station. Examples include text descriptions such as order service database connection timeouts, discount service dependency failures, and payment confirmation write failures, along with error codes, timestamps, service identifiers, and environment identifiers. The second type is system topology data, which reflects the call dependencies, deployment relationships, and underlying resource ownership relationships between various services. For example, the order service depends on the payment routing service, which in turn depends on the account service and the database master node. The third type is processing entity status data, which reflects the duty status of processing entities such as the database administrator group, middleware group, and business application group, the current number of unclosed work orders, and recent processing efficiency.

[0050] After the data enters the system, the semantic and temporal clustering modules perform semantic compression on the work order text, so that descriptions with different expressions but similar mechanisms, such as database connection pool exhaustion, master database handshake failure, and transaction commit timeout, are mapped to adjacent semantic regions. The system clusters these semantic results within a preset time window. The time window here is not for simply counting, but to identify cascading symptoms triggered by the same root cause within the same time period. For example, within a 2-minute window, if multiple services such as payment, refund, discounts, and risk control experience dependency anomalies at the same time, it is more likely that the downstream shared infrastructure has experienced a concentrated failure, rather than the four services failing independently.

[0051] After obtaining the associated work order cluster, the topology penetration and root cause prediction module maps the features extracted from the work orders, such as service name, instance name, database name, and data center name, onto the topology graph. Then, it calculates the propagation path by combining the call direction and dependency depth between nodes. The core here is not just looking at which service reports the most errors, but looking at which node best matches the propagation characteristics of multiple upstream nodes being abnormal at the same time due to topology diffusion. If a database node is connected to three core services—account, payment, and clearing—downstream, and these three services all experience read / write failures within a preset time period, then the root cause probability of this database node will be higher than that of a single upper-layer business node by a difference greater than a preset proportion.

[0052] After the root cause node is identified, the cognitive load assessment module does not immediately dispatch orders, but further determines whether the corresponding processing entity has the ability to handle the wave of anomalies in a timely manner. This is because in major financial system failures, the system recovery rate is limited by the concurrent processing bandwidth of the target processing entity, rather than the rate at which system alarms are generated. The system will combine historical processing efficiency, the number of unclosed tasks, and the current on-duty personnel to estimate the current parallel processing capacity of the processing entity. If the size of the associated work order cluster is greater than this capacity threshold, it means that continuing to dispatch orders one by one will only cause information overload for the team and trigger a lot of invalid communication. At this time, the system marks the queue overflow risk as high risk.

[0053] In high-risk situations, the dynamic scheduling and synthesis module switches from independent distribution mode to multi-work order folding synthesis mode. Folding does not simply mean splicing multiple work orders together, but rather extracting information from work order clusters around the root cause node, retaining the affected business aspects, propagation links, and collaborative actions, and then outputting a global collaborative work order. This work order serves as a unified handling and transfer node, primarily handled by the root cause team, while other affected teams receive synchronization information and execute cooperative actions according to instructions, avoiding duplicate identification of the same root cause. Conversely, if the system is assessed as low-risk, the independent distribution mode is maintained to ensure response speed and clarity of responsibility in localized abnormal scenarios.

[0054] In an exception handling scenario, if the semantic clustering results are unstable, for example, if multiple work orders have no clear semantic proximity relationship and lack clustering features within the same time window, the system allows these work orders to temporarily not be clustered, but instead enter the regular single-work-order processing flow. If topology data is missing within a preset time period, for example, if a newly launched service has not yet been configured and managed by the database, the system can first form temporary association clusters based on the semantic clustering results, limit the root cause location range to the known node set, and mark the topology as incomplete. If the processing entity status data is delayed in updating, the system uses the most recent stable sampling results as a conservative benchmark, prioritizing the avoidance of over-dispatch.

[0055] During the evening clearing peak of a bank's payment platform, the database master node experienced storage jitter. Within 30 seconds, the monitoring platform continuously reported 120 alarms. The alarm texts involved payment confirmation failure, coupon status write-back timeout, order settlement failure, and abnormal risk control transaction record supplementation. The system first converted these alarms into real-time work orders, and then found that these work orders appeared in the same time window and semantically pointed to the downstream persistence failure.

[0056] The system identified multiple business services corresponding to these work orders in the topology diagram that all depend on the same database master node. Therefore, it identified this node as the root cause node and identified the corresponding processing entity as the database administrator group. Furthermore, the system found that the database administrator group currently only has 2 on-duty engineers and 3 high-priority work orders that have not been closed. Therefore, it determined that if 120 work orders were sent out one by one, it would cause a significant queue overflow. So, it switched to the multi-work order folding and merging mode to generate a global collaborative work order, which was sent to the database administrator group and simultaneously sent to the payment group, order group, and risk control group.

[0057] The purpose of this step is to connect alarm collection, cause identification, load judgment, and scheduling switching into a closed loop, so that the operation and maintenance system has the ability to reduce the complexity of cascading failures before handling them, thereby reducing duplicate distribution, suppressing cross-team concurrent overload response, and shortening the global recovery path.

[0058] The semantic and temporal clustering module includes:

[0059] The semantic vectorization unit is used to extract textual description features from real-time work order data using word embedding technology of large language models, and to transform the textual description features into semantic vectors.

[0060] Density clustering units are used to perform clustering analysis on semantic vectors within a preset time window based on density clustering algorithms, in order to identify clusters of related work orders with the same root cause characteristics.

[0061] This embodiment provides a refined mechanism for semantic and temporal clustering. Specifically, when cascading anomalies occur on the aforementioned payment and clearing platform, relying solely on keyword matching can easily lead to treating payment timeouts, inventory lock failures, and risk control rejections as unrelated issues, since alarm text descriptions differ across business domains. Therefore, this embodiment introduces semantic vectorization units and density clustering units to compress the differences in textual descriptions into comparable semantic proximity relationships, and then combines these with concurrency features in the temporal dimension to identify work orders from the same source.

[0062] To elaborate, after receiving the work order text, the semantic vectorization unit jointly encodes the service name, resource name, error code, and fault action. For ease of understanding, the three work orders can be abstracted into vectors A, B, and C: where A corresponds to order service write timeout, B corresponds to payment service transaction submission failure, and C corresponds to SMS notification sending rate limiting. After encoding, the spatial distance between A and B in the vector space is less than or equal to a first preset distance threshold, because both point to persistent link obstruction. C, on the other hand, reflects more of the peripheral notification link problem, and its spatial distance from A and B is greater than a second preset distance threshold, which is greater than the first preset distance threshold. If the spatial distance is greater than the first preset distance threshold and less than or equal to the second preset distance threshold, then the corresponding work order is marked as a pending feature vector. In this way, even if the exact same keywords do not appear in the text, the system can still identify transaction submission failure and main database write timeout as similar semantic symptoms.

[0063] After semantic encoding is completed, the density clustering unit does not require prior knowledge of the number of fault categories. Instead, it observes which vectors form high-density clusters in the local space within a certain time window. For example, in a 60-second window, if there are 20 work order vectors related to database write failures that are concentrated in one cluster, while another 2 work orders related to SMS gateway jitter appear scattered, the former will form the main cluster, and the latter may be identified as independent small clusters or discrete noise. The technical significance of this design is that cascading faults often release a large number of symptoms from the same source in a short period of time, and density rather than absolute quantity can better reflect the existence of the same root cause.

[0064] Furthermore, the role of the time window is not only to capture data, but also to suppress false clustering of historically similar but currently irrelevant data. For example, a batch of cache breakdown alarms occurred during the day, and a database master database anomaly occurred at night. If we only look at the text of the two batches of work orders, they may both contain words such as timeout failure, but they occurred at different times and had different propagation paths, so they should not be merged into the same cluster. Therefore, the system requires both semantic similarity and temporal proximity when clustering, so that the clusters of related work orders are closer to the actual fault waves.

[0065] In an exception handling scenario, if the character length of some work order texts is less than a preset length threshold and only contains information such as error code 500, the semantic vectorization unit can supplement it by reading the context metadata of the same alarm source, such as service name, instance tag, and deployment partition, to avoid distortion of expression due to short text. If the character length of the work order text is greater than or equal to the preset length threshold, it is directly vectorized. If the number of work orders within a certain time window is less than the preset number threshold and a stable density structure cannot be formed, the system can extend the compensation window by a shorter time window before making a judgment. If clustering is still not possible after compensation, it is retained as a single work order path to prevent forced clustering from causing misleading results. If the same work order is close to two clusters at the same time, the system prioritizes the topological adjacency relationship and assigns it to the cluster that is more in line with the direction of call chain propagation.

[0066] In the aforementioned database master node jitter event, the system first received 6 sample work orders: T1 was a timeout for writing to the database for the order service, T2 was a transaction commit failure for the payment service, T3 was a failure to update the balance for the account service, T4 was a timeout for calling downstream for the discount service, T5 was a rate limit for the SMS gateway, and T6 was a failure to read the master database for the reconciliation batch. After semantic vectorization, T1, T2, T3, T4, and T6 are close to each other in space and all appear within 90 seconds, thus forming the same cluster of related work orders. Although T5 also appears in the same time period, it is semantically closer to the external gateway fluctuation, so it is separated into another small cluster and does not participate in the subsequent database root cause localization.

[0067] The purpose of this mechanism is to reduce a large number of inconsistent abnormal texts to a small number of symptom clusters with engineering significance, thereby realizing the transformation from text noise accumulation to fault cluster identification and providing stable input for subsequent topology penetration.

[0068] The topology penetration and root cause prediction module includes:

[0069] The mapping unit is used to extract feature nodes from the associated work order clusters and align the feature nodes with the topology nodes contained in the system topology graph data;

[0070] Spatial convolutional units are used to extract features from aligned system topology graph data using a pre-defined spatial graph convolutional network to generate topological feature representations.

[0071] The reverse tracing unit is used to calculate the transition probability of topological nodes based on a preset random walk algorithm, and to calculate the root cause probability score of each topological node in combination with the topological feature representation, and to determine the topological node with the highest root cause probability score as the root cause node.

[0072] This embodiment provides a topology penetration and root cause prediction mechanism. Specifically, although work order text clustering can identify that the above anomalies belong to the same batch of faults, it may still be unable to distinguish whether it is a database fault, message bus blockage, or an upstream gateway amplifying the error. Therefore, based on the associated work order clusters in the previous stage, this embodiment introduces topology alignment, spatial feature extraction, and reverse tracing processes, enabling the system to trace back nodes along the real dependency links and lock the most likely source of the fault.

[0073] To elaborate, the mapping unit first extracts characteristic nodes corresponding to the infrastructure from the associated work order clusters, such as service name, instance identifier, database alias, link endpoint, and data center label. For ease of explanation, we can assume that there are nodes N1 for order service, N2 for payment service, N3 for account service, and N4 for database master node in the topology diagram, with the dependency direction being N1→N2→N4 and N3→N4. If an order write to the database fails, a payment transaction fails to submit, or an account balance update fails in the work order cluster, these work orders can be mapped to the three business nodes N1, N2, and N3, respectively. At this time, although the error occurs on the upper-level node, they all point to N4 in the topology, which provides a structural basis for subsequent source tracing.

[0074] The role of the spatial convolutional unit is to consider the node's own state together with the states of its neighbors, rather than viewing a single alarm in isolation. In engineering, cascading failures often manifest as multiple upstream nodes synchronizing abnormally, while a single downstream node remains silent or generates only a few alarms. For example, the database master node may not directly generate the most logs, but the out-degree of its downstream dependencies is greater than the preset node propagation threshold, and the upstream symptoms are concentrated. The spatial convolutional unit aggregates the abnormal propagation characteristics of neighboring nodes to form a topological feature representation that better reflects the local structural pressure, thereby avoiding the bias caused by simply sorting by the number of alarms.

[0075] The reverse tracing unit further traces back from the symptom nodes to the potential root cause nodes. This process can be understood as: starting from the abnormal business nodes N1, N2, and N3, performing a reverse traversal along the dependency edges, and counting which downstream nodes are repeatedly pointed to by multiple abnormal paths; if most of the reverse paths eventually converge to N4, then N4 has the highest root cause probability score; unlike simple topological back-pointing, the score here also combines the aforementioned spatial feature representation, thus considering both the path convergence degree and whether the node has a structural position that triggers widespread propagation;

[0076] The specific quantization calculation rules are as follows: the reverse tracing unit reduces the dimensionality of the topological feature representation output by the spatial convolution unit to generate a structural anomaly confidence scalar for each potential node; when executing the preset random walk algorithm, the abnormal appearance nodes mapped by the work order are used as the starting set, and the connection edges of the system topology graph data are used for reverse transfer; the transfer probability is configured as the product of the basic connectivity weight of the target node and the structural anomaly confidence scalar of the target, so that the walk path actively tilts towards nodes with higher structural anomaly characteristics;

[0077] After multiple iterations of the walk to reach a stable distribution, the steady-state frequency of each topological node being visited is the convergence result of the random walk. The system further multiplies this steady-state frequency by the structural anomaly confidence scalar of the node to obtain the final root cause probability score. This structured feature dimensionality reduction process clearly defines the fusion and flow rules of the walk trajectory and convolutional features, enabling the system to accurately locate the root cause without relying on complex and uninterpretable formulas.

[0078] This combination process is necessary because there may be accompanying abnormal nodes in the financial system. For example, message bus N5 may experience consumption backlog at the same time, but if its abnormality only affects the notification link and does not form the main propagation trunk with the core transaction failure, then although it has local alarms, it should not be judged as the main cause of this wave of failures. Through the constraints of spatial characteristics and reverse convergence, the system can screen out the node with the most propagation explanatory power from multiple suspicious nodes.

[0079] In an anomaly handling scenario, if the feature nodes in a work order cluster cannot be perfectly aligned with the topology graph (e.g., the log uses an old version service name), the mapping unit can normalize them based on the alias table or configuration management database change records. If they still cannot be aligned, the work order is marked as a weak mapping to reduce its impact in subsequent scoring and prevent a single dirty data entry from distorting the root cause judgment. If multiple nodes have similar scores, the system can perform secondary screening based on the size of the impact area, the critical path level, or the most recent health check status. If they still cannot be distinguished, multiple candidate root cause nodes are allowed to be output and simultaneously prompted by the collaborative work order.

[0080] In the aforementioned fault, the work order cluster already included anomalies in order service, payment service, account service, and discount service; the topology diagram shows that these four services access the same database master node D1 through two intermediate layer services, while the SMS notification service accesses the external gateway G1; the system maps the first four types of work orders to business nodes related to D1, and maps work orders related to the SMS gateway to the G1 branch; after spatial feature extraction, the branch where D1 is located shows obvious multi-path convergence characteristics; reverse tracing also found that most abnormal paths ultimately point back to D1, so the system identifies D1 as the root cause node, and does not mistakenly identify the SMS gateway G1 as the main source of the fault;

[0081] The purpose of this mechanism is to transform the characteristics of apparent error nodes into the characteristics of potential root cause nodes, thereby achieving topological source tracing convergence of root cause localization from surface symptoms to underlying dependency sources.

[0082] The cognitive load assessment module includes:

[0083] The capacity calculation unit is used to calculate the current concurrent processing capacity of the target processing entity based on a preset queuing theory model and processing entity status data. The processing entity status data includes historical processing efficiency, current number of unclosed work orders, and a cognitive load matrix composed of historical processing time and manpower time consumption characteristics of different types of work orders.

[0084] The risk assessment unit is used to determine the queue overflow risk status as high-risk when the number of work orders in the associated work order cluster is greater than the current concurrent processing capacity, and to determine the queue overflow risk status as low-risk when the number of work orders in the associated work order cluster is less than or equal to the current concurrent processing capacity.

[0085] This embodiment provides a cognitive load assessment mechanism. Specifically, after the root cause node has been identified, if a large number of work orders in the same wave are still pushed to the corresponding teams in the traditional way, congestion may easily occur where the amount of information exceeds the processing capacity. In particular, basic teams such as databases, networks, and middleware often need to locate the root cause and respond to investigation requests from multiple business groups during major failures. Their actual processing capacity is not limited by the number of personnel, but by the total amount of complex information that can be effectively absorbed and processed per unit time. Therefore, this embodiment calculates the current concurrent processing capacity by processing entity state data and judges the risk of queue overflow accordingly.

[0086] To elaborate, the capacity calculation unit considers three types of factors: first, historical processing efficiency, which reflects the average processing speed of a processing entity under different fault types; second, the current number of unclosed work orders, which reflects the current queuing pressure; and third, the cognitive load matrix, which characterizes the degree to which different types of work orders consume engineers' analytical, collaborative, and verification resources. For ease of explanation, it can be assumed that the database administrator group has a lower load for local issues such as slow queries on single instances, and a higher load for cross-component issues such as master-slave switch anomalies. Even if the number of work orders for the two types of issues is the same, the latter has a higher resource consumption rate for the team's concurrent processing capacity.

[0087] When introducing the pre-set queuing theory model, the capacity calculation unit maps the queuing theory elements to the engineering dimension: the number of available on-duty personnel of the target processing entity is set as the number of parallel service stations in the model; based on the currently located root cause node and associated work order type, the theoretical time consumption coefficient for processing this type of problem is extracted from the cognitive load matrix, and combined with the historical processing efficiency to calculate the dynamic service rate of the current processing entity in this specific scenario.

[0088] The current number of unclosed work orders is considered as the initial queue length. Based on the classic multi-server queuing logic, the capacity calculation unit calculates the maximum remaining capacity of the current system to continue accepting new requests without causing the waiting time to exceed the limit, under the threshold constraint of setting the maximum tolerable queuing time. This remaining capacity is output as the current concurrent processing capacity of the target processing entity. Through the structured decomposition of the above business logic, the abstract queuing formula is made transparent, and the specific data flow calculation rules of personnel resources, theoretical time consumption, and queue backlog in system scheduling are clearly defined.

[0089] The risk assessment unit does not aim to accurately predict how many work orders each person can handle, but rather focuses on whether the system is approaching the cognitive overflow boundary. For example, if a team currently has 3 engineers on duty according to the system records, but one of them is performing data verification and another is occupied for primary / backup switchover confirmation, the actual processing resources available for new work order analysis may be far lower than the number of people displayed. Therefore, the system compares the number of related work order clusters with the current concurrent processing capacity. If the former significantly exceeds the latter, it is judged as a high-risk state; if the former is within the processing range, it is judged as a low-risk state, allowing normal distribution.

[0090] This design reinforces the previous stage; because even if the root cause is correctly identified, if dozens or even hundreds of work orders pointing to the same root cause are assigned to the same team, the team will repeatedly read similar symptoms and give the same conclusions, resulting in communication congestion rather than analytical gain; the essence of cognitive load assessment is to identify whether continuing to distribute work orders will reduce the overall recovery efficiency before dispatching them.

[0091] In an exception handling scenario, if the historical samples of a certain processing entity are insufficient, for example, if a newly formed middleware emergency team does not yet have sufficient statistical data, the system can first use the conservative benchmark of similar teams as the initial evaluation value, and gradually correct it as the subsequent closed-loop results are obtained; if the current number of unclosed work orders is not fully counted, for example, if some tasks are in offline interaction links not recorded by the system, the system can allow the shift leader to supplement the busy status mark through manual confirmation and increase the risk level in this round of scheduling; if the size of the associated work order cluster is close to the boundary of concurrent processing capacity, the system can set a buffer and prioritize a more stable folding and synthesis strategy to avoid frequent switching caused by critical fluctuations;

[0092] In the aforementioned payment platform failure, the system has identified database master node D1 as the root cause node, and the corresponding handling entity is the database administrator group. There are two people on duty in the database administrator group, one of whom is handling a backup verification anomaly, and the other is following up on another P1-level storage expansion work order. After querying the historical status, the system found that failures involving master database write anomalies usually require simultaneous log verification, connection pool status confirmation, and master-slave health comparison, which are high cognitive load tasks. At this time, even if there are only 20 work orders related to D1 in the work order cluster, its analysis resource consumption on the database administrator group has exceeded the current carrying capacity, and therefore it is judged as a high-risk state.

[0093] The purpose of this mechanism is to allow the system to perceive human processing bottlenecks before distributing actions, thereby avoiding cognitive overload caused by repetitive information to the root cause team and providing a trigger for switching scheduling modes.

[0094] The dynamic scheduling and synthesis module includes:

[0095] The normal distribution unit is used to trigger the independent distribution mode and perform independent routing of work orders in the associated work order cluster when the queue overflow risk status is low.

[0096] The cascading interception unit is used to trigger the multi-work order folding and synthesis mode and intercept all work orders in the associated work order cluster when the queue overflow risk status is high-risk.

[0097] The collaborative work order synthesis unit is used to call the large language model to read the root cause node and the intercepted related work order clusters in the multi-work order folding synthesis mode, so as to synthesize a global collaborative work order.

[0098] This embodiment provides a dynamic scheduling and synthesis mechanism. Specifically, after completing the risk assessment, the system needs to solve a key problem: whether to maintain the traditional order dispatching or to actively interrupt this process and consolidate multiple symptoms into a single processing node. Without this switching mechanism, even if the root cause and overload risk have been identified, the system may still continue to dispatch a large number of work orders out of inertia, resulting in the identification results not being able to be converted into actual control actions. Therefore, this embodiment sets up a normal dispatching unit, a cascading interception unit, and a collaborative work order synthesis unit.

[0099] To elaborate, the normal distribution unit is used in low-risk scenarios. In this case, although the related work order clusters may be triggered by the same root cause, their number is limited, and the target processing entity still has enough capacity to receive and close the loop one by one. The system will then route each work order independently according to the existing rules, making the responsibility boundary clear. For example, if a local cache node jitter only affects a small number of order query requests, and the cache group is currently idle, there is no need to fold it, and the relevant work orders can be directly distributed to the cache group.

[0100] However, the above approach has significant drawbacks in handling major cascading failures: it assumes that each work order deserves to be read and responded to individually, ignoring the repetitiveness of symptoms originating from the same source at the cognitive level. Therefore, this embodiment introduces a cascading interception unit under high-risk conditions to perform unified interception on work orders in related work order clusters. Interception means suspending these work orders from entering the regular queue, preventing them from immediately triggering parallel investigation actions by multiple teams. This pauses the initial parallel distribution action at the system organization level, preventing the concurrent overload response from further amplifying.

[0101] After interception, the collaborative work order synthesis unit calls the large language model to read the root cause node and the intercepted work order cluster, extracts the common symptoms, scope of impact and troubleshooting context, and generates a global collaborative work order. The following specific example illustrates this: If the work order cluster contains T1 to T20, T1 to T15 come from the three upstream services of payment, order and account respectively, and T16 to T20 come from the discount and reconciliation services, and the root cause node all points back to database D1, then the system will not retain 20 work orders that occupy processing resources from each other, but will output a global collaborative work order organized around D1, and will reference the original work order number as the evidence chain in the global collaborative work order.

[0102] This global collaborative work order differs from traditional summary emails; its core lies in the fact that it does not pile information together, but organizes the information structure around the root cause; that is, the collaborative work order takes the source of the fault as the main line, reducing the apparent work order to the affected area, timeline and collaborative actions, so that the receiving team only needs to analyze one fault situation, instead of repeatedly reading multiple similar work orders.

[0103] In an anomaly handling scenario, if the system is in a high-risk state but the root cause node has not yet converged to the candidate range that meets the preset confidence threshold, the cascaded interception unit can first perform a short-term buffer interception, wait for the topology information to be completed or for more symptoms to enter, and then decide whether to formally synthesize the main work order; if convergence still cannot be achieved after the buffer period, a collaborative work order is allowed to be generated in the form of multiple candidate root causes; if during the interception period, it is manually confirmed that a work order belongs to an independent event, such as the SMS channel failure being unrelated to the database failure, then the work order can be removed from the intercepted set and re-enter the regular distribution queue;

[0104] In the aforementioned D1 fault, the system included all 120 work orders related to D1 into the same associated work order cluster. Since the database administrator group was nearing its cognitive limit, the system triggered a high-risk state. The cascading interception unit suspended the entry of these 120 work orders into the regular to-do lists of the payment group, order group, risk control group, and discount group. After reading these work orders, the collaborative work order synthesis unit generated a global collaborative work order named "Core Transaction Database Write Link Anomaly," and attached the original alarm number, the list of affected business services, and the fault start time to the work order.

[0105] The purpose of this mechanism is to truly implement the risk assessment results into scheduling actions, thereby achieving a shift from dispatching orders one by one to dispatching orders based on root causes.

[0106] The collaborative work order synthesis unit is also used for:

[0107] The large language model is guided to generate situational awareness text by using a preset prompt word template that includes slots for speculative root cause information, slots for affected surface information, and slots for collaborative action instructions.

[0108] The situational awareness text is encapsulated as a global collaborative work order, which includes inferred root cause information, affected surface information, and collaborative action instructions that each processing entity needs to cooperate with.

[0109] This embodiment provides a situational awareness text generation mechanism for global collaborative work orders. Specifically, simply concatenating the root cause node name and several original work orders is still insufficient to directly guide cross-team collaboration. This is because in a major failure, different teams have different concerns: the root cause team needs to know what to investigate first, while affected teams need to know whether to suspend releases, freeze compensation tasks, or stop self-inspection. Therefore, this embodiment guides the generation of structured situational awareness text through preset prompt word templates, and then encapsulates it into a global collaborative work order.

[0110] To elaborate, the prompt word template is not an open-ended summary, but rather an engineered template with a defined output structure. The template contains at least three types of information slots: the first is inferred root cause information, used to identify the most likely source of the failure, the topological convergence relationship on which the judgment is based, and the current confidence level; the second is affected surface information, used to indicate which business domains, service links, and transaction scenarios have been impacted; and the third is collaborative action instructions, used to instruct different processing entities on the collaborative actions they need to perform at this time, rather than allowing each processing entity to infer on its own. This results in text that is executable and action-oriented.

[0111] A simplified sandbox example can be used to illustrate this; if the input includes root cause node D1 and work order clusters T1 to T20, the template will guide the model to output a structure similar to the following: It describes the suspected root cause as being located in the core transaction database master node D1, with related symptoms concentrated in payment, order, and account services; it describes the currently affected areas, including payment confirmation, refund write-back, and balance updates; and it provides action suggestions, such as the database administrator group prioritizing verification of master database I / O and connection status, the payment group suspending the triggering of order replenishment scripts, the order group suspending batch retry tasks, and the risk control group only monitoring for transaction backlogs. Such text is more effective in supporting on-site decision-making than simply listing 20 work orders.

[0112] The reason for template constraints is that technical defects such as divergent expression and confusion of key points are prone to occur in major failure scenarios. Templates can ensure that each collaborative work order is output with the same structure, which makes it easy for the shift leader to browse quickly and also makes it easy for the subsequent work order system, instant messaging group or emergency board to automatically extract fields. For example, the affected area field can be directly displayed on the failure board, and the collaborative action instruction field can be pushed down to the corresponding team channel.

[0113] In an anomaly handling scenario, if certain key fields cannot be reliably extracted from existing input, such as when the affected business entity is incomplete, the situational awareness text can explicitly indicate that the scope of impact is continuously expanding or currently only covers observed services, to avoid giving overly certain conclusions. If the collaborative action generated by the model conflicts with the preset security rules, such as suggesting the execution of a high-risk switching action but not meeting the approval conditions, the system will take the security rules as the standard and block or rewrite the action. If a slot in the template is empty, the system can automatically fill in the placeholder information to prevent the generation of an incomplete master work order.

[0114] In the aforementioned failure, the system generates the following situational awareness text based on the template: The root cause is suspected to be an abnormal write link of the core transaction database master node D1; the affected areas are payment confirmation, order posting, account balance update, and discount reversal write-back; the collaborative action instructions include the database administrator group immediately verifying the status of the master database disk and connection pool; the payment group suspends automatic retry to avoid duplicate writes; the order group stops manual order-by-order investigation and instead waits for the progress of the root cause to be synchronized; the risk control group only maintains traffic observation and does not add new independent diagnostic work orders; the system encapsulates this text into the body and structured fields of a global collaborative work order;

[0115] The purpose of this mechanism is to elevate fault information from a set of multiple original symptoms into a situation description that can be collaboratively executed, thereby achieving a standardization of fault handling language and a clarity of action instructions;

[0116] The dynamic scheduling and synthesis module also includes:

[0117] The intelligent routing unit is used to send the global collaborative work order to the target processing entity corresponding to the root cause node, and copy the global collaborative work order to the affected business entities obtained by parsing the tag information contained in the topology node corresponding to the associated work order cluster, so as to synchronize the fault status and prevent the affected business entities from performing independent troubleshooting actions.

[0118] This embodiment provides an intelligent routing mechanism for global collaborative work orders. Specifically, after the situational awareness text has been generated, if the ordinary mass sending method is still used, all teams may regard themselves as the main responsible party or continue to start independent investigations, causing the aforementioned folding mechanism to fail. Therefore, this embodiment further distinguishes between two types of routing roles: main sender and copy sender, so that the root cause team can assume the main responsibility for the closed loop, while the affected business entities mainly focus on synchronization and cooperation.

[0119] To elaborate, the intelligent routing unit reads the target processing entity corresponding to the root cause node and sends the global collaborative work order to that entity. The meaning of sending the order to the entity is not only message notification, but also setting the team as the main person in charge of the work order, the main updater of the event clock, and the main feedback party of the handling status. For example, when the root cause node is the database master node D1, the database administrator group is set as the main sender, and it has the main authority to update the root cause analysis, execute troubleshooting actions, and close events in the work order system.

[0120] At the same time, the system reverse-analyzes the affected business entities based on the associated work order clusters and copies the same collaborative work order to these entities. The copying is not to allow them to conduct parallel investigations, but to unify and synchronize the fault status, so that they stop issuing duplicate orders, stop investing manpower in the wrong direction, and execute the cooperative tasks according to the collaborative actions.

[0121] A simplified example can be used to illustrate this: If a work order cluster involves a payment group, an order group, and a risk control group, and the root cause node belongs to the database administrator group, then the work order is sent to the database administrator group as the primary recipient, and copied to the payment group, the order group, and the risk control group. After receiving the work order, the payment group will not continue to examine the application code in detail, but will pause automatic retry according to the instructions of the master work order; the order group will stop manually processing each order; the risk control group will remain under observation and will not create new independent fault tickets.

[0122] This step is a further implementation of the text synthesis in the previous stage; because collaborative text is used to output structured fault status information, and intelligent routing is used to clarify the information receiving entity, the responsible entity, and the collaborating entity; only when the two are combined can the system truly form a single entry point for handling at the organizational level.

[0123] In an exception handling scenario, if the root cause node corresponds to multiple potentially handling entities, such as a database issue involving both the storage group and the database administrator group, the system can designate one primary recipient according to preset priorities, and another as a high-priority copy recipient, marking the coordinating primary responsibility pending confirmation in the work order; if the number of affected business entities is too large, such as involving more than ten upstream services, the system can merge teams within the same business domain into the same copy group to avoid overloading the notification recipients again; if an affected team still attempts to initiate an independent investigation work order after receiving the notification, the system can identify the association between the work order and the existing global collaborative work order through work order rules, and prompt the system to merge it into the existing event;

[0124] In the aforementioned evening clearing failure, the system wrote a global collaborative work order for the core transaction database to "Link Anomaly," which was sent to the database administrator group and copied to the payment R&D group, order R&D group, account group, risk control group, and operations shift leader. Upon receiving the work order, the database administrator group became the sole responsible party for handling the issue. The payment group suspended automatic retry as required by the work order. The order group stopped checking each order individually and focused on the recovery progress. The risk control group only retained traffic monitoring. In this way, the information sources of each team were unified into the same work order, and different conclusions were no longer derived from their respective alarms.

[0125] The purpose of this mechanism is to clarify the boundaries of primary responsibility and cooperation, thereby achieving single-source information and convergent organizational actions during a failure.

[0126] The data receiving module includes:

[0127] The streaming data parsing unit is used to receive real-time alarm streaming data and extract error codes and timestamps from the real-time alarm streaming data to generate real-time work order data;

[0128] The topology building unit is used to receive configuration management database data and link tracing data, and to build system topology diagram data based on the configuration management database data and link tracing data.

[0129] This embodiment provides a refined implementation mechanism for a data receiving module. Specifically, if the input data source itself is incomplete or has an inconsistent structure, subsequent semantic clustering, topology penetration, and scheduling switching are prone to distortion. Therefore, this embodiment generates real-time work order data through a streaming data parsing unit and generates system topology data that can be used for fault propagation analysis through a topology construction unit.

[0130] In detail, the streaming data parsing unit interfaces with the monitoring platform, log platform, and application performance management alarm bus to convert continuously arriving raw alarm streams into real-time work orders in a unified format. Raw alarms typically include fields such as alarm title, body, error code, occurrence time, source service, instance address, and priority. The streaming data parsing unit extracts at least the error code and timestamp, and can further supplement it with service identifiers and environment tags to form a standard work order object that is easy for subsequent modules to process. For example, a raw log entry for payment service: SQLState08S01, transaction commit failed, 21:03:15, after parsing, can be converted into a real-time work order with service name = payment-service, error code = 08S01, and timestamp = 21:03:15.

[0131] Based on this, the topology building unit receives configuration management database data and link tracing data. Configuration management database data is used to provide static attribution relationships, such as the order service belonging to the transaction domain, deployed in data center A, and dependent on the payment routing service. Link tracing data is used to provide runtime call relationships, such as the order service calling the payment routing service during the current time period, and the payment routing service calling the account service and database D1. The former is used to represent static service dependencies, and the latter is used to represent the actual call chain at runtime. The topology graph constructed by combining the two has both structural stability and can reflect runtime path changes, making it more suitable for cascading fault analysis.

[0132] In a specific application scenario, suppose the configuration management database records nodes N1 for order services, N2 for payment services, and N3 for database D1, with the relationship N1 depending on N2 and N2 depending on N3; and the link tracing data shows that there is a path where N2 calls the risk control service N4 within the last 5 minutes; then the constructed topology graph not only retains the main chain N1→N2→N3, but also supplements the runtime edge N2→N4; in this way, when risk control anomalies occur independently, the system will not mistakenly determine that they are caused by D1; and when anomalies related to N1, N2, and N3 occur together, the main propagation chain can be accurately identified.

[0133] This step also exposes the shortcomings of traditional static configuration tables; if only the configuration management database is relied upon, it may not be able to reflect real-time dependency changes caused by canary releases, temporary bypasses, and dynamic scaling; if only link data is relied upon, potential dependencies may be missed during low traffic. Therefore, this embodiment uses both in combination to improve the completeness and timeliness of the topology diagram.

[0134] In an anomaly handling scenario, if an alarm lacks an error code, the stream data parsing unit can generate a minimum available work order based solely on the text and timestamp, and mark it as a missing code. If the timestamp is abnormal, the receiving time can be used as a substitute reference while retaining the original fields. If the configuration management database data is outdated and the tracing shows that there are no newly registered services, the topology building unit can first include it in the topology graph as a temporary node and mark it as a node to be archived in the graph. If the tracing is interrupted for a short time, the system can revert to the most recent stable topology snapshot to avoid root cause prediction failure due to topology holes.

[0135] In the aforementioned payment platform failure, the monitoring bus received multiple alarms between 21:03 and 21:05. The stream data parsing unit extracted error codes, timestamps, and service names from these alarms and generated standardized real-time work orders. At the same time, the topology building unit read the service dependencies of the payment domain from the configuration management database and the actual call chain of the most recent 10 minutes from the link tracing system. This allowed them to construct a topology structure in which the order service, payment service, account service, and discount service all depend on database D1. This provided a basis for identifying multiple service anomalies caused by the same underlying node.

[0136] The purpose of this mechanism is to provide a standardized, associative, and traceable input base for subsequent analysis, thereby enabling the transformation from heterogeneous alarm sources to a unified fault map.

[0137] Example 2:

[0138] The system also includes:

[0139] The status update module is used to receive the closed-loop processing results of the target processing entity for the global collaborative work order, and update the status data of the processing entity based on the closed-loop processing results, so as to adjust the evaluation benchmark of the cognitive load assessment module in subsequent time periods.

[0140] This embodiment provides a status update mechanism. Specifically, if the system only makes a one-time judgment when a fault occurs, without correcting the entity status data based on the closed-loop result, the cognitive load assessment is likely to remain at the static experience level for a long time and cannot reflect the reality of changes in team capabilities, shift structure, and fault types over time. Therefore, this embodiment introduces a status update module after the global collaborative work order is closed to continuously correct the subsequent assessment benchmark.

[0141] To elaborate, the status update module receives the closed-loop results submitted by the target processing entity for the global collaborative work order. These results can include at least the following information: whether the actual root cause is consistent with the prediction, troubleshooting time, number of participants, whether cross-team escalation occurred, whether duplicate work orders were generated, and final recovery time. The system does not perform complex theoretical calculations on these results, but rather transforms them into empirical benchmarks that can be used for subsequent scheduling. For example, if a certain type of database write anomaly usually requires joint handling by the database administrator group and the storage group, and relying solely on the database administrator group often prolongs the recovery time, then the next time a similar root cause is encountered, the system can increase the load level of the event in advance during the cognitive load assessment and synchronously include the storage group in the intelligent routing.

[0142] A simplified sandbox can be used to illustrate this; suppose a global collaborative work order G1 is ultimately closed within 40 minutes by the database administrator group, during which one new collaborative object is added, and no duplicate independent work orders are generated, indicating that the previous estimate of the database administrator group's capacity is relatively reasonable; another work order G2, although also judged as a database anomaly, is urgently pulled into the middleware group during actual processing, and the total processing time increases significantly, indicating that there are still differences in complexity within the category of database anomalies; the status update module can then record the fault characteristics corresponding to G2 into the processing entity status data, so that subsequent similar events can trigger high-risk judgments or collaborative strategies earlier;

[0143] This mechanism provides feedback and compensation for all previous steps. The aforementioned solution addresses how to optimize scheduling at the current moment, while the closed-loop update addresses how to make the next scheduling more closely reflect the actual resource consumption. Without this feedback process, the system is likely to continue using historical benchmarks that are not in the current cycle after shift changes, new system launches, or team responsibilities are adjusted, leading to deviations in the assessed processing capacity.

[0144] In an exception handling scenario, if the closed-loop result is incomplete, such as only closing the work order without supplementing the actual root cause, the status update module can first update the most basic completion time and participating object information, and mark the root cause field as pending entry to avoid the entire record being discarded; if the closed-loop result is significantly inconsistent with the initial root cause prediction, the system does not directly overwrite the original model basis, but archives the case as a deviation sample separately for subsequent correction of topology mapping and prompt template; if an event skips the system flow due to emergency manual takeover, the status update module can also supplement the entry through post-event import to maintain the continuity of status data;

[0145] After the aforementioned D1 fault handling was completed, the database administrator group reported in the global collaborative work order: the actual cause was a surge in storage latency on the database master node, the participants included 2 people from the database administrator group and 1 person from the storage group, the total recovery time was 35 minutes, and no new independent investigation work orders were created for the payment group and order group during this period; the status update module updated the database administrator group's load profile of the abnormal write link of the master database accordingly, and recorded the high correlation of the storage group in such events; when similar symptoms reappear several days later, the system can more quickly determine that the event belongs to the high cognitive load type and tighten the distribution strategy in advance;

[0146] The purpose of this mechanism is to record the results of each fault handling as a basis for subsequent evaluation, thereby enabling continuous adaptive updates of the cognitive load model and scheduling strategy.

[0147] It should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the technical solutions of the present invention.

Claims

1. A maintenance work order workflow management system based on a large language model, characterized in that, The system includes: The data receiving module is used to receive real-time work order data, configuration management database data, link tracing data, and processing entity status data corresponding to the operation and maintenance terminal; and to generate system topology data based on the configuration management database data and the link tracing data. The semantic and temporal clustering module is used to call a pre-configured large language model to perform semantic vectorization processing on the real-time work order data, and to perform clustering based on a preset time window dynamically generated based on historical alarm frequency to generate associated work order clusters. The topology penetration and root cause prediction module is used to map the associated work order cluster to the system topology graph data, extract the node features and edge weights contained in the system topology graph data to construct an input feature vector matrix, and calculate the propagation path through a preset graph neural network to determine the root cause node and the target processing entity corresponding to the root cause node. The cognitive load assessment module is used to calculate the current concurrent processing capacity of the target processing entity based on the processing entity status data, and to determine the queue overflow risk status based on the current concurrent processing capacity. The dynamic scheduling and synthesis module is used to switch between independent distribution mode and multi-work order folding synthesis mode based on the queue overflow risk status. In the multi-work order folding synthesis mode, the module calls the large language model to extract information from the root cause node and the associated work order cluster to generate the corresponding global collaborative work order and perform flow scheduling.

2. The operation and maintenance work order flow management system based on a large language model according to claim 1, characterized in that, The semantic and temporal clustering module includes: The semantic vectorization unit is used to extract the textual description features of the real-time work order data through the word embedding technology of the large language model, and to convert the textual description features into semantic vectors. The density clustering unit is used to perform clustering analysis on the semantic vector within the preset time window based on the density clustering algorithm, so as to identify the related work order clusters with the same root cause features.

3. The operation and maintenance work order flow management system based on a large language model according to claim 1, characterized in that, The topology penetration and root cause prediction module includes: The mapping unit is used to extract feature nodes from the associated work order cluster and align the feature nodes with the topology nodes contained in the system topology graph data; A spatial convolutional unit is used to extract features from the aligned system topology graph data using a preset spatial graph convolutional network to generate a topology feature representation. The reverse tracing unit is used to calculate the transition probability of the topological nodes based on a preset random walk algorithm, and to calculate the root cause probability score of each topological node in combination with the topological feature representation, and to determine the topological node with the highest root cause probability score as the root cause node.

4. The operation and maintenance work order flow management system based on a large language model according to claim 1, characterized in that, The cognitive load assessment module includes: The capacity calculation unit is used to calculate the current concurrent processing capacity of the target processing entity based on a preset queuing theory model and the processing entity state data. The processing entity state data includes historical processing efficiency, current number of unclosed work orders, and a cognitive load matrix composed of historical processing time and manpower time consumption characteristics of different types of work orders. The risk determination unit is used to determine the queue overflow risk state as a high-risk state when the number of work orders in the associated work order cluster is greater than the current concurrent processing capacity; and to determine the queue overflow risk state as a low-risk state when the number of work orders in the associated work order cluster is less than or equal to the current concurrent processing capacity.

5. The operation and maintenance work order flow management system based on a large language model according to claim 4, characterized in that, The dynamic scheduling and synthesis module includes: The normal distribution unit is used to trigger the independent distribution mode and independently route the work orders in the associated work order cluster when the queue overflow risk status is the low-risk status. The cascading interception unit is used to trigger the multi-work order folding and synthesis mode and intercept all work orders in the associated work order cluster when the queue overflow risk state is the high-risk state. The collaborative work order synthesis unit is used to call the large language model to read the root cause node and the intercepted associated work order cluster in the multi-work order folding synthesis mode, so as to synthesize the global collaborative work order.

6. The operation and maintenance work order flow management system based on a large language model according to claim 5, characterized in that, The collaborative work order synthesis unit is also used for: The large language model is guided to generate situational awareness text by using a preset prompt word template that includes slots for speculative root cause information, slots for affected surface information, and slots for collaborative action instructions. The situational awareness text is encapsulated into the global collaborative work order, wherein the situational awareness text includes inferred root cause information, affected surface information, and collaborative action instructions that each processing entity needs to cooperate with.

7. The operation and maintenance work order flow management system based on a large language model according to claim 6, characterized in that, The dynamic scheduling and synthesis module further includes: The intelligent routing unit is used to send the global collaborative work order to the target processing entity corresponding to the root cause node, and to copy the global collaborative work order to the affected business entities obtained by parsing the tag information contained in the topology node corresponding to the associated work order cluster, so as to synchronize the fault status and prevent the affected business entities from performing independent troubleshooting actions.

8. The operation and maintenance work order flow management system based on a large language model according to claim 1, characterized in that, The data receiving module includes: The streaming data parsing unit is used to receive real-time alarm streaming data and extract error codes and timestamps from the real-time alarm streaming data to generate the real-time work order data; The topology building unit is used to receive configuration management database data and link tracing data, and to build the system topology map data based on the configuration management database data and the link tracing data.

9. The operation and maintenance work order flow management system based on a large language model according to claim 1, characterized in that, The system also includes: The status update module is used to receive the closed-loop processing result of the target processing entity for the global collaborative work order, and update the status data of the processing entity based on the closed-loop processing result, so as to adjust the evaluation benchmark of the cognitive load assessment module in subsequent time periods.

Images