Task self-healing closed-loop control method and task self-healing closed-loop control system

Abstract

The application discloses a task self-recovery closed-loop control method and a task self-recovery closed-loop control system. The method comprises the following steps: when a task to be executed is received, a one-time temporary execution instance corresponding to the task to be executed is created; the task load of the task to be executed is loaded into the one-time temporary execution instance for execution, and the execution state of the one-time temporary execution instance is collected; whether the task to be executed has an execution exception is judged according to the execution state, and in the case that it is judged that the task to be executed has an execution exception, a corresponding exception handling mode is determined; when the exception handling mode is instance reconstruction, the one-time temporary execution instance is disposed to generate a disposal result, and a new one-time temporary execution instance is reconstructed for the task to be executed; the task load is loaded into the new one-time temporary execution instance for execution; and self-recovery whole-process information is closed-loop archived to form a double-layer self-recovery closed loop, wherein the self-recovery whole-process information comprises the disposal result and an execution result.

Description

Technical Field

[0001] This application belongs to the field of task anomaly self-healing recovery technology, and particularly relates to a task self-healing closed-loop control method and a task self-healing closed-loop control system. Background Technology

[0002] With the widespread application of containerized and distributed automated task systems, the demand for self-healing of anomalies in temporary tasks such as detection, scanning, and script execution is increasing.

[0003] Existing technologies still have many problems with handling solutions for task anomalies: 1) Retrying / restarting the original instance will inherit dirty states such as temporary files, locks, processes, mounts, caches, and session credentials, causing secondary anomalies; 2) Platform-level instance restarts only restore resource availability and do not address task execution semantics and environmental remnants, thus failing to guarantee a clean execution environment; 3) Remnant management only describes environment cleanup in a general way and does not break down perceptible, cleanable, and verifiable remnant categories, making it impossible to quantify the cleanup effect; 4) The anomaly, cleanup, reconstruction, re-execution, and backhaul links are fragmented and lack unified associated archiving, making it impossible to form a traceable self-healing closed loop. Summary of the Invention

[0004] To at least partially solve the above-mentioned technical problems, embodiments of this application provide a task self-healing closed-loop control method, a task self-healing closed-loop control system, an electronic device, a computer-readable storage medium, and a computer program product, which can improve the recovery success rate and closed-loop integrity while cutting off the contamination inheritance chain.

[0005] The first aspect of this application provides a task self-healing closed-loop control method, including: When a task is received, a corresponding one-time temporary execution instance is created for that task. Load the task load of the task to be executed into a one-time temporary execution instance for execution, and collect the execution status of the one-time temporary execution instance; Based on the execution status, determine whether the task to be executed has encountered an execution exception, and if it is determined that the task to be executed has encountered an execution exception, determine the corresponding exception handling method; When the exception handling method is instance reconstruction, the one-time temporary execution instance is processed and the processing result is generated, and a new one-time temporary execution instance is reconstructed for the task to be executed. The task load is loaded into a new one-time temporary execution instance for execution, and the execution result is obtained. The entire self-healing process information is archived in a closed loop, forming a two-layer self-healing closed loop. The self-healing process information includes the handling results and the execution results.

[0006] For example, the two-layer self-healing closed loop is a complete closed-loop control structure formed by the mutual linkage of the task-level self-healing closed loop and the instance-level self-healing closed loop. The task-level self-healing closed loop includes at least the following steps: task creation, task execution, task anomaly detection, task re-execution, task result feedback, and task archiving. The instance-level self-healing closed loop includes at least the following steps: instance creation, instance operation, abnormal instance isolation, residual object cleanup, instance destruction, new instance reconstruction, and new instance takeover execution. For example, the task-level self-healing closed loop and the instance-level self-healing closed loop are associated and bound through the task identifier and instance identifier chain to complete the unified tracking, linkage control and result backtracking of the task execution process, instance life cycle process and anomaly recovery process, forming a traceable self-healing control closed loop.

[0007] In one implementation, when an execution exception occurs, determining the corresponding exception handling method includes: Based on the type of execution exception, the risk of pollution inheritance, and the verifiability of the execution status, execution exceptions are classified and their paths are diverted to determine the corresponding exception handling methods.

[0008] In one implementation, execution exceptions are classified and routed to determine the corresponding exception handling method, including: If it is determined that the execution exception can be recovered within the current instance and there is no risk of pollution inheritance, a lightweight recovery operation is performed. When an execution anomaly is determined to pose a risk of pollution inheritance or the execution status is unconfirmed, an instance reconstruction operation is performed. When an execution exception is determined to meet preset conditions, an execution exception is reported.

[0009] In one implementation, processing a one-time temporary execution instance includes performing at least one of the following operations: Implement isolation and control measures for one-time, temporary execution instances; Perform a full cleanup of the execution environment for one-off temporary execution instances; Terminate and destroy a one-time temporary execution instance.

[0010] In one implementation, isolation control is performed on one-off temporary execution instances, including: This prevents the one-time temporary execution instance from outputting the valid execution result of the task.

[0011] In one implementation, a full cleanup of the execution environment for a one-time temporary execution instance is performed, including: Clean up runtime residual objects generated within a one-time temporary execution instance. These runtime residual objects include at least one of the following: file residuals, process residuals, mount residuals, cache residuals, session credential residuals, and context state residuals.

[0012] In one implementation, clearing runtime remnant objects generated within a one-time temporary execution instance includes performing at least one of the following operations: Delete temporary directories, locked files, or script copies to clean up file remnants; Terminate non-primary processes, orphan processes, or zombie processes to clean up process remnants; Unmount points, release temporary volumes, or disconnect unreleased connections to clean up mount-related remnants; Clear the execution cache, session cache, or intermediate state cache to clean up cache class remnants; Delete temporary tokens, authentication files, or expired sessions to clean up session credential remnants; Reset environment variables, delete state files, or restore temporary configurations to clean up residual context state classes.

[0013] In one implementation, the information on the entire self-healing process is archived in a closed loop, including: Perform unified aggregation and association binding on information throughout the entire self-healing process; A traceable archive index is built based on task identifiers and instance identifier chains, and storage and process verification are performed on the self-healing process information.

[0014] In one implementation, the method further includes: Read the self-healing strategy and, based on the self-healing strategy, control the determination of exception handling methods, the scope of handling one-time temporary execution instances, and the execution rules for reconstructing new one-time temporary execution instances.

[0015] A second aspect of this application provides a task self-healing closed-loop control system, comprising: The temporary instance management unit is used to create a corresponding one-time temporary execution instance for the task to be executed when a task to be executed is received. It is also used to handle the one-time temporary execution instance and generate the handling result when the task to be executed encounters an execution exception and the corresponding exception handling method is instance reconstruction, and to reconstruct a new one-time temporary execution instance for the task to be executed. The task execution agent unit is used to load the task load of the task to be executed into the one-time temporary execution instance when the one-time temporary execution instance is created, and to collect the execution status of the one-time temporary execution instance. It is also used to load the task load into the new one-time temporary execution instance when the new one-time temporary execution instance is created, and to obtain the execution result. The exception determination unit is used to determine whether the task to be executed has encountered an execution exception based on the execution status of the one-time temporary execution instance, and to determine the corresponding exception handling method if the task to be executed has encountered an execution exception. The feedback processing unit is used to archive the self-healing process information in a closed loop, forming a two-layer self-healing closed loop. The self-healing process information includes the handling results and the execution results.

[0016] A third aspect of this application provides an electronic device, including: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the above-described task self-healing closed-loop control method.

[0017] A fourth aspect of this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the above-described task self-healing closed-loop control method.

[0018] The fifth aspect of this application provides a computer program product that, when run on an electronic device, enables the electronic device to perform the steps in the above-described task self-healing closed-loop control method.

[0019] The task self-healing closed-loop control method provided in the first aspect of this application completes a full two-layer self-healing closed loop, from anomaly detection, instance handling, new instance reconstruction, task re-execution to unified feedback and archiving. It simultaneously covers both task execution results and instance lifecycles, solving the problem of fragmented recovery links in existing technologies. By employing a one-time temporary execution instance, cross-task contamination is eliminated at the carrier level, ensuring the independence of the execution environment. The contamination inheritance chain is completely severed, achieving structured residual governance and full-process traceable self-healing, significantly reducing the secondary anomaly rate and improving the recovery success rate. It is suitable for anomaly self-healing scenarios of containerized temporary tasks, high-risk detection tasks, and high-concurrency automated tasks. Compared to conventional retry, original context recovery, or single instance restart solutions in existing technologies, the task self-healing closed-loop control method of this application effectively reduces the risk of contamination inheritance, minimizes secondary anomalies, and improves the stability and closed-loop integrity of task recovery by linking the task execution process and instance lifecycle process, and classifies, governs, and reconstructs residual objects associated with abnormal instances. This demonstrates good engineering applicability and technical effectiveness.

[0020] It is understood that the beneficial effects of the second to fifth aspects mentioned above can be found in the relevant descriptions in the first aspect mentioned above, and will not be repeated here. Attached Figure Description

[0021] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0022] Figure 1a This is a schematic diagram of the structure of a task self-healing closed-loop control system provided in one embodiment of this application; Figure 1b This is a schematic diagram of the structure of a task self-healing closed-loop control system provided in another embodiment of this application; Figure 2 This is a flowchart illustrating a task self-healing closed-loop control method provided in one embodiment of this application; Figure 3 This is a schematic diagram of the data structure of a one-time temporary execution instance provided in one embodiment of this application; Figure 4 This is a schematic diagram of the dual-layer linkage between task-level self-healing closed loop and instance-level self-healing closed loop provided in one embodiment of this application; Figure 5 This is a schematic diagram of an abnormal traffic diversion and self-healing decision-making process provided in one embodiment of this application; Figure 6 This is a schematic diagram of residual object cleanup association provided in one embodiment of this application; Figure 7 This is a schematic diagram of the lifecycle state machine of a one-time temporary execution instance provided in one embodiment of this application; Figure 8 This is a schematic diagram of the structure of an electronic device provided in one embodiment of this application. Detailed Implementation

[0023] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0024] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0025] It should also be understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0026] Furthermore, in the description of this application and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0027] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0028] As mentioned earlier, with the widespread application of containerization technology, distributed execution architecture, and automated task systems, a large number of probing, scanning, data collection, script execution, and temporary processing tasks are deployed and run in container or container-like execution environments. Existing technologies typically employ recovery methods for task execution anomalies, including: retrying the original process, restarting the original container, relying on the platform controller to automatically launch a new Pod, or relying on cloud platforms for instance compensation and migration.

[0029] However, existing solutions generally suffer from the following problems: First, retrying in the original context can easily lead to the inheritance of polluted states. For example, situations such as temporary files not being deleted, lock files not being released, orphan processes not ending, mounts not being unmounted, caches not being cleared, sessions or credentials not being expired, and environment variables not being restored can cause the task to continue using the dirty environment during retries, thus causing secondary failures.

[0030] Second, platform-level recovery is not the same as task-level recovery. For example, the routine recovery of Kubernetes Jobs, Pod restarts, or cloud platform ACKs focuses on restarting or scheduling resource instances, but does not address the execution semantics, environmental remnants, and context pollution of the task itself. Therefore, it cannot be guaranteed that task recovery is completed in a clean environment.

[0031] Third, existing technologies often lack structured remnant management mechanisms. Many solutions only vaguely describe "resetting the environment" or "cleaning the cache," but fail to break down remnant objects into perceptible, cleanable, and verifiable structured categories, making the recovery process difficult to audit and the technical effectiveness difficult to quantify and verify.

[0032] Fourth, the anomaly recovery link and the result feedback link are disconnected. Many existing solutions only record the final success or failure status, without unifying and linking the original anomaly, cleanup actions, instance destruction, new instance reconstruction, and new results, making it difficult to form a complete and traceable autonomous recovery closed loop.

[0033] Therefore, a new technical solution is needed to achieve structured self-healing control based on one-time temporary execution instances for abnormal task execution scenarios, thereby cutting off the pollution inheritance chain and improving the recovery success rate and closed-loop integrity.

[0034] To at least partially solve the aforementioned technical problems, embodiments of this application provide a task self-healing closed-loop control method. This task self-healing closed-loop control method can specifically be executed by a task self-healing closed-loop control system. Figure 1a and Figure 1b These are schematic diagrams of the task self-healing closed-loop control system provided in different embodiments of this application. First, refer to... Figure 1a The task self-healing closed-loop control system 100 in this application embodiment may include at least a temporary instance management unit 103, a task execution agent unit 104, an exception determination unit 105, and a feedback processing unit 106. These four units can be interconnected and can collaboratively complete the task self-healing closed-loop control. Furthermore, in Figure 1b In another exemplary structure of the task self-healing closed-loop control system shown, the task self-healing closed-loop control system may further include a task processing unit 101, a scheduling unit 102, and an auditing unit 107. Exemplarily, the task processing unit 101, the scheduling unit 102, the temporary instance management unit 103, and the feedback processing unit 106 may be deployed on distributed nodes, communication may be accomplished via a message bus, and status information may be stored through a combination of a relational database and a cache database.

[0035] Figure 2 This is a flowchart illustrating a task self-healing closed-loop control method provided in one embodiment of this application. Figure 2 As shown, the task self-healing closed-loop control method provided in this application includes the following steps: Step S210: Upon receiving a task to be executed, create a corresponding one-time temporary execution instance for the task to be executed.

[0036] For example, the task processing unit 101 can receive tasks to be executed from external scheduling systems, control platforms, or business modules. Tasks to be executed include, but are not limited to, high-risk, short-term tasks such as remote probing tasks, port scanning tasks, data acquisition tasks, temporary script execution tasks, and batch maintenance tasks. After the task processing unit 101 receives a task to be executed, the temporary instance management unit 103 can create a corresponding one-time temporary execution instance for the task. The one-time temporary execution instance is uniquely bound to the task to be executed; one task identifier corresponds to only one independent one-time temporary execution instance and does not share the execution carrier with other tasks.

[0037] One-time temporary execution instances are the core execution carrier of this application. They are essentially independent execution environments that are task-specific, short-lived, support full cleanup, support isolated destruction, and support reconstruction and replacement. They can be implemented as container instances (created by container runtimes such as containerd and Docker), Pod instances (Kubernetes single-task Pods), lightweight virtual machine instances (micro sandbox virtual machines), sandbox process instances (restricted processes in independent namespaces), and functional short-lived execution instances. They have four core attributes: task specificity, short lifespan, destructibility, and strong isolation. After execution is completed, fails, or is rebuilt, they immediately enter the destruction process and do not occupy system resources for a long time.

[0038] Figure 3 This is a schematic diagram of the data structure of a one-time temporary execution instance provided in one embodiment of this application. For example... Figure 3 As shown, a one-time temporary execution instance may include the following fields: 301: Instance identifier field inst_id; 302: Task identifier field task_id; 303: Lifecycle state field; 304: Health status field health_state; 305: Resource context field resource_context; 306: Exception flag field; 307: The clean_report field is part of the cleanup results. 308: Returns the associated field return_ref; 309: Rebuild_from field (the source field is rebuilt); 310: Six types of residual state fields, residual_state_set.

[0039] Through the above structure, a one-time temporary execution instance is not only a running entity that carries the task, but also a structured control object that can record exceptions, clean up and rebuild relationships.

[0040] Step S220: Load the task load of the task to be executed into a one-time temporary execution instance for execution, and collect the execution status of the one-time temporary execution instance.

[0041] For example, the task load of the task to be executed is loaded into a one-time temporary execution instance and started for execution. The task load includes core execution content such as task execution instructions, execution parameters, business logic, target address, and execution timeout. Throughout the entire lifecycle of task execution, the execution status of the one-time temporary execution instance is continuously and periodically collected. The execution status comprehensively covers the core dimensions of instance operation and environment, including but not limited to process status information, resource usage information (CPU, memory, disk, network), temporary file information, network connection information, mount status information, cache status information, session status information, environment variable status information, credential status information, and context status information. The collection frequency can be dynamically adjusted according to the task risk level. High-risk tasks use high-frequency collection, and low-risk tasks use low-frequency collection.

[0042] Step S230: Based on the execution status, determine whether the task to be executed has encountered an execution exception, and if it is determined that the task to be executed has encountered an execution exception, determine the corresponding exception handling method.

[0043] For example, based on the real-time collected execution status, the system detects whether the task to be executed has encountered execution anomalies through methods such as status threshold judgment, logic verification, integrity verification, and heartbeat detection. Execution anomalies include, but are not limited to, various abnormal scenarios such as execution timeout, process crash, network interruption, missing results, state conflict, credential expiration, context pollution, deadlock, and false liveness. When an execution anomaly is clearly determined, the system determines the corresponding anomaly handling method by combining the task execution semantics, instance running status, and business rules. Anomaly handling methods include, but are not limited to, three main categories: lightweight recovery, instance reconstruction, and termination reporting, providing a core basis for subsequent self-healing operations.

[0044] Step S240: When the exception handling method is instance reconstruction, perform processing on the one-time temporary execution instance and generate processing results, and reconstruct a new one-time temporary execution instance for the task to be executed.

[0045] For example, when the exception handling method is determined to be instance reconstruction, it is determined that the current exception has a risk of contamination or the status is unconfirmed and cannot be resolved by in-situ recovery, so an instance replacement operation needs to be performed. At this time, the one-time temporary execution instance is disposed of and the disposal result is generated. The disposal is a standardized processing operation for the exception instance, which is used to block the spread of contamination, clean up environmental residues, and terminate the instance operation. After the disposal is completed and the disposal result is generated, a new one-time temporary execution instance is reconstructed for the task to be executed. The new instance is uniquely bound to the original task and has no contamination association with the original exception instance, providing a clean execution environment for the re-execution of the task.

[0046] Step S250: Load the task load into a new one-time temporary execution instance for execution, and obtain the execution result.

[0047] For example, the task load of the task to be executed is reloaded into a new one-time temporary execution instance. The new instance only loads the core execution content of the task and does not inherit any temporary data, cache, session, credentials, environment variables or intermediate execution state of the original abnormal instance, ensuring that the task is executed in a completely clean environment and obtaining the execution result of the new one-time temporary execution instance. The execution result includes core content such as task execution success, failure, partial completion, result verification status, etc.

[0048] Step S260: Archive the self-healing process information in a closed loop to form a two-layer self-healing closed loop. The self-healing process information includes the handling results and the execution results.

[0049] For example, all core data in the self-healing process is integrated to form a self-healing full-process information. The self-healing full-process information includes at least the handling results and the execution results of the new one-time temporary execution instance, and can also be extended to include the original instance identifier, the cause of the exception, the reconstruction information, the execution status, the policy version, etc. The self-healing full-process information is archived in a closed loop to complete the unified collection, association binding, persistent storage and process verification of the information. Finally, a two-layer self-healing closed loop is formed, which is a linkage closed loop of task-level self-healing closed loop and instance-level self-healing closed loop.

[0050] Figure 4 This is a schematic diagram illustrating the dual-layer linkage of task-level self-healing closed loop and instance-level self-healing closed loop provided in one embodiment of this application. For example... Figure 4As shown, the task-level self-healing closed loop includes: task creation, task execution, task exception handling, task result review, and final completion or termination reporting. The task-level self-healing closed loop focuses on whether the task ultimately succeeds, fails, or terminates, as well as the feedback and result confirmation at the task level. The instance-level self-healing closed loop includes: instance creation, instance monitoring, instance exception identification, instance remnant cleanup, instance destruction, new instance reconstruction, and new instance takeover execution. The instance-level self-healing closed loop focuses on whether the execution carrier itself is contaminated, whether it needs to be destroyed, and whether it has been taken over by a new instance. The linkage control unit is used to unify the association between the two closed loops. Specifically, it can be linked through the following information: the binding relationship between task_id and inst_id, exception judgment results, cleanup reports, reconstruction reasons, association between old and new instances, feedback results, and audit archive information.

[0051] For example, a task might appear as "successfully recovered after execution failure" from a task-level perspective, but from an instance-level perspective, it might appear as "original instance exception—cleanup—destruction—new instance reconstruction—successful re-execution." This two-layer linkage allows for the simultaneous preservation of both the task recovery result and the instance replacement process, thereby improving the system's traceability, verifiability, and governance precision.

[0052] For example, the dual-layer self-healing closed loop in this application embodiment is a complete closed-loop control structure composed of a task-level self-healing closed loop and an instance-level self-healing closed loop that are linked together. The task-level self-healing closed loop includes at least the following steps: task creation, task execution, task anomaly detection, task re-execution, task result feedback, and task archiving. The instance-level self-healing closed loop includes at least the following steps: instance creation, instance operation, abnormal instance isolation, residual object cleanup, instance destruction, new instance reconstruction, and new instance takeover execution. For example, the task-level self-healing closed loop and the instance-level self-healing closed loop are associated and bound through the task identifier and instance identifier chain to complete the unified tracking, linkage control and result backtracking of the task execution process, instance life cycle process and anomaly recovery process, forming a traceable self-healing control closed loop.

[0053] The above solution achieves a complete two-layer self-healing closed loop, encompassing anomaly detection, instance handling, new instance reconstruction, task re-execution, and unified feedback and archiving. It simultaneously covers both task execution results and instance lifecycles, resolving the fragmented recovery chain issue inherent in existing technologies. Employing one-time temporary execution instances eliminates cross-task contamination at the carrier level, ensuring the independence of the execution environment. Completely severing the contamination inheritance chain enables structured residual management and full-process traceable self-healing, significantly reducing the secondary anomaly rate and improving recovery success rate. This solution is suitable for anomaly self-healing scenarios involving containerized temporary tasks, high-risk detection tasks, and high-concurrency automated tasks.

[0054] In one implementation, step S230, in the event of an execution exception, determines the corresponding exception handling method, including the following steps: Step S231: Based on the type of execution exception, the risk of pollution inheritance, and the verifiability of the execution status, the execution exception is classified and path-based to determine the corresponding exception handling method.

[0055] For example, anomalies are standardized and categorized, including but not limited to transient anomalies (network jitter, temporary resource shortage), pollution anomalies (lock file remnants, cache pollution, credential expiration), state anomalies (execution timeout, missing results, deadlock / false liveness), interruption anomalies (process crash, network disconnection), and context anomalies (environment variable conflicts, state file pollution), etc. Different types of anomalies correspond to different self-healing risks and handling logic. After an anomaly occurs, it is determined whether the original instance's execution environment, context state, and residual data will be passed to subsequent re-execution processes, and whether it will trigger secondary anomalies. Pollution inheritance risk is divided into high, medium, and low levels. High-risk anomalies require instance reconstruction, while low-risk anomalies can attempt lightweight recovery. It is also determined whether the collected execution status can accurately pinpoint the root cause of the anomaly, confirm the instance's running status, and verify the task execution progress. Status confirmability is divided into "clearly confirmable" and "unconfirmable." Anomalies with unconfirmable status are all classified as high-risk and require instance reconstruction.

[0056] Based on the comprehensive judgment of the above three dimensions, execution anomalies are classified into three levels: low risk and recoverable, high risk and need to be rebuilt, and unrecoverable and need to be terminated. Then, the execution path is diverted according to the classification result, and the anomaly is matched to the corresponding anomaly handling path. Finally, the anomaly handling method that is fully adapted to the current anomaly is determined to achieve differentiated self-healing.

[0057] Therefore, this approach abandons the crude logic of relying solely on retries in existing technologies and achieves precise anomaly identification through a three-dimensional judgment based on anomaly type, contamination risk, and state confirmability. Different handling methods are matched to different levels of anomalies, avoiding excessive self-healing for low-risk anomalies and insufficient self-healing for high-risk anomalies. It covers all task execution anomaly types, including transient anomalies, contamination anomalies, state anomalies, and interruption anomalies, demonstrating strong versatility.

[0058] Figure 5 This is a schematic diagram of an anomaly triage and self-healing decision-making process provided in one embodiment of this application. In one implementation, step S231 performs hierarchical judgment and path triage on execution anomalies to determine the corresponding anomaly handling method, including, for example... Figure 5 The steps S2311, S2312, or S2313 shown.

[0059] Step S2311: When it is determined that the execution exception can be recovered within the current instance and there is no risk of pollution inheritance, a lightweight recovery operation is performed.

[0060] When it is determined that an execution exception can be recovered within the current instance and there is no risk of pollution inheritance, a lightweight recovery operation is performed. Lightweight recovery means that self-healing can be completed by performing lightweight operations such as partial repair, partial retries, dependency recovery, and state reset within the current one-time temporary execution instance without destroying and rebuilding the instance. It is suitable for low-risk scenarios such as transient network jitter, temporary resource shortages, and non-polluting transient exceptions. Such exceptions have no residue and no context pollution, and in-situ recovery will not cause secondary exceptions.

[0061] Step S2312: When it is determined that there is a risk of pollution inheritance due to execution abnormality or the execution status cannot be confirmed, the instance reconstruction operation is performed.

[0062] When an execution anomaly is determined to pose a risk of pollution inheritance or the execution status is unverifiable, an instance reconstruction operation is performed. This operation includes scenarios such as execution timeout, lock file residue, cache pollution, invalid credentials, context conflicts, deadlock, false liveness, and missing results. Such anomalies cannot be resolved by in-situ recovery; the original instance must be destroyed and a new instance rebuilt to break the pollution inheritance chain.

[0063] Any anomalies where the status cannot be confirmed (such as normal agent heartbeat but missing results, main process alive but no business progress, partial result file verification failure, network interruption causing inconsistent status, and mutual exclusion conflicts of status fields) are all included in the instance reconstruction path. Even if the root cause cannot be located, pollution can be blocked by replacing the instance.

[0064] Step S2313: When the execution exception is determined to meet the preset conditions, the execution exception is reported.

[0065] Preset conditions include, but are not limited to, exceeding the maximum number of rebuilds, task being manually canceled, core dependent resources being unavailable for a long time, policy-level blocking, and unrecoverable system-level anomalies. Continuing self-healing for such anomalies is meaningless. The self-healing process is terminated and the anomaly information is reported to the superior platform. At the same time, all self-healing data is retained for auditing.

[0066] The three standardized processing paths described above meet the self-healing requirements of all abnormal scenarios. Lightweight recovery balances efficiency, instance reconstruction ensures cleanliness, and termination of reporting avoids resource waste. The combination of these three approaches achieves the optimal solution for self-healing.

[0067] In one implementation, step S240 performs processing on a one-time temporary execution instance, including at least one of the following steps: Step S241: Implement isolation and control measures for one-time temporary execution instances.

[0068] Isolation and control refers to separating abnormal instances from the normal execution chain of the system, restricting their resource access, network communication, and result writing permissions, achieving instance-level isolation, and preventing pollution from spreading to other tasks or system modules. Isolation methods include network isolation, namespace isolation, permission isolation, and resource isolation.

[0069] Step S242: Perform a full cleanup of the execution environment for the one-time temporary execution instance.

[0070] Full cleanup refers to performing a comprehensive and thorough cleanup of the execution environment of an abnormal instance, removing all runtime remnants, context data, temporary files, processes, mounts, caches, session credentials, etc., that may cause pollution, and restoring the instance environment to its initial clean state.

[0071] Step S243: Terminate and destroy the one-time temporary execution instance.

[0072] Termination and destruction refers to completely terminating the operation of abnormal instances, releasing all computing resources, storage resources, network resources, mounted volumes, credentials, etc., occupied by them, removing the instance from the system, and destroying the instance so that it cannot be recovered or reused, thus cutting off the source of pollution at the physical level.

[0073] Optionally, the execution sequence of the disposal operation can be: first isolation and control → then full-area cleanup → finally termination and destruction. This sequence can block the spread of pollution to the greatest extent and ensure that the cleanup process is safe and thorough. High-risk tasks can be carried out in all three steps, while low-risk tasks can be carried out in some steps, which is highly flexible.

[0074] In one implementation, step S241 performs isolation control on the one-time temporary execution instance, including the following steps: blocking the one-time temporary execution instance from outputting the valid execution result of the task.

[0075] For example, when isolating and controlling abnormal instances, the one-time temporary execution instance is immediately removed from the formal output chain, and all its permissions to write to the business database, report valid results, and output execution data are frozen. Any data, results, or status generated by this contaminated instance is prohibited from being included in the final valid result of the task, preventing dirty data and contaminated results from entering the formal business system and ensuring the accuracy, completeness, and compliance of the final task result. After isolation and control, the abnormal instance is only used for residual cleanup and data collection and no longer has any valid result output capability.

[0076] In one implementation, step S242 performs a full cleanup of the execution environment of a one-time temporary execution instance, including the following steps: Step S2421: Clean up the runtime residual objects generated within the one-time temporary execution instance. The runtime residual objects include at least one of the following: file class residuals, process class residuals, mount class residuals, cache class residuals, session credential class residuals, and context state class residuals.

[0077] Figure 6 This is a schematic diagram of residual object cleanup association provided in one embodiment of this application, such as... Figure 6 As shown, the temporary instance management unit 103 includes a cleanup execution module 1031, which is used to perform cleanup execution on... Figure 6 The remaining objects shown are then cleaned up. Figure 6 The six categories of runtime remnants shown are the core of structured remnant governance, covering all types of remnants that cause execution environment pollution. Among them, file remnants (601) include undeleted file data such as temporary directories, lock files, script copies, temporary result files, and log files. Process remnants (602) include unterminated processes such as non-main execution processes, orphan processes, zombie processes, and daemon processes. Mount remnants (603) include unremoved mount points, unreleased temporary volumes, undisconnected network mounts, and unreleased file handles. Cache remnants (604) include uncleared cache data such as execution cache, session cache, intermediate state cache, and data cache. Session credential remnants (605) include unexpired / undeleted credentials such as temporary tokens, authentication files, session IDs, keys, and account passwords. Context state remnants (606) include unreset / undeleted state data such as environment variables, state files, temporary configurations, and execution contexts.

[0078] During the full-domain cleanup, users can choose to clean up all six categories of residues or some residues based on the task's risk level. High-risk tasks require cleaning up all six categories, while low-risk tasks require cleaning up the core categories. After the cleanup is completed, a cleanup report is generated to verify the completeness of the cleanup and to address the ambiguity in the management of existing technology residues.

[0079] In one implementation, step S242 cleans up runtime residual objects generated within a one-time temporary execution instance, including at least one of the following steps: Delete temporary directories, locked files, or script copies to clean up file-related remnants and thoroughly eliminate sources of file-related pollution.

[0080] Terminate non-primary processes, orphan processes, or zombie processes to clean up process remnants, release process resources, and eliminate process blocking.

[0081] Remove mount points, release temporary volumes, or disconnect unreleased connections to clean up mount-related remnants and avoid anomalies caused by mount occupancy.

[0082] Clear the execution cache, session cache, or intermediate state cache to clean up cache class remnants and eliminate state conflicts caused by cache pollution.

[0083] Delete temporary tokens, authentication files, or expired sessions to clean up residual session credentials and expired sensitive credentials, preventing credential leakage.

[0084] Reset environment variables, delete state files, or restore temporary configurations to clean up residual context state classes and restore the execution environment to its initial state.

[0085] The above-mentioned targeted cleanup operations correspond one-to-one with the six types of residues. When executing the operation, one type can be cleaned up alone, or multiple types can be cleaned up in combination. After the cleanup is completed, the cleanup status of each type of residue is verified to ensure that there are no residues or omissions. The verification results are included in the disposal results and filed in a closed loop.

[0086] In one implementation, step S260 involves closed-loop archiving of the self-healing process information, including the following steps: Step S261: Perform unified aggregation and association binding on the self-healing process information.

[0087] The scattered data throughout the self-healing process—including original instance identifier, cause of the anomaly, handling result, cleanup report, destruction time, new instance identifier, reason for reconstruction, new execution result, final task status, and policy version—is uniformly aggregated and integrated into a complete self-healing data chain. Then, all data is linked and bound together through task identifier and instance identifier chains, forming a complete data structure with tasks at its core and instances as its threads, thus resolving the problems of scattered data and fragmented data chains.

[0088] Step S262: Construct a traceable archive index based on the task identifier and instance identifier chain, and perform storage and process verification on the self-healing full process information.

[0089] A traceable archive index is built based on task identifiers (task_id) and instance identifier chains (inst_id_chain, original instance → new instance). The index supports multi-dimensional retrieval by task, instance, time, policy version, and cleanup status, enabling rapid traceability of the entire self-healing process. The aggregated self-healing process information is persistently stored on various media, including relational databases, object storage, log platforms, and blockchain evidence storage systems. Simultaneously, the stored data undergoes process verification to check data integrity, correlation accuracy, and process compliance, ensuring that the archived data is authentic, valid, and auditable.

[0090] This enables the self-healing process to be traceable, auditable, quantifiable, and optimizable.

[0091] In one implementation, the method further includes: reading the self-healing strategy, and based on the self-healing strategy, controlling the determination of the exception handling method, the scope of handling one-time temporary execution instances, and the execution rules for reconstructing new one-time temporary execution instances.

[0092] For example, self-healing strategies can be stored in a rule base, configuration center, or policy file and controlled by rule objects. Rule objects may contain one or more of the following information: maximum number of rebuilds, task risk level, pollution sensitivity level, anomaly trigger threshold, cleanup mask, anomaly types allowed for lightweight recovery, task categories where reuse of the original instance is prohibited, and audit strength level, etc.

[0093] The task processing unit 101, the exception determination unit 105, and the temporary instance management unit 103 can jointly determine, based on the rule object, whether the current exception allows for lightweight recovery, whether it is necessary to enter the instance reconstruction path, which residual objects need to be cleaned up, whether the number of reconstructions has reached the upper limit, and whether the task is allowed to continue execution.

[0094] The self-healing strategy can be read in real time before creating a one-time temporary execution instance or before the execution instance is rebuilt. The system can read the latest strategy in real time and dynamically adjust the self-healing process. It can adapt to different business scenarios and tasks with different risk levels without modifying the core code. No customized development is required, and it supports runtime adjustment to meet dynamic business needs.

[0095] Figure 7 This is a schematic diagram of the lifecycle state machine of a one-time temporary execution instance provided in one embodiment of this application. Figure 7 As shown, a one-time temporary execution instance can have the following lifecycle states: Pending creation: Resources have not yet been allocated; Created: The instance has been initialized. Loaded Tasks: The task load has been loaded but has not yet been executed. In progress: The task is currently being performed; Anomaly detection: Detects whether any execution anomalies have occurred; Pending Cleanup: Residual cleanup has commenced; Cleanup complete and destroyed: The original instance has been destroyed; Rebuilt: The new instance has been rebuilt. Execution successful: The task has been completed and the results have been verified.

[0096] State transition relationships can include: From pending creation to created: Resource allocation completed and instance created; Tasks created to loaded: Task loading complete; Task loaded and in execution: Start execution; Execution-to-Anomaly Detection: Detects whether execution anomalies have occurred; From anomaly detection to successful execution: Execution was successful and the loop was closed. Anomaly detected and pending cleanup: Entering the residual cleanup stage; The cleanup process is complete and the original instance has been destroyed. Cleanup complete (destroyed to rebuilt): Create a new instance for the same task; Rebuilt to a loaded task: The task is injected with a new instance again.

[0097] It is important to emphasize that the state machine in this application contains two key states: "destroyed" and "rebuilt," which are used to clearly distinguish the essential difference between "instance replacement" and ordinary "instance restart." In other words, the recovery process in this application does not restart the original instance, but rather allows the original instance to exit its lifecycle, and then a new instance takes over the task execution.

[0098] In a specific embodiment one, corresponding Figure 2 and Figure 5 The task processing unit 101 receives the task request, generates a task identifier: task_id = T20260329-0847, and records the following task metadata: { "task_id": "T20260329-0847", "payload": "windows_ping_probe", "rule_version": "v3.2.1", "max_retry": 2, "timeout_sec": 30, "is_high_risk": true, "clean_flags": ["R-01", "R-02", "R-03", "R-04", "R-05", "R-06"], "auto_rebuild_on_pollution": true Task processing unit 101 sends a resource request to scheduling unit 102, requesting the creation of a one-time temporary execution instance. Temporary instance management unit 103 creates the instance: inst_id = I20260329-0847-1, and records the instance metadata. { "inst_id": "I20260329-0847-1", "task_id": "T20260329-0847", "status": "created", "host_node": "node-07", "clean_state": { "R-01": false, "R-02": false, "R-03": false, "R-04": false, "R-05": false, "R-06": false } } In this embodiment, the instance has the following characteristics: one instance per task, short instance lifecycle, instance is destructible, no shared volumes between instances, no shared network namespace and no shared credentials.

[0099] Task processing unit 101 loads the task load into a one-time temporary execution instance, and task execution agent unit 104 executes the following commands: / bin / probe -target 10.10.5.23:445 -timeout 30s -output / tmp / result.json The task execution agent unit 104 reports its status to the task processing unit 101 or the exception determination unit 105 every preset time interval. The status includes information such as CPU usage, memory usage, number of processes, temporary files, and network connections. For example: { "inst_id": "I20260329-0847-1", "task_id": "T20260329-0847", "phase": "executing", "pid_count": 1, "tmp_files": [" / tmp / probe.lock", " / tmp / cache.db"], "network_connections": [{"dst": "10.10.5.23:445", "state": "SYN_SENT"}] } Task processing unit 101 re-injects the original task into the new instance for execution.

[0100] In the new example, the task completed successfully within 22 seconds, with the following results: { "inst_id": "I20260329-0847-2", "task_id": "T20260329-0847", "phase": "succeeded", "result": { "status": "online", "latency_ms": 18.7, "service": "SMB" } } If the task is not completed and there is no normal exit signal after execution exceeds timeout_sec=30 seconds, the exception judgment unit 105 detects the exception and performs exception diversion based on the status information.

[0101] In this embodiment, the task is classified as high-risk because it simultaneously meets the following conditions: task timeout, lock file not released, connection not closed, and status unverifiable. Therefore, it is determined to be a pollution risk anomaly and enters the instance reconstruction path instead of the lightweight recovery path.

[0102] Task processing unit 101 issues an isolation and cleanup command to temporary instance management unit 103. The following residual cleanup actions are performed on the original instance: Delete / tmp / * and / var / run / * to clean up residual temporary files; Terminate non-master processes, orphan processes, or unresponsive processes, and clean up process remnants; Unmount temporary connections or release occupied connections, and clean up any residual connections. Clear the cache library or intermediate cache, and clean up cache remnants; Delete credential cache, temporary tokens, or expired sessions; clean up session or credential remnants. Reset environment variables, delete state files, restore temporary configurations, and clean up residual context state.

[0103] Example cleanup results are as follows: { "inst_id": "I20260329-0847-1", "clean_report": { "R-01": true, "R-02": true, "R-03": true, "R-04": true, "R-05": true, "R-06": true, "total_cleaned": 6 } } In this step, the original instance has exited the formal result writing chain.

[0104] After confirming the cleanup is complete, the temporary instance management unit 103 updates the original instance status to destroyed and releases the corresponding resources. Then, the temporary instance management unit 103 recreates a new instance based on the original task: inst_id = I20260329-0847-2, whose metadata includes: { "inst_id": "I20260329-0847-2", "task_id": "T20260329-0847", "rebuild_from": "I20260329-0847-1", "rebuild_reason": "pollution_risk_timeout", "status": "created" } Task processing unit 101 re-injects the original task into the new instance for execution.

[0105] During this process, only task inputs, task identifiers, and rule version information are inherited; temporary files, caches, credentials, sessions, and environment variables from the old instance are not inherited.

[0106] In the new example, the task completed successfully within 22 seconds, and the execution result is as follows: { "inst_id": "I20260329-0847-2", "task_id": "T20260329-0847", "phase": "succeeded", "result": { "status": "online", "latency_ms": 18.7, "service": "SMB" } } The feedback processing unit 106 assembles the following information in a unified manner: original instance exception information, six types of residual cleanup results, original instance destruction information, new instance identifier and reconstruction reason, new instance execution result, and final task status.

[0107] The following return packets can be generated: { "task_id": "T20260329-0847", "self_healing_chain": [ { "inst_id": "I20260329-0847-1", "phase": "failed", "reason": "timeout", "clean_report": { "R-01": true, "R-02": true, "R-03": true, "R-04": true, "R-05": true, "R-06": true } }, { "inst_id": "I20260329-0847-2", "phase": "succeeded", "result": { "status": "online" } } ], "final_status": "self_healed } For example, Figure 1b The audit unit 107 shown can establish associated indexes based on task_id, instance chain inst_id_chain, and rule_version, supporting subsequent retrieval and statistics by task, rule version, and instance cleanup status.

[0108] Optionally, audit archive records may be represented as: { "task_id": "T20260329-0847", "inst_chain": [ "I20260329-0847-1", "I20260329-0847-2" ], "rule_version": "v3.2.1", "events": [ {"type": "exception_detected", "inst_id": "I20260329-0847-1"}, {"type": "residual_cleaned", "inst_id": "I20260329-0847-1"}, {"type": "instance_destroyed", "inst_id": "I20260329-0847-1"}, {"type": "instance_rebuilt", "inst_id": "I20260329-0847-2"}, {"type": "task_succeeded", "inst_id": "I20260329-0847-2"} ], "final_status": "self_healed } The above methods support: tracing the complete task chain by task_id; tracing the instance replacement process by inst_id; calculating the self-healing success rate under different rules by rule_version; and calculating the cleanup completeness and residual rate by six types of residual objects. This has high practical value in operation and maintenance auditing and rule optimization.

[0109] In another specific embodiment two, corresponding Figure 6 and Figure 7 Simultaneously, 500 high-risk tasks are submitted, each bound to an independent, one-time temporary execution instance. Lock file pollution, cache pollution, and timeout exceptions are injected into some of these tasks.

[0110] The temporary instance management unit 103 adopts a task-level serial reconstruction control and a parallel cleanup mechanism for different task instances to ensure that: instance reconstruction for the same task is executed sequentially; instance cleanup and reconstruction between different tasks can be executed in parallel; the remnants of any abnormal instance do not propagate to other task instances; and temporary directories, credential sessions, and state contexts are not shared between different task instances.

[0111] In this embodiment, the task scheduling unit 102 creates one-time temporary execution instances for 500 tasks in batches according to the resource pool capacity. Each instance is assigned a unique inst_id and uniquely bound to the corresponding task_id. During execution, the exception determination unit 105 continuously collects the following statuses: whether the current instance has timed out, whether there are unreleased lock files, whether there is an accumulation of exception cache, whether there are unremoved mounts, whether there are uncleaned sessions or credentials, and whether there is pollution of environment variables or state files.

[0112] For instances where contamination risk is detected, the system immediately executes the following action chain: remove the instance from the formal result chain, freeze the instance's permission to write further results, trigger the cleanup of six types of residual objects, destroy the original instance after cleanup, create a new instance based on the original task identifier, re-inject the task into the new instance, and have the feedback processing unit uniformly summarize the failure information of the original instance and the success information of the new instance.

[0113] For example, for task T20260329-1301, its original instance I20260329-1301-1 suffers from cache pollution and lock file residue. After the system cleans up, it changes the instance status from "abnormal" to "destroyed" and creates a new instance I20260329-1301-2 to execute the same task.

[0114] Therefore, under high-concurrency conditions, the execution environments of each task are isolated from each other, the contamination of the original abnormal instance does not spread to other instances, and the self-healing action can occur in parallel without breaking the single-task closed loop. Under high concurrency conditions, a high recovery success rate and a low secondary anomaly rate can still be maintained.

[0115] Therefore, this application is particularly suitable for temporary task execution scenarios with high concurrency, strong isolation, and low tolerance for contamination.

[0116] In yet another specific embodiment three, corresponding to Figure 5 Exceptions do not always manifest as explicit crashes, timeouts, or error codes; instead, they may manifest as an unverifiable state. For example: the task execution agent does not return a result, but the process still exists; the result file has been generated, but it cannot be confirmed whether it has been completely written; a network connection interruption causes the execution state to be inconsistent with the return state; the container liveness probe is normal, but the application has entered a deadlock or false liveness state; or the session credentials have been refreshed, but it cannot be confirmed whether the old credentials are still valid.

[0117] In such scenarios, existing technologies often tend to continue attempting recovery within the original instance. However, this application preferably considers "unverifiable state" as one of the high-risk anomaly types and initiates the instance reconstruction path.

[0118] Specifically, the anomaly determination unit 105 can determine an instance as having an unconfirmed state based on any of the following conditions: the execution agent heartbeat exists but the result packet is missing, the main process is alive but the business status has not progressed for a long time, some result files exist but the verification fails, network backhaul is interrupted and it is impossible to confirm whether the task execution has been submitted to the final state, or there is a mutual exclusion conflict between status fields, such as the simultaneous existence of "success flag" and "anomaly flag".

[0119] Once the status is determined to be unconfirmable, the system executes the following process: the original instance is no longer allowed to continue writing the final result, the original instance is isolated, six types of residual objects are cleaned up, the original instance is destroyed, a new instance is created, the task is re-injected into the new instance for execution, and the return processing unit is used to retain the original unconfirmable status and the result of the new instance together.

[0120] Therefore, even if the root cause of failure cannot be accurately located from the original instance, potential contamination paths can be cut off by instance replacement, thereby improving the recovery effectiveness in high-risk scenarios.

[0121] To verify the technical effectiveness of the technical solution of this application, the preferred embodiments of this application were verified using the following three sets of test scenarios, each corresponding to the appendix of this application. Figure 5 The implementation process is shown.

[0122] First, the first set of test scenarios is a self-healing verification scenario for contamination exceeding the time limit, corresponding to the specific embodiment one and appendix of this application described above. Figure 5 The abnormal traffic routing process is shown. Specifically, in scenarios such as task execution timeout, residual lock files, and unreleased network connections, the system can trigger instance reconstruction paths and clean up residual objects associated with the abnormal instances. Testing showed that the cleanup of the six types of residual objects was effective, and no pollution inheritance was observed.

[0123] Secondly, the second set of test scenarios is a high-concurrency isolation self-healing verification scenario, corresponding to the above-described specific embodiment two and appendix of this application. Figure 6 The residual object cleanup association and attachment shown Figure 7 The instance lifecycle process is shown. Specifically, in a multi-threaded concurrent task execution scenario, the contamination from the abnormal instance does not spread to other task instances, and effective isolation is maintained between instances. The self-healing loop can execute stably in a concurrent environment. Testing has shown that the self-healing loop executes completely and stably in this scenario.

[0124] Then, the third set of test scenarios is the verification scenario of unconfirmed state anomaly, corresponding to the above-described specific embodiment three and appendix of this application. Figure 5The anomaly triage process is shown below. Specifically, in scenarios where the process is alive but the task result has not been returned, or the instance status is inconsistent or unconfirmed, the system can directly enter the instance reconstruction path, avoiding the use of the original instance execution chain based on an uncertain state and reducing the risk of secondary anomalies. Testing showed that the task recovery effect was stable, and no secondary anomalies occurred.

[0125] The quantitative results of the test performance in the above three test scenarios are as follows: The pollution inheritance rate was 0%; the overall residual rate was 0%; the secondary anomaly rate was 0%; the mission recovery success rate was 100%; the environmental cleanup integrity rate was 100%; and the self-healing closed-loop completion rate was 100%.

[0126] The above data comes from real system testing and corresponds to the technical solution of this application. It can characterize the technical effects of this application in terms of abnormal instance isolation, residual object cleanup, instance reconstruction and task recovery closed loop.

[0127] The task self-healing closed-loop control method and system described in this application have formed an operational engineering implementation scheme, which includes task execution logic, exception diversion logic, residual object cleanup logic, instance reconstruction logic, and two-layer self-healing closed-loop execution logic. The scheme can be deployed and verified, and the above-mentioned technical effects can be reproduced under test conditions.

[0128] Compared to existing technologies that rely on conventional retries, restoration of the original context, or single instance restarts, this application controls the task execution process and instance lifecycle in a coordinated manner, and classifies, manages, and rebuilds residual objects associated with abnormal instances. This effectively reduces the risk of contamination inheritance, minimizes secondary anomalies, and improves the stability and closed-loop integrity of task recovery, demonstrating good engineering applicability and technical effectiveness.

[0129] Those skilled in the art will understand that, without departing from the core ideas of this application, several modifications and substitutions can be made. For example: anomaly detection can be based on a rule engine, threshold engine, or machine learning model; one-time temporary execution instances can be deployed on a single machine, cluster, edge node, or hybrid cloud environment; the backhaul link can be based on a message bus, database records, log streams, or a combination thereof; the six types of residual objects can be further subdivided according to the actual execution carrier, but this will not affect the core solution of this application; audit archiving can be written to a database, object storage, log platform, or block-based evidence storage system. All the above modifications and substitutions should be considered to fall within the protection scope of this application.

[0130] This application also provides a task self-healing closed-loop control system. (Continue to refer to...) Figure 1a ,like Figure 1a As shown, the task self-healing closed-loop control system 100 of this application embodiment includes: The temporary instance management unit 103 is used to create a corresponding one-time temporary execution instance for the task to be executed when a task to be executed is received, and is also used to handle the one-time temporary execution instance and generate the handling result when an execution exception occurs in the task to be executed and the corresponding exception handling method is instance reconstruction, and to reconstruct a new one-time temporary execution instance for the task to be executed; The task execution agent unit 104 is used to load the task load of the task to be executed into the one-time temporary execution instance for execution when the one-time temporary execution instance is created, and to collect the execution status of the one-time temporary execution instance. It is also used to load the task load into the new one-time temporary execution instance for execution when the new one-time temporary execution instance is created, and to obtain the execution result. The exception determination unit 105 is used to determine whether the task to be executed has encountered an execution exception based on the execution status of the one-time temporary execution instance, and to determine the corresponding exception handling method if the task to be executed has encountered an execution exception. The feedback processing unit 106 is used to archive the self-healing process information in a closed loop, forming a two-layer self-healing closed loop. The self-healing process information includes the handling results and the execution results.

[0131] Each unit module of the above-described task self-healing closed-loop control system can execute the corresponding steps in the above method embodiments. Therefore, the details of each unit module will not be elaborated here; please refer to the description of the corresponding steps above for details. It should be noted that the above-described task self-healing closed-loop control system is embodied in the form of functional units. The term "unit" here can be implemented in software and / or hardware, without specific limitations. For example, a "unit" can be a software program, hardware circuit, or a combination of both that implements the above functions. Hardware circuits may include application-specific integrated circuits (ASICs), electronic circuits, processors (e.g., shared processors, proprietary processors, or group processors) and memory for executing one or more software or firmware programs, integrated logic circuits, and / or other suitable components that support the described functions.

[0132] Therefore, the units of the various examples described in the embodiments of this application can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the embodiments of this application.

[0133] This application also provides an electronic device. Figure 8 This is a schematic diagram of the structure of an electronic device provided in one embodiment of this application. Figure 8 As shown, the electronic device 800 includes: at least one processor 810 ( Figure 8 The diagram shows only one processor, a memory 820, and a computer program 821 stored in the memory 820 and executable on at least one processor 810. When the processor 810 executes the computer program 821, it implements the steps of the above-described task self-healing closed-loop control method.

[0134] Figure 8 This is merely an example of an electronic device and does not constitute a limitation on the device. It may include more components than illustrated, or combine certain components, or different components. The processor may be a Central Processing Unit (CPU), but it can also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor.

[0135] It should be noted that the information interaction and execution process between the above-mentioned devices / modules are based on the same concept as the method embodiments of this application. For details on their specific functions and technical effects, please refer to the method embodiments section, and they will not be repeated here.

[0136] Those skilled in the art will understand that, for the sake of convenience and brevity, the above-described division of functional modules is merely an example. In practical applications, the functions described above can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. The functional modules in the embodiments can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module. The integrated modules can be implemented in hardware or as software functional modules. Furthermore, the specific names of the functional modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0137] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, can implement the steps in the above-described task self-healing closed-loop control method.

[0138] This application provides a computer program product that, when run on an electronic device, enables the electronic device to perform the steps in the above-described task self-healing closed-loop control method.

[0139] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A task self-healing closed-loop control method, characterized in that, include: When a task is received, a corresponding one-time temporary execution instance is created for that task. The task load of the task to be executed is loaded into the one-time temporary execution instance for execution, and the execution status of the one-time temporary execution instance is collected; Based on the execution status, determine whether the task to be executed has encountered an execution exception, and if it is determined that the task to be executed has encountered an execution exception, determine the corresponding exception handling method. When the exception handling method is instance reconstruction, the one-time temporary execution instance is processed and a processing result is generated, and a new one-time temporary execution instance is reconstructed for the task to be executed; The task load is loaded into the new one-time temporary execution instance for execution, and the execution result is obtained. The self-healing process information is archived in a closed loop to form a two-layer self-healing closed loop, wherein the self-healing process information includes the handling result and the execution result.

2. The task self-healing closed-loop control method as described in claim 1, characterized in that, When it is determined that the execution exception has occurred in the task to be executed, the corresponding exception handling method is determined, including: Based on the type of execution exception, the risk of pollution inheritance, and the verifiability of the execution status, the execution exception is classified and path-based to determine the corresponding exception handling method.

3. The task self-healing closed-loop control method as described in claim 2, characterized in that, The step of classifying and routing the execution exceptions to determine the corresponding exception handling methods includes: If it is determined that the execution exception can be recovered within the current instance and there is no risk of pollution inheritance, a lightweight recovery operation is performed. When it is determined that the execution exception has the risk of pollution inheritance or the execution status is unconfirmed, an instance reconstruction operation is performed. When the execution exception is determined to meet the preset conditions, the execution exception is reported.

4. The task self-healing closed-loop control method as described in any one of claims 1-3, characterized in that, The processing of the one-time temporary execution instance includes performing at least one of the following operations: Isolation and control are applied to the one-time temporary execution instance; Perform a full cleanup of the execution environment of the one-time temporary execution instance; The one-time temporary execution instance is terminated and destroyed.

5. The task self-healing closed-loop control method as described in claim 4, characterized in that, The isolation and control measures for the one-time temporary execution instance include: Prevent the one-time temporary execution instance from outputting the valid execution result of the task.

6. The task self-healing closed-loop control method as described in claim 4, characterized in that, The process of performing a full cleanup of the execution environment of the one-time temporary execution instance includes: The runtime residual objects generated within the one-time temporary execution instance are cleared, wherein the runtime residual objects include at least one of file-type residuals, process-type residuals, mount-type residuals, cache-type residuals, session credential-type residuals, and context state-type residuals.

7. The task self-healing closed-loop control method as described in claim 6, characterized in that, The process of clearing runtime residual objects generated within the one-time temporary execution instance includes performing at least one of the following operations: Delete temporary directories, lock files, or script copies to clean up any remaining files of that type. Terminate non-primary processes, orphan processes, or zombie processes to clean up process class remnants; Remove mount points, release temporary volumes, or disconnect unreleased connections to clear the mount-related remnants; Clear the execution cache, session cache, or intermediate state cache to clean up any cache remnants. Delete temporary tokens, authentication files, or expired sessions to clean up residual session credentials. Reset environment variables, delete state files, or restore temporary configurations to clean up residual context state classes.

8. The task self-healing closed-loop control method as described in any one of claims 1-3, characterized in that, The closed-loop archiving of information throughout the self-healing process includes: The self-healing process information is uniformly aggregated and associated. A traceable archive index is constructed based on the task identifier and instance identifier chain, and the self-healing full-process information is stored and the process is verified.

9. The task self-healing closed-loop control method as described in any one of claims 1-3, characterized in that, The method further includes: The self-healing strategy is read, and based on the self-healing strategy, the determination of the exception handling method, the scope of the one-time temporary execution instance, and the execution rules for reconstructing a new one-time temporary execution instance are controlled.

10. A task self-healing closed-loop control system, characterized in that, include: The temporary instance management unit is used to create a corresponding one-time temporary execution instance for the task to be executed when a task to be executed is received, and is also used to perform processing on the one-time temporary execution instance and generate processing results when the task to be executed encounters an execution exception and the corresponding exception handling method is instance reconstruction, and to reconstruct a new one-time temporary execution instance for the task to be executed; The task execution agent unit is used to load the task load of the task to be executed into the one-time temporary execution instance for execution when the one-time temporary execution instance is created, and to collect the execution status of the one-time temporary execution instance. It is also used to load the task load into the new one-time temporary execution instance for execution when the new one-time temporary execution instance is created, and to obtain the execution result. An exception determination unit is used to determine whether the task to be executed has encountered an execution exception based on the execution status of the one-time temporary execution instance, and to determine the corresponding exception handling method if the execution exception is found to have occurred in the task to be executed. The feedback processing unit is used to archive the self-healing process information in a closed loop, forming a two-layer self-healing closed loop, wherein the self-healing process information includes the handling result and the execution result.

Images