Fault processing method and device based on cloud server, equipment and storage medium

Abstract

The embodiment of the invention provides a fault processing method and device based on a cloud server, equipment and a storage medium. The method comprises the steps of obtaining user information and system information in response to a selection instruction of a user for a rescue scene; wherein the rescue scene represents the type of a to-be-processed fault, the user information represents identification information of a user, and the system information comprises identification information of a cloud server with a fault and identification information of the rescue scene; determining a rescue flow sequence according to the user information and the system information; wherein the rescue process sequence represents links needing to be executed during fault processing and an execution sequence among the links; according to the rescue process sequence, processing the fault of the cloud server based on the atomization function module corresponding to each link to obtain a fault processing result; wherein the atomization function module represents an API (Application Program Interface) which is packaged in advance and is used for executing a corresponding link.

Description

Technical Field

[0001] This application relates to the field of cloud computing technology, and in particular to a fault handling method, apparatus, device and storage medium based on a cloud server. Background Technology

[0002] With the rapid development of cloud computing technology, cloud servers are widely used as infrastructure in various business systems. When a cloud server operating system experiences a serious failure (such as boot failure, file system corruption, or lost password), the administrator typically modifies the configuration in the backend and mounts a rescue image to perform repairs.

[0003] However, the administrator intervention mode is inefficient, has a long response delay, and manual operation is prone to misconfiguration. For tenants, the efficiency and accuracy of fault handling are low, affecting their use of the cloud server. Summary of the Invention

[0004] This application provides a fault handling method, apparatus, device, and storage medium based on cloud servers to improve the efficiency of fault handling for cloud servers.

[0005] In a first aspect, embodiments of this application provide a fault handling method based on a cloud server, including:

[0006] In response to the user's command to select a rescue scenario, user information and system information are obtained; wherein, the rescue scenario represents the type of fault to be handled, the user information is the identification information representing the user, and the system information includes the identification information of the cloud server with the fault and the identification information of the rescue scenario;

[0007] Based on the user information and the system information, a rescue process sequence is determined; wherein, the rescue process sequence represents the steps required to perform fault handling and the execution order between each step;

[0008] According to the rescue process sequence, based on the atomic functional modules corresponding to each stage, the fault of the cloud server is processed to obtain the fault processing result; wherein, the atomic functional module represents a pre-encapsulated API for executing the corresponding stage.

[0009] Secondly, embodiments of this application provide a fault handling device based on a cloud server, comprising:

[0010] The information acquisition unit is used to acquire user information and system information in response to the user's selection instruction for the rescue scenario; wherein, the rescue scenario represents the type of fault to be processed, the user information is the identification information representing the user, and the system information includes the identification information of the cloud server with the fault and the identification information of the rescue scenario;

[0011] The sequence determination unit is used to determine the rescue process sequence based on the user information and the system information; wherein, the rescue process sequence represents the steps to be performed when handling the fault and the execution order between each step;

[0012] The fault handling unit is used to process the faults of the cloud server according to the rescue process sequence and based on the atomic functional modules corresponding to each stage, and obtain the fault handling result; wherein, the atomic functional module represents a pre-encapsulated API for executing the corresponding stage.

[0013] Thirdly, embodiments of this application provide an electronic device, including: a memory and a processor;

[0014] The memory stores computer-executed instructions;

[0015] The processor executes computer execution instructions stored in the memory, causing the processor to perform the implementation method described in the first aspect above.

[0016] Fourthly, 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 embodiments described in the first aspect above.

[0017] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the implementation methods described in the first aspect above.

[0018] This application provides a cloud server-based fault handling method, apparatus, device, and storage medium. When a cloud server malfunctions and requires rescue, it determines the rescue scenario (i.e., the current fault type) and the user's identity by responding to the user's selection instruction for the rescue scenario. This yields system information and user information, including the identifier of the faulty cloud server and the identifier of the rescue scenario. Based on the different user and system information, a rescue process sequence is determined for the user and the rescue scenario. The rescue process sequence represents the steps required for fault handling and the execution order between these steps. Different users may receive different rescue processes in different rescue scenarios. Each step in the rescue process corresponds to an atomic functional module, which represents a pre-encapsulated API for executing the corresponding step. Based on the atomic functional modules corresponding to each step in the rescue process sequence, the cloud server fault is automatically handled, resulting in a fault handling outcome. By breaking down the rescue process into multiple atomic functional modules and automatically assembling execution sequences based on the rescue scenario selected by the user, the standardization and automation of fault handling are achieved. This enables tenants to perform self-service, low-threshold, and highly secure cloud server fault repair without administrator intervention, significantly improving operational efficiency and system availability. Attached Figure Description

[0019] 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.

[0020] Figure 1 A flowchart illustrating a cloud server-based fault handling method provided in this application embodiment;

[0021] Figure 2 A flowchart illustrating a cloud server-based fault handling method provided in this application embodiment;

[0022] Figure 3 A flowchart illustrating a cloud server-based fault handling method provided in this application embodiment;

[0023] Figure 4 A flowchart illustrating the rescue process for a disk repair scenario provided in this application embodiment;

[0024] Figure 5 A schematic diagram of a cloud server-based fault handling device provided in an embodiment of this application;

[0025] Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0026] 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

[0027] 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.

[0028] First, let me explain the terms used in this application:

[0029] Atomized functional modules: Independent functional modules that break down the rescue process, such as information collection, image matching, and resource loading. Each module performs only a single responsibility, and operation isolation and precise access control are achieved through API encapsulation.

[0030] API: Application Programming Interface;

[0031] Cloud server: refers to virtualized computing resources deployed on a cloud computing platform, which can be accessed and managed by tenants via the network;

[0032] Libvirt (Library for Virtualization) is an open-source virtualization management API that supports various virtualization technologies and enables operations such as creating, starting, stopping, and modifying the configuration of virtual machines. This application uses the Libvirt API to implement the modification and restart control of the underlying configuration of cloud servers. It is a core dependency for the implementation of virtualization layer functions, and the security of API calls is ensured through field-level isolation.

[0033] RESTful API: Representational State Transfer API is a software architectural style API design specification that features statelessness and caching. It is often used for distributed system interactions. This application implements atomic and secure calls for rescue operations by encapsulating RESTful API, and is the core interface form for tenant self-service operations and underlying service interactions.

[0034] During the provision of computing services to users by cloud servers, failures such as operating system corruption, file loss, and forgotten passwords often occur due to user errors, system anomalies, or software conflicts. Traditional physical servers can be repaired by mounting a CD-ROM and entering recovery mode, but cloud servers, as virtualized resources, cannot directly support such physical media access. Currently, some cloud platforms rely on administrators manually modifying virtual machine configurations to simulate ISO (disk image file format) mounting, or using snapshot recovery and instance reconstruction to address failures. These methods generally suffer from high security risks, lack of tenant self-help, and difficulty in guaranteeing data integrity. Especially for small and medium-sized enterprises and non-professional users, the lack of control over the underlying system leads to long fault handling cycles and prolonged business interruptions, severely impacting service availability and user experience.

[0035] Against this backdrop, how to implement a cloud server fault handling mechanism that both ensures security and supports tenant self-service operations has become an urgent technical problem to be solved.

[0036] This application provides a fault handling method, apparatus, device, and storage medium based on a cloud server, which are applied in the field of cloud computing technology to improve the efficiency and accuracy of fault handling.

[0037] It should be noted that the data in this embodiment is not specific to any particular user and does not reflect the personal information of any particular user. It should also be noted that the data in this embodiment comes from a publicly available dataset.

[0038] The collection, storage, use, processing, transmission, provision, and disclosure of user personal information involved in the technical solution of this application all comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0039] To enable readers to have a deeper understanding of the implementation principles of this application, the embodiments are further detailed.

[0040] Figure 1 This is a flowchart illustrating a cloud server-based fault handling method according to an embodiment of this disclosure. This method can be executed by a cloud server-based fault handling device. Figure 1 As shown, the method includes the following steps:

[0041] S101. In response to the user's command to select a rescue scenario, obtain user information and system information; wherein, the rescue scenario represents the type of fault to be processed, the user information is the identification information representing the user, and the system information includes the identification information of the cloud server with the fault and the identification information of the rescue scenario.

[0042] For example, a user refers to a tenant using a cloud server. During the tenant's use of the cloud server, the cloud server may experience failures, and the tenant needs to handle these failures promptly. A cloud server can be implemented using a VM (Virtual Machine), and a cloud server failure can refer to a VM failure.

[0043] Responding to the user's selection of a rescue scenario means that the tenant selects a preset fault handling type on the front-end interface, such as "password reset", "disk repair", or "kernel crash recovery", and the system triggers subsequent processes. This selection behavior can be implemented through various methods such as a graphical console, command-line interface, or RESTful (Representational State Transfer, a software architectural style) calls, and is suitable for public cloud, private cloud, and hybrid cloud deployment environments.

[0044] Rescue scenarios are predefined categories of faults, each corresponding to a specific set of processing logic and toolsets. For example, the "password reset" scenario focuses on intervention in the identity authentication module, while "disk repair" involves loading file system checking and repair tools. By pre-designing rescue scenarios, users do not need to understand the underlying technical details; they only need to select the corresponding scenario based on the actual problem to initiate the repair process. In other words, users only need to know what type of fault they are currently experiencing and select that fault type on the interface.

[0045] Upon receiving a user's instruction to select a rescue scenario, user information and system information can be obtained. User information can be identifying information that represents the user, typically including but not limited to tenant ID, account identifier, role permission level, etc., used to identify the request source and verify the legitimacy of the operation. User information can be obtained from a pre-set identity authentication system to ensure that the calling entity is qualified to perform the corresponding operation. System information mainly includes the unique identifier of the faulty cloud server, for example, it could be the VM ID, and it could also include the identifier of the currently selected rescue scenario. System information can be used to locate the target virtual machine and, combined with the context, determine the processing path to be enabled. System information can be included in the user's selection instruction; for example, the user can select the VM to be processed and the rescue scenario through a human-machine interface, thereby obtaining system information from the selection instruction.

[0046] S102. Determine the rescue process sequence based on user information and system information; wherein, the rescue process sequence represents the steps required to handle the fault and the execution order between each step.

[0047] For example, the rescue process sequence is an ordered task chain, which is represented as a series of functional steps arranged in sequence. For example, the rescue process sequence can be represented as: information collection → image matching → configuration snapshot → resource loading → tool scheduling → configuration rollback. That is, the rescue process sequence includes six steps, namely information collection, image matching, configuration snapshot, resource loading, tool scheduling, and configuration rollback.

[0048] Multiple rescue scenarios are pre-configured, and each scenario can have a different pre-set rescue process sequence. That is, the steps in the corresponding rescue process sequence may differ for different rescue scenarios, and the execution order of each step may also differ. For example, the "password reset" scenario may not include the driver layer loading step; while the "kernel repair" scenario requires the complete execution of all steps.

[0049] For the same rescue scenario, the rescue sequence may differ for different users, and the rescue sequence may also differ for different VMs. Therefore, the association between user information, system information, and the rescue process sequence can be pre-defined. Based on the obtained user information and system information, and according to the pre-defined association, the corresponding rescue process sequence is determined. That is, it determines which steps need to be executed during fault repair and the execution order of each step.

[0050] In this embodiment, the relationships can be implemented using a rule engine or a lightweight state machine, allowing for the addition and removal of scenarios. For example, when adding a "network repair" scenario, two steps can be added to the relationship: "network card driver layer loading" and "network tool layer loading." Each step corresponds to an atomic functional module, which is a pre-packaged API. By adding or removing atomic functional modules from the relationship, the relationship can be modified. That is, only the configuration of the relationship needs to be modified, without changing the core code logic, thus improving the system's flexibility and maintainability.

[0051] In this embodiment, the rescue process sequence can be dynamically adjusted according to the user's permission level. For example, ordinary tenants are only allowed to execute the standard process with automatic rollback protection, while senior administrators can skip certain verification steps to speed up processing and improve the accuracy and efficiency of fault handling.

[0052] S103. Based on the rescue process sequence and the atomic functional modules corresponding to each step, the faults of the cloud server are processed to obtain the fault processing results; wherein, the atomic functional modules represent pre-encapsulated APIs used to execute the corresponding steps.

[0053] For example, an atomized functional module refers to breaking down the complete rescue process into functional units with single responsibilities and clear boundaries, and exposing them to the outside world through standard interfaces. Each module completes only one specific task. For example, the "information collection" module is only responsible for reading the operating system version, kernel number, and PCI (Peripheral Component Interconnect) device list, without involving any configuration modification operations.

[0054] In this embodiment, the atomic functional module of the information collection stage can be the VM information collection API, which is responsible for calling libvirt to obtain basic user information and system information; the atomic functional module of the image matching stage can be the layered image matching API, which is responsible for searching for suitable base images, toolkits, and driver components in the image repository based on the collected information; the atomic functional module of the configuration snapshot stage can be the configuration snapshot API, which is used to back up the original configuration of the VM; the atomic functional module of the configuration rollback stage can be the configuration rollback API, which is used to restore the state when the repair fails; the atomic functional module of the resource loading stage can be the resource loading API, which mounts the rescue image to the specified boot location through the virtualization layer interface and sets the boot order; the atomic functional module of the tool scheduling stage can be the tool scheduling API, which is used to trigger the virtual machine to restart and activate the repair tools in the rescue environment.

[0055] Based on the sequence of steps in the rescue process, the corresponding atomic function modules for each step are invoked to automatically repair the cloud server and obtain the fault handling result. The fault handling result is the final output after the entire process is completed. It is usually returned in a structured form, including fields such as processing status (success / failure), key log summary, and time consumption statistics.

[0056] In this embodiment, each atomic functional module can run in an independent microservice process, with traffic, circuit breaking, and authentication managed uniformly by the service mesh, further enhancing the stability and observability of the system.

[0057] In this embodiment, the user selects a rescue scenario as the entry trigger point, and the system obtains context information accordingly. Based on user and system information, a customized rescue process path is generated through a lookup table. Then, a series of atomic APIs with clearly defined responsibilities are invoked to progressively advance the repair actions, ultimately summarizing a clear result and providing feedback to the user. Through the above steps, this embodiment enables tenants to handle cloud server failures independently without sacrificing security. By encapsulating complex operations into loosely coupled, highly cohesive atomic services, potentially risky operations are effectively isolated. The scenario-driven process orchestration mechanism shields the underlying technical complexity, significantly lowering the barrier to entry. Simultaneously, the modular design supports rapid expansion of new failure types, adapting to the evolving needs of the cloud environment. This solves the problem of tenants being unable to securely repair cloud server failures independently, improving operational efficiency, shortening business downtime, and enhancing cloud platform availability.

[0058] This application provides a cloud server-based fault handling method. When a cloud server malfunctions and requires rescue, the method responds to the user's selection of a rescue scenario to determine the current fault type and the user's identity, thereby obtaining system and user information. The system information may include the identification information of the faulty cloud server and the identification information of the rescue scenario. Based on different user and system information, a rescue process sequence is determined for the user and the rescue scenario. The rescue process sequence represents the steps required for fault handling and the execution order between these steps. Different users may receive different rescue processes in different rescue scenarios. Each step in the rescue process corresponds to an atomic functional module, which represents a pre-encapsulated API for executing the corresponding step. Based on the atomic functional modules corresponding to each step in the rescue process sequence, the cloud server fault is automatically handled to obtain the fault handling result. By decomposing the rescue process into multiple atomic functional modules and automatically assembling the execution sequence based on the user-selected rescue scenario, the method achieves standardization and automation of fault handling. This enables tenant-based, low-threshold, and highly secure cloud server fault repair without administrator intervention, significantly improving operational efficiency and system availability.

[0059] Figure 2 A flowchart illustrating a cloud server-based fault handling method provided in this application embodiment is shown below. Figure 2 As shown, in this embodiment... Figure 1 Based on the embodiments, a fault handling method based on a cloud server is described in detail, the method including:

[0060] S201. In response to the user's command to select a rescue scenario, obtain user information and system information; wherein, the rescue scenario represents the type of fault to be processed, the user information is the identification information representing the user, and the system information includes the identification information of the cloud server with the fault and the identification information of the rescue scenario.

[0061] For example, this step can refer to step S101 above, and will not be repeated here.

[0062] S202. Generate token information based on user information and system information; the token information is used for security verification of user and cloud server fault handling.

[0063] For example, user information refers to data that can uniquely identify a user, including but not limited to tenant ID, account identifier, or API key. This information is used to verify the legitimacy of the operating entity and ensure that only authorized users can trigger the rescue process. For instance, in a public cloud environment, user information may correspond to a tenant's unique identifier in an IAM (Identity and Access Management) system.

[0064] System information refers to metadata related to the cloud server to be rescued, including at least the instance identifier (VM ID), the region it belongs to, and the identifier of the currently selected rescue scenario. User information and system information together constitute the technical context of the operation object, preventing accidental operations from being applied to the wrong instance.

[0065] The token is a one-time security credential dynamically generated based on user and system information. Essentially an encrypted string, it is typically generated through hashing using a preset algorithm. The token serves as the authentication basis for all subsequent atomic function module calls, ensuring that every API request is within a legitimate session context. The token's design aims to achieve binding and timeliness of operation requests, preventing replay attacks or unauthorized calls across different scenarios.

[0066] In this embodiment, the token information may also include a timestamp to limit its valid lifespan. For example, a 10-minute validity period can be set, after which it automatically expires and needs to be reapplied for. Furthermore, random numbers can be introduced to enhance uniqueness and further improve anti-counterfeiting capabilities. In this embodiment, the algorithm used to generate the token information is not specifically limited.

[0067] In this embodiment, generating token information based on user information and system information includes: obtaining the current timestamp; and generating token information based on the timestamp, user information, and system information, according to a preset token format.

[0068] Specifically, the current timestamp represents the moment the token was generated, and this timestamp can be obtained in real time. For example, a time string with time zone information can be used. The precision of the timestamp can be set according to actual security requirements; for example, millisecond-level precision is recommended in high-concurrency environments to avoid collisions. User information may include a tenant ID. In a multi-tenant cloud environment, the tenant ID can be used to distinguish the operational boundaries of different enterprise users, ensuring resource isolation. System information may include identification information of faulty cloud servers and identification information of rescue scenarios, ensuring that token information is only applicable to specific target devices and specific fault types, thereby achieving fine-grained access control.

[0069] The token information is pre-formatted; for example, a pre-defined structured data template can be used to organize timestamps, user information, and system information. The final token information can be generated using a pre-defined encryption algorithm. For instance, the timestamp, user information, and system information fields can be concatenated in a fixed order and then hashed to obtain the token information.

[0070] The benefits of this setup are that timestamps provide dynamism, preventing replay attacks; user information and system information are context-bound; the scope of token use is limited; and a secure token construction method based on the fusion of time dimension and context information is implemented. This enhances the security strength of the call chain, significantly reduces the risk of unauthorized calls, and strengthens the system's resistance to attacks.

[0071] S203. If the token information meets the preset verification conditions, the rescue process sequence is determined based on the system information.

[0072] For example, pre-set verification conditions are used to verify whether the token information is legal or valid. The pre-set verification conditions may include, but are not limited to, one or more of the following: the token information format conforms to a predetermined structure, for example, a Base64 encoded length; the timestamp has not expired, for example, it is no more than 10 minutes from the current time; the signature verification is successful, for example, the token integrity is verified using the server's private key; the user identity matches the cloud server ownership relationship, for example, to prevent unauthorized access across tenants; the rescue scenario is in a permitted state, for example, it is not currently under maintenance or in a disabled state, etc.

[0073] The verification process can be performed by a preset API gateway or an independent authentication service. Only when all verification items pass can the next step be allowed. Otherwise, an error code can be returned and an audit log can be recorded for the user to view.

[0074] A rescue process sequence refers to a predefined set of ordered execution steps for a specific fault type, with each step corresponding to an atomic functional module. The determination of this sequence depends on the rescue scenario identifier in the system information and is obtained by querying a "scenario-process mapping table." That is, after confirming that the token information meets the preset verification conditions, the corresponding rescue process sequence can be found based on the system information. For example, when the system information indicates that the rescue scenario is "kernel repair," the corresponding rescue process sequence might be: configuration snapshot → information collection → image matching → resource loading → tool scheduling → configuration rollback.

[0075] In this embodiment, the determination of the rescue process sequence can also be differentiated based on user level or cloud server type. For example, higher-level tenants can enable more complex diagnostic processes, while lightweight instances can use a simplified version to balance security and efficiency.

[0076] In this embodiment, a mechanism is implemented to generate a security token with identity binding and context association characteristics based on user information and system information, and to trigger the rescue process only after successful verification. Because the token integrates the three attributes of the operating subject, target resource, and intent scenario, it effectively prevents unauthorized access, lateral privilege escalation, and replay attacks. By binding process execution permissions to token validity, a "authenticate first, execute later" security loop is constructed, solving the security risks caused by open self-service interfaces in traditional cloud platforms. This allows tenants to initiate rescue operations independently while ensuring system security, improving service availability and user experience.

[0077] In this embodiment, the rescue process sequence is determined based on system information, including: determining the rescue process sequence corresponding to the system information based on a preset association relationship; wherein, the preset association relationship represents the association relationship between the system information and the rescue process sequence.

[0078] Specifically, the system information and the rescue process sequence are pre-defined. The system information may include the identification information of the cloud server and the identification information of the rescue scenario. That is, the relationship between the cloud server and the rescue process sequence can be pre-defined, the relationship between the rescue scenario and the rescue process sequence can be pre-defined, and the relationship between the cloud server and the rescue scenario and the rescue process sequence can be preset.

[0079] The pre-defined relationships are the core logical carrier for automatically mapping system information to rescue process sequences. These relationships can be pre-deployed in the system using static configuration or dynamically updated at runtime to adapt to new scenario expansion needs. For example, a "Scenario-Process Mapping Table" can be created in the database, where each row corresponds to a rescue scenario, and fields include: scenario ID, applicable OS (Operating System) range, required sequence of steps, corresponding API endpoints for each step, and dependent image tags. When a request containing the VM ID and scenario ID is received, the corresponding rescue process sequence can be quickly located by querying this table.

[0080] The beneficial effect of this setup is that the efficient process matching mechanism based on system information and preset correlation can automatically determine the optimal processing path according to the specific status of the cloud server and the rescue target selected by the user without manual intervention. This improves the system's response speed and maintainability, can flexibly adapt to diverse fault situations, and enhances the level of automation and operation and maintenance efficiency.

[0081] S204. Based on the rescue process sequence and the atomic functional modules corresponding to each step, the faults of the cloud server are processed to obtain the fault processing results; wherein, the atomic functional modules represent pre-encapsulated APIs used to execute the corresponding steps.

[0082] For example, this step can refer to step S103 above, and will not be repeated here.

[0083] This application provides a cloud server-based fault handling method. When a cloud server malfunctions and requires rescue, the method responds to the user's selection of a rescue scenario to determine the current fault type and the user's identity, thereby obtaining system and user information. The system information may include the identification information of the faulty cloud server and the identification information of the rescue scenario. Based on different user and system information, a rescue process sequence is determined for the user and the rescue scenario. The rescue process sequence represents the steps required for fault handling and the execution order between these steps. Different users may receive different rescue processes in different rescue scenarios. Each step in the rescue process corresponds to an atomic functional module, which represents a pre-encapsulated API for executing the corresponding step. Based on the atomic functional modules corresponding to each step in the rescue process sequence, the cloud server fault is automatically handled to obtain the fault handling result. By decomposing the rescue process into multiple atomic functional modules and automatically assembling the execution sequence based on the user-selected rescue scenario, the method achieves standardization and automation of fault handling. This enables tenant-based, low-threshold, and highly secure cloud server fault repair without administrator intervention, significantly improving operational efficiency and system availability.

[0084] Figure 3 A flowchart illustrating a cloud server-based fault handling method provided in this application embodiment is shown below. Figure 3 As shown, in this embodiment... Figure 1 and Figure 2 Based on the embodiments, a fault handling method based on a cloud server is described in detail, the method including:

[0085] S301. In response to the user's command to select a rescue scenario, obtain user information and system information; wherein, the rescue scenario represents the type of fault to be processed, the user information is the identification information representing the user, and the system information includes the identification information of the cloud server with the fault and the identification information of the rescue scenario.

[0086] For example, this step can refer to step S101 above, and will not be repeated here.

[0087] S302. Determine the rescue process sequence based on user information and system information; wherein, the rescue process sequence represents the steps required to handle the fault and the execution order between each step.

[0088] For example, this step can refer to step S102 above, and will not be repeated here.

[0089] S303. Traverse the rescue process sequence and determine the currently traversed stage.

[0090] For example, traversing the rescue process sequence refers to visiting each processing step in the rescue process one by one according to a preset execution order. This process can be implemented using a sequential iteration method. The rescue process sequence is an ordered set of multiple logically related functional steps. Their arrangement order is preset based on the dependencies and execution timing of fault handling, ensuring that the operation process meets the safety and consistency requirements of system recovery. The traversal mechanism supports interruption and recovery, and can record the executed position in abnormal situations, facilitating subsequent retries or rollbacks.

[0091] The process begins by traversing the first step in the rescue workflow sequence, identifying the currently traversed step. In each iteration, the specific functional node to be executed is determined, such as information collection, image matching, or resource loading. Each step has a unique functional semantics and a corresponding atomic functional module call interface. The step can be represented as a string label, an enumeration value, or an object instance, used for subsequent location of the corresponding atomic functional module.

[0092] In this embodiment, the traversal process can be implemented using a state machine model, with each stage as a state node, and the state transition condition being the successful execution of the previous stage. Alternatively, a parallel scheduling mechanism can be introduced to achieve concurrent execution between stages with no dependencies, thereby improving efficiency while maintaining the controllability and observability of the overall process.

[0093] S304. Based on the atomic function module corresponding to the currently traversed stage, determine the execution result of the currently traversed stage on the cloud server.

[0094] For example, each stage corresponds to an atomic functional module. An atomic functional module is a pre-packaged, single-responsibility standard RESTful API interface. Each module performs only a specific function, such as obtaining operating system information, mounting a rescue image, or starting a tool environment. These modules achieve high cohesion and low coupling through decoupling design, facilitating independent testing, deployment, and access control. Atomic functional modules can establish static or dynamic binding relationships with stage names through a configuration mapping table. For the currently traversed stage, the corresponding atomic functional module can be determined.

[0095] For the currently traversed stage, the corresponding atomic function module is used to execute that stage, obtaining the execution result for that stage on the cloud server. This means calling the corresponding atomic function module, receiving its returned data, and using this as the execution result for that stage. The execution result can take various forms, including but not limited to Boolean values ​​(success / failure), structured data (such as the collected operating system version number), error codes, or log information. This execution result not only reflects the success or failure of the operation but can also contain contextual information for use in subsequent stages. For example, the execution result of the information collection stage can serve as input data for the mirror matching stage.

[0096] In practical implementation, calls to atomic function modules are typically initiated via HTTP (Hypertext Transfer Protocol) requests, which can carry token information. The token information is validated; if validation passes, execution proceeds. For example, a timestamp can be retrieved from the token information to determine if the token has timed out. If so, validation fails; otherwise, it passes. If validation fails, a retry or an error message can be returned for the user to review. In other words, timeout mechanisms and retry strategies can be set to prevent process interruptions due to network fluctuations. All calls are logged to the audit log, supporting post-event traceability and analysis.

[0097] In this embodiment, the atomic functional modules can be deployed in a microservice architecture, with routing and authentication managed uniformly by the API gateway, further enhancing the scalability and security of the system.

[0098] In this embodiment, the currently traversed stage is the information acquisition stage. Based on the atomic function module corresponding to the currently traversed stage, the execution result of the currently traversed stage on the cloud server is determined, including: obtaining the operating system information, kernel information, and hardware information of the cloud server through the atomic function module corresponding to the information acquisition stage; and determining the operating system information, kernel information, and hardware information as the execution result of the information acquisition stage on the cloud server.

[0099] Specifically, the information collection phase is the first functional step executed in the rescue process, aiming to obtain critical system status data of the faulty cloud server non-intrusively. This phase is achieved by calling a dedicated atomic function module, which is encapsulated as a standardized RESTful API interface with read-only permissions and minimal operational boundaries, ensuring that information extraction is completed without modifying the cloud server's operating state.

[0100] Operating system information refers to data that characterizes the type, release version, and architectural features of the operating system installed on a cloud server. This includes, but is not limited to, the operating system name, major version number, minor version number, build number, and package management system type. For example, in a Linux-based virtual machine, the contents of the ` / etc / os-release` file can be securely read through the `virsh console` or guest agent channel provided by libvirt, avoiding direct exposure of SSH (Secure Shell) access permissions.

[0101] Kernel information refers to the specific version of the operating system kernel and its compilation characteristics, primarily used for subsequent driver matching and tool compatibility assessment. Typical kernel information includes the kernel major version, minor version, revision version, compilation timestamp, list of supported system calls, and whether specific security modules are enabled. This information can be obtained by executing the commands `uname -r` and `uname -a`, and can be verified in conjunction with the ` / proc / version` file. In some implementation scenarios, more complete kernel attributes can also be obtained by parsing the metadata of the ` / boot / vmlinuz` file.

[0102] Hardware information refers to the abstract description of the physical devices simulated or passed directly to the cloud server in the virtualization environment, covering CPU architecture, number of virtual CPUs, memory capacity, PCI device list, disk controller type, etc. This information can be obtained by executing commands such as `lspci`, `dmidecode`, `lscpu`, and `lsblk`. In default virtualization platforms, some hardware information can also be extracted from the libvirt XML configuration.

[0103] Operating system information, kernel information, and hardware information can serve as core input parameters for subsequent layered image matching. After completing information collection, the atomic function module can structure the collected information into a unified data format, mark the collection timestamp and source trust level, and finally determine the overall information as the execution result of the information collection stage for subsequent stages to use.

[0104] Operating system information determines the range of base images to choose from, kernel information affects driver loading and tool compatibility, and hardware information further refines peripheral adaptation requirements. These three elements work together to form a multi-dimensional set of constraints, used to accurately retrieve the most suitable combination of rescue resources from the pre-defined image repository.

[0105] The advantage of this setup is that it enables the comprehensive and accurate acquisition of core system parameters without interfering with the original state of the faulty cloud server. Because it employs a non-intrusive, read-only acquisition mechanism, it avoids the risk of secondary failures caused by configuration modifications. Furthermore, the complete and clearly structured information provides a reliable basis for accurate image matching, thus solving the problem of adaptation failures due to missing or inaccurate information in traditional rescue methods, and improving the success rate and security of cloud server self-service rescue.

[0106] In this embodiment, the currently traversed stage is the image matching stage, which follows the information collection stage. Based on the atomic function module corresponding to the currently traversed stage, the execution result of the currently traversed stage on the cloud server is determined, including: obtaining the execution result of the information collection stage through the atomic function module corresponding to the image matching stage; wherein the execution result of the information collection stage includes at least one of operating system information, kernel information, and hardware information; searching for a first image from a preset image repository based on the operating system information and kernel information; wherein the first image represents a base image adapted to the operating system information and kernel information, and the preset image repository stores multiple image files; searching for a second image from the preset image repository based on the rescue scenario; wherein the second image represents a lightweight toolkit adapted to the rescue scenario; searching for a third image from the preset image repository based on the kernel information and hardware information; wherein the third image represents a driver image adapted to the kernel information and hardware information; and determining the execution result of the image matching stage on the cloud server based on the first image, the second image, and the third image.

[0107] Specifically, the image matching stage is a crucial step in the fault handling process to achieve accurate resource adaptation. Based on the operating system, kernel, and hardware information obtained in the preceding "information collection stage," and combined with the user-selected rescue scenario, this stage performs multi-dimensional matching within a pre-defined layered image repository to determine a complete set of rescue images suitable for the current cloud server environment. The atomic function module is a standard RESTful API interface that encapsulates the image retrieval logic. Its calls are protected by a security token mechanism and are only allowed to execute under authorized scenarios.

[0108] Obtaining the execution results of the information collection phase refers to reading the data structure returned by the completed information collection API, which contains information such as operating system type, kernel version number, CPU architecture, motherboard model, and network card model. This information forms the basic input parameters for subsequent image matching.

[0109] A pre-configured image repository stores various image files. Finding the first image based on operating system and kernel information involves retrieving a base-layer image from the image repository that is compatible with the cloud server's operating system and kernel. This base-layer image is a minimal boot environment, typically containing a generic kernel image, an initial memory disk, and a bootloader. Its design goal is to ensure normal booting across a specific OS major version and its sub-versions. For example, for a cloud server running CentOS 7 with kernel version 3.10.x, the system will prioritize matching the base-layer image tagged `os=CentOS7,kernel=3.10.x`. This involves extracting a minimal kernel compatible with all OS versions (such as the CentOS 7 3.10 kernel), the GRUB (Grand Unified Bootloader) bootloader, and associated metadata tags. `os=CentOS7,kernel=3.10.x` ensures compatibility with all sub-versions of this OS when mounted via libvirt. This base-layer image does not contain any dedicated repair tools; it only provides runtime support for subsequent tool loading and is typically less than or equal to 1GB. .

[0110] Finding the second image based on the rescue scenario refers to locating the corresponding tool-layer image from the image repository based on the user-selected fault type (such as password reset, disk repair, kernel debugging, etc.). This tool-layer image is a lightweight functional package; each image encapsulates only the toolset required for a single rescue function. For example, the "disk repair" scenario corresponds to a compressed file system image containing tools such as `e2fsck` and `xfs_repair`, while the "network diagnostics" scenario includes network analysis components such as `tcpdump` and `iproute2`. Tool-layer images have clear scenario tags (such as `scene=disk-repair,os=CentOS7`), supporting reuse across different base images and avoiding duplicate storage of the full image.

[0111] Finding a third-party image based on kernel and hardware information refers to matching a driver layer image compatible with the current kernel version and hardware model to ensure the rescue environment can correctly identify and drive physical or virtualized hardware devices. This image contains the specific hardware's kernel modules, firmware, and udev (userspace / dev, the user-space / dev directory manager) rules, such as a driver package for an LSI MegaRAID controller or an Intel I219 network card. The matching criteria depend on both the kernel version and the hardware PCI ID. A typical tag format is `hardware=LSI MR3,kernel=3.10.x`, indicating that the driver is applicable to all sub-versions of kernel version 3.10 and is compatible with LSI MR3 series RAID (Redundant Array of Independent Disks Card).

[0112] Determining the execution result based on the first, second, and third images means integrating the metadata (such as image ID, storage path, and checksum) of these three types of images into a structured matching result object, which serves as the input for the next stage, the "resource loading phase." This result not only includes reference information for each image layer but may also include compatibility tips (such as "use compatibility mode to match kernel minor version differences"), loading order suggestions, and other auxiliary information.

[0113] The images are organized hierarchically according to their functions, forming a three-tiered collaborative structure of "foundation-function-driver": the foundation layer image provides boot capabilities, the tool layer image provides specific repair functions, and the driver layer image ensures hardware accessibility. The three are decoupled and managed through a unified tag management system, supporting independent updates and combined reuse.

[0114] The benefits of this setup are that it splits the traditional monolithic image into a base layer, tool layer, and driver layer that can be matched independently. This solves the problem of insufficient image coverage caused by the diversity of operating systems, the heterogeneity of hardware, and the complexity of fault types. It enables the dynamic construction of a rescue environment with a high adaptability rate, significantly improves the image reuse rate and adaptation success rate, reduces storage overhead, and provides tenants with a more stable and reliable self-service rescue service.

[0115] In this embodiment, searching for a first image from a preset image repository based on operating system information and kernel information includes: if there is no first image corresponding to the operating system information and kernel information in the preset image repository, then determining the minor version information based on the kernel information; wherein, the minor version information represents the kernel minor version of the kernel information; and searching for the first image from the preset image repository based on the operating system information and the minor version information.

[0116] Specifically, searching for the first image in the pre-defined image repository refers to matching a suitable base layer image from a pre-built layered image repository based on the collected operating system type (e.g., CentOS 7, Ubuntu 20.04) and kernel version number (e.g., 5.4.0-73-generic). This base layer image contains the kernel image required for minimal booting, the initial memory disk, and the bootloader (e.g., GRUB), and its purpose is to provide a bootable rescue environment for a faulty cloud server. Each base layer image in the image repository is tagged with multidimensional tags, such as `os=CentOS7,kernel=3.10.x,arch=x86_64`, to support fast metadata retrieval.

[0117] When searching for the first image, the system checks if an image file corresponding to the operating system and kernel information exists in the preset image repository. If it does, the found image file is designated as the first image, i.e., the base layer image; in other words, a fully matching image file resource has been detected. If it does not exist, it means that an available image could not be found through exact matching logic (i.e., the operating system name, major version number, and kernel major and minor versions are all consistent), triggering the compatibility matching mechanism. For example, if the cloud server is running a CentOS 7 system with kernel version 3.10.0-1160.el7.x86_64, and the image repository only contains a general base image applicable to 3.10.0-957.el7.x86_64, although a full field matching is not satisfied, both belong to the 3.10.x series and have binary compatibility. Therefore, effective reuse can be achieved by relaxing the matching granularity.

[0118] When performing coarse-grained matching, minor version information can be determined based on kernel information. For example, the minor version number field can be extracted from the complete kernel version string. Taking the Linux kernel as an example, its version format is usually `major version.minor version.revision number-build number` (e.g., 3.10.0-1160), where "minor version" reflects the feature update or patch level. The system extracts the minor version through regular expression parsing or by calling version processing functions (such as Python's `packaging.version.parse`) and uses it as one of the matching dimensions. For example, 3.10.0-1160 and 3.10.0-957 can be grouped into the `kernel=3.10.x` category, thereby expanding the candidate image set.

[0119] After obtaining the minor version, the system searches for the first matching image from a pre-defined image repository based on the operating system and minor version information. This employs a downgraded matching strategy. The process is still based on a tag matching algorithm, prioritizing the return of the base layer image with the highest compatibility. Furthermore, the system can configure matching priority rules, such as: first, exact match; second, matching major and minor versions; third, matching only major versions. Simultaneously, the front-end interface can display compatibility status information to the user based on the matching results, such as "Matched a general base image suitable for the 3.10.x series; slight driver differences may exist."

[0120] This embodiment employs a progressive fault-tolerant matching mechanism. It first attempts a strict match to ensure optimal adaptation; if this fails, it automatically switches to a more lenient mode, leveraging the backward compatibility of kernel versions to expand the range of available resources. This design avoids interruptions to the recovery process due to minor version discrepancies, making it particularly suitable for long-running production systems that haven't been updated or for customized distributions.

[0121] The advantage of this setup is that it enables the successful location of a compatible image based on operating system information and kernel minor version information, even in the absence of a fully matching base image. The introduction of a fuzzy matching mechanism at the minor version level solves the problem of low image coverage caused by version fragmentation in traditional solutions, improves the reusability of base layer images and the success rate of the rescue process, and enhances the robustness and adaptability of the system.

[0122] In this embodiment, searching for a third image from a preset image repository based on kernel information and hardware information includes: if no third image corresponding to the kernel information and hardware information exists in the preset image repository, determining minor version information based on the kernel information and determining candidate information based on the hardware information; wherein, minor version information represents the kernel minor version of the kernel information, and candidate information represents information belonging to the same series as the hardware information; and searching for a third image from the preset image repository based on the kernel information, hardware information, minor version information, and candidate information.

[0123] Specifically, kernel information refers to the specific version identifier of the operating system kernel currently running on the cloud server, typically including the major version number, minor version number, and revision number. This information is obtained by remotely executing the `uname -r` command through the underlying virtualization management interface (such as libvirt). Kernel information is used to determine the compatibility between driver modules and the operating system kernel, and is one of the key bases for matching and adapting driver images.

[0124] Hardware information refers to the model and category of the physical or virtualized hardware devices configured on the cloud server, such as controller model, network card model, and storage controller type. This information can be obtained through PCI device enumeration commands or preset reading tools. Hardware information is used to locate the dedicated drivers required for specific hardware.

[0125] The default image repository refers to a shared storage system that centrally stores various tiered rescue image files, supporting metadata tag indexing and fast retrieval. This repository can be built on object storage and attach multi-dimensional tags to each image file, such as `os=CentOS7`, `kernel=3.10.x`, `hardware=LSI MR3`, etc., to facilitate efficient matching. The image repository provides query and download services via a RESTful API.

[0126] The third-party image refers to a driver-layer image specifically designed to adapt to a particular kernel version and hardware model. It encapsulates the kernel modules, firmware, and initialization scripts required for the target hardware to operate normally under the corresponding kernel environment. This image does not contain a complete operating system; it is only dynamically mounted to the rescue environment as a runtime dependency.

[0127] Minor version information refers to the minor version field extracted from the complete kernel version string, used to represent different release branches under the same major version. For example, in kernel version "3.10.0-1160.el7", "1160" is the minor version information. When an exact match fails, the system can relax the minor version requirement and try to find a driver image with a similar version, thereby improving adaptation flexibility.

[0128] Alternative information refers to alternative or universally compatible models derived from hardware information. For example, when there is no matching driver for the specific model "LSI MR3", the system can generalize it to "MR series" as a search criterion; similarly, Intel I219-V can be categorized as "I219 series". This mechanism allows alternative driver solutions to be enabled when the hardware models are not exactly the same but the architecture is compatible.

[0129] Based on kernel information, hardware information, minor version information, and alternative information, a third-party image is searched from a pre-defined image repository. This can begin with a precise match between the original kernel and hardware information. If no matching third-party image is found, a coarse-grained matching phase is initiated for compatibility expansion. For example, the minor version information of the kernel and alternative hardware information can be combined to form broader query conditions, and the search can be restarted. Alternatively, kernel information and alternative information can be combined, and minor version information and hardware information can be combined, to determine if an image file exists in the image repository that matches either of these combinations. If it does, the matched image file is designated as the third-party image; otherwise, the minor version information and alternative information are combined to search for a suitable image file in the pre-defined image repository, which is then used as the third-party image. This achieves a smooth transition from strict matching to flexible adaptation.

[0130] In this embodiment, if no image file of the first, second, and third images can be found, an error message can be returned on the interface to prompt the user to check.

[0131] The advantage of this setup is that it enables intelligent downgrade matching in scenarios where a fully matching driver image is unavailable, improving the coverage and applicability of driver layer images. Even when some hardware or kernel versions lack precise support, usable drivers can still be found through approximate matching, ensuring the rescue process continues and effectively reducing the risk of repair interruptions due to driver incompatibility.

[0132] In this embodiment, the currently traversed stage is the resource loading stage, which follows the image matching stage. Based on the atomic function module corresponding to the currently traversed stage, the execution result of the currently traversed stage on the cloud server is determined, including: mounting the execution result of the image matching stage to the cloud server through the atomic function module corresponding to the resource loading stage, and configuring the image startup order of the cloud server; wherein, the image startup order represents the startup order of the image files mounted on the cloud server when the cloud server restarts; the image startup order is determined as the execution result of the resource loading stage on the cloud server.

[0133] Specifically, the resource loading stage is a crucial step in the rescue process, enabling the layered image system to move from logical matching to physical deployment. The core task of this stage is to actually mount the first, second, and third images determined in the preceding image matching stage onto the cloud server. This is achieved by modifying the virtual machine's boot configuration to ensure that the rescue environment, rather than the original operating system, is loaded first upon reboot. This process does not involve any modification to the user's data disk, thus guaranteeing the integrity and recoverability of the original system.

[0134] When the mounting operation is performed by the atomic function module corresponding to the resource loading stage, the management interface provided by the virtualization platform (such as libvirt) is first called. Taking advantage of its ability to dynamically modify the configuration of virtual machine devices, the first image is mounted to the cloud server in the form of a read-only optical drive as the basic operating environment of the rescue system. The second image, namely the lightweight toolkit adapted to specific rescue scenarios, and the third image, namely the driver components adapted to the kernel and hardware, are mounted to the preset directories (such as ` / rescue / tools` and ` / rescue / drivers`) in the form of virtual disks or shared file systems, so that the required tools and drivers can be dynamically loaded after the rescue system starts.

[0135] Furthermore, configuring the cloud server's image boot order refers to adjusting the priority of the virtual machine's boot items so that the first mounted image (i.e., the base rescue image) is set as the first boot device. This configuration can be achieved by modifying the `<image>` section in the virtual machine's libvirt XML configuration file. <os> <boot>`Field implementation, for example, setting` <boot dev="cdrom" / > It is then placed at the top of the boot list. This operation ensures that even if the original operating system fails to boot due to a malfunction, the cloud server can still enter rescue mode after restarting, thus providing a runtime environment for subsequent repair operations.

[0136] In scenarios where multiple images coexist, the startup order can be configured strategically. For example, the images can be loaded in order of dependency relationship: "base layer image → tool layer image → driver layer image", or the delayed loading timing can be dynamically adjusted according to the complexity of the rescue scenario to avoid resource contention.

[0137] The benefits of this setup are that it enables a secure, non-intrusive loading mechanism for layered images, effectively isolating the risk boundaries between rescue operations and business systems; and by precisely controlling the image startup sequence, it ensures that the rescue environment can be reliably activated, thereby improving the effectiveness of fault repair.

[0138] In this embodiment, the currently traversed stage is the tool scheduling stage, which is located after the resource loading stage. Based on the atomic function module corresponding to the currently traversed stage, the execution result of the currently traversed stage on the cloud server is determined, including: restarting the cloud server through the atomic function module corresponding to the tool scheduling stage; if the restart is successful, then based on the image startup order, fault repair is performed on the cloud server to obtain the execution result of the tool scheduling stage on the cloud server; wherein, the execution result of the tool scheduling stage on the cloud server represents whether the fault repair was successful.

[0139] Specifically, the tool scheduling phase refers to triggering the cloud server to enter actual rescue mode after the image file is mounted. The core task of this phase is to activate the prepared rescue context and drive the system to execute pre-defined repair logic in the new environment. Its corresponding atomic functional modules are encapsulated in the form of RESTful APIs, possessing stateless and independently callable characteristics, which conforms to the microservice architecture design principles.

[0140] Rebooting a cloud server involves sending a soft reboot command to the virtual machine (i.e., the cloud server) through the virtualization management layer (such as libvirt), simulating the power outage and reboot process of a physical server, thereby loading the operating system according to the updated boot order. During the reboot process, the system boots from the mounted rescue base layer image first, based on the image boot order set in the resource loading stage, and then loads the tool layer and driver layer to build a complete rescue runtime environment.

[0141] After a successful reboot, the system automatically boots into a lightweight rescue operating system composed of layered images. In this stage, pre-installed dedicated repair programs (such as the file system check tool fsck, the disk repair tool disk-repair, and the password reset script reset-password) are automatically invoked or can be manually executed by the user to intervene in specific rescue scenarios (such as disk damage or forgotten passwords). This stage relies on kernel compatibility verification mechanisms and correct driver loading to ensure that the tools can access underlying storage and hardware resources normally. In this embodiment, no specific limitations are made on the invoked repair tools and repair logic.

[0142] This process records the final status information of the restart and repair attempt, obtaining the execution result of the tool scheduling phase on the cloud server. It is typically returned as a boolean value or an enumeration type, such as "true / false" or "success / failure". This execution result not only includes information on whether the restart was successful, but more importantly, it reflects the actual effectiveness of the fault repair action, i.e., whether the original problem was resolved. For example, after performing file system repair, if errors are detected to have been corrected and there are no unrecoverable anomalies, the repair is considered successful; otherwise, it is marked as a failure for subsequent process decisions, such as triggering a rollback mechanism.

[0143] The reboot operation triggers the environment switch, the image startup order determines the construction method of the rescue system, and fault repair is the purposeful behavior of the entire process. These three elements proceed sequentially, forming a closed-loop control chain from "preparation" to "execution." Rebooting ensures that configuration changes take effect, the image startup order guarantees the correct establishment of the execution context, and the repair logic achieves specific functional goals.

[0144] The advantage of this setup is that it enables automated verification and feedback at critical stages of the cloud server rescue process. By restarting and activating the pre-configured layered rescue mirror chain, and executing targeted repair tools in the new environment, it solves the problems of low efficiency and error-proneness of traditional manual intervention, thereby improving the reliability of fault handling and closed-loop management capabilities.

[0145] In this embodiment, the currently traversed stage is the configuration snapshot stage, which is located before the tool scheduling stage. Based on the atomic function module corresponding to the currently traversed stage, the execution result of the currently traversed stage on the cloud server is determined, including: generating and storing snapshot information of the cloud server through the atomic function module corresponding to the configuration snapshot stage; wherein, the snapshot information represents the running state of the cloud server before fault repair; and the snapshot information is determined as the execution result of the configuration snapshot stage on the cloud server.

[0146] Specifically, the configuration snapshot step refers to the function of backing up the critical configuration state of the cloud server before any operations involving system configuration changes (such as resource loading, image mounting, or modification of the startup order) during the initiation of the rescue process. This step is implemented by calling a dedicated "VM Configuration Snapshot API," and its purpose is to provide reversible rollback capability for any subsequent abnormal operations, ensuring that even if misconfigurations or incompatibilities occur during fault handling, the system can be restored to its original state, i.e., the state before the repair.

[0147] Atomized functional modules are pre-packaged standard RESTful API interfaces with a single responsibility characteristic, used only to perform a specific function without involving other operations. For the configuration snapshot stage, they are dedicated to reading and persistently storing the current virtual machine management configuration data of the cloud server, such as XML format configuration files based on libvirt, covering... <disk> `、` <boot> `、` <interface>The module contains the status values ​​of key fields such as `. This module does not have any write permissions or execution capabilities; it only allows the extraction of configuration content in read-only mode, which is then compressed, encrypted, and stored in a highly available metadata storage system to prevent tampering or loss.

[0148] Snapshot information refers to a structured data set obtained from a cloud server that reflects its complete operating environment before entering rescue mode. It mainly includes, but is not limited to, the connection status and mounting order of virtual disk devices, boot device priority settings, network interface configuration parameters, CPU and memory allocation strategies, and the identifier of the currently active boot image.

[0149] The execution result refers to the output artifact after the configuration snapshot step is completed, namely, the snapshot information record that has been successfully generated and persistently stored. This result is passed to subsequent steps as an intermediate state in the process sequence for the configuration rollback mechanism to invoke. If subsequent operations fail (such as a failed restart or ineffective repair), the rollback process can be automatically triggered by retrieving this snapshot information, accurately restoring the affected configuration fields and avoiding business interruption or data inaccessibility due to temporary modifications.

[0150] The beneficial effect of this setup is that it enables reliable backup of the original configuration state during the cloud server rescue process, providing a safety net for subsequent high-risk operations. It solves the technical problem of the lack of a rollback mechanism in traditional self-service rescue, which leads to further deterioration of the system. As a result, it achieves the technical effects of improving operational security, reducing operational risks, and ensuring business continuity.

[0151] In this embodiment, the currently traversed stage is the configuration rollback stage, which is located after the tool scheduling stage. Based on the atomic function module corresponding to the currently traversed stage, the execution result of the currently traversed stage on the cloud server is determined, including: if the restart fails, the cloud server is rolled back based on the snapshot information through the atomic function module corresponding to the configuration rollback stage to obtain the execution result of the configuration rollback stage on the cloud server; wherein, the execution result of the configuration rollback stage on the cloud server indicates whether the rollback was successful.

[0152] Specifically, a restart failure refers to a situation where, after the cloud server restart operation is triggered during the tool scheduling phase, the system continuously monitors the virtual machine status. If a normal startup signal is not detected within a preset timeout period, or no clear startup exception log is received, the restart is deemed a failure. For example, a maximum waiting window of 120 seconds can be set. If no valid response is received within this period, the configuration rollback phase begins. Furthermore, a multi-level retry strategy can be introduced, allowing attempts at soft restarts and hard restarts after the first failure. Rollback is only initiated if all attempts fail, thus avoiding misjudgments due to temporary resource contention.

[0153] The atomic function module corresponding to the configuration rollback process refers to the pre-encapsulated "VM Configuration Rollback API," which relies on the virtualization management library libvirt. It rewrites the saved snapshot information to the virtual machine by calling the `virDomainDefineXML()` interface. This module has strictly limited permissions, only able to modify previously recorded fields, such as...<boot order> `、`<disk source> `、` <filesystem>Mounting points and other device configurations must not be added or deleted to ensure controllable operational boundaries and prevent unauthorized changes from causing secondary failures.

[0154] Snapshot information is typically stored in a highly available distributed storage system in a compressed, encrypted format, and associated with a unique identifier and timestamp for easy traceability and version management. During rollback, the most recent valid snapshot information is retrieved based on the current VM ID, decrypted, and its integrity verified before being used for recovery operations.

[0155] When rolling back a cloud server, the virtual machine is paused, the original XML from the snapshot information is used to replace the currently modified configuration, then the layered images dynamically mounted during the rescue process—namely, the base layer, tool layer, and driver layer images—are unmounted, and finally, the virtual machine is restored to a runnable state. The entire process is automated and requires no manual intervention. In this embodiment, the rollback process is not specifically limited.

[0156] The rollback configuration for the cloud server refers to the status feedback data generated after the rollback operation is completed, which guarantees whether the rollback was successful. This result can be reported to the front-end console via an asynchronous message queue and used as a basis for subsequent process decisions. For example, if the rollback is successful, the user will be prompted that "the system has been restored to the state before the failure. Please try other repair methods again"; if it fails, detailed logs will be recorded for administrators to investigate, and possible reasons may include storage unreachability, insufficient permissions, or the virtual machine being locked.

[0157] Restart failure serves as a trigger condition, activating the call to the configuration rollback module. The functionality of this module relies on the previously generated snapshot information as its data foundation. The final execution result is both the output of this stage and provides a fault-tolerant closed loop for the overall rescue process. That is, the traversal ends after the rollback is completed.

[0158] The benefit of this setup is that when a rescue operation causes the cloud server to fail to restart normally, it can automatically trigger a reverse recovery mechanism based on historical configuration snapshots to restore the virtual machine state to the state before the rescue, ensuring the minimum availability of the cloud server and improving the security boundary and user experience of the fault handling process.

[0159] In this embodiment, the currently traversed stage is the configuration rollback stage, which is located after the tool scheduling stage. Based on the atomic function module corresponding to the currently traversed stage, the execution result of the currently traversed stage on the cloud server is determined, including: if the execution result of the tool scheduling stage on the cloud server is a repair failure, then the cloud server is rolled back based on snapshot information using the atomic function module corresponding to the configuration rollback stage to obtain the execution result of the configuration rollback stage on the cloud server; wherein, the execution result of the configuration rollback stage on the cloud server indicates whether the rollback was successful.

[0160] Specifically, during the tool scheduling phase, if the restart is successful, the cloud server repair will continue, and the execution result will be obtained. If the rescue operating system fails to load normally, the preset repair script does not complete execution, file system errors are not cleared, or the user clicks to exit rescue mode, the execution result will be repair failure.

[0161] If the repair fails, the process proceeds to the configuration rollback stage. Based on pre-stored snapshot information, the cloud server is rolled back, resulting in a success or failure message. If the repair is successful, no rollback is required, and the rescue process sequence ends.

[0162] The "configure rollback module" is only activated after confirming "repair failure"; the effectiveness of the rollback operation highly depends on the completeness and accuracy of the previously generated "snapshot information." These three elements work together to form a closed-loop security recovery mechanism.

[0163] The benefit of this setting is that when the cloud server fails to recover after entering rescue mode and performing repair operations, it can automatically restore the system state to the state before the fault handling based on the previously saved configuration snapshot, thereby improving the robustness of the service and the tenant experience.

[0164] S305. If the execution result determines that the rescue process sequence traversal has ended, then the execution result shall be determined as the fault handling result.

[0165] For example, after obtaining the execution result of each step, the decision to end the iteration can be determined based on that result. The iteration might end at the last step, or it might end at an intermediate step. For each step, a pre-defined condition for ending the iteration can be set. If the execution result of that step meets the corresponding condition, the iteration ends; otherwise, it continues downwards. For instance, in a rescue process sequence, the last node is configuration rollback, and the second-to-last step is tool scheduling. If the tool scheduling step succeeds, the iteration ends; if the tool scheduling step fails, it continues to the last step. When the configuration rollback is completed, the iteration ends. After the configuration rollback step is completed, regardless of whether the result is successful or not, it is considered the final state of this fault handling. This result can be displayed through a front-end interface, pushed via message notification, or written to the maintenance work order system for users or administrators to view.

[0166] This embodiment achieves structured execution and closed-loop management of the rescue process. By employing a sequential traversal mechanism, it ensures that each functional step is executed according to predetermined logic, avoiding process jumps or omissions. Each step calls independently encapsulated atomic functional modules, resulting in clear operational boundaries and controllable permissions. Finally, the execution result after traversal is used as the overall processing conclusion, ensuring consistency and interpretability of the results. Therefore, this method effectively solves the problems of chaotic processes, lack of monitoring, and unreliable results in traditional cloud server fault handling, improving automation and operational efficiency.

[0167] Figure 4 A flowchart for a disk repair scenario. Figure 4 In this process, when a cloud server malfunctions, the user selects the malfunctioning cloud server and the rescue scenario, obtaining user and system information. Based on this information, a one-time token is generated and verified. If verification fails, the rescue process ends; if successful, a rescue process sequence corresponding to the rescue scenario is generated. Following the order of each step in the rescue process sequence, information about the cloud server is first collected. Layered image matching is then performed based on the collected information, including base layer, tool layer, and driver layer images. If any images do not match, the rescue process ends; if all matches are successful, a snapshot is generated and stored. Layered resource mounting and tool scheduling are performed based on the matched images to repair the cloud server. During repair, the cloud server is first restarted. If restart fails, a rollback operation is performed based on the pre-generated snapshot information; if restart succeeds, disk repair is performed. If the user clicks "Exit Rescue Mode" during the repair process, the repair fails, and a rollback operation is performed based on the pre-generated snapshot information. A log of this repair is generated and recorded, and the rescue result is pushed to the user.

[0168] This application provides a cloud server-based fault handling method. When a cloud server malfunctions and requires rescue, the method responds to the user's selection of a rescue scenario to determine the current fault type and the user's identity, thereby obtaining system and user information. The system information may include the identification information of the faulty cloud server and the identification information of the rescue scenario. Based on different user and system information, a rescue process sequence is determined for the user and the rescue scenario. The rescue process sequence represents the steps required for fault handling and the execution order between these steps. Different users may receive different rescue processes in different rescue scenarios. Each step in the rescue process corresponds to an atomic functional module, which represents a pre-encapsulated API for executing the corresponding step. Based on the atomic functional modules corresponding to each step in the rescue process sequence, the cloud server fault is automatically handled to obtain the fault handling result. By decomposing the rescue process into multiple atomic functional modules and automatically assembling the execution sequence based on the user-selected rescue scenario, the method achieves standardization and automation of fault handling. This enables tenant-based, low-threshold, and highly secure cloud server fault repair without administrator intervention, significantly improving operational efficiency and system availability.

[0169] Figure 5 This application provides a schematic diagram of the structure of a cloud server-based fault handling device, as shown in the embodiments. Figure 5 As shown, the fault handling device 50 based on a cloud server provided in this embodiment includes:

[0170] The information acquisition unit 501 is used to acquire user information and system information in response to the user's selection instruction for the rescue scenario; wherein, the rescue scenario represents the type of fault to be handled, the user information is the identification information representing the user, and the system information includes the identification information of the cloud server with the fault and the identification information of the rescue scenario.

[0171] The sequence determination unit 502 is used to determine the rescue process sequence based on user information and system information; wherein, the rescue process sequence represents the steps required to be performed when handling the fault and the execution order between each step;

[0172] The fault handling unit 503 is used to handle the faults of the cloud server according to the rescue process sequence and based on the atomic functional modules corresponding to each link, and obtain the fault handling result; wherein, the atomic functional module represents the pre-encapsulated API used to execute the corresponding link.

[0173] In one possible implementation, the sequence determination unit 502 includes:

[0174] The token generation module is used to generate token information based on user information and system information; the token information is used for security verification of users and cloud servers for fault handling.

[0175] The sequence determination module is used to determine the rescue process sequence based on system information if the token information meets the preset verification conditions.

[0176] In one possible implementation, the token generation module is specifically used for:

[0177] Get the current timestamp;

[0178] Based on the timestamp, user information, and system information, a token is generated according to a preset token format.

[0179] In one possible implementation, the sequence determination module is specifically used for:

[0180] Based on the preset association, the rescue process sequence corresponding to the system information is determined; whereby the preset association represents the relationship between the system information and the rescue process sequence.

[0181] In one possible implementation, the fault handling unit 503 includes:

[0182] The sequence traversal module is used to traverse the rescue process sequence and determine the currently traversed stage;

[0183] The result determination module is used to determine the execution result of the currently traversed stage on the cloud server based on the atomic function module corresponding to the currently traversed stage.

[0184] The fault handling module is used to determine the execution result as the fault handling result if the execution result indicates that the rescue process sequence traversal has ended.

[0185] In one possible implementation, the currently traversed stage is the information collection stage; the result determination module is specifically used for:

[0186] The atomized functional modules corresponding to the information collection stage are used to obtain the operating system information, kernel information, and hardware information of the cloud server.

[0187] Operating system information, kernel information, and hardware information are identified as the execution results of the information collection process on the cloud server.

[0188] In one possible implementation, the currently traversed stage is the mirror matching stage, which follows the information collection stage; the result determination module is specifically used for:

[0189] The execution results of the information collection phase are obtained through the atomic function modules corresponding to the image matching phase; the execution results of the information collection phase include at least one of the following: operating system information, kernel information, and hardware information.

[0190] Based on the operating system information and kernel information, the first image is searched from the preset image repository; where the first image represents the base image that adapts to the operating system information and kernel information, and the preset image repository stores multiple image files;

[0191] Based on the rescue scenario, a second image is retrieved from a pre-set image repository; the second image represents a lightweight toolkit adapted to the rescue scenario.

[0192] Based on kernel and hardware information, a third image is searched from a pre-defined image repository; the third image represents a driver image that adapts to the kernel and hardware information.

[0193] Based on the first, second, and third images, determine the execution result of the image matching process on the cloud server.

[0194] In one possible implementation, the result determination module is specifically used for:

[0195] If the preset image repository does not contain a first image corresponding to the operating system information and kernel information, then the minor version information is determined based on the kernel information; whereby the minor version information represents the kernel minor version of the kernel information.

[0196] Based on the operating system information and minor version information, the first image is searched from the preset image repository.

[0197] In one possible implementation, the result determination module is specifically used for:

[0198] If there is no third image corresponding to the kernel information and hardware information in the preset image repository, then the minor version information is determined based on the kernel information, and the candidate information is determined based on the hardware information; where the minor version information represents the kernel minor version of the kernel information, and the candidate information represents information that belongs to the same series as the hardware information.

[0199] Based on kernel information, hardware information, minor version information, and alternative information, a third image is searched from a preset image repository.

[0200] In one possible implementation, the currently traversed stage is the resource loading stage, which follows the image matching stage; the result determination module is specifically used for:

[0201] The atomic function module corresponding to the resource loading stage mounts the execution result of the image matching stage to the cloud server and configures the image startup order of the cloud server; the image startup order represents the startup order of the image files mounted in the cloud server when the cloud server restarts.

[0202] The image startup order is determined by the execution result of the resource loading process on the cloud server.

[0203] In one possible implementation, the currently traversed stage is the tool scheduling stage, which follows the resource loading stage; the result determination module is specifically used for:

[0204] The cloud server is restarted using the atomic function modules corresponding to the tool scheduling process;

[0205] If the restart is successful, the cloud server will be repaired based on the image startup order, and the execution result of the tool scheduling process on the cloud server will be obtained; the execution result of the tool scheduling process on the cloud server indicates whether the fault repair was successful.

[0206] In one possible implementation, the currently traversed stage is the configuration snapshot stage, which precedes the tool scheduling stage; the result determination module is specifically used for:

[0207] By configuring the atomic function modules corresponding to the snapshot process, snapshot information of the cloud server is generated and stored; the snapshot information represents the operating status of the cloud server before fault repair.

[0208] The snapshot information is determined as the execution result of the snapshot configuration process on the cloud server.

[0209] In one possible implementation, the currently traversed stage is the configuration rollback stage, which is located after the tool scheduling stage; the result determination module is specifically used for:

[0210] If the restart fails, the cloud server will be rolled back based on the snapshot information by using the atomic function module corresponding to the configuration rollback step, and the execution result of the configuration rollback step on the cloud server will be obtained; the execution result of the configuration rollback step on the cloud server indicates whether the rollback was successful.

[0211] In one possible implementation, the currently traversed stage is the configuration rollback stage, which is located after the tool scheduling stage; the result determination module is specifically used for:

[0212] If the tool scheduling process fails to repair the cloud server, the cloud server is rolled back based on the snapshot information by using the atomic function module corresponding to the rollback process. The execution result of the rollback process is then obtained. The execution result of the rollback process indicates whether the rollback was successful.

[0213] This embodiment provides a cloud server-based fault handling device that can execute the methods provided in the above-described method embodiments. Its implementation principle and technical effects are similar, and will not be described in detail here.

[0214] Figure 6 This is a schematic diagram of the structure of an electronic device provided in this application. Figure 6 As shown, the electronic device 60 provided in this embodiment includes at least one processor 601 and a memory 602. Optionally, the device 60 further includes a communication component 603. The processor 601, memory 602, and communication component 603 are connected via a bus 604.

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

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

[0217] 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.

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

[0219] 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.

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

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

[0222] 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.

[0223] 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.

[0224] 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.

[0225] 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.

[0226] 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.

[0227] 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.

[0228] 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.

[0229] 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.< / filesystem> < / interface> < / boot> < / disk> < / boot> < / os>

Claims

1. A cloud server-based fault processing method, characterized by, The method comprises the following steps: in response to a selection instruction of a user on a rescue scenario, obtaining user information and system information; wherein the rescue scenario represents the type of fault to be processed, the user information is identification information representing the user, and the system information includes identification information of a cloud server with a fault and identification information of the rescue scenario; determining a rescue procedure list according to the user information and the system information; wherein the rescue procedure list represents the steps required to be executed and the execution order between the steps when processing the fault; processing the fault of the cloud server based on the atomic function module corresponding to each step according to the rescue procedure list, to obtain a fault processing result; wherein the atomic function module represents a pre-encapsulated API for executing the corresponding step.

2. The method of claim 1, wherein, Determining a rescue procedure list according to the user information and the system information comprises: generating token information according to the user information and the system information; wherein the token information is used for security verification of the user and the cloud server for fault processing; if the token information meets a preset verification condition, determining the rescue procedure list according to the system information.

3. The method of claim 2, wherein, Generating token information according to the user information and the system information comprises: obtaining a current timestamp; generating the token information based on a preset token format according to the timestamp, the user information, and the system information.

4. The method of claim 2, wherein, Determining the rescue procedure list according to the system information comprises: determining the rescue procedure list corresponding to the system information according to a preset association relationship; wherein the preset association relationship represents the association relationship between the system information and the rescue procedure list.

5. The method according to any one of claims 1-4, characterized in that, Processing the fault of the cloud server based on the atomic function module corresponding to each step according to the rescue procedure list to obtain a fault processing result comprises: traversing the rescue procedure list to determine a currently traversed step; determining the execution result of the currently traversed step on the cloud server according to the atomic function module corresponding to the currently traversed step; if it is determined that the rescue procedure list is traversed according to the execution result, determining the execution result as the fault processing result.

6. The method of claim 5, wherein, The currently traversed step is an information collection step; Determining the execution result of the currently traversed step on the cloud server according to the atomic function module corresponding to the currently traversed step comprises: obtaining operating system information, kernel information, and hardware information of the cloud server through the atomic function module corresponding to the information collection step; determining the operating system information, the kernel information, and the hardware information as the execution result of the information collection step on the cloud server.

7. The method of claim 6, wherein, The currently traversed step is a mirror matching step, and the mirror matching step is located after the information collection step; Determining the execution result of the currently traversed step on the cloud server according to the atomic function module corresponding to the currently traversed step comprises: The execution result of the information collection link is obtained through an atomized function module corresponding to the mirror image matching link, wherein the execution result of the information collection link comprises at least one of operating system information, kernel information, and hardware information; The first mirror image is searched from the preset mirror image warehouse according to the operating system information and the kernel information, wherein the first mirror image represents a basic mirror image adapted to the operating system information and the kernel information, and the preset mirror image warehouse stores a plurality of mirror image files; The second mirror image is searched from the preset mirror image warehouse according to the rescue scene, wherein the second mirror image represents a light tool package adapted to the rescue scene; The third mirror image is searched from the preset mirror image warehouse according to the kernel information and the hardware information, wherein the third mirror image represents a driver mirror image adapted to the kernel information and the hardware information; The execution result of the cloud server by the mirror image matching link is determined according to the first mirror image, the second mirror image, and the third mirror image.

8. The method of claim 7, wherein, The first mirror image is searched from the preset mirror image warehouse according to the operating system information and the kernel information, including: If the first mirror image corresponding to the operating system information and the kernel information does not exist in the preset mirror image warehouse, the secondary version information is determined according to the kernel information, wherein the secondary version information represents a kernel secondary version of the kernel information; The first mirror image is searched from the preset mirror image warehouse according to the operating system information and the secondary version information.

9. The method of claim 7, wherein, The third mirror image is searched from the preset mirror image warehouse according to the kernel information and the hardware information, including: If the third mirror image corresponding to the kernel information and the hardware information does not exist in the preset mirror image warehouse, the secondary version information is determined according to the kernel information, and the alternative information is determined according to the hardware information, wherein the secondary version information represents a kernel secondary version of the kernel information, and the alternative information represents information belonging to the same series as the hardware information; The third mirror image is searched from the preset mirror image warehouse according to the kernel information, the hardware information, the secondary version information, and the alternative information.

10. The method of claim 7, wherein, The current traversed link is a resource loading link, and the resource loading link is located after the mirror image matching link; The execution result of the cloud server by the current traversed link is determined according to the atomized function module corresponding to the current traversed link, including: The execution result of the mirror image matching link is mounted into the cloud server through the atomized function module corresponding to the resource loading link, and the mirror image startup sequence of the cloud server is configured, wherein the mirror image startup sequence represents the startup sequence of the mirror image file mounted in the cloud server when the cloud server is restarted; The mirror image startup sequence is determined as the execution result of the cloud server by the resource loading link.

11. The method of claim 10, wherein, The current traversed link is a tool scheduling link, and the tool scheduling link is located after the resource loading link; The execution result of the cloud server by the current traversed link is determined according to the atomized function module corresponding to the current traversed link, including: restarting the cloud server through an atomized function module corresponding to the tool scheduling link; if the restarting is successful, performing fault repair on the cloud server based on the image starting sequence, to obtain an execution result of the tool scheduling link on the cloud server; wherein the execution result of the tool scheduling link on the cloud server represents whether the fault is successfully repaired.

12. The method of claim 11, wherein, the current traversed link is a configuration snapshot link, and the configuration snapshot link is located before the tool scheduling link; the execution result of the current traversed link on the cloud server is determined according to an atomized function module corresponding to the current traversed link, including: generating and storing snapshot information of the cloud server through an atomized function module corresponding to the configuration snapshot link; wherein the snapshot information represents a running state of the cloud server before fault repair; determining the snapshot information as the execution result of the configuration snapshot link on the cloud server.

13. The method of claim 12, wherein, the current traversed link is a configuration rollback link, and the configuration rollback link is located after the tool scheduling link; the execution result of the current traversed link on the cloud server is determined according to an atomized function module corresponding to the current traversed link, including: if the restarting fails, performing rollback processing on the cloud server based on the snapshot information through an atomized function module corresponding to the configuration rollback link, to obtain an execution result of the configuration rollback link on the cloud server; wherein the execution result of the configuration rollback link on the cloud server represents whether the rollback is successful.

14. The method of claim 12, wherein, the current traversed link is a configuration rollback link, and the configuration rollback link is located after the tool scheduling link; the execution result of the current traversed link on the cloud server is determined according to an atomized function module corresponding to the current traversed link, including: if the execution result of the tool scheduling link on the cloud server is repair failure, performing rollback processing on the cloud server based on the snapshot information through an atomized function module corresponding to the configuration rollback link, to obtain an execution result of the configuration rollback link on the cloud server; wherein the execution result of the configuration rollback link on the cloud server represents whether the rollback is successful. 15.A cloud server-based fault processing apparatus, characterized by, including: an information acquisition unit configured to acquire user information and system information in response to a selection instruction of a rescue scenario by a user; wherein the rescue scenario represents a type of a fault to be processed, the user information is identification information representing the user, and the system information includes identification information of a cloud server having a fault and identification information of the rescue scenario; a sequence determination unit configured to determine a rescue flow sequence according to the user information and the system information; wherein the rescue flow sequence represents links required to be executed and an execution order between the links when performing fault processing. A fault processing unit is configured to process the fault of the cloud server based on the atomic function module corresponding to each link according to the rescue flow sequence, and obtain a fault processing result.

16. An electronic device, comprising: Comprise: A memory, a processor; The memory stores computer execution instructions; The processor executes the computer execution instructions stored in the memory, so that the processor executes the method of any one of claims 1-14.

17. A computer-readable storage medium, characterized in that, The computer readable storage medium stores computer execution instructions, and the computer execution instructions are executed by the processor to implement the method of any one of claims 1-14.

18. A computer program product, characterised in that, The computer program is executed by the processor to implement the method of any one of claims 1-14.

Images