A multi-system overhaul state tracking method and system based on a cloud-native architecture

Abstract

This invention discloses a method and system for tracking the maintenance status of multiple systems based on a cloud-native architecture, belonging to the field of cloud computing and operation and maintenance management technology. Through multi-source heterogeneous data collection and unified four-dimensional model mapping, a maintenance task model is formed, realizing the fusion of maintenance status data from multiple systems. Simultaneously, the maintenance task model undergoes time correlation optimization, streaming topology inference, and dual-stream correlation determination to obtain a set of effective related events for each maintenance task, achieving precise correlation analysis of each event. This not only accurately locates effective related events, improving the accuracy of maintenance progress calculation, but also eliminates a large amount of irrelevant data, reducing the computational overhead for maintenance progress tracking and improving the overall efficiency and response speed of operation and maintenance. Furthermore, through automatic visualization, the efficiency and accuracy of maintenance report generation are improved, significantly enhancing the transparency and visualization level of the multi-system maintenance process.

Description

Technical Field

[0001] This invention belongs to the field of cloud computing and operation and maintenance management technology, specifically relating to a method and system for tracking the maintenance status of multiple systems based on cloud-native architecture. Background Technology

[0002] In current enterprise system operation and maintenance practices, regular inspections and maintenance of multiple independent systems, such as databases, middleware, and business systems, are often involved. However, under the existing technology framework, the tracking of the maintenance status and progress control of each system generally relies on manual recording, scattered work order systems, or independent monitoring tools, lacking a unified scheduling and display view. This results in severely fragmented maintenance information, making it difficult for managers to control the overall progress from a global perspective. Furthermore, existing display methods are mostly static tables or simple lists, failing to present multi-dimensional maintenance dynamics in a real-time and intuitive manner, resulting in severely insufficient visualization capabilities. In addition, the compilation of maintenance reports still heavily relies on manual compilation and summarization, which is not only time-consuming and labor-intensive but also prone to data omissions or statistical errors. More importantly, with the widespread adoption of cloud-native architectures, application systems are increasingly containerized and microservice-based, while traditional operation and maintenance tools struggle to effectively adapt to this dynamic and elastic environment, unable to dynamically perceive the real-time status and changes of service instances, severely restricting the development of automation and intelligence in operation and maintenance management.

[0003] As mentioned above, how to provide a multi-system maintenance status tracking method and system based on cloud-native architecture that can automatically track the real-time status of maintenance tasks, improve the accuracy of status tracking and progress updates, and visualize the status and real-time progress of maintenance tasks has become a technical problem that urgently needs to be solved in this field. Summary of the Invention

[0004] The purpose of this invention is to provide a multi-system maintenance status tracking method and system based on cloud-native architecture to solve the above-mentioned problems existing in the prior art.

[0005] To achieve the above objectives, the present invention adopts the following technical solution: In a first aspect, the present invention provides a multi-system maintenance status tracking method based on a cloud-native architecture, including: The original maintenance status data of each system is acquired in real time from the cloud-native environment through a multi-source heterogeneous acquisition method. A preset operation and maintenance knowledge graph is obtained, and the original maintenance status data of each system is mixed and cleaned to obtain maintenance status data. Based on the operation and maintenance knowledge graph, the maintenance status data of each system is mapped to a unified four-dimensional model, and the unified four-dimensional model with completed data mapping is used as the maintenance task model. Based on the adaptive time window and the maintenance task model, the time window boundaries of each maintenance task are generated, and the maintenance task model is optimized by time correlation according to the time window boundaries of each maintenance task to obtain the time-correlated maintenance task model. By utilizing service mesh call topology and metadata determination, streaming topology inference is performed on the time-related maintenance task model to obtain a causal maintenance task model. Then, dual-stream association determination is performed on the causal maintenance task model to obtain the effective association event set for each maintenance task. Obtain a preset weighted aggregation formula, and calculate the real-time maintenance progress of each maintenance task based on the effective associated event set of each maintenance task using the weighted aggregation formula. Obtain a preset maintenance report template, push the causal relationship maintenance task model and the real-time maintenance progress of each maintenance task to the front end for visualization, and generate a corresponding maintenance report based on the maintenance report template, the maintenance status data, the causal relationship maintenance task model and the real-time maintenance progress of each maintenance task.

[0006] In one possible design, raw maintenance status data of various systems are acquired in real time from the cloud-native environment through a multi-source heterogeneous acquisition method, including: Through three parallel acquisition channels, monitoring indicator data, access log data, and work order data are obtained in real time from multiple maintenance systems in the cloud-native environment; The collected monitoring indicator data, access log data, and work order data are time-aligned and written to a Kafka message queue to form the original maintenance status data of each system.

[0007] In one possible design, a pre-defined operation and maintenance knowledge graph is obtained, and the original maintenance status data of each system is mixed and cleaned to obtain maintenance status data. Based on the operation and maintenance knowledge graph, the maintenance status data of each system is mapped to a unified four-dimensional model, and the unified four-dimensional model with completed data mapping is used as the maintenance task model, including: The original maintenance status data of each system is identified by data type to obtain data type identification results. Based on the data type identification results, the original maintenance status data is divided into continuous index data, discrete status quantity data and status description data. Missing values ​​are detected in the continuous index data, and linear interpolation is used to fill the detected missing values. The continuous index data is then smoothed using a weighted moving average to complete the cleaning of the continuous index data. Missing values ​​are detected in the discrete state variable data, and forward filling is performed on the detected missing values ​​to complete the cleaning of the discrete state variable data. Obtain a preset state constant mapping table and perform constant mapping on the state description data to complete the cleaning of discrete state variable data. The continuous index data, discrete state quantity data, and state description data of the completed cleaning process are integrated to form maintenance state data; Obtain a preset operation and maintenance knowledge graph, extract each maintenance action from the maintenance status data, input the maintenance status data into the operation and maintenance knowledge graph, and use each maintenance action as a key to match the data associated with each maintenance action from the operation and maintenance knowledge graph as valid maintenance status data. A preset unified four-dimensional model is obtained, and the effective maintenance status data is mapped to the four dimensions of the unified four-dimensional model to obtain a unified four-dimensional model with completed data mapping. The unified four-dimensional model with completed data mapping is output as the maintenance task model. The four dimensions of the unified four-dimensional model include the maintenance task life cycle, maintenance task indicators, maintenance task event chain, and maintenance task abnormal information.

[0008] In one possible design, based on the adaptive time window and the maintenance task model, time window boundaries for each maintenance task are generated, and the maintenance task model is time-correlated optimized according to the time window boundaries of each maintenance task to obtain a time-correlated maintenance task model, including: Each maintenance action is extracted from the maintenance status data. Based on the action type of each maintenance action, the historical maintenance task data corresponding to each action type is obtained from the cloud-native environment. The task completion time of each historical maintenance task corresponding to each action type is extracted from the historical maintenance task data corresponding to each action type. Based on the historical maintenance task completion time corresponding to each action type, the average historical task completion time and the standard deviation of historical task completion time corresponding to each action type are calculated. Obtain the preset time window adjustment coefficient, and calculate the corresponding time window length for each maintenance task in the maintenance status data based on the average historical task completion time and standard deviation of historical task completion time corresponding to each action type, as well as the time window adjustment coefficient. The time window length corresponding to each maintenance task is used as the time window boundary of the maintenance task. The life cycle of each maintenance task in the maintenance task model is associated, so that the maintenance task event chain that exceeds the time window boundary in each maintenance task is removed in the maintenance task model, and a time-related maintenance task model is obtained.

[0009] In one possible design, the time-related maintenance task model is subjected to streaming topology inference using service mesh call topology and metadata determination to obtain a causal maintenance task model. Then, a two-stream association determination is performed on the causal maintenance task model to obtain the effective associated event set for each maintenance task, including: Obtain the directed graph stored internally by the streaming operator, obtain the inter-service network call information output by the service mesh under the cloud-native architecture through the streaming operator, construct a request call chain based on the inter-service network call information, and add the request call chain to the directed graph to form a service mesh call topology; Multiple maintenance tasks are extracted from the time-related maintenance task model, and the maintenance task event chain of each maintenance task is extracted to obtain each event corresponding to each maintenance task. For each maintenance task, obtain the service name of each event source, and match the service name of each event source with each topology node in the service mesh call topology to determine whether the service name of each event source matches each topology node in the service mesh call topology. If so, the event is determined to be a causal event; otherwise, the event is determined to be background noise. For each maintenance task, the various causal events are integrated to form a set of causal events for each maintenance task. In the causal event set of each maintenance task, the cloud-native container orchestration platform metadata of each causal event is obtained. The cloud-native container orchestration platform metadata of each causal event is matched with the maintenance target pointed to by the corresponding maintenance task. Based on the matching result, the causal event set of each maintenance task is filtered. The time-related maintenance task model is updated using the causal event set of each maintenance task after the event filtering is completed, and the causal maintenance task model is obtained. The corresponding causal events are extracted from the causal relationship maintenance task model as an event stream, and the work order data is extracted from the maintenance status data as a work order data stream. The maintenance target pointed to by each maintenance task is used as the matching key, and the approval time of the work order data is used as the judgment criterion. The event stream and the work order data stream are correlated and judged. Each event that matches the approval time of the work order data is selected as a valid correlation event. The valid correlation events are integrated to form a set of valid correlation events for each maintenance task.

[0010] In one possible design, a preset weighted aggregation formula is obtained, and based on the effective associated event set of each maintenance task, the real-time maintenance progress of each maintenance task is calculated using the weighted aggregation formula, including: Obtain a preset event status quantification comparison table, and based on the effective associated event set of each maintenance task, count the total number of effective associated events corresponding to each maintenance task. Extract the event status of each effective associated event from the maintenance status data, and quantify the event status of each effective associated event according to the event status quantification comparison table to obtain the event status quantification value of each effective associated event. Obtain a preset event weight allocation table, and use the event name of each valid associated event to match the event weight corresponding to each valid associated event from the event weight allocation table; Obtain a preset weighted aggregation formula, and calculate the real-time maintenance progress of each maintenance task based on the total number of valid associated events corresponding to each maintenance task, the event status quantification value of each valid associated event, and the event weight corresponding to each valid associated event.

[0011] In one possible design, a preset maintenance report template is obtained, and the causal relationship maintenance task model and the real-time maintenance progress of each maintenance task are pushed to the front end for visualization. Based on the maintenance report template, the maintenance status data, the causal relationship maintenance task model, and the real-time maintenance progress of each maintenance task, a corresponding maintenance report is generated, including: The front end pushes the causal relationship maintenance task model and the real-time maintenance progress of the maintenance tasks, performs interface layout and chart rendering of the causal relationship maintenance task model and the real-time maintenance progress of each maintenance task, and displays the rendered causal relationship maintenance task model and the real-time maintenance progress of each maintenance task on a large screen. Obtain a preset maintenance report template, and perform structured processing on the maintenance status data, the causal relationship maintenance task model, and the real-time maintenance progress of each maintenance task according to the maintenance report template to obtain a structured maintenance report, and send the maintenance report to the operation and maintenance management terminal.

[0012] Secondly, this invention provides a multi-system maintenance status tracking system based on a cloud-native architecture, comprising: The data acquisition unit is used to acquire raw maintenance status data of various systems in real time from the cloud-native environment through multi-source heterogeneous acquisition methods. The model mapping unit is used to acquire a preset operation and maintenance knowledge graph, mix and clean the original maintenance status data of each system to obtain maintenance status data, and map the maintenance status data of each system to a unified four-dimensional model based on the operation and maintenance knowledge graph, so as to use the unified four-dimensional model with completed data mapping as the maintenance task model. The time association unit is used to generate the time window boundaries of each maintenance task based on the adaptive time window and the maintenance task model, and to perform time association optimization on the maintenance task model according to the time window boundaries of each maintenance task to obtain the time-associated maintenance task model. The association determination unit is used to perform streaming topology inference on the time-related maintenance task model by using service mesh call topology and metadata determination to obtain the causal-related maintenance task model, and to perform dual-stream association determination on the causal-related maintenance task model to obtain the effective association event set of each maintenance task. The progress calculation unit is used to obtain a preset weighted aggregation formula and calculate the real-time maintenance progress of each maintenance task based on the effective associated event set of each maintenance task using the weighted aggregation formula. The output display unit is used to obtain a preset maintenance report template, push the causal relationship maintenance task model and the real-time maintenance progress of each maintenance task to the front end for visualization display, and generate a corresponding maintenance report based on the maintenance report template, the maintenance status data, the causal relationship maintenance task model and the real-time maintenance progress of each maintenance task.

[0013] Thirdly, the present invention provides an electronic device comprising a memory, a processor, and a transceiver connected in sequence and communication, wherein the memory is used to store a computer program, the transceiver is used to send and receive messages, and the processor is used to read the computer program and execute the multi-system maintenance status tracking method based on cloud-native architecture as described in the first aspect or any possible design of the first aspect.

[0014] Fourthly, the present invention provides a computer-readable storage medium storing instructions that, when executed on a computer, perform the multi-system maintenance status tracking method based on cloud-native architecture described in the first aspect or any possible design of the first aspect.

[0015] Fifthly, the present invention provides a computer program product containing instructions that, when executed on a computer, cause the computer to perform the multi-system maintenance status tracking method based on a cloud-native architecture as described in the first aspect or any possible design of the first aspect.

[0016] Beneficial Effects: This invention provides a multi-system maintenance status tracking method and system based on a cloud-native architecture. Through multi-source heterogeneous data collection from various systems and unified four-dimensional model mapping, a maintenance task model is formed, achieving the fusion of multi-system maintenance status data and providing data support for subsequent operation and maintenance decisions. Simultaneously, the maintenance task model undergoes time correlation optimization, streaming topology inference, and dual-stream correlation determination to obtain a set of effective related events for each maintenance task. This enables precise correlation analysis of each event, not only accurately locating effective related events and improving the accuracy of subsequent maintenance progress calculations, but also eliminating a large amount of irrelevant data. It reduces the computational overhead of tracking maintenance progress, improving the overall efficiency and response speed of operation and maintenance. In addition, through automated data processing, adaptive progress calculation, and automatic visualization, it effectively reduces the overall operation and maintenance cost, significantly reduces the workload of operation and maintenance personnel, improves the generation efficiency and accuracy of maintenance reports, and outputs maintenance status data, causal relationship maintenance task models, and real-time maintenance progress of each maintenance task through maintenance reports and visualization, significantly improving the transparency and visualization level of the multi-system maintenance process, making it easier for operation and maintenance personnel to intuitively grasp the real-time progress of global maintenance tasks. Attached Figure Description

[0017] Figure 1 A flowchart illustrating the multi-system maintenance status tracking method based on cloud-native architecture provided in this embodiment of the invention; Figure 2 This is a functional structure diagram of a multi-system maintenance status tracking system based on a cloud-native architecture provided in an embodiment of the present invention. Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0018] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the present invention will be briefly introduced below in conjunction with the accompanying drawings and descriptions of the embodiments or the prior art. Obviously, the following description of the structure of the accompanying drawings is only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. It should be noted that the description of these embodiments is for the purpose of helping to understand the present invention, but does not constitute a limitation of the present invention.

[0019] It should be understood that although the terms first, second, etc., may be used herein to describe various units, these units should not be limited by these terms. These terms are only used to distinguish one unit from another. For example, a first unit may be referred to as a second unit, and similarly, a second unit may be referred to as a first unit, without departing from the scope of the exemplary embodiments of the invention.

[0020] It should be understood that the term "and / or" that may appear in this document is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can mean: A exists alone, B exists alone, and A and B exist simultaneously. The term " / and" that may appear in this document describes another relationship between related objects, indicating that two relationships can exist. For example, A / and B can mean: A exists alone, and A and B exist alone. In addition, the character " / " that may appear in this document generally indicates that the related objects before and after it are in an "or" relationship.

[0021] Example: like Figure 1 As shown, the first aspect of this embodiment provides a multi-system maintenance status tracking method based on a cloud-native architecture, which may include, but is not limited to, the following steps: S1. Obtain raw maintenance status data of various systems in real time from the cloud-native environment through multi-source heterogeneous acquisition; In one possible implementation, step S1, which involves acquiring raw maintenance status data of various systems in real time from the cloud-native environment using a multi-source heterogeneous acquisition method, can be broken down into, but is not limited to, the following steps S11-S12, specifically including: S11. Real-time acquisition of monitoring indicator data, access log data, and work order data from multiple maintenance systems in the cloud-native environment through three parallel acquisition channels; S12 performs time alignment on the collected monitoring indicator data, access log data, and work order data, and writes them to the Kafka message queue to form the original maintenance status data of each system.

[0022] It should be noted that in the multi-system maintenance status tracking method provided in this embodiment, raw maintenance status data is obtained in real time from multiple maintenance systems in the cloud-native environment through three parallel acquisition channels. The data collected by each channel is uniformly time-aligned and then merged into the Kafka message queue for downstream processing and consumption.

[0023] Specifically, the first collection channel is used to collect monitoring metrics data. Its collection objects can include, but are not limited to, Pod resource metrics (such as CPU, memory, and IO), business metrics (such as error rate and latency), and maintenance-specific metrics (such as Pod restart count and rolling update progress). Based on the service discovery mechanism, the first collection channel will periodically poll the Kubernetes API Server in the cloud-native environment to automatically discover Pods, Services, and Endpoints annotated with prometheus.io / scrape=true. When a service is scaled up or down, it will automatically collect monitoring metrics data without manual intervention. Its collection cycle can be set to execute a crawl once every 15 seconds by default.

[0024] Correspondingly, the second collection channel is used to collect access log data. Its collection targets can include, but are not limited to, container standard output (stdout) and standard error (stderr) logs, system logs (such as logs from Kubernetes components like kubelet and kube-apiserver), and application logs. This second collection channel is deployed as a DaemonSet on each Kubernetes node to ensure that one Fluentd collection instance runs on each node. It writes container logs to the node's ` / var / log / containers / ` directory (a symbolic link to the specific container logs under ` / var / log / pods / `). The Fluentd collection instance can perform collection by mounting this directory. It should be noted that while collecting data, the `kubernetes_metadata` filtering plugin adds corresponding Kubernetes metadata (namespace, Pod name, container name, etc.) to each access log data entry, and extracts key fields using regular expressions as metadata appended to the corresponding access log data. In a possible implementation, a non-blocking memory buffer combined with a local disk persistence mechanism can also be used to ensure that access log data is not lost in the event of transmission interruption.

[0025] Correspondingly, the third acquisition channel is used to collect work order data. Its collection objects may include, but are not limited to, work order data from third-party work order systems (including work order ID, action type, target system, and approval status). This third acquisition channel implements an adapter mode for different work order systems (such as Jira and ServiceNow), shielding the differences in system interfaces within the cloud-native environment. It may support, but is not limited to, two access modes: polling (actively pulling work order data every 30 seconds by default) and Webhook callback (actively pushed by the third-party system when the work order status changes). Furthermore, after collection is complete, the collected work order data needs to be uniformly converted into a preset internal work order object format to facilitate downstream delivery processing by the Kafka message queue.

[0026] Furthermore, in this embodiment, when aligning the collected monitoring metric data, access log data, and work order data by time, it is necessary to uniformly convert the timestamps of all data sources to UTC millisecond precision and mark the system identifier of the data source. Specifically: the monitoring metric data has a built-in nanosecond-level timestamp, which is converted to millisecond-precision UTC; the access log data has an @timestamp field appended during collection, uniformly in UTC format; the work order data is converted from the local time of each system to a UTC millisecond timestamp through an adapter. Time alignment of the monitoring metric data, access log data, and work order data is the foundation for data cleaning, causal correlation analysis, and real-time progress calculation in subsequent steps. The three types of data that have completed time alignment are written to a Kafka message queue (different data types are written to different topics (data classification pipelines)), so that the Apache Flink stream processing engine in subsequent steps can consume them and perform subsequent data cleaning, causal correlation analysis, and real-time progress calculation.

[0027] S2. Obtain a preset operation and maintenance knowledge graph, mix and clean the original maintenance status data of each system to obtain maintenance status data, and map the maintenance status data of each system to a unified four-dimensional model based on the operation and maintenance knowledge graph, so as to use the unified four-dimensional model with completed data mapping as the maintenance task model. In one possible implementation, step S2 involves acquiring a preset maintenance knowledge graph, mixing and cleaning the original maintenance status data of each system to obtain maintenance status data, and mapping the maintenance status data of each system to a unified four-dimensional model based on the maintenance knowledge graph. The unified four-dimensional model with completed data mapping is then used as the maintenance task model. This can be decomposed into, but is not limited to, the following steps S21-S27, specifically including: S21. The original maintenance status data of each system is identified by data type to obtain data type identification results, and the original maintenance status data is divided into continuous index data, discrete status quantity data and status description data according to the data type identification results. S22. Perform missing value detection on the continuous index data, fill the detected missing values ​​with linear interpolation, and smooth the continuous index data using a weighted moving average to complete the cleaning of the continuous index data. S23. Perform missing value detection on the discrete state variable data, and perform forward filling on the detected missing values ​​to complete the cleaning of the discrete state variable data; S24. Obtain a preset state constant mapping table and perform constant mapping on the state description data to complete the cleaning of discrete state variable data; S25. Integrate the continuous index data, the discrete state quantity data, and the state description data after cleaning to form maintenance state data; S26. Obtain a preset operation and maintenance knowledge graph, extract each maintenance action from the maintenance status data, input the maintenance status data into the operation and maintenance knowledge graph, and use each maintenance action as a key to match the data associated with each maintenance action from the operation and maintenance knowledge graph as valid maintenance status data. S27. Obtain a preset unified four-dimensional model, map the effective maintenance status data to the four dimensions of the unified four-dimensional model to obtain a unified four-dimensional model with completed data mapping, and output the unified four-dimensional model with completed data mapping as the maintenance task model. The four dimensions of the unified four-dimensional model include the maintenance task life cycle, maintenance task indicators, maintenance task event chain, and maintenance task abnormal information.

[0028] In specific application scenarios, missing values ​​detected in the continuous index data are filled using linear interpolation, and the presentation layer data (the data used for subsequent visualization) is smoothed using Exponentially Weighted Moving Average (EWMA). It should be noted that the missing value detection is performed independently based on the original values ​​to avoid masking abrupt anomalies during smoothing. For missing values ​​detected in the discrete state quantity data, forward imputation is used to fill in the missing values ​​using the most recent valid state value, maximizing the validity of the imputed data. For the state description data, constant mapping is performed according to a preset state constant mapping table to transform the differentiated state representations of different systems into standard constant representations, thereby eliminating semantic errors between systems.

[0029] It should be noted that extracting each maintenance action from the maintenance status data actually involves parsing parameters describing the maintenance task from the work order data or detecting an update in the monitoring indicator data to create a maintenance task instance. For this maintenance task instance, the action type for this maintenance is automatically determined based on the specific maintenance task description parameters or the type of indicator change.

[0030] The maintenance task model includes multiple maintenance tasks (corresponding to maintenance actions), and each maintenance task has a four-dimensional data representation.

[0031] S3. Based on the adaptive time window and the maintenance task model, generate the time window boundary of each maintenance task, and perform time correlation optimization on the maintenance task model according to the time window boundary of each maintenance task to obtain the time-correlated maintenance task model. In one possible implementation, in step S3, based on the adaptive time window and the maintenance task model, time window boundaries for each maintenance task are generated, and the maintenance task model is time-related optimized according to the time window boundaries of each maintenance task to obtain a time-related maintenance task model. This can be decomposed into, but is not limited to, the following steps S31-S34, specifically including: S31. Extract each maintenance action from the maintenance status data, and according to the action type of each maintenance action, obtain the historical maintenance task data corresponding to each action type from the cloud-native environment, and extract the task completion time of the historical maintenance task corresponding to each action type from the historical maintenance task data corresponding to each action type. S32. Based on the historical maintenance task completion time corresponding to each action type, calculate the average historical task completion time and the standard deviation of historical task completion time for each action type. S33. Obtain the preset time window adjustment coefficient, and calculate the corresponding time window length for each action type of maintenance task in the maintenance status data based on the average historical task completion time and standard deviation of historical task completion time for each action type of maintenance task, as well as the time window adjustment coefficient. S34. Using the time window length corresponding to each maintenance task as the time window boundary of the maintenance task, the life cycle of each maintenance task in the maintenance task model is associated, so as to remove the maintenance task event chain that exceeds the time window boundary in each maintenance task in the maintenance task model, and obtain the time-related maintenance task model.

[0032] Specifically, the time window length for maintenance tasks corresponding to each action type. When performing the calculation, the average completion time of the historical tasks is used. and the standard deviation of the historical task completion time and the time window adjustment coefficient To achieve this, the specific formula is as follows: ; It should be noted that in the multi-system maintenance status tracking method provided in this embodiment, the average historical task completion time and standard deviation of historical task completion time for each action type, as well as the number of historical maintenance tasks corresponding to each action type, are stored through Flink's Broadcast State. Whenever a maintenance task is completed, Flink sends the actual time of this maintenance task to a dedicated computation operator to update the average historical task completion time and standard deviation of historical task completion time for that maintenance task type in real time (incremental update). When a new maintenance task arrives, based on its action type and maintenance broadcast state, the average historical task completion time and standard deviation of historical task completion time for that action type are read to calculate the time window length of the current maintenance task. In specific application scenarios, if a maintenance task for an action type does not have corresponding historical maintenance task data (first occurrence), the preset default duration (e.g., 300 seconds) is directly used as the time window length of the current maintenance task.

[0033] By calculating the time window length of each maintenance task, the time window boundary of each maintenance task is formed. The time window boundary is used to characterize the time range required to complete the maintenance task corresponding to the action type. Events (event chains) that occur outside this window boundary are irrelevant to this maintenance task and are not included in the correlation analysis, thereby avoiding false correlations in subsequent causal correlation analysis. At the same time, the removal of invalid events can also significantly reduce the computational overhead and improve computational efficiency.

[0034] S4. Utilize service mesh call topology and metadata determination to perform streaming topology inference on the time-related maintenance task model to obtain the causal-related maintenance task model, and perform dual-stream association determination on the causal-related maintenance task model to obtain the effective association event set for each maintenance task. In one possible implementation, step S4 involves using service mesh call topology and metadata determination to perform streaming topology inference on the time-related maintenance task model to obtain a causal maintenance task model, and then performing dual-stream association determination on the causal maintenance task model to obtain the effective association event set for each maintenance task. This can be decomposed into, but is not limited to, the following steps S41-S46, specifically including: S41. Obtain the directed graph stored internally by the streaming operator, obtain the inter-service network call information output by the service mesh under the cloud-native architecture through the streaming operator, construct a request call chain based on the inter-service network call information, and add the request call chain to the directed graph to form a service mesh call topology; S42. Extract multiple maintenance tasks from the time-related maintenance task model, and extract the maintenance task event chain of each maintenance task to obtain each event corresponding to each maintenance task. S43. For each maintenance task, obtain the service name of each event source, and match the service name of each event source with each topology node in the service mesh call topology to determine whether the service name of each event source matches each topology node in the service mesh call topology. S44. If yes, then the event is determined to be a causal event; otherwise, the event is determined to be background noise. For each maintenance task, integrate the various causal events to form a causal event set for each maintenance task. S45. In the causal event set of each maintenance task, obtain the cloud-native container orchestration platform metadata of each causal event, match the cloud-native container orchestration platform metadata of each causal event with the maintenance target pointed to by the corresponding maintenance task, filter the causal event set of each maintenance task according to the matching result, and update the time-related maintenance task model using the causal event set of each maintenance task after event filtering to obtain the causal maintenance task model. S46. Extract the corresponding causal events from the causal maintenance task model as an event stream, and extract the work order data from the maintenance status data as a work order data stream. Use the maintenance target pointed to by each maintenance task as the matching key and the approval time of the work order data as the judgment criterion to perform association judgment on the event stream and the work order data stream. Select each event that matches the approval time of the work order data as a valid association event, and integrate the valid association events to form a valid association event set for each maintenance task.

[0035] In specific application scenarios, to accurately identify which events have a genuine causal relationship with the current maintenance task from the massive and chaotic event chain of each maintenance task, it is necessary to establish causal evidence at the level of inter-service call relationships. In cloud-native architectures, a maintenance task (such as a rolling update) typically triggers a series of cross-service interface calls (such as API gateways, business services, and databases). By reconstructing the complete chain of these calls, events occurring at nodes in this chain can be marked as being related to the propagation path of this maintenance task, thereby effectively filtering out background traffic events that, although time-matched, are not caused by this operation (such as events generated by scheduled inspection tasks).

[0036] Specifically, Flink operators continuously consume inter-service network call information output from service meshes (such as Istio / Envoy) in cloud-native architectures. Each inter-service network call includes a traceId (a unique trace ID across the entire chain), a spanId (the current call segment ID), and a parentSpanId (the parent call segment ID). Internally, the Flink operator maintains a memory-based directed (acyclic) graph in the Flink State Backend, using the traceId as the grouping key. Whenever inter-service network call information flows in, topology nodes and directed edges are added to the directed graph corresponding to the traceId based on its spanId and parentSpanId, thereby dynamically generating a complete service mesh call topology for each request. For each maintenance task, when an event needs to be determined, the service name from which the event originates is extracted, and it is checked whether the service name falls on any of the topology nodes in the service mesh call topology. If so, the event is determined to be on the impact propagation path of this maintenance task, and its matching traceId is recorded, marking this event as a causal event. In practical applications, to prevent the state of the service mesh call topology from expanding indefinitely, an automatic eviction mechanism with a 10-minute TTL (Time to Live) is also set up.

[0037] In practice, each piece of monitoring metric data and access log data collected is accompanied by complete cloud-native container orchestration platform (Kubernetes, k8s) metadata, including namespace, pod_name, and owner_reference (the name and UID of the parent resource, such as Deployment or State), via the tag injection mechanism of Fluentd or Prometheus, before entering the maintenance task model. In the Flink operator, the maintenance target description of each maintenance task is first parsed (e.g., the task declaration explicitly states that Deployment / nginx needs to be updated). Then, the owner_reference in the causal association event to be determined is matched with the maintenance target using both string and UID. Only causal association events that match successfully are retained for the next round of dual-stream association determination.

[0038] S5. Obtain the preset weighted aggregation formula, and calculate the real-time maintenance progress of each maintenance task based on the effective associated event set of each maintenance task using the weighted aggregation formula. In one possible implementation, step S5 involves obtaining a preset weighted aggregation formula and calculating the real-time maintenance progress of each maintenance task based on the effective associated event set of each maintenance task using the weighted aggregation formula. This can be broken down into, but is not limited to, the following steps S51-S53, specifically including: S51. Obtain a preset event status quantification comparison table, and according to the effective associated event set of each maintenance task, count the total number of effective associated events corresponding to each maintenance task, and extract the event status of each effective associated event from the maintenance status data, so as to quantify and compare the event status of each effective associated event according to the event status quantification comparison table, and obtain the event status quantification value of each effective associated event. S52. Obtain a preset event weight allocation table, and use the event name of each valid associated event to match the event weight corresponding to each valid associated event from the event weight allocation table; S53. Obtain the preset weighted aggregation formula, and calculate the real-time maintenance progress of each maintenance task based on the total number of valid related events corresponding to each maintenance task, the event status quantification value of each valid related event, and the event weight corresponding to each valid related event.

[0039] It should be noted that in the multi-system maintenance status tracking method provided in this embodiment, the weighted aggregation formula is preset as follows: ; in, This indicates the real-time progress of the current maintenance task. Indicates the index number of the valid associated event for the current maintenance task. This represents the total number of valid associated events corresponding to the current maintenance task. Effective related events in the current maintenance task The event state quantization value, Effective related events in the current maintenance task Event weights.

[0040] In the specific implementation, within the time window of the maintenance task, the Flink operator maintains a corresponding accumulator according to the ID of the maintenance task. Whenever this accumulator receives a valid associated event belonging to the maintenance task, it updates the corresponding event state quantization value and recalculates the real-time maintenance progress of the maintenance task. The calculated real-time maintenance progress corresponding to the current event is then written back to the memory of the Flink operator as the basis for accumulating the next valid associated event.

[0041] S6. Obtain a preset maintenance report template, push the causal relationship maintenance task model and the real-time maintenance progress of each maintenance task to the front end for visualization display, and generate a corresponding maintenance report based on the maintenance report template, the maintenance status data, the causal relationship maintenance task model and the real-time maintenance progress of each maintenance task.

[0042] In one possible implementation, step S6 involves obtaining a preset maintenance report template, pushing the causal relationship maintenance task model and the real-time maintenance progress of each maintenance task to the front end for visualization, and generating a corresponding maintenance report based on the maintenance report template, the maintenance status data, the causal relationship maintenance task model, and the real-time maintenance progress of each maintenance task. This can be broken down into, but is not limited to, the following steps S61-S62, specifically including: S61. Push the causal relationship maintenance task model and the real-time maintenance progress of the maintenance tasks to the front end, perform interface layout and chart rendering of the causal relationship maintenance task model and the real-time maintenance progress of each maintenance task, and cover and display the rendered causal relationship maintenance task model and the real-time maintenance progress of each maintenance task on the large screen. S62. Obtain a preset maintenance report template, perform structured processing on the maintenance status data, the causal relationship maintenance task model, and the real-time maintenance progress of each maintenance task according to the maintenance report template, obtain a structured maintenance report, and send the maintenance report to the operation and maintenance management terminal.

[0043] In potential application scenarios, when the large screen page loads, the front end establishes a WebSocket long connection with the back end. When the Flink operator calculates the new real-time maintenance progress, it writes the update event to Redis. After the back end service detects the change, it immediately pushes this lightweight state change notification to the front end via WebSocket. The front end's JavaScript listens for the state change event, parses the received notification, and calls the vue-echarts component in the chart library to render the causal relationship maintenance task model and the real-time maintenance progress of each maintenance task into a chart, updating the rendered data on the large screen page.

[0044] like Figure 2 As shown, the second aspect of this embodiment provides a hardware system for implementing the multi-system maintenance status tracking method based on cloud-native architecture described in the first aspect of the embodiment, including: The data acquisition unit is used to acquire raw maintenance status data of various systems in real time from the cloud-native environment through multi-source heterogeneous acquisition methods. The model mapping unit is used to acquire a preset operation and maintenance knowledge graph, mix and clean the original maintenance status data of each system to obtain maintenance status data, and map the maintenance status data of each system to a unified four-dimensional model based on the operation and maintenance knowledge graph, so as to use the unified four-dimensional model with completed data mapping as the maintenance task model. The time association unit is used to generate the time window boundaries of each maintenance task based on the adaptive time window and the maintenance task model, and to perform time association optimization on the maintenance task model according to the time window boundaries of each maintenance task to obtain the time-associated maintenance task model. The association determination unit is used to perform streaming topology inference on the time-related maintenance task model by using service mesh call topology and metadata determination to obtain the causal-related maintenance task model, and to perform dual-stream association determination on the causal-related maintenance task model to obtain the effective association event set of each maintenance task. The progress calculation unit is used to obtain a preset weighted aggregation formula and calculate the real-time maintenance progress of each maintenance task based on the effective associated event set of each maintenance task using the weighted aggregation formula. The output display unit is used to obtain a preset maintenance report template, push the causal relationship maintenance task model and the real-time maintenance progress of each maintenance task to the front end for visualization display, and generate a corresponding maintenance report based on the maintenance report template, the maintenance status data, the causal relationship maintenance task model and the real-time maintenance progress of each maintenance task.

[0045] The working process, working details and technical effects of the system provided in this embodiment can be found in the first aspect of the embodiment, and will not be repeated here.

[0046] like Figure 3 As shown, the third aspect of this embodiment provides an electronic device, including: a memory, a processor, and a transceiver that are sequentially and communicatively connected, wherein the memory is used to store a computer program, the transceiver is used to send and receive messages, and the processor is used to read the computer program and execute the multi-system maintenance status tracking method based on cloud-native architecture as described in the first aspect of the embodiment.

[0047] For specific examples, the memory may include, but is not limited to, random access memory (RAM), read-only memory (ROM), flash memory, first-in-first-out (FIFO) memory, and / or first-in-last-out (FILO) memory, etc.; specifically, the processor may include one or more processing cores, such as a 4-core processor, an 8-core processor, etc. The processor may be implemented using at least one hardware form of DSP (Digital Signal Processing), FPGA (Field-Programmable Gate Array), PLA (Programmable Logic Array). The processor may also include a main processor and a coprocessor. The main processor, also known as the CPU (Central Processing Unit), is used to process data in the wake-up state; the coprocessor is a low-power processor used to process data in the standby state.

[0048] In some embodiments, the processor may integrate a GPU (Graphics Processing Unit), which is responsible for rendering and drawing the content to be displayed on the screen. For example, the processor may not be limited to microprocessors of the STM32F105 series, reduced instruction set computer (RISC) microprocessors, x86 architecture processors, or processors with integrated neural network processing units (NPUs). The transceiver may be, but is not limited to, a Wi-Fi transceiver, a Bluetooth transceiver, a General Packet Radio Service (GPRS) transceiver, a ZigBee (a low-power LAN protocol based on the IEEE 802.15.4 standard) transceiver, a 3G transceiver, a 4G transceiver, and / or a 5G transceiver. Furthermore, the electronic device may also include, but is not limited to, a power module, a display screen, and other necessary components.

[0049] The working process, working details and technical effects of the electronic device provided in this embodiment can be found in the first aspect of the embodiment, and will not be repeated here.

[0050] The fourth aspect of this embodiment provides a storage medium that stores instructions containing the multi-system maintenance status tracking method based on cloud-native architecture as described in the first aspect of the embodiment. That is, the storage medium stores instructions, and when the instructions are run on a computer, the multi-system maintenance status tracking method based on cloud-native architecture as described in the first aspect of the embodiment is executed.

[0051] The storage medium refers to a carrier for storing data, which may include, but is not limited to, floppy disks, optical disks, hard disks, flash memory, USB flash drives, and / or memory sticks. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices.

[0052] The working process, working details, and technical effects of the storage medium provided in this embodiment can be found in the first aspect of the embodiment, and will not be repeated here.

[0053] The fifth aspect of this embodiment provides a computer program product containing instructions that, when executed on a computer, cause the computer to perform the multi-system maintenance status tracking method based on cloud-native architecture as described in the first aspect of this embodiment, wherein the computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device.

[0054] Finally, it should be noted that the above description is merely a preferred embodiment of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for tracking the maintenance status of multiple systems based on a cloud-native architecture, characterized in that, include: The original maintenance status data of each system is acquired in real time from the cloud-native environment through a multi-source heterogeneous acquisition method. A preset operation and maintenance knowledge graph is obtained, and the original maintenance status data of each system is mixed and cleaned to obtain maintenance status data. Based on the operation and maintenance knowledge graph, the maintenance status data of each system is mapped to a unified four-dimensional model, and the unified four-dimensional model with completed data mapping is used as the maintenance task model. Based on the adaptive time window and the maintenance task model, the time window boundaries of each maintenance task are generated, and the maintenance task model is optimized by time correlation according to the time window boundaries of each maintenance task to obtain the time-correlated maintenance task model. By utilizing service mesh call topology and metadata determination, streaming topology inference is performed on the time-related maintenance task model to obtain a causal maintenance task model. Then, dual-stream association determination is performed on the causal maintenance task model to obtain the effective association event set for each maintenance task. Obtain a preset weighted aggregation formula, and calculate the real-time maintenance progress of each maintenance task based on the effective associated event set of each maintenance task using the weighted aggregation formula. Obtain a preset maintenance report template, push the causal relationship maintenance task model and the real-time maintenance progress of each maintenance task to the front end for visualization, and generate a corresponding maintenance report based on the maintenance report template, the maintenance status data, the causal relationship maintenance task model and the real-time maintenance progress of each maintenance task.

2. The multi-system maintenance status tracking method based on cloud-native architecture according to claim 1, characterized in that, Raw maintenance status data of various systems are acquired in real time from the cloud-native environment through a multi-source heterogeneous acquisition method, including: Through three parallel acquisition channels, monitoring indicator data, access log data, and work order data are obtained in real time from multiple maintenance systems in the cloud-native environment; The collected monitoring indicator data, access log data, and work order data are time-aligned and written to a Kafka message queue to form the original maintenance status data of each system.

3. The multi-system maintenance status tracking method based on cloud-native architecture according to claim 1, characterized in that, A pre-defined operation and maintenance knowledge graph is obtained. The original maintenance status data of each system is mixed and cleaned to obtain maintenance status data. Based on the operation and maintenance knowledge graph, the maintenance status data of each system is mapped to a unified four-dimensional model. The unified four-dimensional model with completed data mapping is used as the maintenance task model, including: The original maintenance status data of each system is identified by data type to obtain data type identification results. Based on the data type identification results, the original maintenance status data is divided into continuous index data, discrete status quantity data and status description data. Missing values ​​are detected in the continuous index data, and linear interpolation is used to fill the detected missing values. The continuous index data is then smoothed using a weighted moving average to complete the cleaning of the continuous index data. Missing values ​​are detected in the discrete state variable data, and forward filling is performed on the detected missing values ​​to complete the cleaning of the discrete state variable data. Obtain a preset state constant mapping table and perform constant mapping on the state description data to complete the cleaning of discrete state variable data. The continuous index data, discrete state quantity data, and state description data of the completed cleaning process are integrated to form maintenance state data; Obtain a preset operation and maintenance knowledge graph, extract each maintenance action from the maintenance status data, input the maintenance status data into the operation and maintenance knowledge graph, and use each maintenance action as a key to match the data associated with each maintenance action from the operation and maintenance knowledge graph as valid maintenance status data. A preset unified four-dimensional model is obtained, and the effective maintenance status data is mapped to the four dimensions of the unified four-dimensional model to obtain a unified four-dimensional model with completed data mapping. The unified four-dimensional model with completed data mapping is output as the maintenance task model. The four dimensions of the unified four-dimensional model include the maintenance task life cycle, maintenance task indicators, maintenance task event chain, and maintenance task abnormal information.

4. The multi-system maintenance status tracking method based on cloud-native architecture according to claim 3, characterized in that, Based on the adaptive time window and the maintenance task model, time window boundaries for each maintenance task are generated. Then, time correlation optimization is performed on the maintenance task model according to the time window boundaries of each maintenance task to obtain a time-correlated maintenance task model, including: Each maintenance action is extracted from the maintenance status data. Based on the action type of each maintenance action, the historical maintenance task data corresponding to each action type is obtained from the cloud-native environment. The task completion time of each historical maintenance task corresponding to each action type is extracted from the historical maintenance task data corresponding to each action type. Based on the historical maintenance task completion time corresponding to each action type, the average historical task completion time and the standard deviation of historical task completion time corresponding to each action type are calculated. Obtain the preset time window adjustment coefficient, and calculate the corresponding time window length for each maintenance task in the maintenance status data based on the average historical task completion time and standard deviation of historical task completion time corresponding to each action type, as well as the time window adjustment coefficient. The time window length corresponding to each maintenance task is used as the time window boundary of the maintenance task. The life cycle of each maintenance task in the maintenance task model is associated, so that the maintenance task event chain that exceeds the time window boundary in each maintenance task is removed in the maintenance task model, and a time-related maintenance task model is obtained.

5. The multi-system maintenance status tracking method based on cloud-native architecture according to claim 1, characterized in that, By utilizing service mesh call topology and metadata determination, streaming topology inference is performed on the time-related maintenance task model to obtain a causal maintenance task model. Then, dual-stream association determination is performed on the causal maintenance task model to obtain the effective association event set for each maintenance task, including: Obtain the directed graph stored internally by the streaming operator, obtain the inter-service network call information output by the service mesh under the cloud-native architecture through the streaming operator, construct a request call chain based on the inter-service network call information, and add the request call chain to the directed graph to form a service mesh call topology; Multiple maintenance tasks are extracted from the time-related maintenance task model, and the maintenance task event chain of each maintenance task is extracted to obtain each event corresponding to each maintenance task. For each maintenance task, obtain the service name of each event source, and match the service name of each event source with each topology node in the service mesh call topology to determine whether the service name of each event source matches each topology node in the service mesh call topology. If so, the event is determined to be a causal event; otherwise, the event is determined to be background noise. For each maintenance task, the various causal events are integrated to form a set of causal events for each maintenance task. In the causal event set of each maintenance task, the cloud-native container orchestration platform metadata of each causal event is obtained. The cloud-native container orchestration platform metadata of each causal event is matched with the maintenance target pointed to by the corresponding maintenance task. Based on the matching result, the causal event set of each maintenance task is filtered. The time-related maintenance task model is updated using the causal event set of each maintenance task after the event filtering is completed, and the causal maintenance task model is obtained. The corresponding causal events are extracted from the causal relationship maintenance task model as an event stream, and the work order data is extracted from the maintenance status data as a work order data stream. The maintenance target pointed to by each maintenance task is used as the matching key, and the approval time of the work order data is used as the judgment criterion. The event stream and the work order data stream are correlated and judged. Each event that matches the approval time of the work order data is selected as a valid correlation event. The valid correlation events are integrated to form a set of valid correlation events for each maintenance task.

6. The multi-system maintenance status tracking method based on cloud-native architecture according to claim 1, characterized in that, Obtain a preset weighted aggregation formula, and calculate the real-time maintenance progress of each maintenance task based on the effective associated event set of each maintenance task using the weighted aggregation formula, including: Obtain a preset event status quantification comparison table, and based on the effective associated event set of each maintenance task, count the total number of effective associated events corresponding to each maintenance task. Extract the event status of each effective associated event from the maintenance status data, and quantify the event status of each effective associated event according to the event status quantification comparison table to obtain the event status quantification value of each effective associated event. Obtain a preset event weight allocation table, and use the event name of each valid associated event to match the event weight corresponding to each valid associated event from the event weight allocation table; Obtain a preset weighted aggregation formula, and calculate the real-time maintenance progress of each maintenance task based on the total number of valid associated events corresponding to each maintenance task, the event status quantification value of each valid associated event, and the event weight corresponding to each valid associated event.

7. The multi-system maintenance status tracking method based on cloud-native architecture according to claim 1, characterized in that, Obtain a preset maintenance report template, push the causal relationship maintenance task model and the real-time maintenance progress of each maintenance task to the front end for visualization, and generate a corresponding maintenance report based on the maintenance report template, the maintenance status data, the causal relationship maintenance task model, and the real-time maintenance progress of each maintenance task, including: The front end pushes the causal relationship maintenance task model and the real-time maintenance progress of the maintenance tasks, performs interface layout and chart rendering of the causal relationship maintenance task model and the real-time maintenance progress of each maintenance task, and displays the rendered causal relationship maintenance task model and the real-time maintenance progress of each maintenance task on a large screen. Obtain a preset maintenance report template, and perform structured processing on the maintenance status data, the causal relationship maintenance task model, and the real-time maintenance progress of each maintenance task according to the maintenance report template to obtain a structured maintenance report, and send the maintenance report to the operation and maintenance management terminal.

8. A multi-system maintenance status tracking system based on cloud-native architecture, characterized in that, The method for tracking the maintenance status of a multi-system system based on a cloud-native architecture, as described in any one of claims 1 to 7, includes: The data acquisition unit is used to acquire raw maintenance status data of various systems in real time from the cloud-native environment through multi-source heterogeneous acquisition methods. The model mapping unit is used to acquire a preset operation and maintenance knowledge graph, mix and clean the original maintenance status data of each system to obtain maintenance status data, and map the maintenance status data of each system to a unified four-dimensional model based on the operation and maintenance knowledge graph, so as to use the unified four-dimensional model with completed data mapping as the maintenance task model. The time association unit is used to generate the time window boundaries of each maintenance task based on the adaptive time window and the maintenance task model, and to perform time association optimization on the maintenance task model according to the time window boundaries of each maintenance task to obtain the time-associated maintenance task model. The association determination unit is used to perform streaming topology inference on the time-related maintenance task model by using service mesh call topology and metadata determination to obtain the causal-related maintenance task model, and to perform dual-stream association determination on the causal-related maintenance task model to obtain the effective association event set of each maintenance task. The progress calculation unit is used to obtain a preset weighted aggregation formula and calculate the real-time maintenance progress of each maintenance task based on the effective associated event set of each maintenance task using the weighted aggregation formula. The output display unit is used to obtain a preset maintenance report template, push the causal relationship maintenance task model and the real-time maintenance progress of each maintenance task to the front end for visualization display, and generate a corresponding maintenance report based on the maintenance report template, the maintenance status data, the causal relationship maintenance task model and the real-time maintenance progress of each maintenance task.

9. An electronic device, characterized in that, The system includes a memory, a processor, and a transceiver that are sequentially and communicatively connected. The memory is used to store computer programs, the transceiver is used to send and receive messages, and the processor is used to read the computer programs and execute the multi-system maintenance status tracking method based on cloud-native architecture as described in any one of claims 1 to 7.

10. A computer program product, comprising a computer program or instructions, characterized in that, When the computer program or the instructions are executed by the computer, they implement the multi-system maintenance status tracking method based on cloud-native architecture as described in any one of claims 1 to 7.

Images