An OpenStack cloud platform automatic operation and maintenance method and system

Abstract

This invention provides an automated operation and maintenance method and system for OpenStack cloud platforms, relating to the fields of cloud computing and intelligent operation and maintenance technology. The method includes receiving natural language operation and maintenance questions; intent recognition and entity extraction; inferring the target host based on a static asset list; unified retrieval of multi-source knowledge to generate standardized knowledge and candidate commands; generating a structured execution plan; command risk classification and approval; SSH remote execution; result aggregation; and full-process auditing. The system includes modules for question parsing, host inference, knowledge retrieval, execution plan generation, risk assessment, remote execution, result summarization, audit trail, and process orchestration. This invention achieves natural language-driven, CMDB-free, knowledge-executable, command-risk-controllable, and process-auditable OpenStack operation and maintenance, improving operation and maintenance efficiency, standardization, security, and consistency in fault handling. It is suitable for daily operation and maintenance and fault self-healing scenarios of OpenStack cloud platforms.

Description

Technical Field

[0001] This invention relates to the fields of cloud computing and intelligent operation and maintenance technology, and in particular, to an integrated operation and maintenance method and system for OpenStack cloud platforms, based on large model intent understanding, unified retrieval of multi-source knowledge, intelligent inference of CMDB-less hosts, command risk classification and control, graph process orchestration and remote automated execution; more specifically, it relates to an automated operation and maintenance method and system for OpenStack cloud platforms. Background Technology

[0002] OpenStack, as a mainstream open-source cloud platform management framework, is widely used in enterprise data centers, government clouds, carrier clouds, and industry-specific cloud scenarios. Its clusters typically include multiple roles such as control nodes, compute nodes, storage nodes, and network nodes, running dozens of services such as Nova, Neutron, Keystone, Glance, Cinder, and Ceph. As the cluster size increases, the number of nodes grows, and the complexity of business operations rises, traditional OpenStack operation and maintenance methods face serious bottlenecks.

[0003] Currently, OpenStack cloud platform operations and maintenance primarily rely on manual experience. Maintenance personnel must manually diagnose faulty components, locate target hosts, select maintenance commands, and execute operations on each node based on alarm information, user problem descriptions, and log content, and then manually summarize the results. This approach exposes the following significant drawbacks in large-scale clusters and high-concurrency failure scenarios:

[0004] 1. Operation and maintenance knowledge is scattered and has low utilization: Operation and maintenance knowledge is scattered and stored in internal knowledge bases, document systems, Elasticsearch log libraries, relational databases, operation manuals, and historical SOP documents. The formats of each system are not consistent, the retrieval efficiency is low, and it is difficult to directly convert heterogeneous knowledge into executable operation and maintenance instructions.

[0005] 2. Target host location relies on manual judgment, which is prone to errors and inefficient: With multiple nodes (control nodes, computing nodes, storage nodes, and network nodes) deployed in a mixed manner, maintenance personnel need to manually select the target host based on the problem description and judge the range of target hosts based on experience. The location efficiency is low and the accuracy is poor, and it is easy to make misjudgments or omissions. In multi-machine scenarios, it is not possible to quickly locate in batches, and it is highly dependent on the CMDB system. Without the CMDB system, it cannot run efficiently and cannot achieve automated host screening.

[0006] 3. Low standardization of command execution and uncontrollable risks: Operation and maintenance rely on manual login and command input on each machine, which is lengthy and slow. It is difficult to ensure the consistency of execution order in multi-machine scenarios. The experience of different personnel varies greatly, resulting in inconsistent handling results for similar faults and making it difficult to establish standardized SOPs. There is a lack of a unified risk identification mechanism. High-risk commands (such as rm, mkfs, shutdown, reboot) are easily executed by mistake, causing serious accidents such as business interruption and data loss.

[0007] 4. Inability to achieve a closed loop from natural language to execution: Existing AI question-answering systems can only return text answers, usually only staying at the level of "giving an answer". They cannot further link target host selection, command risk classification and remote execution to form a closed loop. They cannot automatically infer the target host, generate structured execution plans, link remote execution, and directly implement operation and maintenance operations. In addition, traditional automation scripts require pre-specifying the host and steps and do not support dynamic reasoning from natural language.

[0008] 5. The process cannot be paused, resumed, or audited: Although the single-agent black box big model decision-making mode introduces a big model, it usually entrusts the problem understanding, knowledge retrieval, command generation, host selection, and execution control to a single model to complete all at once. The process is unexplainable, the nodes are unauditable, there are no approval breakpoints, approval is difficult to insert, it is impossible to pause and wait for manual confirmation, and it is difficult to resume execution after failure; there is no end-to-end audit of the execution process, which makes it difficult to meet the compliance requirements of government and enterprises.

[0009] 6. Poor platform scalability and reliance on external systems such as CMDB: Most automated operation and maintenance solutions rely on complete CMDB systems, asset management platforms, and dedicated agents, which cannot be deployed in environments without supporting systems; the modules are highly coupled, and replacing underlying capabilities requires extensive modification of business code. Summary of the Invention

[0010] Therefore, the purpose of this invention is to propose an automated operation and maintenance method and system for the OpenStack cloud platform. Through natural language intent parsing, CMDB-free two-stage host inference, multi-source knowledge standardization adaptation, structured execution plan generation, rule-priority risk gating, graph flow state orchestration, SSH remote execution, and full-link audit tracing, it achieves full-process automation of OpenStack operation and maintenance from natural language question input to operation and maintenance result output. It does not rely on CMDB, supports natural language interaction, unified utilization of multi-source knowledge, and intelligent host location. Through standardized operation and maintenance operations, it eliminates differences in personnel experience, ensures consistent handling of similar faults, controls command risks, and enables auditable, paused, and recoverable processes. It can achieve auditable and traceable closed-loop operation and maintenance from natural language operation and maintenance commands to fault diagnosis, service inspection, service restart, log query, and cluster operations, improving operation and maintenance efficiency, accuracy, security, and standardization.

[0011] This invention provides an automated operation and maintenance method for OpenStack cloud platforms, such as... Figure 1 The steps shown are as follows:

[0012] S1. Receive a natural language operation and maintenance question input by the user; perform intent recognition and entity extraction on the natural language operation and maintenance question to obtain a structured intent containing service name, environment information, host role, fault action type, and execution scope;

[0013] S2. Based on a pre-maintained static asset list, the target host set is inferred by combining rule-based recall and scoring ranking.

[0014] S3. By using a unified adaptation interface to query multi-source heterogeneous knowledge sources in parallel, standardized operation and maintenance knowledge and candidate commands are obtained.

[0015] S4. Combine structured intents, target host sets, and standardized operation and maintenance knowledge to generate a structured command execution plan;

[0016] S5. Based on preset risk rules, classify the commands in the command execution plan according to risk and determine three categories of command rules: prohibited from execution, requiring manual confirmation, and automatically executed.

[0017] S6. For commands that have passed risk approval, execute the commands on the target host set via the SSH tunnel;

[0018] Preferably, step S6 supports single-machine execution, multi-machine parallel execution, and multi-machine rolling execution. Rolling execution is used for multi-node change operations to ensure service continuity.

[0019] S7. Summarize the execution results, generate a result summary and output it; write the entire operation and maintenance process data into the audit log.

[0020] Furthermore, the intent recognition and entity extraction in step S1 includes:

[0021] Text normalization and synonym replacement; stop word filtering; service entity identification based on pre-set service tables and dynamic regular expressions; extraction of environmental and role entities based on keywords; determination of inspection or execution actions based on action keywords; determination of single-machine or multi-machine execution range based on range keywords.

[0022] Furthermore, the inference of the target host set in step S2 includes:

[0023] Phase 1 rule recall: Match the fields env, business, cluster, hostname, ip, roles, and tags in the static asset list, and add the matched host to the candidate host list;

[0024] The second stage of scoring and ranking is calculated as follows: HostScore = W1×EnvMatch + W2×BusinessMatch + W3×ClusterMatch + W4×RoleMatch + W5×TagMatch + W6×HostnameMatch + W7×IpMatch…

[0025] EnvMatch indicates whether the environment was hit;

[0026] RoleMatch indicates whether the character hits;

[0027] TagMatch indicates whether the tag was matched;

[0028] HostnameMatch and IpMatch indicate whether the user directly specifies the hostname or IP address;

[0029] For single-machine selection, the host with the highest score is chosen; for multi-machine selection, all candidate hosts are chosen. The set of target hosts and the reason for the hit are output.

[0030] Furthermore, the multi-source heterogeneous knowledge sources mentioned in step S3 include API knowledge bases, Elasticsearch, relational databases, and DOCX / PDF / Markdown / TXT document knowledge bases. The retrieval results are uniformly encapsulated into a Knowledge Hit structure, which includes source_name, title, content, summary, commands, score, and metadata.

[0031] Furthermore, the structured command execution plan in step S4 includes step_id, command, purpose, target_hosts, and risk_hint; the inspection class automatically filters high-risk commands, and generates systemctlstatus and journalctl rollback commands when no knowledge is matched; the execution class adds a restart command; the execution modes include single, parallel, and rolling.

[0032] Furthermore, the risk classification in step S5 is matched in the order of deny_patterns, confirm_patterns, allow_patterns, and unknown;

[0033] Commands that cannot be executed include rm -rf / , mkfs, dd, shutdown, and reboot;

[0034] Commands requiring manual confirmation include systemctl restart / stop / start, docker restart, and kill;

[0035] Commands that can be executed automatically include systemctl status, journalctl, ps, cat, grep, openstacklist, ceph -s, and ovs-vsctl show.

[0036] If the rule command is not matched, the process will proceed to manual confirmation by default.

[0037] This invention also provides an automated operation and maintenance system for OpenStack cloud platforms, used to implement the automated operation and maintenance method for OpenStack cloud platforms as described above, including:

[0038] Problem parsing module: Used to receive natural language operation and maintenance problems input by users; perform intent recognition and entity extraction on the natural language operation and maintenance problems to obtain a structured intent containing service name, environment information, host role, fault action type, and execution scope;

[0039] Host inference module: Based on a pre-maintained static asset list, it uses a combination of rule-based recall and scoring sorting to infer the target host set;

[0040] The unified knowledge base retrieval module is used to query multi-source heterogeneous knowledge sources in parallel through a unified adaptation interface to obtain standardized operation and maintenance knowledge and candidate commands.

[0041] Execution plan generation module: used to combine structured intents, target host sets, and standardized operation and maintenance knowledge to generate structured command execution plans;

[0042] Risk assessment and approval module: used to classify the risks of commands in the command execution plan based on preset risk rules, and to determine three categories of commands: prohibited from execution, requiring manual confirmation, and automatically executed.

[0043] Remote execution module: Used to execute commands that have passed risk approval on a set of target hosts via an SSH tunnel and return the results;

[0044] The results summary and audit trail module is used to summarize execution results, generate result summaries and output them; and write the entire operation and maintenance process data into the audit log to achieve full-process data recording and traceability.

[0045] Preferably, the system uses a unified state object AgentState to pass the context, which includes user_query, normalized_intent, candidate_hosts, selected_hosts, knowledge_hits, execution_plan, risk_assessment, approval_status, execution_results, and final_answer, and supports direct resumption of execution without loss of context after approval is paused.

[0046] Furthermore, the OpenStack cloud platform automated operation and maintenance system also includes a process orchestration module. The process orchestration module is used to connect the problem parsing module, host inference module, knowledge base unified retrieval module, execution plan generation module, risk assessment and approval module, remote execution module, result summary and audit trail module according to the state flow using LangGraph or a similar graph orchestration framework, and supports conditional jump, approval pause and resumption of execution.

[0047] Preferably, the process orchestration module adopts the LangGraph framework, and the node flow order is parse_query, infer_hosts, retrieve_knowledge, build_plan, assess_risk, approval_gate, execute_ssh, summarize_result, supporting conditional branching, pause, continue, and blocking logic.

[0048] The system of this invention does not rely on CMDB and supports static assets, CMDB, Ansible Inventory, and bastion host interfaces as host metadata sources; the modules are loosely coupled and can independently replace the underlying model, knowledge source, execution channel, and process framework.

[0049] Optionally, the LangGraph in the process orchestration of this invention can be replaced with other directed graph frameworks; the static assets in the host source can be replaced with CMDB, Ansible Inventory, or a bastion host interface; the SSH in the execution channel can be replaced with Ansible, SaltStack, a dedicated agent, or a bastion host channel; the knowledge storage can be replaced with a vector library, a full-text search engine, or an SOP library; the model supports local large models and enterprise private models; and the rule files in risk control can be replaced with a rule engine or a policy center.

[0050] This invention receives user-generated natural language operation and maintenance questions, and through text normalization, intent recognition, and entity extraction, obtains structured information such as services, environments, roles, actions, and scopes. This solves the problem that existing multi-source heterogeneous operation and maintenance knowledge cannot be uniformly retrieved, standardized, or directly used for command generation. Based on a static asset list, it automatically locates single-machine or multi-machine target hosts through a two-stage mechanism of rule retrieval and weighted scoring, solving the problem that existing technologies cannot automatically and accurately locate single-machine or multi-machine target hosts based on natural language in environments without a CMDB. It parallelly retrieves knowledge from multiple sources such as APIs, Elasticsearch, databases, and documents, extracts recommended commands, and standardizes them uniformly, solving the problems of low execution efficiency, poor standardization, and inconsistent execution across multiple machines in existing manual commands. This addresses the challenges of unpredictable risks in operations and maintenance (O&M) commands. It generates structured execution plans containing steps, commands, purposes, hosts, and risk warnings by combining intent and host information. Command risk is categorized in the order of rejection, confirmation, permission, and unknown. Low-risk commands are executed automatically, medium-risk commands require manual approval, and high-risk commands are directly blocked. This solves the problems of uncontrollable O&M command risks, lack of tiered approval, and missing full-process auditing. Process pause, resumption, and redirection are achieved through graph orchestration. Single-machine, parallel, and rolling execution are accomplished via SSH channels. Results are summarized and output as a summary. Full-process data is written to audit logs, forming an interpretable, controllable, traceable, and reusable automated O&M system. This solves the problems of existing AI O&M systems that can only answer questions, cannot be implemented, and have unexplainable black-box processes.

[0051] The present invention also provides a computer-readable storage medium having a computer program stored thereon, wherein the program, when executed by a processor, implements the steps of the OpenStack cloud platform automated operation and maintenance method described above.

[0052] The present invention also provides a computer device, the computer device including a memory, a processor and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps of the OpenStack cloud platform automated operation and maintenance method described above.

[0053] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0054] The OpenStack cloud platform automated operation and maintenance method and system provided by this invention integrates knowledge retrieval and command execution in a closed loop, moving beyond simple question-and-answer processes to generate structured command plans and implement them. Even without a CMDB, it can automatically locate hosts through a static asset list and candidate host scoring mechanism, resulting in a low deployment threshold. It supports automatically identifying one or more machines based on user issues, suitable for both single-machine and cluster-level troubleshooting. Employing a self-developed unified state object and graph orchestration mechanism, it enables resumption of execution after approval pauses, significantly improving system controllability. The KnowledgeHit structure directly transforms heterogeneous enterprise knowledge into candidate sets, giving historical documents executable value. A rule-first risk gating approach is adopted, which is safer and more interpretable than pure model-based decision-making. The use of structured execution plan objects ensures that system outputs are not merely "suggestions." Instead, it is a traceable and reusable runbook; it has auditing capabilities, which can fully record problems, commands, execution, and results, which is conducive to accountability, review, and continuous optimization; through standardized operation and maintenance operations, it eliminates differences in personnel experience and ensures consistent handling of similar faults; it achieves integrated automated OpenStack operation and maintenance driven by natural language, unified utilization of knowledge, automatic host inference, automatic command generation, controllable risks, closed-loop execution, and full-process auditability; this invention can adapt to OpenAI compatible models and other subsequent model vendors, has strong scalability, and through modular design, it is easy to replace underlying capabilities such as CMDB, bastion host, Ansible, Agent, and vector library without changing the main process of this invention. It is suitable for operation and maintenance scenarios of infrastructure built on OpenStack, such as private cloud, hybrid cloud, government cloud, and enterprise cloud. Attached Figure Description

[0055] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the invention.

[0056] In the attached diagram:

[0057] Figure 1 This is a flowchart of an automated operation and maintenance method for an OpenStack cloud platform according to the present invention;

[0058] Figure 2 This is a schematic diagram of the configuration of a computer device according to an embodiment of the present invention. Detailed Implementation

[0059] 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 numerals 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 disclosure. Rather, they are merely examples of systems and products consistent with some aspects of this disclosure as detailed in the appended claims.

[0060] The terminology used in this disclosure is for the purpose of describing particular embodiments only and is not intended to be limiting of the disclosure. The singular forms “a,” “the,” and “the” as used in this disclosure and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any and all possible combinations of one or more of the associated listed items.

[0061] It should be understood that although the terms first, second, third, etc., may be used in this disclosure to describe various information, such information should not be limited to these terms. These terms are used only to distinguish information of the same type from one another. For example, without departing from the scope of this disclosure, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to determination."

[0062] The embodiments of the present invention will be described in further detail below.

[0063] Example

[0064] This invention provides an automated operation and maintenance method for the OpenStack cloud platform, including the following steps:

[0065] Step 1: Receive the user's input of a natural language operation and maintenance question. Utilize the large model and rule parsing module to perform intent recognition and entity extraction on the question, obtaining the service name, environment information, host role, fault action type, and execution scope.

[0066] Intent recognition and entity extraction are performed according to the following process:

[0067] Convert the user question into a unified text format, and perform alias normalization on synonyms such as "production / production environment", "control / control node", "compute / compute node", "storage / storage node", "all / everything"; then extract a token set composed of letters, numbers, underscores, hyphens and dots from the normalized text, and filter out stop words such as `check`, `show`, `node`, `nodes`, `host`, `hosts`, `service`, `services`, `the`, `all`, `in`;

[0068] Identify service entities in combination with a preset service name table and dynamic regular expressions, where the preset service name table at least includes `nova-api`, `nova-compute`, `neutron-server`, `keystone`, `libvirtd`, `ceph-osd`, `glance-api`, `cinder-volume`, and the dynamic regular expressions are used to identify service names in the form of `xxx-yyy` when no match is found in the preset services;

[0069] Extract environment entities and role entities according to keyword rules, where `env=prod` is determined when `prod`, `production`, or "shengchan (production)" appears, the `controller` role is added when `controller` or "kongzhi (control)" appears, the `compute` role is added when `compute` or "jisuan (compute)" appears, and the `storage` role is added when `storage` or "cunchu (storage)" appears; then determine the task type according to action keywords, where an execution-type action `action=execute` is recorded when `restart`, `fix`, `repair`, "zhixing (execute)", "chuli (process)", "jiejue (solve)" appears, otherwise it defaults to an inspection-type action `action=inspect`;

[0070] Determine `scope=multi` or `scope=single` according to scope keywords such as `all`, "suoyou (all)", "quanbu (all)", and output a structured intent object.

[0071] Step 2: From the pre-maintained static asset list, candidate hosts are recalled based on entity information, and a final target host set is generated by combining model reasoning. The target host set can be one or more hosts. The host reasoning method includes two stages: In the first stage, the `env`, `business`, `cluster`, `hostname`, `ip`, `roles`, and `tags` fields in the static asset list are matched item by item. If any field matches, the host is added to the candidate set. In the second stage, the candidate hosts are scored and sorted, and then filtered based on the task scope. 3 points are added for a match in the environment field, 2 points for a match in the business field, 2 points for a match in the cluster field, and 2 points for each match in the hostname, IP, role, and tag fields. Hosts with a score greater than 0 are retained as candidate hosts, and the matching fields are written into the candidate host's matching reason description. After sorting, when the execution scope is a single machine, the host with the highest score is selected as the final target host; when the execution scope is multiple machines, all candidate hosts are selected as the final target host, thus achieving single-machine location and multi-machine location.

[0072] Step 3: Parallel query multiple knowledge sources within the enterprise, including API knowledge base, Elasticsearch, relational database, and document knowledge base, to obtain knowledge fragments, operation suggestions, and recommended commands related to the problem.

[0073] Step 4: Combine the knowledge retrieval results, target host information, and user questions to generate a structured execution plan. The execution plan includes execution steps, target host, command content, command purpose, and expected output.

[0074] Methods for combining knowledge retrieval results, target host information, and user questions include:

[0075] Read the candidate command list from the knowledge hit results and combine it with the structured intent to determine whether high-risk commands need to be filtered; when the task type is an inspection action, filter commands containing dangerous words such as `restart`, `stop`, `start`, `delete`, `rm`, and `kill`, and only retain query commands;

[0076] When the knowledge hit result fails to provide a candidate command, a fallback command is generated based on the service name, which includes at least `systemctl status`. <service>`and`journalctl-u <service>-n 100--no-pager`;

[0077] When the task type is an execution action, further add `systemctl restart` <service>`;

[0078] Perform deduplication on candidate commands and extract the top few commands based on knowledge retrieval sorting;

[0079] The execution mode is determined based on the number of target hosts and the command content. Single host corresponds to the `single` mode, multi-host query corresponds to the `parallel` mode, and multi-host query corresponds to the `rolling` mode when there are restart commands.

[0080] For each command, generate a step identifier `step_id`, a command purpose `purpose`, a target host list `target_hosts`, and a risk hint `risk_hint`, thus forming a structured execution plan object.

[0081] Step 5: Classify commands according to the risk strategy to determine whether they are low-risk commands to be executed automatically, commands requiring manual confirmation, or commands to be prohibited from execution. Risk strategies are stored in a rule file and regular expression matching is performed in the order `deny_patterns->confirm_patterns->allow_patterns->unknown`. A command is marked as prohibited from execution when it matches a denial rule, marked as requiring manual confirmation when it matches a confirmation rule or matches no rules, and marked as automatically executable when it matches an allow rule.

[0082] Specifically, the allowed rules include at least `^systemctl status.*$`, `^journalctl.*$`, `^ps.*$`, `^cat.*$`, `^grep.*$`, `^openstack.*list.*$`, `^ceph-s$`, and `^ovs-vsctl show$`;

[0083] The rules must include at least `^systemctl restart.*$`, `^systemctl stop.*$`, `^systemctl start.*$`, `^openstack service.*`, `^docker restart.*$`, and `^kill.*`.

[0084] The rejection rules must include at least `^rm-rf / .*$`, `^mkfs.*$`, `^dd if=.*of= / dev / .*$`, `^shutdown.*$`, and `^reboot.*$`.

[0085] Step 6: Execute the allowed commands on the target host set via the SSH channel. The execution can be single-machine execution, multi-machine parallel execution, or multi-machine rolling execution.

[0086] Step 7: Summarize the execution results and output a results summary including execution success information, failure information, risk warnings, and follow-up suggestions; write the original problem, target host, knowledge source, command plan, approval actions, and execution results into the audit log.

[0087] This invention also provides an automated operation and maintenance system for an OpenStack cloud platform, used to implement the automated operation and maintenance method for an OpenStack cloud platform as described above. The system includes:

[0088] Problem parsing module: Used to receive natural language operation and maintenance problems input by users; perform intent recognition and entity extraction on the natural language operation and maintenance problems to obtain a structured intent containing service name, environment information, host role, fault action type, and execution scope;

[0089] Host inference module: Based on a pre-maintained static asset list, it uses a combination of rule-based recall and scoring sorting to infer the target host set;

[0090] The unified knowledge base retrieval module is used to query multi-source heterogeneous knowledge sources in parallel through a unified adaptation interface to obtain standardized operation and maintenance knowledge and candidate commands.

[0091] Execution plan generation module: used to combine structured intents, target host sets, and standardized operation and maintenance knowledge to generate structured command execution plans;

[0092] Risk assessment and approval module: used to classify the risks of commands in the command execution plan based on preset risk rules, and to determine three categories of commands: prohibited from execution, requiring manual confirmation, and automatically executed.

[0093] Remote execution module: Used to execute commands that have passed risk approval on a set of target hosts via an SSH tunnel;

[0094] The Results Summary and Audit Trail module is used to summarize execution results, generate and output a results summary, and write all operational data into the audit log.

[0095] Workflow orchestration module: Used with LangGraph or similar graph orchestration framework to connect the problem parsing module, host inference module, knowledge base unified retrieval module, execution plan generation module, risk assessment and approval module, remote execution module, result summary and audit trail module according to state flow, supporting conditional jump, approval pause and resumption of execution.

[0096] In terms of host management, this embodiment of the invention does not rely on CMDB, but instead uses a static asset inventory file containing information such as `hostname`, `ip`, `env`, `business`, `cluster`, `roles`, `tags`, and `ssh` as the basis for host inference.

[0097] In terms of knowledge retrieval, a unified knowledge adaptation interface is defined to standardize the processing of knowledge sources such as API, ES, DB, DOCX, PDF, Markdown, and TXT.

[0098] In terms of security, a risk policy file is used to classify commands by regular expression matching, and the matching is performed in the order of `deny_patterns`, `confirm_patterns`, and `allow_patterns`. If none of them are matched, the command is classified as a confirmation command by default.

[0099] Specifically, the risk strategy file includes the following expression:

[0100] Automatically allow the following classes: `^systemctl status.*$`, `^journalctl.*$`, `^ps.*$`, `^cat.*$`, `^grep.*$`, `^openstack.*list.*$`, `^ceph-s$`, `^ovs-vsctl show$`;

[0101] Manual confirmation required: `^systemctl restart.*$`, `^systemctl stop.*$`, `^systemctl start.*$`, `^openstack service.*`, `^docker restart.*$`, `^kill.*`;

[0102] The following classes are prohibited from execution: `^rm-rf / .*$`, `^mkfs.*$`, `^dd if=.*of= / dev / .*$`, `^shutdown.*$`, and `^reboot.*$`.

[0103] In the expression, `^` represents the start position of the command, `$` represents the end position of the command, `.` represents any single character, and `.*` represents a string of any length;

[0104] For example, `^systemctl status.*$` represents all commands that begin with `systemctl status`;

[0105] `^dd if=.*of= / dev / .*$` represents the `dd` command where the input file parameter has any value and the output target points to any device file.

[0106] Specifically, the hierarchical types for regular expression matching of commands include:

[0107] Low-risk query commands that can be executed automatically;

[0108] Change commands that require manual confirmation;

[0109] High-risk orders that are refused to be executed.

[0110] Among them, the low-risk query commands that can be executed automatically include `systemctl status nova-api`, `journalctl -u nova-api -n 100 --no-pager`, `ps -ef|grep nova-api`, `openstackserver list`, `ceph -s`, and `ovs-vsctl show`.

[0111] The change commands that require manual confirmation include `systemctl restart nova-api`, `systemctl stop neutron-server`, `systemctl start libvirtd`, `docker restart nova-api`, and `kill 1234`.

[0112] High-risk commands that are refused execution include `rm-rf / `, `mkfs.ext4 / dev / sdb`, `dd if= / tmp / aof= / dev / sda`, `shutdown-hnow`, and `reboot`.

[0113] In terms of process control, a stateful diagram orchestration model is adopted, which determines whether to enter a remote execution node based on the approval status, thereby realizing an intelligent operation and maintenance process that is pauseable, resumable, and auditable. The intelligent operation and maintenance process can be represented as follows:

[0114] `User question input->parse_query->infer_hosts->retrieve_knowledge->build_plan->assess_risk->approval_gate`;

[0115] When `approval_gate` determines that `approval_required=false` or `approval_status=approved`, the process transfers to `execute_ssh->summarize_result`.

[0116] When `approval_status=pending`, the process directly proceeds to `summarize_result` to output the information pending approval;

[0117] When the risk result is `blocked=true`, the process directly jumps to `summarize_result` to output the blocking information. The state diagram of this process clearly shows the pause point, the resumption point, and the execution of the access control.

[0118] This invention does not rely on CMDB, and achieves intelligent host inference, rule-based risk control to ensure security, graph state orchestration to support approval breakpoints, unified transformation of multi-source knowledge into executable plans, and modular and scalable full-process workflow.

[0119] To enhance the executability and interpretability of the system, this embodiment of the invention does not directly generate results using a single prompt word. Instead, it defines a set of self-developed data structures, inference algorithms, gating rules, and graph state transition mechanisms; specifically as follows:

[0120] 1. Self-developed state objects and closed-loop state flow:

[0121] The system internally defines a unified state object `AgentState` to pass intermediate results between different processing stages and support resumption of execution after approval is paused. This state object includes at least the following fields:

[0122] `user_query`: The original user query.

[0123] `normalized_intent`: The parsed structured intent.

[0124] `candidate_hosts`: A set of candidate hosts.

[0125] `selected_hosts`: The one or more hosts that were ultimately selected.

[0126] `knowledge_hits`: Standardized knowledge hit results.

[0127] `execution_plan`: Structured command plan.

[0128] `risk_assessment`: Risk assessment results.

[0129] `approval_status`: Approval status.

[0130] `execution_results`: The set of execution results.

[0131] `final_answer`: The final output summary.

[0132] A unified state object enables problem understanding, knowledge retrieval, plan generation, risk assessment, and command execution to be broken down into multiple auditable nodes.

[0133] When a command requires approval, it can be paused in the `approval_status=pending` state without losing the context generated by the previous node.

[0134] Once the user approves the request, simply updating the status to `approval_status=approved` will restore graph execution; there is no need to re-query the knowledge base or re-parse the issue.

[0135] The illustrative pseudocode for defining a unified state object in this embodiment is as follows:

[0136] …text

[0137] AgentState={

[0138] user_query,

[0139] normalized_intent,

[0140] candidate_hosts,

[0141] selected_hosts,

[0142] knowledge_hits,

[0143] execution_plan,

[0144] risk assessment

[0145] approval_status,

[0146] execution_results,

[0147] final_answer

[0148] }

[0149] …

[0150] 2. Candidate Host Recall and Scoring Mechanism:

[0151] The embodiments of this invention do not simply rely on a large model to "guess" the target host, but instead employ a two-stage inference mechanism of "rule recall and model induction," as detailed below:

[0152] The first phase involves performing field-level searches on the static asset list. The search fields must include at least the following:

[0153] `env`

[0154] `business`

[0155] `cluster`

[0156] `roles`

[0157] `tags`

[0158] `hostname`

[0159] `ip`

[0160] In the second stage, the recalled candidate set is scored and ranked, and then the model performs the final selection based on the user question and the role description of the candidate host. The candidate host score is calculated as follows:

[0161] …text

[0162] HostScore=W1×EnvMatch+W2×BusinessMatch+W3×ClusterMatch+W4×RoleMatch+W5×TagMatch+W6×HostnameMatch+W7×IpMatch

[0163] …

[0164] Here, `EnvMatch` indicates whether the environment is matched, such as `prod`, `test`;

[0165] `RoleMatch` indicates whether a role has been matched, such as `controller`, `nova-api`, and `compute`.

[0166] `TagMatch` indicates whether a tag is matched, such as `control-plane`, `ceph`;

[0167] `HostnameMatch` and `IpMatch` indicate whether the user directly specifies the hostname or IP address.

[0168] The illustrative pseudocode is as follows:

[0169] …text

[0170] For host in inventory:

[0171] score=0

[0172] if host.env in query:score+=3

[0173] if host.business in query:score+=2

[0174] if host.cluster in query:score+=2

[0175] For the role in host.roles:

[0176] if role in query:score+=2

[0177] For tags in host tags:

[0178] if tag in query: score+=1

[0179] if host.hostname in query or host.ip in query:

[0180] score+=3

[0181] if score > threshold:

[0182] Add host to candidate_hosts

[0183] sort candidate_hosts by score desc

[0184] …

[0185] Through the above mechanism, this embodiment can stably achieve single-machine and multi-machine positioning without CMDB, and can clearly give the reason for each machine being selected, rather than generating unverifiable machine names from the model.

[0186] 3. Unified and standardized structure for multi-source knowledge:

[0187] This invention defines a unified knowledge hit object `Knowledge Hit`, used to absorb heterogeneous results returned by different knowledge sources and to make subsequent plan generation modules independent of specific knowledge source formats. `Knowledge Hit` includes at least the following fields:

[0188] `source_name`: Name of the knowledge source;

[0189] `title`: Title;

[0190] `content`: Original content;

[0191] `summary`: a summary or summary;

[0192] `commands`: A list of candidate commands extracted from the knowledge content;

[0193] `score`: Hit score;

[0194] `metadata`: Metadata information.

[0195] The problem analysis module performs text extraction and command recognition on `DOCX / PDF / Markdown / TXT` files. When recognizing commands, it pays attention to at least the following maintenance command prefixes:

[0196] `systemctl`

[0197] `journalctl`

[0198] `openstack`

[0199] `ceph`

[0200] `ovs-vsctl`

[0201] `grep`

[0202] `cat`

[0203] `ps`

[0204] The following is a schematic pseudocode for text extraction and command recognition:

[0205] …text

[0206] for file in knowledge_dir:

[0207] text = extract_text(file)

[0208] If query_terms overlap text:

[0209] commands=extract_command_lines(text)

[0210] hit={

[0211] source_name:source,

[0212] title:file.name,

[0213] content:text,

[0214] summary: summarize(text),

[0215] commands:commands,

[0216] score:overlap_score(query_terms,text),

[0217] metadata:{path,suffix}

[0218] }

[0219] …

[0220] By introducing this standard structure, this embodiment of the invention can transform document knowledge that was originally only used for reading into structured knowledge that can be directly used in command planning.

[0221] 4. Command plan generation mechanism:

[0222] This invention does not directly output the retrieved document fragments to the user as is, but defines a structured execution plan object `ExecutionPlan`, where each step (a specific command execution action) includes at least:

[0223] `step_id`

[0224] `command`

[0225] `purpose`

[0226] `target_hosts`

[0227] `risk_hint`

[0228] The execution plan generation module combines the user's original question, the parsed structured intent, the target host set, and the standardized knowledge hit results to generate the final command plan.

[0229] For query-only issues, this embodiment of the invention automatically filters high-risk commands, retaining only `status / log / show` commands. For issues that explicitly require repair or handling, `restart` operations can be added to the plan, but must enter the risk gating process. Illustrative pseudocode is as follows:

[0230] …text

[0231] if intent.action == inspect:

[0232] remove commands containing restart / stop / start / kill / delete

[0233] if no command from knowledge Hits:

[0234] generate fallback command based on service name

[0235] for command in selected_commands:

[0236] add step(step_id,command,purpose,target_hosts,risk_hint)

[0237] …

[0238] The command plan generation mechanism ensures that the output of this embodiment of the invention is an "executable runbook" rather than ordinary question and answer text.

[0239] 5. Command risk gating and approval sequence:

[0240] The risk control in this embodiment of the invention does not rely solely on model judgment, but rather adopts a "rule-first, model-assisted interpretation" approach, performing the following matching on commands sequentially:

[0241] (1) `deny_patterns`

[0242] (2) `confirm_patterns`

[0243] (3) `allow_patterns`

[0244] (4) Default command for rules not hit

[0245] The order of judgment is as follows:

[0246] …text

[0247] if command matches deny_patterns:

[0248] level=deny

[0249] elif command matches confirm_patterns:

[0250] level=confirm

[0251] elif command matches allow_patterns:

[0252] level=allow

[0253] else:

[0254] level=unknown

[0255] …

[0256] Where `deny` means to prevent execution, such as deleting the root directory, formatting the disk, or forcing shutdown;

[0257] `confirm` indicates that manual confirmation is required, such as `systemctl restart` or `systemctl stop`.

[0258] `allow` indicates low-risk query commands that can be executed automatically, such as `systemctl status`, `journalctl`, and `ps`.

[0259] `unknown` indicates that the rule was not hit, and the process will proceed to the confirmation stage by default.

[0260] This gating method prevents the model from misjudging dangerous commands as low-risk; it supports enterprise operations and maintenance in configuring whitelists, confirmation lists, and rejection lists according to actual policies; and it allows the same batch of commands to include both automatically executed commands and commands that require manual confirmation.

[0261] 6. Graph-based pause and resume execution mechanism:

[0262] This invention employs a directed graph state arrangement method to organize the operation and maintenance process, with the preferred node order as follows:

[0263] …text

[0264] parse_query->infer_hosts->retrieve_knowledge->build_plan

[0265] ->assess_risk->approval_gate->execute_ssh->summarize_result

[0266] …

[0267] The `approval_gate` node has conditional branching functionality:

[0268] When `approval_required=false`, it directly enters `execute_ssh`.

[0269] When `approval_required=true` and `approval_status=pending`, pause at the current status and return the pending approval result.

[0270] When `approval_status=approved`, resume from the current state and enter `execute_ssh`.

[0271] When a command is marked `deny`, execution is skipped and the blocking result is output.

[0272] The illustrative pseudocode is as follows:

[0273] …text

[0274] if risk_assessment.blocked:

[0275] goto summarize_result

[0276] if not risk_assessment.approval_required:

[0277] goto execute_ssh

[0278] if approval_status==approved:

[0279] goto execute_ssh

[0280] else:

[0281] goto summarize_result with pending message

[0282] …

[0283] Compared to existing black-box agents that make one-off decisions, this graph orchestration method offers greater interpretability, pluggability, and auditability.

[0284] Application examples

[0285] The present invention can be applied to a variety of practical scenarios. The following are examples of the actual operation process of the present invention in two different scenarios.

[0286] Application Example 1: Query-related problems:

[0287] User input: "Please check the nova-api status on all control nodes in the production environment."

[0288] The system execution process is as follows:

[0289] 1. The problem analysis module identified:

[0290] `service=nova-api`

[0291] `env=prod`

[0292] `role=controller`

[0293] `scope=multi`

[0294] `action=inspect`

[0295] 2. The host inference module retrieves `controller-01` and `controller-02` from the static asset list and generates a candidate set based on the environment, role, and service hit information.

[0296] 3. The unified retrieval module of the knowledge base includes knowledge entries in the document knowledge base that contain `systemctl status nova-api` and `journalctl -u nova-api`.

[0297] 4. The command plan generation module constructs the following plan:

[0298] Execute `systemctl status nova-api` on `controller-01` and `controller-02`.

[0299] Execute `journalctl -u nova-api -n 100 --no-pager` on `controller-01` and `controller-02`.

[0300] 5. The risk assessment module identified that all of the above commands are low-risk query commands.

[0301] 6. The remote execution module executes commands on two hosts in parallel via SSH.

[0302] 7. The results summary module returns the execution status and log summary for each machine.

[0303] Application Example 2: Handling Class Problems:

[0304] User input: "The production environment nova-api is malfunctioning. Please try to restore it directly."

[0305] The system execution process is as follows:

[0306] 1. The problem analysis module identified:

[0307] `service=nova-api`

[0308] `env=prod`

[0309] `action=execute`

[0310] 2. The host inference module determines the target host as a set of control nodes.

[0311] 3. The unified retrieval module of the knowledge base extracts `systemctl restart nova-api` from the knowledge entries.

[0312] 4. The command plan generation module adds inspection commands and recovery commands to the execution plan.

[0313] 5. The risk assessment module identified `systemctl restart nova-api` as a confirmation command.

[0314] 6. The diagram arrangement process pauses at the approval node and outputs the "pending approval" plan result to the user.

[0315] 7. After user approval, the system resumes execution from the paused state and executes the recovery command on a rolling basis for each target host.

[0316] 8. Finally, output the execution result and write the approval action and execution result into the audit log.

[0317] As can be seen from the above application examples, the solution of the present invention can not only answer the question, but also form a true operation and maintenance execution closed loop in single-machine and multi-machine scenarios.

[0318] This invention also provides a computer device. Figure 2 This is a schematic diagram of the structure of a computer device provided in an embodiment of the present invention; see the accompanying drawings. Figure 2 As shown, the computer device includes: an input device 23, an output device 24, a memory 22, and a processor 21; the memory 22 is used to store one or more programs; when the one or more programs are executed by the one or more processors 21, the one or more processors 21 implement the OpenStack cloud platform automated operation and maintenance method provided in the above embodiments; wherein the input device 23, the output device 24, the memory 22, and the processor 21 can be connected via a bus or other means. Figure 2 Taking the example of a connection between China and Israel via a bus.

[0319] The memory 22, as a read / write storage medium for computing devices, can be used to store software programs and computer-executable programs, such as the program instructions corresponding to the OpenStack cloud platform automated operation and maintenance method described in this embodiment of the invention. The memory 22 may mainly include a program storage area and a data storage area. The program storage area may store the operating system and at least one application program required for a function; the data storage area may store data created based on the use of the device. Furthermore, the memory 22 may include high-speed random access memory and non-volatile memory, such as at least one disk storage device, flash memory device, or other non-volatile solid-state storage device. In some instances, the memory 22 may further include memory remotely located relative to the processor 21, and these remote memories can be connected to the device via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0320] Input device 23 can be used to receive input digital or character information, and generate key signal inputs related to user settings and function control of the device; output device 24 may include display devices such as a display screen.

[0321] The processor 21 executes various functional applications and data processing of the device by running software programs, instructions and modules stored in the memory 22, thereby realizing the above-mentioned automated operation and maintenance method of the OpenStack cloud platform.

[0322] The computer equipment provided above can be used to execute the OpenStack cloud platform automated operation and maintenance method provided in the above embodiments, and has corresponding functions and beneficial effects.

[0323] This invention also provides a storage medium containing computer-executable instructions, which, when executed by a computer processor, are used to perform the OpenStack cloud platform automated operation and maintenance method provided in the above embodiments. The storage medium can be any type of memory device or storage device, including: mounting media such as CD-ROM, floppy disk, or magnetic tape; computer system memory or random access memory such as DRAM, DDRRAM, SRAM, EDORAM, Rambus RAM, etc.; non-volatile memory such as flash memory, magnetic media (e.g., hard disk or optical storage); registers or other similar types of memory elements; the storage medium may also include other types of memory or combinations thereof; furthermore, the storage medium may reside in a first computer system in which the program is executed, or it may reside in a different second computer system connected to the first computer system via a network (such as the Internet); the second computer system can provide program instructions to the first computer for execution. The storage medium includes two or more storage media that may reside in different locations (e.g., in different computer systems connected via a network). The storage medium may store program instructions (e.g., specifically implemented as a computer program) executable by one or more processors.

[0324] Of course, the computer-executable instructions provided in the embodiments of the present invention are not limited to the OpenStack cloud platform automated operation and maintenance method described in the above embodiments, but can also perform related operations in the OpenStack cloud platform automated operation and maintenance method provided in any embodiment of the present invention.

[0325] The technical solution of the present invention has been described above with reference to the preferred embodiments shown in the accompanying drawings. However, it will be readily understood by those skilled in the art that the scope of protection of the present invention is obviously not limited to these specific embodiments. Without departing from the principles of the present invention, those skilled in the art can make equivalent changes or substitutions to the relevant technical features, and the technical solutions after these changes or substitutions will all fall within the scope of protection of the present invention.

[0326] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.< / service> < / service> < / service>

Claims

1. An automated operation and maintenance method for an OpenStack cloud platform, characterized in that, Includes the following steps: S1. Receive a natural language operation and maintenance question input by the user; perform intent recognition and entity extraction on the natural language operation and maintenance question to obtain a structured intent containing service name, environment information, host role, fault action type, and execution scope; S2. Based on a pre-maintained static asset list, the target host set is inferred by combining rule-based recall and scoring ranking. S3. By using a unified adaptation interface to query multi-source heterogeneous knowledge sources in parallel, standardized operation and maintenance knowledge and candidate commands are obtained. S4. Combine structured intents, target host sets, and standardized operation and maintenance knowledge to generate a structured command execution plan; S5. Based on preset risk rules, classify the commands in the command execution plan according to risk and determine three categories of command rules: prohibited from execution, requiring manual confirmation, and automatically executed. S6. For commands that have passed risk approval, execute the commands on the target host set via SSH tunnel; S7. Summarize the execution results, generate a result summary and output it; write the entire operation and maintenance process data into the audit log.

2. The automated operation and maintenance method for the OpenStack cloud platform according to claim 1, characterized in that, The intent recognition and entity extraction in step S1 include: Text normalization and synonym replacement; stop word filtering; service entity identification based on pre-set service tables and dynamic regular expressions; extraction of environmental and role entities based on keywords; determination of inspection or execution actions based on action keywords; determination of single-machine or multi-machine execution range based on range keywords.

3. The automated operation and maintenance method for the OpenStack cloud platform according to claim 1, characterized in that, The inference of the target host set in step S2 includes: Phase 1 rule recall: Match the fields env, business, cluster, hostname, ip, roles, and tags in the static asset list, and add the host to the candidate list if a match is found; The second stage of scoring and ranking is calculated as follows: HostScore = W1×EnvMatch + W2×BusinessMatch + W3×ClusterMatch + W4×RoleMatch + W5×TagMatch + W6×HostnameMatch + W7×IpMatch… EnvMatch indicates whether the environment was hit; RoleMatch indicates whether the character hits; TagMatch indicates whether the tag was matched; HostnameMatch and IpMatch indicate whether the user directly specifies the hostname or IP address; For single-machine selection, the host with the highest score is chosen; for multi-machine selection, all candidate hosts are chosen. The set of target hosts and the reason for the hit are output.

4. The automated operation and maintenance method for the OpenStack cloud platform according to claim 1, characterized in that, The multi-source heterogeneous knowledge sources mentioned in step S3 include API knowledge bases, Elasticsearch, relational databases, and DOCX / PDF / Markdown / TXT document knowledge bases. The search results are uniformly encapsulated into a Knowledge Hit structure, which includes source_name, title, content, summary, commands, score, and metadata.

5. The automated operation and maintenance method for the OpenStack cloud platform according to claim 1, characterized in that, The structured command execution plan in step S4 includes step_id, command, purpose, target_hosts, and risk_hint; the inspection class automatically filters high-risk commands, and generates systemctl status and journalctl rollback commands when no knowledge is matched; the execution class adds a restart command; the execution modes include single, parallel, and rolling.

6. The automated operation and maintenance method for the OpenStack cloud platform according to claim 1, characterized in that, The risk classification in step S5 is matched in the order of deny_patterns, confirm_patterns, allow_patterns, and unknown; Commands that cannot be executed include rm -rf / , mkfs, dd, shutdown, and reboot; Commands requiring manual confirmation include systemctl restart / stop / start, docker restart, and kill; Commands that can be executed automatically include systemctl status, journalctl, ps, cat, grep, openstack list, ceph -s, and ovs-vsctl show; If the rule command is not matched, the process will proceed to manual confirmation by default.

7. An automated operation and maintenance system for an OpenStack cloud platform, used to implement the automated operation and maintenance method for an OpenStack cloud platform as described in any one of claims 1-6, characterized in that, include: Problem parsing module: Used to receive natural language operation and maintenance problems input by users; The natural language operation and maintenance question is subjected to intent recognition and entity extraction to obtain a structured intent containing service name, environment information, host role, fault action type, and execution scope; Host inference module: Based on a pre-maintained static asset list, it uses a combination of rule-based recall and scoring sorting to infer the target host set; The unified knowledge base retrieval module is used to query multi-source heterogeneous knowledge sources in parallel through a unified adaptation interface to obtain standardized operation and maintenance knowledge and candidate commands. Execution plan generation module: used to combine structured intents, target host sets, and standardized operation and maintenance knowledge to generate structured command execution plans; Risk assessment and approval module: used to classify the risks of commands in the command execution plan based on preset risk rules, and to determine three categories of commands: prohibited from execution, requiring manual confirmation, and automatically executed. Remote execution module: Used to execute commands that have passed risk approval on a set of target hosts via an SSH tunnel; The Results Summary and Audit Trail module is used to summarize execution results, generate a results summary, and output it. Write all operation and maintenance process data into the audit log.

8. The OpenStack cloud platform automated operation and maintenance system according to claim 7, characterized in that, It also includes a process orchestration module, which uses LangGraph or a similar graph orchestration framework to connect the problem parsing module, host inference module, knowledge base unified retrieval module, execution plan generation module, risk assessment and approval module, remote execution module, result summary and audit trail module according to the state flow, and supports conditional jump, approval pause and resumption of execution.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the steps of the OpenStack cloud platform automated operation and maintenance method as described in any one of claims 1-6.

10. A computer device, the computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the steps of the OpenStack cloud platform automated operation and maintenance method as described in any one of claims 1-6.

Images