Intelligent operation and maintenance, fault classification response and health management method for heterogeneous IT systems

Abstract

The present application belongs to the technical field of fault prediction and health management, and particularly relates to an intelligent operation and maintenance, fault grading response and health management method for a heterogeneous IT system. The method collects performance indicators, logs, alarms and inspection change records of small computers, storage, servers, databases, middleware clusters and backup systems, converts them into unified event, indicator and state objects, maps them according to resource bearing, access blocking, task backlog, configuration drift and data protection semantic categories, and constructs a cross-stack dependency semantic graph. A dynamic performance baseline is established based on the running context, a node offset, propagation order and health offset chain are calculated, and a fault type, grade, root cause candidate node and health portrait are generated in combination with a rule engine. The method can identify slight abnormalities that have not exceeded the limit in a dispersed platform as a fault precursor chain with a dependency path, thereby enhancing the explainability and continuity of fault prediction and health management.

Description

Technical Field

[0001] This invention belongs to the field of fault prediction and health management technology, specifically involving intelligent operation and maintenance, fault classification response and health management methods for heterogeneous IT systems. Background Technology

[0002] The operation and maintenance of heterogeneous IT systems is typically accomplished through a combination of equipment monitoring, database monitoring, middleware monitoring, backup monitoring, and manual inspections. The most common approach involves deploying data collection scripts or enabling vendor-provided monitoring interfaces on minicomputers, enterprise-level storage arrays, multi-platform servers, databases, middleware clusters, and backup programs. Data such as CPU usage, memory, disk capacity, I / O latency, connection count, session count, thread pool usage, backup task status, and log alerts are collected periodically. A centralized monitoring platform then establishes monitoring items based on device type. For quantifiable metrics, conventional solutions often use fixed thresholds, tiered thresholds, or deviations from historical averages to identify anomalies. For logs and alerts, alert records are typically generated based on alert codes, severity levels, and keyword matching. For inspection results, maintenance personnel generate reports based on checklists and then manually enter anomalies into work orders or the inspection system. This approach achieves cross-platform data aggregation and basic alerting, but the data models of each platform retain their original semantics. The monitoring platform primarily handles data presentation and alert forwarding. Data from different sources is typically stored in separate columns according to device directory, application directory, or alarm directory after being entered into the database. There is a lack of semantic merging of metrics at the same object level, and alarm records are difficult to automatically associate with the corresponding storage volume, instance, service process, and backup object.

[0003] In terms of automated inspection and standardized report generation, conventional solutions typically pre-configure inspection templates, writing check items such as server resource utilization, storage capacity, database tablespaces, archived logs, middleware instance status, and backup task completion status into a rule table. The system calls scripts according to scheduled tasks to read the status of target objects, compares the results with preset standards, generates pass, alarm, or anomaly conclusions, and outputs daily, weekly, or monthly reports in a fixed format. For common alarms, the rule table binds notification methods and handling suggestions, such as restarting services, cleaning temporary files, expanding tablespaces, adjusting connection pool parameters, or patching. This implementation relies on operations personnel to pre-determine check items and judgment conditions. Rules are usually separated by single objects, single indicators, or single alarms. A few rules may reference multiple indicators within the same device, but it rarely incorporates the dependencies between storage volumes, database instances, middleware instances, server resources, and backup objects into the same judgment chain. Even if a centralized platform can display the operating curves of multiple platforms, the sequential changes between the curves still require manual judgment based on experience. Inspection reports can reflect local conditions, but they are difficult to explain the propagation order of anomalies between different platforms, and it is also difficult to put inspection conclusions and subsequent performance deviations into the same time chain.

[0004] In terms of performance monitoring and fault prediction, existing solutions store historical metrics in a centralized platform and calculate baselines on a daily, weekly, and monthly basis to identify trends such as increased resource utilization, longer response times, and extended task durations. Some solutions use statistical or machine learning models to detect anomalies in metric sequences and then classify faults based on alarm levels. For fault response in heterogeneous systems, conventional solutions often input prediction results or alarm results into a work order process; low-level alarms are handled by automated scripts, while higher-level alarms are handled by remote or on-site personnel. Because the sampling frequency, metric units, log granularity, alarm meanings, and maintenance window records are inconsistent across different platforms, existing baselines are mostly established based on single devices or single software instances, making it impossible to directly determine whether a fluctuation in a metric is caused by business peaks, backup tasks, patch upgrades, parameter changes, or a precursor to a fault. If an artificial intelligence model only receives the normalized sequence of indicators, it is easy to lose the dependency semantics between the original objects. The abnormal conclusions output by the model are difficult to explain from which running object the abnormality started, along which call or mount relationship it propagated, or whether it was affected by the backup window or change window. Subsequent personnel still need to re-check the object relationships and historical records.

[0005] The main technical problem with existing technologies is that multi-source operational data in heterogeneous information technology systems lacks unified semantic constraints and cross-stack dependency expressions. This leads to the inability to identify multiple minor anomalies that have not yet exceeded fixed thresholds as the same chain of precursory failures. Storage I / O latency, database wait events, middleware thread pool usage, server resource fluctuations, and backup task latency may all be within acceptable ranges when observed individually. However, if these data continuously shift along business access, storage mounting, instance deployment, call relationships, and backup attribution relationships, they can already characterize a degradation in system health. Because conventional solutions do not combine semantic mapping, dynamic performance baselines, and dependency propagation order, the system can only trigger a response after a single point of failure or alarm accumulation, making it difficult to generate interpretable fault prediction results and health profiles in a timely manner. As the number of alarms increases, anomalies from multiple platforms can overlap within the same time period. Root cause candidate nodes are easily influenced by the order of most recent alarms, highest-level alarms, or manual experience, causing inconsistencies between fault prediction results and the actual propagation path, and making subsequent tiered responses lack stable data support. This problem directly affects anomaly aggregation, root cause screening, and tier judgment in the fault prediction and health management process, preventing the continuous expression of system operating status. Summary of the Invention

[0006] The purpose of this invention is to provide a method for intelligent operation and maintenance, fault classification response, and health management of heterogeneous IT systems, which can effectively solve the problems mentioned in the background art.

[0007] To achieve the above objectives, the technical solution adopted by the present invention is as follows: The method for intelligent operation and maintenance, fault classification response and health management of heterogeneous IT systems includes: collecting performance indicators, logs, alarms, inspection results and change records of minicomputers, storage, servers, databases, middleware and backup systems, and converting them into unified event objects, unified indicator objects and unified status objects; Based on the semantic mapping relationship of indicators, data from different sources are classified into semantic categories such as resource carrying capacity, access blocking, task backlog, configuration drift, and data protection. Construct a cross-stack dependency semantic graph based on business access, storage mounting, instance deployment, middleware invocation, and backup attribution; A dynamic performance baseline is established based on the runtime context, the baseline offset and propagation order of each node are calculated, and the fault prediction results and health profiles are generated by combining the cross-stack dependency semantic graph.

[0008] Preferably, the conversion process of the unified event object, unified indicator object, and unified state object includes: configuring the source identifier, sampling time, object level, indicator granularity, and state validity period; Parse the exception codes, alarm levels, change actions, and inspection conclusions in the log text into associable fields; Align performance metrics by sampling time windows; Data that cannot be directly aligned is written into the same object index according to the affiliation of device objects, software instances, and business links, so that multiple types of state data of the same running object can be referenced when building dependency maps later.

[0009] Preferably, the process of forming the semantic mapping relationship of the indicators includes: establishing mapping items between indicator names, measurement units, sampling periods, normal range sources and business meanings for the original indicators of different platforms; Storage input / output latency, database wait events, middleware thread pool usage, server resource utilization, and backup task time are categorized into corresponding semantic categories. Set source weights and time credibility for indicators within the same semantic category; When multiple source metrics conflict within the same time window, the semantic state value is determined based on the object level, sampling completeness, and most recently changed state, and the semantic state value is bound to the corresponding node or edge of the cross-stack dependency semantic graph.

[0010] Preferably, the construction process of the cross-stack dependency semantic graph includes: using servers, storage volumes, database instances, middleware instances, backup tasks, and business access objects as graph nodes, and using mount relationships, connection relationships, call relationships, backup object ownership relationships, and change impact relationships as directed edges; Configure the propagation direction, propagation delay interval, and affected semantic category for each directed edge; When the same running object has multiple dependency paths, the primary dependency path is determined based on the access link priority, backup link ownership, and historical fault propagation records. The node state, edge state, and the dynamic performance baseline result are written together into the graph attributes for subsequent fault chain generation.

[0011] Preferably, the process of sampling alignment of the time window includes: determining the alignment window together with the business cycle, inspection cycle, alarm generation time and change execution time; Continuous indicators are represented by trend segments within a window, discrete alarms are represented by occurrence and recovery times, and inspection results are represented by the effective interval of the conclusion. When the same object has missing data in adjacent windows, a missing marker is generated using the most recent valid state from the same source, the state of the same layer object, and the state dependent on the upstream state, without replacing the original sample with the filler value. Using missing markers as input constraints for calculating the dynamic performance baseline avoids erroneous offsets caused by differences in heterogeneous sampling frequencies.

[0012] Preferably, the process of determining the semantic state value includes: first generating node candidate states based on the object level to which the indicator belongs, and then generating a state confidence interval based on the indicator source weight and time credibility; When storage latency, database wait, middleware backlog, and backup time change in the same direction within the same semantic link, multiple node candidate states are combined into a cross-node semantic state. When the cross-node semantic state matches a maintenance window, patch upgrade record, or parameter change record, an interpretable fluctuation identifier is written into the semantic state value. When a mismatch occurs, the anomaly propagation flag is retained and passed on to subsequent calculations in fault prediction and health management.

[0013] Preferably, the process of determining the primary dependency path includes: enumerating the paths from the business access object to the database instance, middleware instance, server, and storage volume; The path correlation is calculated based on the current running status of the path nodes, the frequency of historical failure chains, the ownership of backup objects, and the scope of impact of changes. When there is overlap in path correlation, candidate paths are selected based on the order of index offsets before the failure occurred. The path that covers the most anomaly semantic categories and conforms to the direction of directed edge propagation among the candidate paths is determined as the primary dependency path, and other paths are reserved as bypass verification paths in the cross-stack dependency semantic graph.

[0014] Preferably, the process of establishing the dynamic performance baseline includes: dividing the operating context according to weekdays, non-weekdays, peak business periods, backup windows, inspection windows, patch upgrade windows, and parameter change windows; Establish node baselines and edge baselines separately within each runtime context; Set baseline switching conditions for state transitions of the same node across different contexts; When the real-time state enters a new running context, the corresponding baseline is first selected according to the baseline switching conditions, and then the node offset magnitude, offset duration and offset direction are calculated. The node offset magnitude, offset duration, and offset direction are combined with the main dependency path to generate a sortable healthy offset chain.

[0015] Preferably, the process of generating the health offset chain includes: starting from the graph node where the earliest baseline offset occurs, reading the offset status of subsequent nodes and directed edges along the main dependency path; When the offset direction, offset duration, and propagation delay interval of a subsequent node satisfy the propagation constraints of the directed edge, the corresponding node is added to the same healthy offset chain. When there are synchronous offsets of the same semantic category in the bypass verification path, the link credibility of the corresponding health offset chain is increased; When the offset order of the bypass verification path contradicts that of the main dependency path, the health offset chain is split into multiple candidate chains, and the root cause candidate node and propagation evidence field are retained respectively.

[0016] Preferably, the process of generating the fault prediction results and health profile includes: inputting the link credibility, root cause candidate node, abnormal propagation identifier, explainable fluctuation identifier and data missing marker of each candidate chain into the fault prediction model to obtain the fault type and initial level; Then, the initial level is corrected by verifying the maintenance window, change records, backup verification results, and disaster recovery linkage status through the rule engine. The corrected fault type, level, root cause candidate node, affected dependency path, relevant baseline offset and handling trigger conditions are written into the health profile and saved in chronological order as a continuous health management record for heterogeneous IT systems.

[0017] Compared with the prior art, the beneficial effects of the present invention are as follows: 1. By converting performance metrics, logs, alarms, inspection results, and change records from minicomputers, storage devices, multi-platform servers, databases, middleware clusters, and backup systems into unified event objects, unified indicator objects, and unified status objects, and mapping them according to semantic categories such as resource capacity, access blockage, task backlog, configuration drift, and data protection, runtime data can be separated from its original platform name and alarm format and enter the same semantic space. Furthermore, a cross-stack dependency semantic graph is constructed based on business access, storage mounting, instance deployment, middleware calls, and backup attribution relationships. Dynamic performance baselines are established under different runtime contexts, and the system can generate health offset chains according to baseline offset, offset duration, propagation direction, and propagation order. Thus, multiple individual, non-limited minor anomalies can be grouped into a fault precursor chain with dependency paths and time order. Fault prediction results can simultaneously include fault type, level, root cause candidate nodes, and affected dependency paths, solving the problems of delayed fault precursor identification and root cause location offset under decentralized monitoring conditions.

[0018] 2. By setting source identifiers, object levels, state validity periods, sampling alignment windows, and missing data flags during data transformation, data misalignments caused by different sampling frequencies, log granularities, and inspection conclusion effective times across heterogeneous platforms can be preserved as computational constraints, rather than simply being filled in as false continuous data. By adding source weights, time credibility, explainable fluctuation flags, and anomaly propagation flags to semantic state values, and using maintenance windows, patch upgrade records, parameter change records, bypass verification paths, and disaster recovery linkage status for verification, health profiles can distinguish between explainable fluctuations caused by plan changes and anomalous offsets propagating on the dependency chain. By continuously saving corrected fault types, levels, root cause candidate nodes, related baseline offsets, and handling trigger conditions, subsequent fault prediction and health management can reuse historical records along the same data structure, reducing duplicate judgments caused by differences in data formats and missing object relationships. Attached Figure Description

[0019] Figure 1 This is an overall flowchart of the intelligent operation and maintenance, fault prediction and health management method for heterogeneous information technology systems of the present invention; Figure 2 This is a flowchart of the unified object conversion and semantic state generation process of the present invention; Figure 3 This is a flowchart of the cross-stack dependency semantic graph construction and main dependency path filtering process of the present invention; Figure 4 This is a flowchart of the dynamic performance baseline, health offset chain, and fault health profile generation process of the present invention. Detailed Implementation

[0020] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0021] Please refer to Figure 1 This embodiment provides a method for intelligent operation and maintenance, fault classification response, and health management of heterogeneous IT systems. It runs on a centralized operation and maintenance data processing platform. This platform provides access interfaces for collecting data from minicomputers, storage, servers, databases, middleware, and backup systems. It receives data such as CPU usage, memory usage, disk capacity, storage I / O latency, database wait events, middleware thread pool usage, connection pool status, backup task time, backup verification results, log anomaly codes, alarm levels, inspection conclusions, and change records as raw operational data. After access, the data is not directly saved in isolation as in the original device directory. Instead, it is converted into unified event objects, unified indicator objects, and unified status objects. Unified event objects carry alarms, logs, inspection anomalies, and change actions. Unified indicator objects carry continuously sampled performance data. Unified status objects carry the operational status of device instances, software instances, backup objects, and business links within a specified validity period. The method then categorizes data from different sources into resource carrying capacity, access blocking, task backlog, configuration drift, and other categories based on a preset indicator semantic mapping relationship. Data protection semantic categories are defined, and a cross-stack dependency semantic graph is constructed according to business access relationships, storage mounting relationships, instance deployment relationships, middleware call relationships, and backup ownership relationships. This ensures that each running object has a node identity, semantic state, upstream and downstream dependencies, and time state. Subsequently, a dynamic performance baseline is established based on weekdays, non-weekdays, business peaks, backup windows, inspection windows, patch upgrade windows, and parameter change windows. The baseline offset, offset direction, offset duration, and offset propagation order of each node relative to the current running context are calculated. If multiple offsets that have not yet exceeded the limit appear consecutively along directed edges in the cross-stack dependency semantic graph, a healthy offset chain is generated. The healthy offset chain, candidate root cause nodes, explainable fluctuation identifiers, anomaly propagation identifiers, and data missing markers are jointly input into the fault prediction process to generate fault type, level, affected dependency paths, and continuous health profile. This embodiment defines the technical meaning of running data through unified object conversion, semantic classification, dependency graph construction, and dynamic baselines, enabling minor anomalies in the distributed platform to be organized into a fault precursor chain with a propagation order, avoiding fault judgment only after a single point threshold is exceeded.

[0022] In this embodiment, the dynamic performance baseline uses graph nodes as the smallest computational object. For the normal fluctuations of the same node under different operating contexts, the baseline mean and fluctuation scale are saved separately. After real-time sampling enters the processing, the operating context is first determined based on the current time, task type, inspection status, and change status. Then, the node offset is normalized and calculated. The node offset is expressed by the following formula: ; in, Represents a node In the time window The overall offset value relative to the current runtime context. Represents a node The number of semantic metrics bound. Indicates the first The source weight of each indicator Indicates the first Each indicator within the time window The reliability of the time frame within the period Indicates the first The current sampled value of each indicator, Indicates the first In the current operating context, each metric The baseline value below, Indicates the first The baseline fluctuation scale of each indicator in the current operating context This represents a smoothing measure to prevent the denominator from being zero. Physically, it converts the deviation of metrics from different sources relative to their respective context baselines into comparable offsets at the same node level. For example, a database instance node might be bound to two metrics: database wait events and connection pool usage. Source weights of each indicator , No. Source weights of each indicator , No. Each indicator within the time window Time reliability , No. Each indicator within the time window Time reliability , No. Current sample value of each indicator , No. In the current operating context, each metric Baseline value , , No. Current sample value of each indicator , No. The baseline value of each metric in the current operating context , No. Baseline fluctuation scale of each indicator in the current operating context , hour, The two offsets together result in an approximate value of 2.10, indicating that the node forms a positive offset in the current context that requires propagation verification.

[0023] In a preferred embodiment, reference Figure 2 The unified object conversion process configures source identifier, sampling time, object level, indicator granularity, and status validity period for HP minicomputers, Sanpak storage, multi-platform servers, Oracle databases, middleware clusters, and backup systems. The source identifier distinguishes objects with the same indicator name on different platforms; the sampling time establishes cross-platform time relationships; the object level determines whether the data belongs to a device, volume, instance, process, task, or business chain; the indicator granularity identifies whether the indicator is based on continuous sampling, discrete events, manual inspection conclusions, or change records; and the status validity period prevents a single alarm or inspection conclusion from indefinitely participating in subsequent judgments. Log text is then included in the conversion process. The system extracts exception codes, alarm levels, exception descriptions, recovery flags, and change actions using parsing rules. Continuous performance indicators retain their original sampling time and period when entering the conversion process. Inspection conclusions record their source and effective period when entering the conversion process. Data that cannot be directly time-aligned is not replaced with mean interpolation but is written to the same object index based on the attribution relationship between device objects, software instances, and business links. During subsequent dependency mapping, multiple types of status data for the same running object can be read simultaneously from the object index. This embodiment ensures that the original data forms a relatable representation under the same object level before entering fault prediction, avoiding the splitting of the same running object due to platform naming differences. The data field configuration for the unified running object is shown in Table 1.

[0024] Table 1. Data Field Configuration Table for Unified Runtime Object ; Table 1 illustrates the source, processing method, and written object of each field in the unified object transformation. The source identifier and object level jointly establish a cross-platform object index, the sampling time and state validity period jointly constrain the time range for state participation in the calculation, and the index granularity and semantic category jointly determine how data enters the dynamic performance baseline, cross-stack dependency semantic graph, or fault prediction process.

[0025] Furthermore, the time window alignment process does not use a single fixed cycle, but rather uses the business cycle, inspection cycle, alarm generation time, and change execution time to jointly determine the alignment window. Continuous indicators are represented by trend segments within the window, discrete alarms are represented by the occurrence time and recovery time, inspection results are represented by the effective interval of the conclusion, and change records are represented by the interval consisting of change start, change completion, and rollback confirmation. When the same object has missing data in adjacent windows, the processing reads the most recent valid state from the same source, the comparison state of objects at the same level, and the dependent upstream state to generate a missing marker. The missing marker is included in the dynamic performance baseline calculation along with the unified object. During the calculation, the imputation value is not used to replace the original sample to avoid mistaking the collection gap as a stable state or abnormal recovery. Data completeness and missing degree are expressed by the following formula:

[0026] ; in, Represents a node In the time window Sampling integrity within the range, Represents a node In the time window The degree of data missing within, Represents a node The Semantic indicators in the time window This indicates whether there are valid original samples. A value of 1 indicates that there are valid samples, and a value of 0 indicates that there are no valid samples. This indicates the number of semantic metrics bound to a node. Physically, it translates the differences in heterogeneous sampling frequencies into baseline calculation constraints. For example, if a storage volume node is bound to four metrics within a window, where input / output latency, queue depth, and capacity utilization are effectively sampled, but link error counts are missing, then... , Subsequent health offset chain calculations will mark the offset evidence of this node as having missing constraints. This embodiment retains the missing markers instead of filling in the data, so that inconsistent sampling on heterogeneous platforms will not form an incorrect baseline offset.

[0027] In a preferred embodiment, the semantic mapping relationship of indicators is composed of indicator name, measurement unit, sampling period, source of normal interval, and business meaning. Mapping items are established for indicators with similar meanings but different names across different platforms. Storage input / output latency, disk queue, and controller load are categorized into resource carrying or access blocking semantic categories; database wait events, lock waits, and archive write latency are categorized into access blocking semantic categories; middleware thread pool usage, request queue length, and connection pool exhaustion records are categorized into task backlog semantic categories; server configuration changes, database parameter changes, and middleware patch upgrade records are categorized into configuration drift semantic categories; backup task time, backup copy verification results, and recovery point continuity status are categorized into data protection semantic categories. For the same semantic... Multiple source metrics under a category are assigned source weights and time reliability. When multiple source metrics conflict within the same time window, the semantic state value is determined based on object level, sampling completeness, and recent change status. For example, if storage volume latency increases slightly while server CPU usage remains stable, the resource carrying semantic state will not be offset by server metrics. If the same database instance experiences wait event fluctuations within the patch upgrade window, an interpretable fluctuation flag is added to the semantic state value. If there is no basis for maintenance or change, an anomaly propagation flag is added and bound to the corresponding node or edge in the cross-stack dependency semantic graph. This embodiment uses semantic mapping to enable metrics from different platforms to participate in calculations under the same technical meaning, avoiding mixing data with the same name but different meanings or different names but the same meaning into a single curve.

[0028] In this embodiment, the semantic state value is first generated from the node candidate state at the object level to which the indicator belongs, and then the state confidence interval is generated from the source weight, time reliability, and sampling completeness. If storage latency, database wait, middleware backlog, and backup time change in the same direction within the same semantic link, the processing will synthesize multiple node candidate states into a cross-node semantic state. The semantic state calculation is expressed by the following formula: ; in, Represents a node In the time window Internal targeting semantic categories The semantic state value, Represents a node The middle belongs to the semantic category The set of indicators, This indicates the sampling completeness of the node within the time window. Indicates the first Candidate states after normalization of each indicator.

[0029] For example, a middleware instance has a thread pool occupancy candidate state of 0.7, a request queue candidate state of 0.8, source weights of 0.5 and 0.5 respectively, time confidence of 1 and 0.9 respectively, and a sampling completeness of 1. hour, The value is approximately 0.68. If a patch upgrade record exists for the node within the same time window, an interpretable fluctuation flag is written to the semantic state value. If no patch upgrade record exists and the upstream database waiting state is also in a positive offset, an anomaly propagation flag is written to the semantic state value. This embodiment enables the semantic state value to have source constraints, time constraints, and upstream and downstream propagation constraints, avoiding the generation of fault judgments based solely on a single indicator. The semantic category and cross-stack dependency binding relationship are shown in Table 2.

[0030] Table 2. Semantic Category and Cross-Stack Dependency Binding Relationship ; Table 2 illustrates the binding relationship between semantic categories and cross-stack dependency semantic graphs. Among them, access blocking and task backlog states are used to form propagation chains, configuration drift states are used to explain baseline offsets within the same window, and data protection states are used to provide backup verification and disaster recovery linkage constraints when fault level is generated.

[0031] In one embodiment, reference Figure 3 The cross-stack dependency semantic graph uses servers, storage volumes, database instances, middleware instances, backup tasks, and business access objects as graph nodes, and directed edges as mount relationships, connection relationships, call relationships, backup object ownership relationships, and change impact relationships. Mount relationships express the dependency of a server or database instance on a storage volume; connection relationships express the session dependency between a database instance and an application access object; call relationships express the request passing between a middleware instance and a database instance; backup object ownership relationships express the protection scope between a backup task and the database, file system, or business data; and change impact relationships express the impact of parameter changes, patch upgrades, and configuration adjustments on the state of nodes or edges. Each directed edge is configured with a propagation direction and propagation delay. The interval and the semantic category of the impact, for example, the directed edge from the storage volume to the database instance is configured to propagate the storage access blockage to the database wait event, and the directed edge from the database instance to the middleware instance is configured to propagate the database response delay to the middleware task backlog. When there are multiple dependency paths for the same running object, the processing determines the primary dependency path based on the access link priority, backup link affiliation and historical fault propagation records, and retains the other paths as bypass verification paths in the graph attributes. The node status, edge status and dynamic performance baseline results are all written into the graph attributes so that fault chains can be generated later. In this embodiment, business access, storage mounting, instance deployment, middleware invocation and backup affiliation no longer remain at the configuration list level, but become the calculation objects for judging the propagation of fault precursors.

[0032] Furthermore, the primary dependency path is determined through path enumeration and path affinity calculation. The process starts from the business access object, enumerates the reachable paths to the middleware instance, database instance, server, and storage volume, and reads the current node status, frequency of historical failure chains, backup object ownership, and scope of change impact for each path. The path affinity is expressed by the following formula: ; in, Representing a path In the time window Internal path relevance, Representing a path The number of times it appears in the historical failure chain Representing a path The set of semantic categories covered This represents the set of semantic categories with offsets within the current time window. Representing a path The matching value between the order of index offsets and the direction of directed edge propagation, ranging from 0 to 1. Representing a path The matching value between the backup object's ownership and the scope of impact of the change, ranging from 0 to 1. , , , This represents four weighting coefficients with a sum of 1. Physically, it means converting historical propagation experience, current semantic coverage, propagation order, and attribution relationship into a single path selection criterion. For example, if a path has appeared 3 times historically, covers 2 out of the current 3 types of offsets, its propagation order matching value is 0.8, and its attribution matching value is 0.6. , , , , hour, The value is approximately 0.70. If another candidate path only covers a type 1 offset and the propagation direction does not match, it will not be determined as the primary dependent path. This embodiment avoids determining the source of the fault solely based on the highest alarm or the most recent alarm by using path correlation.

[0033] In a preferred embodiment, when path correlations overlap or multiple path scores are close, the processing reads the order of index offsets from multiple time windows before the fault occurs, and uses the node with the earliest baseline offset as a candidate starting point. Then, it checks whether the offset direction, offset duration, and propagation delay interval of subsequent nodes satisfy edge attribute constraints along directed edges. Candidate paths that cover the most abnormal semantic categories and conform to the propagation direction are written into the main dependency path. Unselected paths are not deleted but saved as bypass verification paths. These bypass verification paths are used to provide synchronous offsets and reverse offsets in subsequent healthy offset chains. When verification information with or without offset, such as positive offsets in storage volume, database instance, and middleware instance, is provided, if the storage volume offset occurs earliest, followed by the database waiting offset, and then the middleware thread pool offset, and the offset interval falls within the propagation delay range of each side, then the path from storage volume to database instance and then to middleware instance is written into the main dependency path. If another server resource path does not have a synchronized offset, it is used as a bypass verification path to exclude insufficient server resources as the main root cause. In this embodiment, the dependency propagation relationship is expressed by the main path and the bypass path, so that the healthy offset chain can retain candidate evidence and exclusion evidence.

[0034] In one embodiment, reference Figure 4 The dynamic performance baseline divides the operating context into weekdays, non-weekdays, peak business periods, backup windows, inspection windows, patch upgrade windows, and parameter change windows. Within each operating context, a node baseline and a side baseline are established. The node baseline represents the normal indicator distribution of a certain operating object under the same context, while the side baseline represents the normal relationship between upstream and downstream nodes in terms of propagation delay, offset direction consistency, and semantic category association. The processing procedure sets baseline switching conditions for the state migration of the same node between different contexts. For example, when the time falls within the backup window and the backup task node is in the running state, the database archive write, storage input / output, and backup task time use the backup window baseline. When the patch upgrade record is in the effective period and the inspection result confirms the version change, the relevant node uses the patch upgrade window baseline. After the real-time state enters a new operating context, the corresponding baseline is selected first, and then the node offset magnitude, offset duration, and offset direction are calculated. The node offset is not directly equivalent to a fault, but is combined with the main dependency path to generate a sortable health offset chain. This embodiment incorporates normal fluctuations under peak business periods, planned backups, planned inspections, patch upgrades, and parameter change conditions into the baseline selection process, avoiding misjudging context changes as precursors to faults.

[0035] In this embodiment, the healthy offset chain is generated starting from the graph node where the earliest baseline offset occurs. The processing reads the offset status of subsequent nodes and directed edges along the primary dependency path, and for each directed edge, it determines whether the offset direction, offset duration, and propagation delay interval of the subsequent node meet the edge attribute constraints. When a subsequent node meets the propagation constraints, it is added to the same healthy offset chain. When there are synchronous offsets of the same semantic category in the bypass verification path, the link credibility of the healthy offset chain is increased. When the offset order of the bypass verification path contradicts that of the primary dependency path, the healthy offset chain is split into multiple candidate chains, and the root cause candidate nodes and propagation evidence fields are retained respectively. The link credibility is expressed by the following formula: ; in, Represents the health offset chain In the time window Internal link trustworthiness, Represents the health offset chain The set of directed edges contained therein This indicates the number of directed edges. Indicates from node To the node A directed edge, Represents a node To node The value is set to 1 if the offset direction matches the propagation direction and 0 otherwise. Indicates time window internal nodes Offset to node The actual interval of the offset. This indicates the normal propagation delay for directed edge configuration. Represents a node The degree of data missing, in physical terms, is the conversion of the consistency of propagation direction, the degree of matching of propagation delay, and the data completeness of successor nodes into link reliability. For example, a healthy offset chain contains two directed edges, both of which have matching propagation directions. The actual interval and the deviation from the normal delay are 2 and 1, respectively, and the normal propagation delay is 10. The degree of missing data in successor nodes is 0 and 0.25, respectively. At that time, the link credibility is approximately 0.78. This embodiment makes the healthy offset chain not just a set of abnormal nodes, but a propagation evidence structure with direction, time, and data quality constraints.

[0036] In a preferred embodiment, the root cause candidate nodes of the health offset chain are generated jointly based on the node's occurrence time, the object level of the node, the node's semantic state value, and the path correlation. The processing involves finding the node in the chain that has the earliest stable positive offset and whose upstream bypass verification path has not been synchronously offset as the root cause candidate node. Then, the unified event object and unified state object of this node are read to confirm whether there are maintenance windows, parameter changes, patch upgrades, or inspection anomaly records. If there is a change record that matches the current offset direction, an interpretable fluctuation identifier is added to the root cause candidate node. If there is no interpretable record and the downstream node offsets occur sequentially, an abnormal propagation identifier is added. If multiple candidate nodes meet the conditions at the same time, they are sorted according to the path correlation and semantic state value, and multiple candidate nodes are retained. It is not mandatory to write a single node as the unique root cause. The relevant propagation evidence fields include the starting offset time, downstream offset time, propagation direction, offset semantic category, bypass verification result, and missing marker. This embodiment enables the root cause screening process to retain positive evidence, negative evidence, and data quality evidence at the same time, avoiding the true propagation starting point being covered by a certain alarm level being high.

[0037] In one embodiment, the fault prediction result and health profile are jointly generated by the link credibility of the candidate chain, root cause candidate nodes, anomaly propagation identifiers, explainable fluctuation identifiers, and data missing markers. The fault prediction model uses the health offset chain as input, rather than an isolated indicator sequence as the sole input. The model output includes the fault type and initial level. The fault type is determined based on the combination of resource capacity degradation, access blockage, task backlog, configuration drift, and data protection anomalies. The initial level is jointly determined based on the link credibility, root cause candidate node object level, number of affected dependency paths, and data protection status. Subsequently, the initial level is corrected by verifying the maintenance window, change records, backup verification results, and disaster recovery linkage status through the rule engine. The level correction is expressed by the following formula: ; in, Indicates time window The internally corrected fault level ranges from 1 to 4, with higher values ​​indicating a higher response level. This indicates the initial level output by the fault prediction model. This indicates the link credibility of the health offset chain. This indicates a data protection risk flag, with a value of 0 or 1. It is set to 1 when backup verification or disaster recovery linkage status is abnormal. This indicates an interpretable fluctuation flag; a value of 1 is used when the maintenance window, patch update history, or parameter change history can interpret the current offset. This indicates a reduction in data evidence; a value of 1 is assigned when the degree of missing key nodes exceeds a preset quality threshold. , , , This represents four correction factors. and Used to limit the range of levels, its physical meaning is to incorporate dissemination evidence, data protection status, explainable fluctuations, and evidence quality into level generation, for example... , , , , , , , , At that time, the result inside the parentheses was 3.19, which was rounded up. If the same offset is in the patch upgrade window and When the correction result is reduced according to the formula, it will be redefined. In this embodiment, the fault level is generated by both the propagation evidence and the operating context, avoiding the determination of the response level based solely on the original alarm level.

[0038] Furthermore, the health profile is persistently saved according to the running object, dependency path, semantic state, baseline offset, candidate root cause, and response triggering condition. The running object part saves the node identifier, object level, source identifier, and state validity period. The dependency path part saves the main dependency path, bypass verification path, and propagation evidence fields. The semantic state part saves the state values, explainable fluctuation identifiers, anomaly propagation identifiers, and data missing markers under the semantic categories of resource bearing, access blocking, task backlog, configuration drift, and data protection. The baseline offset part saves the current running context, baseline selection basis, offset magnitude, offset direction, and offset duration. The candidate root cause part saves the root cause candidate nodes, corresponding unified event objects, and related change records. The response triggering condition part saves the fault type, level, affected dependency path, backup verification result, disaster recovery linkage status, and handling triggering condition. Each update of the profile retains the time sequence, so that the health status of the same object in multiple windows can be traced along a unified data structure. In this embodiment, the health profile writes the distributed indicators, logs, inspections, changes, dependency paths, and fault prediction results into the same queryable object, and subsequent health management can be continuously updated based on the same object relationship.

[0039] In a preferred embodiment, the rule engine does not replace the fault prediction model, but rather imposes deterministic constraints on the fault type and initial level output by the model. The rule items include maintenance window rules, change log rules, backup verification rules, disaster recovery linkage rules, dependency propagation direction rules, and data quality rules. Maintenance window rules determine whether the offset time falls within a registered backup, inspection, patch upgrade, or parameter change window. Change log rules determine whether the changed object is located on a node or directed edge of the health offset chain. Backup verification rules read the integrity of relevant backup tasks and the continuity status of recovery points. Disaster recovery linkage rules read production... The synchronization status with the disaster recovery synchronization object depends on the propagation direction rule to determine whether the offset chain is consistent with the direction of the directed edge propagation, and the data quality rule to determine whether the degree of missing key nodes affects the level judgment. If the prediction model gives a high level but the rule shows that the offset falls completely within the interpretable change window and the bypass verification path is not abnormal, the correction level is reduced and the interpretable fluctuation mark is retained. If the prediction model gives a medium level but the relevant backup verification or disaster recovery linkage is abnormal, the correction level is increased and a data protection risk mark is written. This embodiment makes the model judgment and rule constraints form a traceable record in the same health profile, avoiding black box output that directly triggers fault response.

[0040] In a preferred embodiment, for the combined offset of storage I / O latency, database wait events, middleware thread pool usage, and backup task latency, the processing first locates the object hierarchy of storage volume, database instance, middleware instance, and backup task in the unified object index. Then, it reads the directed edges from storage volume to database instance, database instance to middleware instance, and database instance to backup task based on the cross-stack dependency semantic graph. Subsequently, it selects a backup window or a dynamic performance baseline under peak business context. If the access blocking semantic state of the storage volume node shows a positive offset first, the access blocking semantic state of the database instance node is in the propagation delay zone. If a positive offset occurs within a certain period, the task backlog semantic state of the middleware instance node will subsequently show a positive offset, and the data protection semantic state of the backup task node will show a time-consuming offset. Then, the processing will generate a health offset chain containing the storage volume, database instance, middleware instance, and backup task, and consider the storage volume as one of the root cause candidate nodes. At the same time, the patch upgrade window and parameter change records will be checked. If there are no explanatory fluctuation records, the abnormal propagation identifier will be written into the link attribute. In this embodiment, the non-limit-crossing indicators of multiple platforms are synthesized into a fault precursor chain according to the dependency path and time order, so that the health degradation state that is difficult to identify in the decentralized monitoring can enter the unified prediction process.

[0041] In a preferred embodiment, for explainable fluctuations caused by patch upgrades or parameter changes, the processing procedure records the changed object, start and end time of the change, scope of the change's impact, rollback confirmation status, and inspection and review conclusions when collecting change records. The change impact relationship is written as a directed edge or edge attribute in the cross-stack dependency semantic graph. When a node offset appears within the scope of the change's impact, the semantic state value is not directly determined as an abnormal propagation. Instead, it is matched with the object level, semantic category, and time window in the change record. If the offset direction is consistent with the change's impact semantics and no associated offset occurs in the bypass verification path, an explainable fluctuation identifier is added, and a change window baseline is selected in the dynamic performance baseline. If the offset duration exceeds the validity period of the change record's state, or if the offset continues to propagate along the main dependency path to downstream nodes not included in the scope of the change's impact, the explainable fluctuation identifier is converted into an abnormal propagation identifier, and a healthy offset chain is regenerated. This embodiment enables planned changes to be incorporated into the baseline selection and fault prediction process while retaining the judgment channel for abnormal change spillover.

[0042] Furthermore, to address the insufficient evidence caused by missing data and asynchronous heterogeneous sampling, the processing steps set data quality judgments for key nodes within each time window. Key nodes include the starting node of the health offset chain, root cause candidate nodes, propagation direction intersection nodes, and data protection nodes. If the data missing degree of a key node is high, the fault prediction model can still output candidate results, but the rule engine will write a data evidence reduction mark in the health profile and require subsequent windows to continue collecting the most recent effective state of the same source, the comparison state of objects at the same level, and the upstream dependent state of the node. If the data supplemented by the subsequent window is consistent with the current health offset chain direction, the link credibility increases. If the data of the subsequent window contradicts the current link direction, the candidate chain is split and reordered. The processing will not treat missing data as a normal state, nor will it directly treat missing data as a fault state. This embodiment enables the fault prediction process to distinguish between collection gaps, transient fluctuations, and true propagation offsets through data missing marking and subsequent window review mechanisms.

[0043] In one embodiment, continuous health management records are stored in time windows. Each record includes a unified object index, runtime context, semantic state value, dynamic performance baseline, main dependency path, bypass verification path, health offset chain, link credibility, fault type, correction level, and rule verification result. When predicting similar faults in the future, the number of occurrences of health offset chains in the historical records participates in the path correlation calculation, the interpretable fluctuation identifiers in the historical records participate in the context baseline selection, the anomaly propagation identifiers in the historical records participate in the root cause candidate node sorting, and the data missing markers in the historical records participate in the data quality judgment. If a certain type of link repeatedly exhibits the same offset order in multiple time windows, the number of occurrences of historical fault chains in the path correlation increases. If a certain type of offset is interpreted by change records multiple times, the corresponding context baseline retains its normal fluctuation range. This embodiment enables the dynamic performance baseline and cross-stack dependency semantic graph to be continuously updated during operation by writing back each prediction and correction result as a structured health management record.

[0044] In a preferred embodiment, the input features of the fault prediction model are not directly concatenated from the original platform fields. Instead, they are extracted from the health offset chain, including link confidence, chain length, root cause candidate node level, offset semantic category set, offset duration set, bypass verification results, explainable fluctuation identifier, abnormal propagation identifier, data missing marker, backup verification status, and disaster recovery linkage status. Before input, continuous features are context-normalized, discrete identifiers are categorically encoded, and the directed edge order is preserved for path-type features. The fault type output by the model and the initial level are entered into the rule engine for constraint verification. If the fault type output by the model is inconsistent with the semantic category set of the health offset chain, the candidate type is recalculated according to the semantic category set, and the weight of the corresponding model confidence information in the profile is reduced. If the root cause object output by the model is not in the main dependency path or the bypass verification path, it is not written as a root cause candidate node in the health profile. This embodiment limits the structure of the prediction model's input and output, so that machine learning judgment is based on unified semantics and dependency propagation evidence, rather than on the mechanical concatenation of platform fields.

[0045] In a preferred embodiment, the standardized report is directly generated from the health profile. The report content no longer simply lists alarms according to platform columns, but is organized around the running object, semantic category, dependency path, health offset chain, root cause candidate node, backup verification status, and disaster recovery linkage status. Each anomaly in the report references a unified event object, a unified indicator object, and a unified status object, and can display the semantic category, baseline offset, propagation direction, offset duration, bypass verification result, and rule verification result of the anomaly. If an anomaly belongs to an explainable fluctuation, the report records the corresponding maintenance window or change record and its status validity period. If an anomaly belongs to an anomaly propagation, the report records the health offset chain and the affected dependency path. When the report is generated, the fault level is not re-determined, but the fault type and level that have been corrected in the health profile are read. This embodiment enables the inspection report and the fault prediction process to share the same data source and the same object index, avoiding inconsistencies in objects and semantics between the report conclusions and the prediction results.

[0046] In a preferred embodiment, remote alarms, automatic handling of low-level faults, and emergency fault work order scheduling all take the handling trigger conditions in the health profile as input. Low-level faults only enter automatic handling when the link credibility, data missing degree, explainable fluctuation identifier, and backup verification status meet the preset handling boundaries. Remote alarms carry root cause candidate nodes, affected dependency paths, relevant baseline offsets, bypass verification results, and prohibited operation prompts. Emergency fault work orders carry backup verification results, disaster recovery linkage status, affected object level, and health offset chain evidence. After handling is completed, the semantic state values ​​of relevant nodes are re-collected and written into the health profile of the next time window. If the offset chain converges, the handling completion status is recorded. If the offset chain continues to propagate along the main dependency path, the link credibility and fault level are recalculated. This embodiment connects the fault prediction results and the hierarchical response process in the same closed-loop data structure, so that the response action is executed based on traceable dependency propagation evidence.

[0047] In this embodiment, the storage device's full lifecycle health management and the health profile share a unified object index. The storage hardware and software status, volume performance, link errors, historical faults, parts replacement records, backup task ownership, backup verification results, and disaster recovery synchronization status are all bound to storage nodes, storage volume nodes, backup task nodes, and disaster recovery instance nodes. If the storage lifecycle health status degrades but the backup task is formally completed, the processing continues to read the recovery point continuity and backup copy verification status under the data protection semantic category. If the data protection status and the storage access blocking status appear in the same health offset chain, the fault level correction process will write the data protection risk marker. If the storage parts replacement record is within the planning window, the rule engine will match the parts replacement object with the affected path in the cross-stack dependency semantic graph, confirm the linkage status of the relevant backup object and disaster recovery object, and then generate the disposal trigger condition. This embodiment makes storage health, backup verification, and disaster recovery linkage no longer processed separately, and can express the data protection status in the same fault prediction and health management link.

[0048] In one embodiment, the entire processing uses configurable rules, a unified object index, a cross-stack dependency semantic graph, a dynamic performance baseline, a health offset chain, and a continuous health profile as the core data structures. The acquisition layer provides raw runtime data, the transformation process provides objectified data, the semantic mapping process provides a unified semantic state, the dependency graphing process provides propagation constraints, the dynamic baseline process provides context offsets, the health offset chain process provides evidence of early signs of failure, and the prediction and rule correction process provides failure type, level, and handling trigger conditions. The data structures are continuously updated according to time windows. Any change in the state of a running object enters the same health profile through source identifier, object level, semantic category, and dependency path. This embodiment fully covers the data acquisition, transformation, semantic fusion, dependency propagation, baseline judgment, failure classification, and profile saving processes required for fault prediction and health management in heterogeneous information technology systems, enabling the runtime status of multiple heterogeneous platforms to be continuously expressed as calculable, interpretable, and traceable health management records.

Claims

1. A method for intelligent operation and maintenance, fault classification response, and health management of heterogeneous IT systems, characterized in that: include: Collect performance metrics, logs, alarms, inspection results, and change records from minicomputers, storage, servers, databases, middleware, and backup systems, and convert them into unified event objects, unified indicator objects, and unified status objects; Based on the semantic mapping relationship of indicators, data from different sources are classified into semantic categories such as resource carrying capacity, access blocking, task backlog, configuration drift, and data protection. Construct a cross-stack dependency semantic graph based on business access, storage mounting, instance deployment, middleware invocation, and backup attribution; A dynamic performance baseline is established based on the runtime context, the baseline offset and propagation order of each node are calculated, and the fault prediction results and health profiles are generated by combining the cross-stack dependency semantic graph.

2. The method for intelligent operation and maintenance, fault classification response, and health management of heterogeneous IT systems according to claim 1, characterized in that, The conversion process of the unified event object, unified indicator object and unified status object includes: configuring the source identifier, sampling time, object level, indicator granularity and status validity period; Parse the exception codes, alarm levels, change actions, and inspection conclusions in the log text into associable fields; Align performance metrics by sampling time windows; Data that cannot be directly aligned is written into the same object index according to the affiliation of device objects, software instances, and business links, so that multiple types of state data of the same running object can be referenced when building dependency maps later.

3. The method for intelligent operation and maintenance, fault classification response, and health management of heterogeneous IT systems according to claim 1, characterized in that, The process of forming the semantic mapping relationship of the indicators includes: establishing mapping items between indicator names, measurement units, sampling periods, normal range sources and business meanings for the original indicators of different platforms; Storage input / output latency, database wait events, middleware thread pool usage, server resource utilization, and backup task time are categorized into corresponding semantic categories. Set source weights and time credibility for indicators within the same semantic category; When multiple source metrics conflict within the same time window, the semantic state value is determined based on the object level, sampling completeness, and most recently changed state, and the semantic state value is bound to the corresponding node or edge of the cross-stack dependency semantic graph.

4. The method for intelligent operation and maintenance, fault classification response, and health management of heterogeneous IT systems according to claim 1, characterized in that, The construction process of the cross-stack dependency semantic graph includes: using servers, storage volumes, database instances, middleware instances, backup tasks, and business access objects as graph nodes, and using mount relationships, connection relationships, call relationships, backup object ownership relationships, and change impact relationships as directed edges; Configure the propagation direction, propagation delay interval, and affected semantic category for each directed edge; When the same running object has multiple dependency paths, the primary dependency path is determined based on the access link priority, backup link ownership, and historical fault propagation records. The node state, edge state, and the dynamic performance baseline result are written together into the graph attributes for subsequent fault chain generation.

5. The method for intelligent operation and maintenance, fault classification response, and health management of heterogeneous IT systems according to claim 2, characterized in that, The process of sampling alignment for the time window includes: determining the alignment window by combining the business cycle, inspection cycle, alarm generation time and change execution time; Continuous indicators are represented by trend segments within a window, discrete alarms are represented by occurrence and recovery times, and inspection results are represented by the effective interval of the conclusion. When the same object has missing data in adjacent windows, a missing marker is generated using the most recent valid state from the same source, the state of the same layer object, and the state dependent on the upstream state, without replacing the original sample with the filler value. The missing markers are used as input constraints for calculating the dynamic performance baseline to avoid erroneous offsets caused by differences in heterogeneous sampling frequencies.

6. The method for intelligent operation and maintenance, fault classification response, and health management of heterogeneous IT systems according to claim 3, characterized in that, The process of determining the semantic state value includes: first generating candidate node states based on the object level to which the indicator belongs, and then generating a state confidence interval based on the indicator source weight and time credibility. When storage latency, database wait, middleware backlog, and backup time change in the same direction within the same semantic link, multiple node candidate states are combined into a cross-node semantic state. When the cross-node semantic state matches a maintenance window, patch upgrade record, or parameter change record, an interpretable fluctuation identifier is written into the semantic state value. When a mismatch occurs, the anomaly propagation flag is retained and passed on to subsequent calculations in fault prediction and health management.

7. The method for intelligent operation and maintenance, fault classification response, and health management of heterogeneous IT systems according to claim 4, characterized in that, The process of determining the primary dependency path includes: enumerating the paths from the business access object to the database instance, middleware instance, server, and storage volume; The path correlation is calculated based on the current running status of the path nodes, the frequency of historical failure chains, the ownership of backup objects, and the scope of impact of changes. When the path correlations overlap, candidate paths are selected based on the order of index offsets before the fault occurred. The path that covers the most anomaly semantic categories and conforms to the direction of directed edge propagation among the candidate paths is determined as the primary dependency path, and other paths are reserved as bypass verification paths in the cross-stack dependency semantic graph.

8. The method for intelligent operation and maintenance, fault classification response, and health management of heterogeneous IT systems according to claim 4, characterized in that, The process of establishing the dynamic performance baseline includes dividing the operating context according to weekdays, non-weekdays, peak business periods, backup windows, inspection windows, patch upgrade windows, and parameter change windows; Establish node baselines and edge baselines separately within each runtime context; Set baseline switching conditions for state transitions of the same node across different contexts; When the real-time state enters a new running context, the corresponding baseline is first selected according to the baseline switching conditions, and then the node offset magnitude, offset duration and offset direction are calculated. The node offset magnitude, offset duration, and offset direction are combined with the main dependency path to generate a sortable healthy offset chain.

9. The method for intelligent operation and maintenance, fault classification response, and health management of heterogeneous IT systems according to claim 8, characterized in that, The process of generating the health offset chain includes: starting from the graph node where the earliest baseline offset occurs, reading the offset status of subsequent nodes and directed edges along the main dependency path; When the offset direction, offset duration, and propagation delay interval of a subsequent node satisfy the propagation constraints of the directed edge, the corresponding node is added to the same healthy offset chain. When there are synchronous offsets of the same semantic category in the bypass verification path, the link credibility of the corresponding health offset chain is increased; When the offset order of the bypass verification path contradicts that of the main dependency path, the health offset chain is split into multiple candidate chains, and the root cause candidate node and propagation evidence field are retained respectively.

10. The method for intelligent operation and maintenance, fault classification response, and health management of heterogeneous IT systems according to claim 9, characterized in that, The process of generating the fault prediction results and health profile includes: inputting the link credibility, root cause candidate node, abnormal propagation identifier, explainable fluctuation identifier and data missing marker of each candidate chain into the fault prediction model to obtain the fault type and initial level; Then, the initial level is corrected by verifying the maintenance window, change records, backup verification results, and disaster recovery linkage status through the rule engine. The corrected fault type, level, root cause candidate node, affected dependency path, relevant baseline offset and handling trigger conditions are written into the health profile and saved in chronological order as a continuous health management record for heterogeneous IT systems.

Images