Operation and maintenance method and system

Abstract

This application provides an operation and maintenance method and system. The method includes: acquiring operational data of a target business system; based on a first intelligent agent, when an anomaly is determined in the operational data, inferring current operation and maintenance command information based on the anomaly data in the operational data and writing it to a file system; based on a second intelligent agent, acquiring the current operation and maintenance command information from the file system, performing a security assessment on the current operation and maintenance command information, obtaining a risk level of the current operation and maintenance command information, and writing it to the file system; acquiring the risk level from the file system, and when it is determined that the risk level is lower than a preset level, performing operation and maintenance processing on the target business system based on the current operation and maintenance command information, obtaining the current operation and maintenance result, and writing it to the file system. This method aims to improve the security of operation and maintenance.

Description

Technical Field

[0001] This application relates to the field of operation and maintenance technology, and in particular to an operation and maintenance method and an operation and maintenance system. Background Technology

[0002] With the large-scale deployment of cloud computing and distributed systems, intelligent operation and maintenance has become a core means to ensure the stable operation of various business systems, quickly handle operational anomalies, and reduce manual operation and maintenance costs.

[0003] Currently, intelligent operation and maintenance (O&M) solutions generally adopt an integrated centralized control architecture, which integrates all intelligent O&M functions into a single control entity. This results in high coupling between functional modules, with operational data and interactive information largely relying on internal system synchronous calls and temporary memory interactions for flow. However, under this architecture, O&M command output is prone to self-generation and self-auditing vulnerabilities, leading to a lack of independence and objectivity in security assessments and consequently, lower O&M security. Summary of the Invention

[0004] The operation and maintenance method and system provided in this application are used to improve the security of operation and maintenance.

[0005] In a first aspect, embodiments of this application provide an operation and maintenance method, the method being applied to an operation and maintenance system; including:

[0006] Obtain operational data from the target business system;

[0007] Based on the first intelligent agent, when it is determined that there is an anomaly in the running data, the operation and maintenance command information for this operation is inferred from the abnormal data in the running data and then written to the file system.

[0008] Based on the second intelligent agent, the operation and maintenance command information for this operation and maintenance is obtained from the file system, and the operation and maintenance command information for this operation and maintenance is subjected to security assessment processing. After obtaining the risk level of the operation and maintenance command information for this operation and maintenance is written to the file system.

[0009] The risk level is obtained from the file system, and when the risk level is determined to be lower than the preset level, the target business system is operated and maintained based on the operation and maintenance command information of this operation and maintenance, and the operation and maintenance result is written to the file system.

[0010] In one possible implementation, the step of inferring the current maintenance operation command information based on abnormal data in the operational data includes:

[0011] Based on the first intelligent agent, the operation and maintenance command to be executed is inferred from the abnormal data in the operation data.

[0012] The operation and maintenance command to be executed is matched with the preset format rules to generate structured operation and maintenance command information for this operation and maintenance.

[0013] In one possible implementation, the format rules include the following fields: the operation and maintenance command to be executed, the target host, the reasoning basis for the command generation, the risk level, the approval status, and the expected output format.

[0014] In one possible implementation, the step of performing a security assessment on the current maintenance operation command information to obtain the risk level of the current maintenance operation command information includes:

[0015] Based on the second intelligent agent, the security assessment of the current operation and maintenance command information is performed from multiple preset dimensions to obtain the risk level of the current operation and maintenance command information; wherein, the preset dimensions include at least one of the following dimensions: command structure legality, command semantic risk, target host compliance, and business access permission matching.

[0016] In one possible implementation, the step of performing maintenance processing on the target business system based on the current maintenance operation command information to obtain the maintenance result includes:

[0017] The operation and maintenance command information is sent to the execution agent module, so that the execution agent module can perform operation and maintenance processing on the target business system based on the operation and maintenance command information and obtain the operation and maintenance results.

[0018] In one possible implementation, the method further includes:

[0019] If the risk level is determined to be higher than or equal to the preset level, the manual review result of the current operation and maintenance command information is obtained, and the target business system is operated and maintained based on the manual review result to obtain the operation and maintenance result.

[0020] In one possible implementation, the manual review result is either an approved execution or a manually modified operation and maintenance command; the operation and maintenance processing of the target business system based on the manual review result to obtain the operation and maintenance result includes:

[0021] When the manual review result is "agree to execute", the target business system is subjected to operation and maintenance processing based on the operation and maintenance command information of this operation and maintenance, and the operation and maintenance result is obtained.

[0022] When the manual review result is the manually modified operation and maintenance command information, the target business system is operated and maintained based on the manually modified operation and maintenance command information to obtain the operation and maintenance result.

[0023] In one possible implementation, the method further includes:

[0024] When the manual review result is "reject execution", the new operation and maintenance command information is re-inferred based on the first intelligent agent, according to the abnormal data and the rejection reason in the manual review result.

[0025] In one possible implementation, the method further includes:

[0026] Based on the first intelligent agent, the current operation and maintenance result is obtained from the file system, and iterative reasoning is performed based on the current operation and maintenance result to obtain the next operation and maintenance command information.

[0027] Secondly, embodiments of this application provide an operation and maintenance device, which is applied to an operation and maintenance system and includes:

[0028] The acquisition module is used to acquire runtime data from the target business system.

[0029] The reasoning module is used to, based on the first intelligent agent, infer the current operation and maintenance command information from the abnormal data in the operation data when it is determined that there is an anomaly in the operation data, and then write it to the file system.

[0030] The evaluation module is used to obtain the current operation and maintenance command information from the file system based on the second intelligent agent, perform security evaluation processing on the current operation and maintenance command information, obtain the risk level of the current operation and maintenance command information, and write it into the file system.

[0031] The determination module is used to obtain the risk level from the file system, and when the risk level is determined to be lower than the preset level, to perform operation and maintenance processing on the target business system based on the operation and maintenance command information of this operation and maintenance, and then write the operation and maintenance result to the file system.

[0032] Thirdly, embodiments of this application provide a server, including: a memory and a processor;

[0033] The memory stores computer-executed instructions;

[0034] The processor executes computer execution instructions stored in the memory, causing the processor to perform the first aspect and / or various possible implementations of the first aspect as described above.

[0035] Fourthly, embodiments of this application provide an operation and maintenance system, including at least one server, which performs the first aspect and / or various possible implementations of the first aspect.

[0036] Fifthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the first aspect and / or various possible implementations of the first aspect.

[0037] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the first aspect and / or various possible implementations of the first aspect.

[0038] The operation and maintenance method and system provided in this application collect operational status data of the target business system. An independent first intelligent agent identifies data anomalies and generates structured operation and maintenance commands. This data is then stored on a file system. A second intelligent agent, deployed in isolation, asynchronously reads the command information and performs an independent security assessment. The assessed risk level is then stored back to the file system. Finally, based on the risk level determination, low-risk operation and maintenance operations are automatically performed. Key data generated at each step is persistently written to the file system. This approach abandons the tightly coupled design of traditional integrated centralized operation and maintenance architectures. By separating the responsibilities of two intelligent agents, the main bodies for command generation and security assessment are isolated. This avoids the control defects of a single self-audit entity from the root of the architecture, ensuring the objectivity and independence of security assessment results. Furthermore, the file system enables asynchronous decoupling and collaboration among various business processes, effectively reducing module dependencies. Simultaneously, key data throughout the entire process is uniformly retained and stored, completely recording the operation and maintenance handling chain, improving the traceability and compliance of operation and maintenance behavior. Overall, this optimizes the operational security and architectural adaptability of the intelligent operation and maintenance model in production business scenarios. Attached Figure Description

[0039] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0040] Figure 1 This is a schematic diagram of the structure of an operation and maintenance system provided in an embodiment of this application;

[0041] Figure 2 This is a schematic diagram of another operation and maintenance system provided in an embodiment of this application;

[0042] Figure 3 Flowchart of the operation and maintenance method provided in this application Figure 1 ;

[0043] Figure 4 Flowchart of the operation and maintenance method provided in this application Figure 2 ;

[0044] Figure 5A schematic diagram illustrating an application scenario provided in an embodiment of this application;

[0045] Figure 6 A schematic diagram of the operation and maintenance device provided in this application;

[0046] Figure 7 This is a schematic diagram of the server structure provided in this application.

[0047] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0048] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0049] In daily production operations and maintenance, online services often experience various failures such as performance degradation, interface response timeouts, and cluster node anomalies. In such scenarios, it's often necessary to log into the target server specifically to perform a series of diagnostic operations, including resource status checks, service process monitoring, log retrieval and analysis, network connectivity verification, and database connection testing. Due to the high business continuity requirements and strict access control in production environments, it's not possible to execute maintenance commands arbitrarily. The core limiting factors are mainly reflected in four aspects:

[0050] First, operational permissions in the production environment are highly sensitive, and direct access by AI systems is strictly prohibited. Incorrect input of maintenance commands can easily lead to high-risk behaviors such as accidental deletion of business files or forced shutdown of core services, potentially causing large-scale online business failures. Therefore, the industry has established unified security standards that strictly prohibit AI tools such as Large Language Models (LLMs) and intelligent agents from directly logging into production servers to execute commands. Second, the execution of production maintenance commands must follow a complete and rigorous approval process. Even qualified professional maintenance personnel must undergo manual secondary confirmation or compliance review by the security management team before executing server commands. This ensures accurate verification of the command content, target host scope, and impact range, guaranteeing controllable operational risks and preventing unauthorized operations. Third, existing AI-powered maintenance agents can only output plain text reference suggestions and cannot complete the closed loop of production environment maintenance operations. For example, outputting "You can execute xxx command" cannot connect to the actual online business environment, cannot participate in command execution, and cannot form a traceable and verifiable complete maintenance task execution chain. Fourth, the risk levels of commands vary significantly across different operation and maintenance scenarios, necessitating the support of automated and intelligent security assessment capabilities. Specifically, read commands used solely for querying system running status have the lowest risk level; commands involving configuration modification, service restart, and resource changes are considered high-risk operations; and some core control commands require super administrator privileges to execute.

[0051] To address the aforementioned pain points in operation and maintenance, the existing intelligent operation and maintenance system has formed a basic solution: relying on AI intelligent agents to automatically generate operation and maintenance troubleshooting instructions based on fault scenarios, completing instruction security risk assessment through systematic rules, and finally implementing various operation and maintenance troubleshooting and handling tasks after manual compliance approval, covering three core capabilities: abnormal data analysis, intelligent generation of operation and maintenance instructions, and operation risk security assessment.

[0052] However, current intelligent operation and maintenance solutions generally adopt an integrated centralized control architecture, which highly integrates core functions such as abnormal data analysis, operation and maintenance command generation, and security risk assessment into the same control entity. The functional modules are highly coupled, and the flow of operational data and interactive information between modules mainly relies on internal system synchronous calls and temporary memory interactions. However, under this architecture, the operation and maintenance command generation and security risk verification stages lack independent and isolated execution entities, which can easily lead to control vulnerabilities such as self-generation and self-verification of commands. This results in a lack of independence and objectivity in security risk assessment results, leading to potential risks in the overall security control mechanism. The security compliance of operation and maintenance management is insufficient, the architecture lacks flexibility and scalability, and it is difficult to adapt to the complex and ever-changing production operation and maintenance security management needs.

[0053] Addressing the inherent technical flaws of integrated centralized operation and maintenance architectures in related technologies—namely, highly coupled functions and the centralization of all operation and maintenance control functions within a single control entity—which easily lead to self-generation and self-auditing of operation and maintenance commands, a lack of independent checks and balances in security assessments, insufficient objectivity of assessment results, and difficulty in guaranteeing overall operation and maintenance security, the inventors moved beyond the traditional single integrated control design mindset. Recognizing that relying solely on internal rule optimization cannot fundamentally avoid risk control vulnerabilities at the architectural level, they conceived a method to reconstruct the operation and maintenance collaboration model through responsibility decomposition and entity isolation. This involves decoupling and separating operation and maintenance command generation from command security assessment, and configuring mutually independent and isolated dual intelligent agents. It carries dedicated functions for fault reasoning, command generation, security assessment, and risk classification. At the same time, it abandons the existing technology's reliance on internal synchronous calls and temporary memory data interaction, and introduces a file system as a standardized and persistent intermediate interaction carrier. It relies on cross-agent file read and write interaction to complete asynchronous data flow and information transmission. From the architectural level, it achieves complete isolation and checks and balances between the command production stage and the security review stage, avoids the control risks caused by the concentration of permissions of a single subject, ensures that the security assessment work is carried out independently and objectively, effectively solves the security shortcomings of the existing solutions, and comprehensively improves the security protection capabilities of the entire intelligent operation and maintenance process.

[0054] Figure 1 This is a schematic diagram of the structure of an operation and maintenance system provided in an embodiment of this application, such as... Figure 1 As shown, the operation and maintenance system may include at least one server. Figure 1 This example only uses two servers for illustration; the number of servers is not limited in this embodiment. The operation and maintenance system can be deployed in an enterprise's internal data center, private cloud platform, hybrid cloud environment, or a centralized operation and maintenance platform for distributed business systems. The executing entity can be a server within the operation and maintenance system. In some possible implementations, this server may also be referred to as a task node.

[0055] Among some possible implementations, Figure 2 This is a schematic diagram of another operation and maintenance system provided in an embodiment of this application. The above-mentioned operation and maintenance system adopts the design concept of centralized scheduling, module decoupling, and permission isolation. At the software level, it mainly includes a management node, a first intelligent agent, a second intelligent agent, a file system, an execution agent module, and an approval module. Each module is deployed independently and has a clear division of labor. The file system serves as a unified data flow carrier, and the management node coordinates the entire process of collaborative scheduling. From the software architecture level, it takes into account both operation and maintenance automation capabilities and production business security.

[0056] The management node can be deployed on at least one server of the operation and maintenance system. As the global scheduling core and control center of the operation and maintenance system, it is responsible for the overall task orchestration, process logic control, risk level threshold configuration, and unified management of module permissions. It reads the risk level data in the file system in real time, automatically distinguishes between low-risk branches that are automatically executed and high-risk branches that are manually reviewed, coordinates the distribution of operation and maintenance tasks, synchronizes the flow status, summarizes the processing data of the entire chain, and coordinates the orderly operation of various software modules.

[0057] The first intelligent agent can be deployed as an independent microservice on at least one server in the operations and maintenance system. It is responsible for anomaly identification and operations and maintenance command generation. It continuously receives operational data collected from the business system, automatically identifies abnormal conditions in the operational data, and combines the abnormal data with preset format rules to infer and generate structured operations and maintenance command information, which is then written to the file system. Simultaneously, it can read the operations and maintenance execution results stored in the file system, perform iterative inference based on feedback data, and generate subsequent continuous operations and maintenance instructions. It should be noted that this first intelligent agent passively receives operational data such as operational metrics, logs, and status from the business system only through the data acquisition link; it cannot actively access or operate the business system. This first intelligent agent can also be called a diagnostic agent.

[0058] The second intelligent agent is deployed as an independent software service on at least one server within the operations and maintenance system, completely isolated from the first intelligent agent and the business system. This second intelligent agent acts as an independent security review unit, asynchronously reading operations and maintenance command information generated by the first intelligent agent from the file system. It conducts automated security assessments from multiple dimensions, including command structure, semantic risks, host compliance, and business permissions, generating standardized risk levels and writing them to the file system. It independently completes the entire risk assessment process, achieving a separation of command generation and security assessment, avoiding architectural vulnerabilities caused by a single entity generating and reviewing its own data, and ensuring the objectivity and neutrality of the security assessment results. This second intelligent agent can also be referred to as a security review agent.

[0059] The file system (FS Workspace) is built upon distributed shared storage software services. As a dedicated data middleware layer for the operations and maintenance (O&M) system, it is divided into independent, isolated directories based on function. It categorizes and stores data such as O&M commands, risk levels, and O&M results, and configures granular read / write permission policies for different modules. This file system serves as a unified, persistent data interaction carrier between modules and dual agents, handling the entire data flow. It centrally stores core information such as structured O&M commands, risk assessment levels, and O&M execution results. It supports asynchronous reading and independent writing by each module, breaking down the strong coupling and synchronous call limitations of traditional integrated architectures, and achieving decoupled collaboration between various stages. Simultaneously, it completely retains the entire process operation record, providing data support for O&M auditing and behavior tracing.

[0060] Optionally, the file system has a secure exchange channel (Result Collector), also known as a result feedback module, used to communicate with various agents, execution agent modules, management nodes, and approval modules.

[0061] For example, a file system is a structured exchange medium that may include the following directories:

[0062] The requests / directory is used to store operation and maintenance commands to be executed.

[0063] The security_review / directory is used to store the output of the second agent (including risk levels).

[0064] The `approval / ` directory is used to store the output content of the approval module.

[0065] The results / directory is used to store operation and maintenance results;

[0066] The analysis directory is used to store the subsequent inference output of the first agent;

[0067] The logs / directory is used to store archived logs.

[0068] It should be noted that this application embodiment utilizes a file system for context management (FS-Based ContextOrchestration), meaning the file system serves as the context carrier for the entire execution chain. Each operation and maintenance command information independently forms a corresponding task processing node. The input information and output content generated during the operation of each task node are completely recorded and stored in file form. The complete inference chain of the intelligent agent can flexibly read and retrieve various archived files to support continuous analysis and iterative decision-making. The entire process processing links form a coherent and orderly time sequence record according to the actual execution time. Relying on this file-based context management architecture, it can smoothly support full-chain operation auditing, fault tracing and backtracking, and routine automated operation and maintenance with high efficiency. At the same time, the data stored in the file system can also be used as a dataset for supervised fine-tuning (SFT) or reinforcement learning from human feedback (RLHF) to iteratively optimize and train each intelligent agent.

[0069] The Executor module is a lightweight software program deployed locally and in a distributed manner on various business servers, cluster nodes, and business edge gateways, running close to the business systems. It is a software unit that brings the operations and maintenance system down to the business environment. This Executor module receives legitimate operations and maintenance instructions from the management node, parses structured operations and maintenance commands in the file system, and performs compliant troubleshooting, resource detection, service control, and other operations and maintenance operations on the target business system. It also collects unified operation feedback information, generates standardized operations and maintenance results, and writes them back to the file system. Furthermore, it isolates the upper-layer intelligent agent from the business environment, intercepts unauthorized operation requests, and prevents the intelligent agent from directly accessing production operations. Optionally, the Executor module can directly write the operations and maintenance results to the file system, or it can first return the results to the management node based on a preset callback interface, and then the management node writes the results to the file system.

[0070] Optionally, the execution agent module may be an automated script executor (such as Jenkins, ArgoCD, Rundeck, CI / CD Runner), a remote command agent (such as Ansible Runner), a host operation and maintenance agent, a container orchestration platform interface, a database operation and maintenance gateway, a manual operation and maintenance terminal (manually copying command execution), or a controlled orchestration service. This application embodiment does not limit the scope of the application.

[0071] The approval module is a software client deployed on the office terminals of operations and security management personnel. It provides a human-machine collaborative interaction interface, specifically handling high-risk operations and maintenance processes, receiving high-risk command review work orders pushed by management nodes, and visually displaying key information such as the content of the operations and maintenance command, target host, risk level, and assessment opinions. It supports operations and maintenance personnel in completing manual operations such as approving execution, modifying commands, and rejecting requests, supplementing the manual control capabilities for high-risk scenarios. This approval module can take the form of a web interface, command-line interface, enterprise internal communication software, Slack approval robot, Jenkins / GitOps risk approval process, etc., and this embodiment does not limit the specific implementation.

[0072] The aforementioned operation and maintenance system uses the management node as the scheduling core and the file system as the data bridge to achieve decoupled collaboration between the two intelligent agents. From the software architecture perspective, it solves the problems of high coupling, lack of independent security assessment, and high risk of direct connection of intelligent agents to the production environment in the traditional integrated operation and maintenance architecture.

[0073] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0074] Figure 3 Flowchart of the operation and maintenance method provided in this application Figure 1 ,like Figure 3 As shown, the method includes:

[0075] S201. Obtain the operating data of the target business system.

[0076] For example, the target business system refers to various online business clusters, application services, database nodes, and containerized business platforms that require operational status monitoring, fault diagnosis, and daily operation and maintenance management. This target business system can be a monolithic application, a microservice system, a database service cluster, a container orchestration cluster, a middleware platform, a caching service, or a comprehensive business environment including host, network, storage, and application components; this embodiment does not limit the scope of the application.

[0077] Operational data is used to characterize the operating status of the target business system at the current moment or within a specified time window. It may include the utilization rate of the Central Processing Unit (CPU), memory usage, disk I / O (Input / Output), network throughput, network latency, process status, number of threads, log information, number of connections, database session status, interface response time, error code distribution, number of container restarts, and health check results.

[0078] In one example, the server's management node can continuously capture real-time operational data of the target business system through a data acquisition link deployed on the business environment side, and then uniformly aggregate it to the operation and maintenance system via a dedicated intranet transmission link.

[0079] In practice, the operations and maintenance system can pre-connect to data collection sources from multiple business systems to achieve continuous state awareness of the target business system. For example, monitoring probes deployed on host nodes can collect CPU, memory, disk, and process-level metrics; log collectors can capture application logs, system logs, and middleware logs in real time; database proxy interfaces can obtain connection pool status, slow query statistics, and lock wait information; container runtime interfaces can obtain container health status, resource limits, and restart records; and service gateways or application performance monitoring interfaces can obtain interface latency, success rate, and upstream and downstream dependency call information.

[0080] In one possible embodiment, the data collection mode can adopt a timed polling method. The server of the operation and maintenance system can initiate a collection request to the target business system based on the management node according to a preset sampling period and write the returned results to a unified data cache. In another possible embodiment, the collection mode can adopt an event-triggered method. When an alarm threshold is triggered, a node becomes disconnected, a service probe fails, or a specific abnormal keyword appears in the log, an enhanced collection process targeting the relevant host, instance, and time window is immediately initiated. Timed collection can also be combined with event-triggered collection to balance continuity and timeliness.

[0081] To support subsequent agent inference, this embodiment of the application can also perform standardization processing after acquiring the runtime data. Specifically, the server of the operation and maintenance system can perform time alignment, field mapping, host identifier normalization, unit conversion, and missing value completion on data from different data sources based on the management node. For example, hostnames reported by different collectors are uniformly mapped to asset numbers, CPU utilization is uniformly converted to percentages, log timestamps are converted to a unified time zone format, and application instances, database instances, and network link indicators belonging to the same business link are associated under the same context object. The runtime data formed in this way not only includes the original monitoring values, but also contextual information such as business system identifier, node identifier, collection time, alarm source, associated components, and abnormal window range, which facilitates the subsequent identification of abnormal data.

[0082] S202. Based on the first intelligent agent, when it is determined that there is an anomaly in the running data, the operation command information for this operation and maintenance is inferred from the abnormal data in the running data and then written to the file system.

[0083] For example, the first intelligent agent is a software processing entity with analysis, reasoning, and decision-making capabilities, specifically designed for anomaly assessment and operation and maintenance command generation. The first intelligent agent can be a diagnostic intelligent agent deployed within an operation and maintenance system. Its core function is to generate operation and maintenance operation command information adapted to the current anomaly scenario based on anomaly data and its contextual information, combined with an operation and maintenance knowledge base, rule base, historical fault cases, dependency graphs, or semantic reasoning models.

[0084] Anomaly data refers to characteristic data in operational data that can characterize abnormal business performance or operational failures. It can be understood that anomalies in operational data can refer to deviations from preset thresholds, historical baselines, average values ​​of similar nodes, time series prediction results, or the normal range defined by the operation and maintenance rule base.

[0085] The operation and maintenance command information in this context refers to a set of machine-executable instructions used to diagnose, inspect, or handle the target business system. These instructions can manifest as Shell commands, database query commands, container management commands, network probe commands, service control commands, or encapsulated script call commands. Inferring this operation and maintenance command information means that the first intelligent agent does not simply return a pre-set script, but rather filters, sorts, and combines candidate operations based on the anomaly type, location, and severity reflected in the abnormal data, and then outputs the specific command content corresponding to this anomaly handling task.

[0086] A file system is a shared storage medium within an operations and maintenance system used for cross-module data interaction, persistent storage, and asynchronous data transfer. This file system can be a local disk directory, a shared file directory, a network attached storage directory, or a directory structure formed by object storage mapping. Writing to the file system refers to saving the commands and information of this operations and maintenance operation to a preset directory in a persistent, readable, and traceable file format.

[0087] In one example, the first intelligent agent receives the collected operational data, identifies abnormal data based on the built-in anomaly detection logic, autonomously infers and generates appropriate operation and maintenance instructions based on the anomaly occurrence scenario, encapsulates the instructions into standardized command information, and persistently stores them in a specified directory of the file system by writing to a file.

[0088] At the anomaly identification level, the operation and maintenance system can determine whether there are anomalies in the operational data based on threshold rules, trend analysis, correlation comparison, or anomaly detection models. For example, when CPU utilization continuously exceeds a set threshold and is accompanied by a significant increase in interface response time, a performance anomaly can be identified; when the number of database connections suddenly increases in a short period of time and the connection establishment failure rate increases, a database resource shortage anomaly can be identified; when timeouts, connection rejections, memory overflows, or node unreachable keywords continuously appear in the logs, an operational anomaly can also be identified. For distributed scenarios, similar indicators of multiple nodes can also be compared horizontally to identify local node anomalies or link-type anomalies. The above process transforms the operational data from raw monitoring information into anomaly data that can be used by the first intelligent agent, forming a clear scope of anomalies, anomaly objects, and evidence of anomalies.

[0089] Furthermore, the first intelligent agent can perform semantic analysis and fault scenario modeling on abnormal data. For example, when receiving abnormal data such as "CPU usage of an application instance consistently exceeds 95%, interface timeout rate increases, and system load increases," the first intelligent agent can classify this scenario as a fault type of "high load leading to service performance degradation." When receiving abnormal data such as "sudden increase in database connection count, increase in slow query count, and application-side connection acquisition failure," it can be classified as a fault type of "database connection congestion or session anomaly." When receiving abnormal data such as "node health check failure, increased network packet loss, and cross-service call timeout," it can be classified as a fault type of "network connectivity anomaly or node disconnection." After completing the scenario classification, the first intelligent agent can retrieve the corresponding diagnostic path from the knowledge base and fill in the command template with parameters based on the environmental attributes of the current target business system, such as the host address, container name, service instance identifier, database name, log path, time window, or network target address, to obtain the command information for this operation and maintenance.

[0090] In one possible embodiment, if the anomaly manifests as abnormal CPU resource usage, the first intelligent agent can generate operation command information for viewing high-utilization processes, thread resource distribution, system load details, and recent system logs; if the anomaly manifests as abnormal database connection, it can generate operation command information for querying session status, lock wait status, slow query logs, and connection pool usage; if the anomaly manifests as abnormal network link, it can generate operation command information for connectivity detection, port detection, route tracing, and network interface statistics queries.

[0091] It should be noted that in this embodiment of the application, there is no limit to the number of commands to be executed included in the current operation and maintenance command information. For example, multiple related commands can be encapsulated into a list of commands with an execution order, and each command can be appended with the reason for generation, target object, applicable scope, and expected purpose. For example, in the same current operation and maintenance command information, it can be recorded that "the first command is used to query process resource usage, the second command is used to pull the corresponding log fragment, and the third command is used to verify the status of related dependent services".

[0092] When writing to the file system, the operations and maintenance system server can assign a unique task number to this exception handling task based on the management node, and generate a command file using the task number, business system identifier, and timestamp as the file naming basis. This command file can be stored in a structured format, including fields such as task identifier, exception summary, command text, command type, target host, target service, generation time, generation subject, dependency context, and command description. For example, the file can record information such as "task number, exception type, exception evidence, recommended command, command parameters, execution preconditions, and prohibition conditions." In another implementation, the command content and context can be split into a main file and a metadata file, and associated with the same task number. Optionally, a signature digest or checksum can be added to the command file to identify whether the file has been modified without authorization.

[0093] Based on the above analysis, this step transforms abnormal operational data into executable, evaluable, and traceable operation and maintenance commands through the first intelligent agent. This elevates anomaly diagnosis beyond manual reading of alarms and verbal suggestions, generating standardized outputs with machine processing capabilities. Furthermore, because the operation and maintenance commands are first written to the file system rather than directly driving the executor to the production environment, a structural isolation boundary is established between diagnostic reasoning and production execution, reducing the risk of direct misoperation of the production system due to reasoning errors.

[0094] S203. Based on the second intelligent agent, obtain the operation and maintenance command information of this operation and maintenance command information from the file system, perform security assessment on the operation and maintenance command information of this operation and maintenance command information, and write it into the file system after obtaining the risk level of the operation and maintenance command information of this operation and maintenance command information.

[0095] For example, the second intelligent agent may be an independently deployed security audit intelligent agent, a policy evaluation service, or a control module with command auditing capabilities. Its processing target is not the anomaly itself, but the operation and maintenance command information generated by the first intelligent agent and the context corresponding to the command.

[0096] Security assessment refers to determining the potential system impact of a command based on security rules, command semantics, target environment attributes, permission boundaries, historical execution consequences, and current business status.

[0097] Risk level is used to characterize the degree of risk that may be brought about after the execution of this operation and maintenance command information. It can adopt a three-level mode of high, medium and low, or a more granular level system, such as severe, high, normal and low.

[0098] In one example, the server actively reads the operation and maintenance command information stored in the file system based on the second intelligent agent, completes automated security assessment from multiple risk control dimensions, outputs the corresponding quantitative risk level, and synchronously writes the risk level result to the file system.

[0099] In practice, the server, based on a second intelligent agent, can periodically scan the directory to be evaluated in the file system, or discover new command files by monitoring file creation events, and read the corresponding command content, anomaly summary, and target object information according to the task number. After reading, the server, based on the second intelligent agent, can first perform structural verification to confirm that key fields such as task identifier, time information, command text, and target host in the command file are complete and valid. If missing fields, format errors, or inconsistent command file verification values ​​are found, the risk level can be directly marked as high risk or abnormal state, and the reason can be written into the evaluation result file to prevent non-standard tasks from entering the execution stage.

[0100] During security assessments, servers based on a second intelligent agent can comprehensively employ multiple judgment mechanisms. For example, sensitive behaviors such as deletion, overwriting, formatting, stopping, restarting, permission changes, configuration modifications, and batch operations can be identified through keyword matching; high-risk characteristics such as wildcards, wide-range paths, recursive deletion, high-privilege calls, dangerous redirections, forced overwriting, or script download and execution can be identified through regular expression parsing and command abstraction syntax analysis; sensitivity analysis can be performed on command parameters, such as identifying whether the target path is a critical system directory, whether the target service is a core production service, whether the target database is the primary instance, and whether the target host belongs to a critical business cluster; contextual verification can also be performed based on the current business time window, for example, increasing the risk rating of service restart commands during peak business periods and increasing the review level of configuration change commands within the release window. If the operations and maintenance system saves historical approval records and execution results, servers based on a second intelligent agent can also incorporate historical feedback information to increase the risk weight of similar commands that have caused failures, rollbacks, or business fluctuations.

[0101] In one possible embodiment, the server, based on a second intelligent agent, can calculate the comprehensive risk value of a command using a risk scoring model. For example, it can map command type, target object level, scope of impact, execution permissions, time window, and historical failure rate to multiple scoring factors, and obtain an overall risk score through weighted averages. This score range is then mapped to a risk level. For instance, the higher the risk of the behavior, the more critical the target object, and the larger the scope of impact, the higher the comprehensive score and the higher the corresponding risk level. Conversely, if the command is only used for read-only queries, has a clear target scope, and does not have any modification effect, the comprehensive score is lower, corresponding to a lower risk level. The purpose of this risk grading method is to unify and quantify the previously dispersed security judgment standards, enabling the operation and maintenance system to automatically decide which commands can be directly allowed and which require manual intervention, thereby achieving a balance between efficiency and security.

[0102] After the assessment is completed, the server, based on the second intelligent agent, writes the risk level, assessment rationale, hit rules, assessment time, and assessment subject to the file system. The writing method can be either generating a risk assessment file corresponding to the task number in the command file, or adding risk and review fields to the metadata area associated with the original command file.

[0103] It should be noted that the second intelligent agent in the embodiments of this application does not specifically refer to a single intelligent agent. The second intelligent agent can be a cluster of intelligent agents that are different from the first intelligent agent in terms of functional positioning, operating logic or service objects. The system can call any intelligent agent or any combination of intelligent agents in the intelligent agent cluster as the second intelligent agent according to the operation type and target object of the operation and maintenance command information generated by the first intelligent agent, so as to perform security assessment on the operation and maintenance command information based on the second intelligent agent.

[0104] This step introduces a separate second intelligent agent and a security review result carried by the file system before command execution. This ensures that the operation and maintenance commands generated by the first intelligent agent must undergo security assessment before entering the execution phase, thus forming a security buffer layer between diagnosis and execution. This approach effectively solves problems such as accidental file deletion, service shutdown, configuration modification, and accidental restarts that may occur when intelligent assistants directly access the production system. It also ensures that risk opinions, assessment basis, and subsequent execution conclusions are continuously accumulated around the same task file, thereby significantly improving the auditability, compliance, and collaborative consistency of the operation and maintenance process.

[0105] S204. Obtain the risk level from the file system, and if the risk level is determined to be lower than the preset level, perform maintenance on the target business system based on the maintenance operation command information, and write the maintenance result to the file system.

[0106] For example, the preset level is a pre-configured safety risk threshold standard, which is used to distinguish between low-risk operations that can be executed automatically and high-risk operations that require manual control.

[0107] Operation and maintenance processing refers to compliant business operations such as fault diagnosis, resource detection, and status verification performed on the target business system based on operation and maintenance operation command information.

[0108] The results of this operation and maintenance are used to characterize the output information and execution status after the command is executed. They may include standard output content, standard error content, return code, execution start time, execution end time, success or failure flags, target object feedback, key log fragments, and preliminary analysis conclusions based on the results.

[0109] In one example, the server reads risk level data from the file system based on the management node, performs a level comparison and judgment, and when the risk level meets the automatic execution standard, it calls the execution agent module to load the operation and maintenance command information and complete the operation and maintenance of the target business system. After the operation is completed, it integrates and generates standardized operation and maintenance results, and synchronously writes them to the file system to complete the full-process data retention.

[0110] In practice, the server, based on the management node, first reads the risk level from the assessment result file in the file system and compares it with the preset levels configured in the system. The preset levels can be determined according to the enterprise's operation and maintenance (O&M) policies; for example, "low risk" can be set as the highest level allowing automatic execution, while "medium risk and above" can be set as a level requiring manual approval. Alternatively, differentiated thresholds can be set for different business systems; for example, automatic execution of low-to-medium risk commands can be allowed in the testing environment, while only low-risk commands can be automatically executed in the production core system. When the risk level is determined to be lower than the preset level, the server, based on the management node, sends the O&M operation command information to the execution agent module for O&M processing. Then, the execution agent module can perform O&M processing on the target business system based on the O&M operation command information to obtain the O&M result.

[0111] After obtaining the operation and maintenance results, the server, based on the management node, can structure and write these results to the file system. Specifically, standard output, error output, exit codes, execution time, execution node, execution account, and result summary can be written to the corresponding result file. For log collection commands, the collected log file path, log summary, and key error segments can also be recorded. For service control commands, the status verification results collected again after execution can be added to confirm whether the operation has taken effect. If the risk level is not lower than the preset level, the management node will not initiate automatic operation and maintenance processing for the target business system. Instead, it will write the "not meeting the automatic execution conditions" status to the file system and can further generate a pending approval mark or notification information so that human reviewers can take over the subsequent process. In this way, even if it is not executed automatically, the entire task chain still maintains status continuity around the same file system, ensuring that the process is not lost.

[0112] In this approach, the preceding steps complete anomaly identification, command generation, and security assessment. This final step only occurs when risk conditions are met, and the feedback data after execution flows back to the file system. This ensures continuous flow of operational data, command information, risk levels, and maintenance results within the same data carrier, supporting automated execution while preserving a complete chain of evidence. If further diagnosis is needed, the first agent can read the result file for secondary reasoning; if auditing is required, auditors can directly reconstruct the source, basis, and result of each operation based on the task chain in the file system, improving the traceability, reusability, and closed-loop processing capabilities of the maintenance process.

[0113] It should be noted that the method of information interaction between the first and second intelligent agents through the file system in this embodiment is merely illustrative. In practical applications, the first and second intelligent agents can also interact through other existing data interaction methods. For example, a standardized communication interface can be established between the first and second intelligent agents. The first intelligent agent encapsulates the operation and maintenance command information into a message according to the agreed data format and sends it to the second intelligent agent. After receiving the message, the second intelligent agent parses the message and performs a security assessment on the parsed information. Alternatively, the first intelligent agent encapsulates the operation and maintenance command information into a message entity and delivers it to a designated message queue. The second intelligent agent listens to the corresponding message queue and consumes the message data, completes data parsing, and performs a security assessment on the parsed information. This application is not limited to these methods.

[0114] The operation and maintenance method provided in this application involves an operation and maintenance system that collects operational status data from the target business system. An independent first intelligent agent identifies data anomalies and generates structured operation and maintenance commands. This data is then stored on a file system. A second intelligent agent, deployed in isolation, asynchronously reads the command information and performs an independent security assessment. The assessed risk level is then stored back to the file system. Finally, based on the risk level determination, low-risk operation and maintenance operations are automatically performed, and key data generated at each step is persistently written to the file system. This approach abandons the tightly coupled design of traditional integrated centralized operation and maintenance architectures. By separating the responsibilities of two intelligent agents, the main bodies responsible for command generation and security assessment are isolated. This avoids the control defects of a single entity's self-audit from the root of the architecture, ensuring the objectivity and independence of security assessment results. Furthermore, the file system enables asynchronous decoupling and collaboration among various business processes, effectively reducing module dependencies. Simultaneously, key data throughout the entire process is uniformly retained and stored, completely recording the operation and maintenance handling chain, improving the traceability and compliance of operation and maintenance activities. Overall, this optimizes the operational security and architectural adaptability of the intelligent operation and maintenance model in production business scenarios.

[0115] Figure 4 Flowchart of the operation and maintenance method provided in this application Figure 2 ,like Figure 4 As shown, in this embodiment... Figure 3 Based on the implementation examples, the operation and maintenance method is described in detail, which includes:

[0116] S301. Obtain the operating data of the target business system.

[0117] It should be noted that this step is similar to the aforementioned step S201, and will not be repeated here.

[0118] S302. Based on the first intelligent agent, when it is determined that there is an anomaly in the running data, the operation and maintenance command to be executed is inferred from the abnormal data in the running data.

[0119] For example, the operation and maintenance command to be executed in this instance refers to an executable instruction used to troubleshoot anomalies, repair faults, or verify the business status. For example, it may include specific operation instructions such as resource query, log retrieval, and service restart.

[0120] In one example, the server receives operational data in real time based on the first intelligent agent, identifies abnormal data through a built-in anomaly detection algorithm, and autonomously infers and generates operation and maintenance commands that are adapted to the current anomaly by combining the type, characteristics and related business scenarios of the abnormal data, ensuring that the commands are accurately matched with the abnormal scenario.

[0121] S303. Based on the first intelligent agent, the operation and maintenance command to be executed this time is matched with the preset format rules to generate structured operation and maintenance command information for this time.

[0122] For example, the preset format rules are standardized data specifications pre-configured by the operation and maintenance system, used to define the structured presentation of operation and maintenance commands. These rules may include fixed fields such as command content, parameters (args), target host (target_host), reasoning basis (reason), and expected output format (expected_output_format). It should be noted that this application embodiment does not limit the content of the preset format rules; these preset format rules can be referred to as a Command Request Protocol (CRP).

[0123] The structured operation and maintenance command information refers to standardized instruction data that conforms to preset format rules, can be automatically parsed by each module, and is easy to transmit and store across modules.

[0124] In one example, the first agent invokes a preset format rule template, fills in and matches the inferred operation and maintenance command according to the template fields, and encapsulates it to generate operation and maintenance command information containing complete structured fields, ensuring the standardization and uniformity of the command information. Specifically, when matching the operation and maintenance command to be executed with the preset format rules, the command text can be parsed, and the parsed content can be filled into the corresponding fields in the format rule template. Then, it is encapsulated and output according to structured expression methods such as JSON (JavaScript Object Notation), XML (Machine Learning), or YAML (YAML Ain't Markup Language) to obtain the structured operation and maintenance command information.

[0125] Understandably, after being constrained by formatting rules, the command content has clear field boundaries and consistent semantics, which can reduce ambiguity in the transmission of natural language commands and enable security assessments to accurately locate the command object, execution scope, and potential impact. In this way, after the first intelligent agent completes command reasoning based on abnormal data, it forms structured command information through formatted output, ensuring a consistent data carrier between anomaly identification, command generation, and subsequent review.

[0126] By adopting the above approach, operation and maintenance commands generated for abnormal scenarios can be transformed into a standardized structure, improving the parsability and auditability of command transmission, and providing a unified input for security assessment, manual review and automatic execution. This reduces the risk of misoperation caused by ambiguous command semantics, while improving processing efficiency and collaborative consistency in complex operation and maintenance scenarios.

[0127] Optionally, the format rules include the following fields: the operation and maintenance command to be executed, the target host, the reasoning basis for the command generation, the risk level (risk_level), the approval status (approval_status), and the expected output format.

[0128] The "Operational Operation Command to be Executed" field records the actual command text generated by the first intelligent agent based on abnormal operation data. This command text can be instructions such as querying processes, checking links, reading logs, reloading configurations, or restarting services. The command content corresponds to the type of abnormality in the target business system. The "Target Host" field identifies the server, virtual machine, container instance, database node, or cluster member to which the command will be executed. It can be represented by hostname, IP (Internet Protocol) address, instance identifier, or tag to ensure that the command execution target is unique and traceable.

[0129] The command generation reasoning field records the source of abnormal data and diagnostic correlation information. Abnormal data sources may include monitoring metrics, log fragments, alarm information, resource fluctuation records, and historical fault modes. Diagnostic correlation information explains why the first agent generated the corresponding command. The risk level field carries the result of the second agent's security assessment of the command. Its judgment criteria may include command type, scope, duration of impact, and whether it involves write operations or service interruption. The initial value of this risk level field can be "Pending Review," reserving a space for the second agent to backfill the risk level after its security assessment, thus enabling a continuous flow of risk information.

[0130] The approval status field indicates the progress of the command's review, recording statuses such as unapproved, pending approval, approved for execution, executed after manual modification, or rejected for execution, thus clearly defining control boundaries in the file system. The expected output format field constrains the return format of the executed result, which can be text, table, JSON object, or structured log, and can further limit key field names, hierarchical relationships, and result file naming conventions.

[0131] Therefore, the operation and maintenance command information for this task can be represented as follows:

[0132] {

[0133] "command": "cat / proc / cpuinfo",

[0134] "target_host": "node-23",

[0135] "reason": "Check for possible causes of high CPU load".

[0136] "expected_output_format": "text",

[0137] "risk_level": "pending_review",

[0138] "security_agent_opinion": "",

[0139] "approval_status": "pending"

[0140] }

[0141] In practical implementation, the format rules can be pre-configured as a structured template. Each field in the template uses a fixed key name and is written to the file system. After receiving the operation command to be executed, the first agent fills the template with the corresponding reasoning basis, target host, and other information. The second agent then reads the template and adds the risk level and approval status. Subsequently, the execution agent module generates the return result according to the expected output format. The template can be implemented using JSON Schema, YAML description files, or database records. JSON Schema is beneficial for validating field types, required fields, and value ranges. In practical applications, other models can also be selected for this component; this application embodiment does not limit this. Using a YAML template facilitates manual reading and parsing by the operation and maintenance platform, making it suitable for multi-system collaboration scenarios. By uniformly incorporating the above fields into the same format rules, consistent data constraints can be formed between command generation, security assessment, approval control, and result output.

[0142] In this way, operation and maintenance command information is expanded from a single text to a structured object containing context, risk control, and result constraints. This can improve the auditability and executability of command generation, reduce the risk of misjudgment due to missing context, and at the same time enable approval, execution, and feedback to have a unified data interface, thereby enhancing security, consistency, and traceability in the production environment.

[0143] S304. Based on the first intelligent agent, write the operation command information of this maintenance operation to the file system.

[0144] For example, the server writes the structured operation and maintenance command information to the file system based on the first intelligent agent. Optionally, the first intelligent agent will pause inference after writing the operation and maintenance command information to the file system, waiting for subsequent security assessment.

[0145] S305. Based on the second intelligent agent, obtain the operation command information for this maintenance operation from the file system.

[0146] For example, the server reads structured operation command information for the current maintenance task from the file system based on a second intelligent agent.

[0147] S306. Based on the second intelligent agent, perform security assessment on the operation and maintenance command information from multiple preset dimensions to obtain the risk level of the operation and maintenance command information.

[0148] The preset dimensions include at least one of the following dimensions: command structure legality, command semantic risk, target host compliance, and business access permission matching.

[0149] Command structure validity is used to verify whether the command string meets the preset syntax format and whether there are missing parameters, illegal symbols, concatenation injection, or escape exceptions; command semantic risk is used to identify whether the command intent involves high-risk semantics such as deleting files, terminating processes, restarting services, modifying configurations, or batch execution; target host compliance is used to verify whether the host pointed to by the command belongs to the asset scope that allows the execution of such operations; business access permission matching is used to compare whether the role, approval status, time window and command permission boundary of the initiating entity are consistent.

[0150] In actual processing, the server, based on a second intelligent agent, first performs structural parsing on the operation and maintenance command information, extracting fields such as the operation and maintenance command to be executed, the target host, and the reasoning basis. The parsing results are then matched against preset blacklists, whitelists, and syntax templates to identify any illegal structures. Subsequently, the server, based on the second intelligent agent and combining command keywords, parameter combinations, and historical execution samples, determines whether the semantics of the operation and maintenance command to be executed fall within a high-risk range. It further reads the target host attributes, business tags, and isolation status to verify the compliance of the target object of the operation and maintenance command. When the command involves permission-sensitive operations, the second intelligent agent also considers the current access subject's authorization scope, approval records, and policy configuration to determine whether the command meets the business access permission matching requirements, and summarizes the judgment results from all dimensions to form a comprehensive risk level.

[0151] The overall risk level can be obtained by mapping the risk weights of each dimension. The risk level can be divided into three levels: low, medium, and high, or into multiple levels with finer granularity, so that subsequent decisions on whether to proceed to manual review or direct execution can be made based on the risk threshold. For example, the risk level of maintenance operation commands waiting to be executed, such as rm, kill-9, and systemctl restart, can be judged as high risk.

[0152] Optionally, the second agent can output the risk level, along with the rationale for the risk and operational suggestions. For example, the output of the second agent could be:

[0153] Risk level: High;

[0154] Reason: The command contains write operations, which may cause service unavailability;

[0155] Recommendation: Allow only root access to execute; a business recovery plan must be provided.

[0156] By employing the above methods, the second intelligent agent can conduct multi-dimensional reviews of the operation and maintenance command information based on the command itself, the target object, and the permission boundaries, thereby improving the accuracy of risk identification and adaptability to the production environment. This solution can identify potential dangers in a timely manner before the command is executed, reducing the business impact caused by accidental deletion, accidental stopping, accidental modification, and unauthorized operations, and improving the security, traceability, and collaborative efficiency of the operation and maintenance chain.

[0157] S307. Obtain the risk level from the file system based on the management node.

[0158] S308. When the management node determines that the risk level is lower than the preset level, it sends the operation and maintenance command information to the execution agent module, so that the execution agent module can perform operation and maintenance processing on the target business system based on the operation and maintenance command information and obtain the operation and maintenance results.

[0159] For example, the execution agent module is used to receive external execution requests from the operation and maintenance system and convert the received operation and maintenance command information into action instructions that can be executed on the target business system side.

[0160] In the specific implementation, after the management node confirms that the risk assessment results meet the execution conditions, the server sends the operation command information to the execution agent module via interface call, message queue delivery, or file transfer. Upon receiving the command information, the execution agent module first parses the command fields, target host identifier, and permission flags. Then, based on the preset execution strategy, it initiates remote commands, script calls, interface requests, or local task scheduling against the target business system. This completes operation actions such as status query, log collection, service restart, configuration update, or diagnostic checks. The standard output, standard error, execution time, and success flags during the execution process are compiled into operation results, and the operation results (stdout / stderr) are written to the corresponding directory in the file system, such as results / . <request-id>.txt.

[0161] During execution, the execution agent module can also incorporate identity authentication, token verification, command whitelisting, and audit logging mechanisms to confirm received command information before execution and leave traces after execution, thus preventing unauthorized commands from directly affecting the production environment. By transforming command information into actual operations through the execution agent module, preventing the AI ​​agent from directly accessing the production environment, a controlled and isolated execution boundary can be established between the operations and maintenance system and the target business system. The execution results are then returned to the operations and maintenance system in a unified format for subsequent analysis, recording, and tracking.

[0162] By adopting this approach, the operations and maintenance system can complete operations and maintenance actions without directly accessing the target business system. This reduces the risk of misoperation caused by intelligently generated commands being directly applied to the production environment, while improving the consistency and auditability of command transmission, execution, and result feedback. Since the execution agent module is responsible for implementing the command information, the operations and maintenance process can be completed under controlled permissions and complete record-keeping, thereby improving the efficiency and security of automated operations and maintenance in complex business scenarios.

[0163] S309. If the management node determines that the risk level is higher than or equal to the preset level, it obtains the manual review result of the operation and maintenance command information for this operation and maintenance, and performs operation and maintenance processing on the target business system based on the manual review result to obtain the operation and maintenance result.

[0164] For example, a preset risk level is used to characterize the risk threshold requiring manual intervention. When the risk level reaches or exceeds this threshold, the system does not directly execute the command. Instead, it sends the command information to a manual review interface. Operations personnel, security administrators, or on-duty engineers review the command based on business impact, change windows, rollback conditions, and historical operations records, and generate a manual review result of agreeing to execute, modifying and executing, or rejecting execution. The manual review result can be written back to the file system and associated with the original command information for subsequent traceability of the review basis. For example, the manual review result can be written as a file to the corresponding directory in the file system, such as approval / . <request-id>.json

[0165] At this point, the aforementioned agent-based automated execution chain can resume from its paused state. When performing maintenance on the target business system based on the manual review results, the system can select the corresponding execution method according to the review conclusion. When the manual review result is "agree to execute," the execution agent module reads the confirmed maintenance operation command information and submits it to the target business system; when the manual review result includes modifications, the system updates the command parameters, target host, or execution scope before execution; when the manual review result is "reject execution," the maintenance process is terminated and the reason for rejection is recorded. By introducing high-risk commands into the manual review chain, the system can maintain maintenance responsiveness while avoiding the risks of accidental deletion, accidental stoppage, or accidental modification of configurations caused by automated execution, thereby improving the security and auditability of the production environment.

[0166] This manual intervention mechanism enables security assessments and human judgments to complement each other, ensuring that target business systems can still obtain controlled and traceable operation and maintenance results even in high-risk scenarios, and enhancing the stability and compliance of the anomaly handling process.

[0167] Specifically, when the manual review result is "agree to execute," the target business system is processed based on the current operation and maintenance command information to obtain the operation and maintenance result; when the manual review result is "modified operation and maintenance command information," the target business system is processed based on the modified operation and maintenance command information to obtain the operation and maintenance result; when the manual review result is "reject execution," the first intelligent agent, based on abnormal data and the rejection reason in the manual review result, re-infers and obtains new operation and maintenance command information.

[0168] The manual review result represents the reviewer's confirmation or modification opinion on the command information. When the command content matches the current business scenario and the risk is controllable, the reviewer can directly output "agree to execute". When the reviewer believes that the command has parameter deviations, an excessively large scope of action, or an inappropriate execution timing, the command content can be revised to form a manually modified operation and maintenance command information. The manually modified operation and maintenance command information is not limited to changes in content; for example, it could involve modifying the target host field, modifying the field of the operation and maintenance command to be executed, or adding remarks (such as an explanation of the operation window).

[0169] Reasons for rejection in manual review results may include excessive risk of the command, mismatch of the target object, insufficient permissions, excessive impact, or conflict with compliance policies.

[0170] In practice, after receiving the manual review result, the operation and maintenance system associates and saves the result with the currently pending command record. If the review result is "agree to execute," the execution agent module directly reads the original operation and maintenance command information and initiates operation and maintenance processing to the target business system based on the target host, command statements, and parameter configurations. This processing could include log queries, service restarts, configuration updates, or connection checks, and returns the corresponding operation and maintenance result. If the review result is a manually modified operation and maintenance command, the system replaces the original execution basis with the modified command record, and the execution agent module executes the operation and maintenance processing according to the revisions, ensuring that the execution object, execution scope, or command parameters are consistent with the intention confirmed by the human.

[0171] By categorizing manual review results into "approved for execution" and "manually modified operation and maintenance command information," the system maintains the security oversight capabilities of human reviewers while allowing reviewers to finely revise commands and reuse them directly. This avoids duplicate generation and review due to simple rejections. This approach enables both original and revised commands to serve as valid inputs for operation and maintenance processing, improving execution flexibility, review controllability, and result traceability in the production environment, while reducing the risk of erroneous execution.

[0172] Upon receiving a rejection result, the first agent can use the rejection reason and the original anomaly data as new inference input to re-match the fault characteristics, target object selection conditions, and command constraints used in the previous command generation to form new command information that conforms to security review requirements. For example, if the original command was rejected because it directly restarted the service, the first agent can generate a read-only diagnostic command, a log collection command, or a status query command instead; if the original command was rejected because the target host was non-compliant, the first agent can relocate the processing object corresponding to the compliant host and generate new operation and maintenance command information for that object.

[0173] In practical implementation, the first intelligent agent can read abnormal data, pending command information, and manual review feedback stored in the file system, and perform semantic parsing on the rejection reasons, mapping them to risk constraint labels, object constraint labels, or permission constraint labels. It then reconstructs the inference context by combining the fault characteristics in the abnormal data. Based on this context, the first intelligent agent outputs new operation command information for this maintenance task, ensuring it meets the review requirements in terms of command type, target host, execution scope, and expected output format. This information can be written back to the file system for subsequent security assessments and manual reviews.

[0174] By incorporating human reasons for rejection into the re-reasoning process, the first intelligent agent can correct the command generation results based on audit feedback. This allows operational diagnostics to continue even after rejection, while reducing the probability of generating high-risk commands and improving the alignment between commands and security policies and object compliance requirements. This approach creates a closed-loop feedback between abnormal data and human experience, helping to improve the accuracy, controllability, and auditability of operational command generation, thereby enhancing the security collaboration capabilities of intelligent operations and maintenance in a production environment.

[0175] Through this approach, supported by a multi-agent safety review pipeline and a human-in-the-loop architecture, the operations and maintenance (O&M) system can proactively trigger an intelligent interruption mechanism at key risk control nodes in the O&M process. This temporarily suspends the automated O&M link, actively intercepts high-risk O&M operations, and awaits human intervention for verification and approval. Once O&M personnel have completed manual actions such as command review, risk confirmation, instruction modification, or operation rejection, the system automatically resumes and continues the subsequent O&M execution process based on the final manual review result. By embedding flexible human intervention breakpoints into the fully automated intelligent reasoning and execution link, this effectively overcomes the unidirectional execution limitations of purely autonomous AI and compensates for the limitations of intelligent agents in decision-making in high-risk and complex scenarios. While retaining the fully automated and efficient processing capabilities for low-risk operations, a secondary manual verification barrier is added for high-risk operations and maintenance behaviors. This enables controllable management and control of the entire operations and maintenance chain from the process scheduling level, avoiding business failures and operational risks caused by the unrestricted automatic execution of high-risk instructions. It builds an operating mode that deeply integrates intelligent autonomous handling and human safety checks and balances, allowing AI to participate in fault diagnosis and automated operations and maintenance processes within the safety boundary. This not only ensures the automation efficiency of daily operations and maintenance, but also strengthens the safety, compliance, and controllability of operations in the production environment through human supervision and intervention. The overall operations and maintenance process has the dynamic adjustment capabilities of flexible interruption, on-demand intervention, and approval-based continuation, significantly improving the fault tolerance and operational stability of the intelligent operations and maintenance system in complex production scenarios.

[0176] S310. Based on the first intelligent agent, obtain the operation and maintenance results from the file system, perform iterative reasoning based on the operation and maintenance results, and obtain the operation and maintenance command information for the next operation and maintenance.

[0177] For example, the first intelligent agent can read the maintenance results from the corresponding directory in the file system using a file-reading tool. After obtaining the maintenance results, the first intelligent agent will perform correlation analysis with previous abnormal data, command generation basis, and historical command sequences, and determine whether the current fault has been eliminated, whether there are residual anomalies, or whether it is necessary to move to the next diagnostic direction based on the status changes reflected in the maintenance results. For example, iterative reasoning can be used to analyze the cause of CPU anomalies, analyze Kafka Consumer Lag, analyze memory leaks, or recommend repair solutions.

[0178] When the current maintenance results indicate that the command has completed its intended action but the fault persists, the first agent can combine error messages, resource usage changes, and service response changes in the results to perform iterative reasoning and continue root cause analysis. This allows for a re-identification of the objects to be investigated and the command objects, thereby generating the next maintenance operation command information. The next maintenance operation command information can be written to the file system in a structured format for subsequent security assessments and execution.

[0179] Understandably, compared to the traditional one-time linear inference operation mode of AI, the above steps construct an interruptible and recoverable execution mechanism for the inference link that is adapted to the human-in-the-loop (human-in-the-loop) management system. During the continuous fault analysis inference process, the first intelligent agent will automatically pause the current inference process whenever it needs to initiate an operation and maintenance command information execution request, and switch to the security assessment and / or manual review stage. After completing the security assessment and / or manual review and obtaining the complete operation and maintenance execution results, the inference link can automatically resume and advance the subsequent analysis steps. This fine-grained segmented scheduling capability can only be achieved by relying on professional intelligent agent orchestration frameworks (deepagents / LangGraph). However, the embodiment of this application has completed the protocol-based customized design of the operation and maintenance execution process for the operation and maintenance business scenario, forming an original technical implementation solution in this application direction.

[0180] Through the above methods, the first intelligent agent can continuously adjust its inference path based on actual execution feedback, forming a closed-loop mechanism of execution, observation, re-inference, and re-generation in the operation and maintenance process. This gradually narrows down the scope of the fault and improves troubleshooting accuracy. Since the command information for the next operation and maintenance operation comes from the iterative analysis of the current operation and maintenance results, it is more closely aligned with the current system state, reducing invalid commands and redundant troubleshooting, improving the efficiency of automated operation and maintenance in complex fault scenarios, and enhancing the traceability and continuity of the entire operation and maintenance chain.

[0181] The operation and maintenance method provided in this application embodiment allows the operation and maintenance system to continuously acquire the operating data of the target business system. After the first intelligent agent identifies data anomalies, it infers and generates operation and maintenance operation commands to be executed, encapsulates them into structured command information according to preset format rules, and writes them to the file system. The second intelligent agent reads the command information from the file system, conducts a security assessment from multiple preset dimensions, and determines the risk level. Based on the risk level, it executes branch processes: low-risk operations are automatically sent to the execution agent module to complete the operation and maintenance, while high-risk operations are carried out after obtaining manual review results. Finally, the first intelligent agent reads the operation and maintenance results and iteratively infers the next operation and maintenance operation command information based on the results. This approach achieves complete decoupling of operation and maintenance command generation and security assessment through the independent division of labor between the first and second intelligent agents. This avoids the control vulnerabilities of self-generation and self-audit in traditional integrated architectures, ensuring the objectivity and independence of security assessments. By generating structured command information using preset format rules, it ensures the standardization and efficiency of cross-module data interaction. Relying on the file system, it achieves persistent storage and asynchronous flow of data throughout the entire process, reducing coupling dependencies between modules. Through risk level-based hierarchical control, it balances operation and maintenance efficiency with production safety. The manual review process fills the gaps in security control for high-risk scenarios, while the iterative reasoning capability of the first intelligent agent achieves closed-loop optimization of the operation and maintenance process, effectively improving the accuracy, security, and continuity of operation and maintenance operations. At the same time, the traceability of data throughout the process meets the requirements of enterprise production environments for operation and maintenance compliance, and the overall architecture of the intelligent operation and maintenance system is optimized for flexibility and practical adaptability.

[0182] Figure 5 This is a schematic diagram illustrating an application scenario provided in an embodiment of this application, such as... Figure 5 As shown, after the management node of the operation and maintenance system obtains the operating data of the target business system, the first intelligent agent, acting as the diagnostic agent, generates the operation and maintenance command information for this operation and maintenance, and submits it as a structured command execution application to the second intelligent agent, acting as the security review agent, for security assessment. When the risk level of the operation and maintenance command information is determined to be high risk, it enters the approval module for HITL manual approval. The operation and maintenance personnel manually verify the command. If the command is approved for execution, the execution agent module executes the operation and maintenance command and returns the result to the first intelligent agent for iterative reasoning. If the command is rejected for execution, the first intelligent agent resumes the reasoning chain analysis and finally completes the operation and maintenance process.

[0183] The operation and maintenance methods provided in the embodiments of this application will be described below in conjunction with various existing operation and maintenance solutions.

[0184] (1) Compared with the traditional approach of "AI only provides text suggestions", the AI ​​operation and maintenance assistant under the traditional solution can only output the reference content of operation and maintenance commands. It cannot be integrated into the actual production environment operation chain and does not have the core capabilities of command-level context tracking, execution result feedback and continuous reasoning analysis. The complete fault diagnosis process still needs to be implemented manually. The operation and maintenance method provided in this application breaks the limitation of AI only providing text suggestions and constructs an AI participatory fault diagnosis process that can be practically applied. The intelligent agent can autonomously generate standardized and structured command requests, combine the operation return results to carry out continuous reasoning analysis, form a complete automated diagnosis closed loop, and have the ability to make autonomous continuous decisions. It can gradually advance the troubleshooting chain around multiple dimensions such as equipment resources, operation logs, and network status, and unify and standardize the expression protocol of all operation and maintenance commands, so that every operation can support full recording, review and traceability and compliance audit.

[0185] (2) Compared with the traditional "AI directly executes commands" solution, the intelligent agent framework under the traditional solution supports direct invocation of underlying system operation commands and can directly call shell / SSH. It can autonomously initiate remote operation and service control. However, such solutions generally lack a complete risk assessment system and are prone to generating high-risk and destructive operation commands, which can lead to online business failures and production accidents. For security reasons, most companies prohibit intelligent agents from directly accessing production servers to carry out operations. The operation and maintenance method provided in this application eliminates the possibility of AI directly executing any operation and maintenance command from the underlying architecture. All operation commands must undergo independent security risk assessment, multi-level manual approval, and multi-level verification by a dedicated external execution module before they can be implemented. This avoids the security risks caused by the autonomous operation of intelligent agents from the root. At the same time, it is equipped with an automated security rating mechanism, which can accurately distinguish the risk levels of different operations such as read-only query, network debugging, configuration modification, and service control, and realize differentiated risk control management. It completely retains the approval subject, execution record and operation feedback results, and ensures the transparency and controllability of the entire process of operation and maintenance command execution.

[0186] (3) Compared with the traditional operation and maintenance work order system, the traditional operation and maintenance work order system has a rigid and inflexible overall operation process. The work order content relies entirely on manual editing and filling, the information structure is insufficient, the approval and transfer process is cumbersome and inefficient, and the actual command execution requires operation and maintenance personnel to make independent judgments and decisions and repeatedly communicate and confirm. The key information in the fault investigation process is scattered in different locations such as chat records, work order forms, and operation logs, which can easily lead to the interruption and blockage of the investigation link. The operation and maintenance method provided in this application relies on intelligent capabilities to automatically generate structured work orders and command applications containing command semantics, target host, risk basis, output specifications and reasoning context. It automatically connects the integrated pipeline process of approval and review, instruction execution and result feedback, which greatly shortens the fault investigation closed-loop cycle and improves the overall handling efficiency. It relies on the file system to realize the continuous flow and sharing of work order context information. The intelligent agent can read the historical data and independently continue to carry out in-depth analysis without the need for manual repeated supplementation of scenario information and fault background, effectively reducing collaboration breakpoints.

[0187] (4) Compared with DevOps automation frameworks, traditional DevOps automation tools such as Ansible and Terraform are good at completing preset script configuration and batch fixed operation and maintenance operations, but they are limited to the repeated execution of established processes. They do not have the ability to make autonomous intelligent decisions, generate dynamic commands, deeply analyze execution results, and integrate human-in-the-loop processes. They cannot adjust the handling strategy and plan the next investigation action based on the feedback from the on-site operation. The operation and maintenance method provided in this application has the intelligent analysis capability at the upper cognitive level. It can independently judge the required investigation instructions based on business anomalies and realize progressive continuous reasoning based on the complete context. For example, when high CPU usage is detected, the top command will be automatically initiated to check the process status. If an abnormal thread is found, relevant log keywords will be further searched. If timeout information appears in the log, the downstream interface status will continue to be investigated. According to the abnormal characteristics, the resource status, log information, link interaction and other key contents will be deeply explored layer by layer to complete the dynamic and scenario-based fault investigation that traditional automation tools cannot achieve. Combined with the human-in-the-loop control mechanism, flexible process breakpoints are set to ensure that all automated operation and maintenance actions are strictly limited within the safety boundary, taking into account both automation efficiency and production compliance requirements.

[0188] (5) Compared with the traditional single-agent framework, the AI ​​operation and maintenance framework that uses a single large model to carry all business logic has many problems such as opaque operation reasoning logic, weak risk assessment capability, difficulty in splitting and disassembling the reasoning link, and lack of functional role division. The single model independently completes the entire process and is also prone to judgment errors and operational deviations due to model illusion. The operation and maintenance method provided in this application adopts a multi-agent division of labor and cooperation operation architecture, which fits the division of labor logic of the actual operation and maintenance organization of the enterprise. It is configured with a diagnostic agent responsible for fault location analysis, a security agent focused on command risk review, a manual decision confirmation link, and an independent instruction execution unit. The roles are clearly divided, cooperate with each other and check each other, effectively reducing the error probability caused by the operation of a single model and alleviating the operational risks caused by large model illusion. At the same time, the overall architecture has good scalability and can expand customized sub-agents for different professional operation and maintenance fields such as database, K8s, network, and security, enriching the scenario adaptation capability.

[0189] (6) Compared with internal synchronous calls and temporary memory interaction, the operation and maintenance method provided in this application uses the shared file system as a unified state storage and context carrier across intelligent agents and business processes. It is naturally adapted to the process interruption and automatic recovery needs under the human-loop architecture. The intelligent operation and maintenance process can be autonomously paused at key risk control nodes and wait for manual approval intervention. After approval, the retained file is read and the reasoning task is automatically resumed. The file-based storage format can expand the context carrying capacity without limitation. All data such as operation and maintenance commands, operation logs, analysis reports, and execution results are uniformly archived and retained. It is deeply compatible with the human-machine collaborative operation mode. Operation and maintenance personnel can directly write review opinions and operation results to the file system. The intelligent agent automatically reads the updated content and continues to advance the task. There is no need to build a complex remote procedure call (RPC) interface between multiple intelligent agents. Data interaction and collaborative cooperation can be completed by relying only on the shared file directory. This greatly simplifies the multi-module collaborative architecture and improves the overall stability and adaptability of the system.

[0190] In summary, the operation and maintenance method provided in this application has the technical advantages shown in Table 1 compared with traditional solutions.

[0191] Table 1 Comparison of Technical Advantages

[0192]

[0193] Figure 6 A schematic diagram of the operation and maintenance device provided in this application is shown below. Figure 6 As shown, the maintenance device 400 provided in this embodiment includes:

[0194] Module 401 is used to acquire the runtime data of the target business system;

[0195] The reasoning module 402 is used to, based on the first intelligent agent, infer the current operation and maintenance command information from the abnormal data in the operation data when it is determined that there is an anomaly in the operation data, and then write it to the file system.

[0196] The evaluation module 403 is used to obtain the operation and maintenance command information of this operation and maintenance operation from the file system based on the second intelligent agent, perform security evaluation processing on the operation and maintenance command information of this operation and maintenance operation, obtain the risk level of the operation and maintenance command information of this operation and maintenance operation and write it to the file system.

[0197] The determination module 404 is used to obtain the risk level from the file system, and when the risk level is determined to be lower than the preset level, to perform operation and maintenance processing on the target business system based on the operation and maintenance command information of this operation and maintenance, and then write the operation and maintenance result to the file system.

[0198] In one possible implementation, the inference module 402 is configured to:

[0199] Based on the first intelligent agent, the operation and maintenance command to be executed is inferred from the abnormal data in the operation data.

[0200] The system matches the operation and maintenance command to be executed with the preset format rules to generate structured operation and maintenance command information for this operation and maintenance.

[0201] In one possible implementation, the format rules include the following fields: the operation and maintenance command to be executed, the target host, the reasoning basis for the command generation, the risk level, the approval status, and the expected output format.

[0202] In one possible implementation, the evaluation module 403 is used for:

[0203] Based on the second intelligent agent, the security assessment of the operation and maintenance command information is performed from multiple preset dimensions to obtain the risk level of the operation and maintenance command information. The preset dimensions include at least one of the following dimensions: command structure legality, command semantic risk, target host compliance, and business access permission matching.

[0204] In one possible implementation, the determining module 404 is configured to:

[0205] The operation and maintenance command information is sent to the execution agent module, so that the execution agent module can perform operation and maintenance processing on the target business system based on the operation and maintenance command information and obtain the operation and maintenance results.

[0206] In one possible implementation, the determining module 404 is configured to:

[0207] If the risk level is determined to be higher than or equal to the preset level, the manual review result of the operation and maintenance command information is obtained, and the target business system is operated and maintained based on the manual review result to obtain the operation and maintenance result.

[0208] In one possible implementation, the manual review result is either an agreement to execute or a manually modified operation and maintenance command; the determination module 404 is used for:

[0209] When the manual review result is approved for execution, the target business system is processed for maintenance based on the maintenance operation command information to obtain the maintenance result.

[0210] When the manual review result is the manually modified operation and maintenance command information, the target business system is operated and maintained based on the manually modified operation and maintenance command information to obtain the operation and maintenance result.

[0211] In one possible implementation, the determining module 404 is configured to:

[0212] When the manual review result is "reject execution", the first intelligent agent, based on the abnormal data and the rejection reason in the manual review result, re-infers the new operation and maintenance command information for this operation and maintenance.

[0213] In one possible implementation, the inference module 402 is configured to:

[0214] Based on the first intelligent agent, the operation and maintenance results are obtained from the file system. Based on the operation and maintenance results, iterative reasoning is performed to obtain the command information for the next operation and maintenance.

[0215] The operation and maintenance device provided in this embodiment can execute the method provided in the above method embodiment. Its implementation principle and technical effect are similar, and will not be described in detail here.

[0216] Figure 7 This is a schematic diagram of the server structure provided in this application. Figure 7 As shown, the server 500 provided in this embodiment includes at least one processor 501 and a memory 502. Optionally, the server 500 further includes a communication component 503. The processor 501, memory 502, and communication component 503 are connected via a bus.

[0217] In a specific implementation, at least one processor 501 executes computer execution instructions stored in memory 502, causing at least one processor 501 to perform the above-described method.

[0218] The specific implementation process of processor 501 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0219] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0220] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0221] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0222] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0223] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

[0224] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0225] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.

[0226] The division of units is merely a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0227] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0228] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0229] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0230] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0231] Finally, it should be noted that other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein, and is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of the invention is limited only by the appended claims.

Claims

1. An operation and maintenance method, characterized in that, The method is applied to an operation and maintenance system; including: Obtain operational data from the target business system; Based on the first intelligent agent, when it is determined that there is an anomaly in the running data, the operation and maintenance command information for this operation is inferred from the abnormal data in the running data and then written to the file system. Based on the second intelligent agent, the operation and maintenance command information for this operation and maintenance is obtained from the file system, and the operation and maintenance command information for this operation and maintenance is subjected to security assessment processing. After obtaining the risk level of the operation and maintenance command information for this operation and maintenance is written to the file system. The risk level is obtained from the file system, and when the risk level is determined to be lower than the preset level, the target business system is operated and maintained based on the operation and maintenance command information of this operation and maintenance, and the operation and maintenance result is written to the file system.

2. The method according to claim 1, characterized in that, The step of inferring the operation command information for this maintenance task based on the abnormal data in the operational data includes: Based on the first intelligent agent, the operation and maintenance command to be executed is inferred from the abnormal data in the operation data. The operation and maintenance command to be executed is matched with the preset format rules to generate structured operation and maintenance command information for this operation and maintenance.

3. The method according to claim 2, characterized in that, The format rules It includes the following fields: the operation and maintenance command to be executed, the target host, the reasoning basis for the command generation, the risk level, the approval status, and the expected output format.

4. The method according to claim 1, characterized in that, The process of performing a security assessment on the operation and maintenance command information to obtain the risk level of the operation and maintenance command information includes: Based on the second intelligent agent, the security assessment of the current operation and maintenance command information is performed from multiple preset dimensions to obtain the risk level of the current operation and maintenance command information; wherein, the preset dimensions include at least one of the following dimensions: command structure legality, command semantic risk, target host compliance, and business access permission matching.

5. The method according to claim 1, characterized in that, The process of performing maintenance on the target business system based on the current maintenance operation command information to obtain the maintenance result includes: The operation and maintenance command information is sent to the execution agent module, so that the execution agent module can perform operation and maintenance processing on the target business system based on the operation and maintenance command information and obtain the operation and maintenance results.

6. The method according to claim 1, characterized in that, The method further includes: If the risk level is determined to be higher than or equal to the preset level, the manual review result of the current operation and maintenance command information is obtained, and the target business system is operated and maintained based on the manual review result to obtain the operation and maintenance result.

7. The method according to claim 6, characterized in that, The manual review result is either an approval for execution or a manually modified operation and maintenance command. The operation and maintenance process for the target business system based on the manual review results, to obtain the operation and maintenance results, includes: When the manual review result is "agree to execute", the target business system is subjected to operation and maintenance processing based on the operation and maintenance command information of this operation and maintenance, and the operation and maintenance result is obtained. When the manual review result is the manually modified operation and maintenance command information, the target business system is operated and maintained based on the manually modified operation and maintenance command information to obtain the operation and maintenance result.

8. The method according to claim 7, characterized in that, The method further includes: When the manual review result is "reject execution", the new operation and maintenance command information is re-inferred based on the first intelligent agent, according to the abnormal data and the rejection reason in the manual review result.

9. The method according to any one of claims 1-8, characterized in that, The method further includes: Based on the first intelligent agent, the current operation and maintenance result is obtained from the file system, and iterative reasoning is performed based on the current operation and maintenance result to obtain the next operation and maintenance command information.

10. An operation and maintenance system, characterized in that, The operation and maintenance system includes at least one server: the server is used to perform the method as described in any one of claims 1-9.

Images