Father-child plan associated emergency plan system, father-child plan associated emergency plan execution method, equipment and computer program product

Abstract

The invention discloses a father-child plan associated emergency plan system, a father-child plan associated emergency plan execution method, equipment and a computer program product, and the system comprises an interaction layer which is used for receiving operation instructions of a user, including a plan creation and configuration instruction and a plan execution instruction; the control layer is used for responding to a plan creation and configuration instruction, creating and configuring a sub-plan execution component in an atomization mode, generating a configured sub-plan and nesting the sub-plan into a corresponding parent plan, and generating an emergency plan task associated with the parent plan and the sub-plan; and the execution layer is used for responding to the plan execution instruction, calling a plan execution tool to remotely execute the emergency plan task based on the distributed task queue, and monitoring the execution state of each sub-plan execution component in the emergency plan task. According to the emergency plan system, atomization packaging, multi-stage nested arrangement and remote automatic execution of the plan are realized, and the flexibility, maintainability and execution reliability of the emergency plan system are improved.

Description

Technical Field

[0001] This application relates to the field of financial information technology, and in particular to an emergency response system with parent-child contingency plans linked together, an emergency response plan execution method, equipment, and computer program product with parent-child contingency plans linked together. Background Technology

[0002] With the rapid development of fintech, internet finance platforms, core banking systems, and large-scale operation and maintenance platforms have placed extremely high demands on system high availability and business continuity. When faced with unexpected scenarios such as sudden failures, network outages, and data center crashes, enterprises need to rely on contingency plans (hereinafter referred to as "contingency plans") to quickly complete fault isolation, service switching, and disaster recovery operations to minimize business interruption time.

[0003] Currently, most enterprises' emergency management systems still adopt the traditional linear contingency plan model, where each plan is an independent, flat operational process containing a series of sequentially executed manual or automated steps. This type of system has revealed numerous problems in practical applications and struggles to meet the demands of efficient emergency response under modern complex distributed architectures.

[0004] First, the contingency plans lack atomic reusability. In multiple similar disaster recovery failover scenarios (such as database master-slave failover between different business systems), there are often many repetitive operation steps, such as "stopping application services," "modifying configuration center parameters," and "starting the target instance." Existing systems cannot abstract these common processes into reusable functional modules, forcing operations and maintenance personnel to write almost identical contingency plans from scratch for each new scenario, resulting in wasted human resources and template redundancy. More seriously, when a common step needs to be modified (such as changing script commands or adjusting timeout thresholds), all relevant contingency plans must be opened and updated synchronously, which is prone to omissions and brings maintenance risks.

[0005] Secondly, existing orchestration systems only support simple linear connections or serial workflows. Although they implement workflow design based on graphical interfaces and generate workflow diagrams through drag-and-drop element generation, their essence remains limited to a single-layer, linear task chain structure. This approach only supports direct connections between two work steps and cannot embed a complete contingency plan as a functional unit into another higher-level process; in other words, it lacks the ability for "contingency plan nesting." This forces complex emergency processes to be implemented by lengthening a single contingency plan, resulting in a bloated plan structure, chaotic logic, and poor readability and maintainability.

[0006] Secondly, multi-level call relationships are prone to circular dependencies. When attempting to build a parent-child relationship system of pre-defined plans, without an effective dependency management mechanism, a situation may arise where the parent plan calls the child plan A, and the child plan A in turn calls the parent plan, leading to infinite recursive calls, causing system execution deadlocks or task backlog. Existing technologies do not provide pre-emptive detection and interception methods for such call loops, posing a serious operational security risk.

[0007] Furthermore, the system lacks state tracking capabilities during nested execution. When executing a complex emergency process containing sub-plans, users cannot monitor the progress and status of each step within the sub-plans in real time. Traditional systems typically only provide a final result of "success" or "failure," lacking transparency regarding intermediate processes, which makes troubleshooting difficult and impacts the efficiency of emergency decision-making.

[0008] Finally, there is insufficient support for collaborative editing of long contingency plans. Large disaster recovery and switchover plans involving hundreds of steps typically require the joint participation of multiple team members in writing and reviewing them. However, existing systems generally employ a "lock-in" mechanism, allowing only one person to modify and save the plan during editing, preventing other personnel from developing in parallel and severely impacting collaboration efficiency.

[0009] In summary, existing emergency response system systems with parent-child contingency plans have significant shortcomings in terms of reusability, structure, security, observability, and collaboration, making them unsuitable for the requirements of financial-grade systems for agile response, stability, reliability, and engineering management. Summary of the Invention

[0010] To address at least one of the aforementioned technical problems, embodiments of this application provide an emergency response plan system with parent-child plan association, an emergency response plan execution method, device, and computer program product with parent-child plan association, to achieve an emergency response plan scheme that supports multi-level nesting and parent-child association.

[0011] The embodiments of this application adopt the following technical solutions:

[0012] In a first aspect, embodiments of this application provide an emergency response plan system with parent-child plan association, the parent-child plan association emergency response plan system comprising:

[0013] The interaction layer is used to receive user operation instructions, which include pre-plan creation and configuration instructions as well as pre-plan execution instructions;

[0014] The control layer is used to respond to the user's instructions for creating and configuring contingency plans, to create and configure sub-contingency plan execution components in an atomic manner, to generate configured sub-contingency plans, and to nest the configured sub-contingency plans into the corresponding parent contingency plans, thereby generating emergency contingency plan tasks associated with the parent and child contingency plans.

[0015] The execution layer is used to respond to the user's contingency plan execution command, and based on the distributed task queue, to call the contingency plan execution tool to remotely execute the corresponding parent-child contingency plan tasks, and to monitor the execution status of each sub-contingency plan execution component in the parent-child contingency plan tasks.

[0016] Optionally, the interaction layer is further used for:

[0017] Provide an interactive interface;

[0018] The user's operation instructions are received through the interactive interface;

[0019] This displays the execution status of each sub-plan execution component in the emergency plan task associated with the parent and child plans.

[0020] Optionally, the control layer is further configured to:

[0021] Different execution templates are set according to the task types in the business scenario, and they are encapsulated into multiple different execution components in an atomic manner and stored in the data structure of the contingency plan template. The execution components include sub-contingency plan execution components.

[0022] In response to the user's pre-plan creation and configuration instructions, determine and configure the sub-pre-plan execution components selected by the user.

[0023] Optionally, the contingency plan creation and configuration instructions include the execution method of the sub-contingency plan components, and the control layer is further used for:

[0024] In response to the user's pre-plan creation and configuration instructions, the execution mode of the sub-pre-plan execution component selected by the user is configured, wherein the execution mode is synchronous execution or asynchronous execution.

[0025] Optionally, the execution layer is further configured to:

[0026] Determine the execution method of each sub-plan execution component included in the emergency plan task associated with the parent and child plans;

[0027] If the execution mode of the sub-plan execution component is synchronous, the parent plan will pause execution until the sub-plan execution component returns the final execution result;

[0028] If the execution mode of the sub-plan execution component is asynchronous, the parent plan will trigger the execution of the sub-plan execution component and continue to execute subsequent steps. The sub-plan execution component runs independently in the distributed task queue.

[0029] Optionally, the control layer is further configured to:

[0030] In response to the user's plan creation and configuration instructions, when configuring the sub-plan execution component, a binding relationship is established between the sub-plan execution component and the user-selected sub-plan execution component by referencing the name of the sub-plan execution component. The binding relationship is stored in the data structure of the plan template in the form of a foreign key.

[0031] Optionally, the control layer is further configured to:

[0032] When a user creates or modifies a contingency plan template, script execution component, or initiates a contingency plan execution command, the approver information corresponding to the emergency plan task can be configured by calling the approval tool.

[0033] Secondly, embodiments of this application also provide a method for executing an emergency plan that links parent and child emergency plans, the method comprising:

[0034] Receive user operation instructions, which include plan creation and configuration instructions and plan execution instructions;

[0035] In response to the user's instructions for creating and configuring contingency plans, sub-contingency plan execution components are created and configured in an atomic manner to generate configured sub-contingency plans, and the configured sub-contingency plans are nested into the corresponding parent contingency plans to generate emergency contingency plan tasks associated with the parent and child contingency plans.

[0036] In response to the user's contingency plan execution command, based on a distributed task queue, the contingency plan execution tool is invoked to remotely execute the corresponding parent-child contingency plan tasks, and to monitor the execution status of each sub-contingency plan execution component in the parent-child contingency plan tasks.

[0037] Thirdly, embodiments of this application also provide an apparatus, comprising:

[0038] A processor; and a memory configured to store computer-executable instructions, which, when executed, cause the processor to perform the aforementioned contingency plan execution method associated with the parent-child contingency plan.

[0039] Fourthly, embodiments of this application also provide a computer program product, including a computer program / instruction, which, when executed by a processor, implements the aforementioned emergency plan execution method for the parent-child contingency plan association.

[0040] The above-mentioned at least one technical solution adopted in the embodiments of this application can achieve the following beneficial effects: The emergency plan system of parent-child plan association in the embodiments of this application includes: an interaction layer, used to receive user operation instructions, the operation instructions including plan creation and configuration instructions and plan execution instructions; a control layer, used to respond to the user's plan creation and configuration instructions, to atomically create and configure sub-plan execution components, generate configured sub-plans, and nest the configured sub-plans into the corresponding parent plan to generate emergency plan tasks associated with parent and child plans; and an execution layer, used to respond to the user's plan execution instructions, to remotely execute the corresponding emergency plan tasks associated with parent and child plans by calling a plan execution tool based on a distributed task queue, and to monitor the execution status of each sub-plan execution component in the emergency plan tasks associated with parent and child plans. The emergency response system with parent-child plan association in this application embodiment constructs a three-level architecture of interaction layer, control layer and execution layer working together, realizing atomic encapsulation of plans, multi-level nested orchestration and remote automated execution, supporting process reuse, status tracking and safe scheduling in complex emergency scenarios, and improving the flexibility, maintainability and execution reliability of the emergency response system. Attached Figure Description

[0041] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments of this application and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0042] Figure 1 This is a schematic diagram of the structure of an emergency response plan system with parent-child plan association in an embodiment of this application;

[0043] Figure 2 This is a flowchart illustrating a synchronous execution method in an embodiment of this application;

[0044] Figure 3 This is a flowchart illustrating an asynchronous execution method in an embodiment of this application;

[0045] Figure 4 This is a flowchart illustrating an emergency plan execution method for parent-child plan association in an embodiment of this application;

[0046] Figure 5 This is a schematic diagram of the structure of a device according to an embodiment of this application. Detailed Implementation

[0047] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0048] The technical solutions provided by the various embodiments of this application are described in detail below with reference to the accompanying drawings.

[0049] This application provides an emergency response plan system with parent-child plan association, such as... Figure 1 As shown, a structural diagram of an emergency response plan system with parent-child plan association is provided in an embodiment of this application. The emergency response plan system with parent-child plan association includes:

[0050] The interaction layer is used to receive user operation instructions, which include pre-plan creation and configuration instructions as well as pre-plan execution instructions;

[0051] The control layer is used to respond to the user's instructions for creating and configuring contingency plans, to create and configure sub-contingency plan execution components in an atomic manner, to generate configured sub-contingency plans, and to nest the configured sub-contingency plans into the corresponding parent contingency plans, thereby generating emergency contingency plan tasks associated with the parent and child contingency plans.

[0052] The execution layer is used to respond to the user's contingency plan execution command, and based on the distributed task queue, to call the contingency plan execution tool to remotely execute the corresponding parent-child contingency plan tasks, and to monitor the execution status of each sub-contingency plan execution component in the parent-child contingency plan tasks.

[0053] In the emergency response plan system with parent-child plan association provided in this application embodiment, the interaction layer serves as the user operation entry point. It receives user operation instructions through a graphical interface, including various instructions such as plan creation and configuration instructions and plan execution instructions. Users can add various components, especially the "sub-plan execution component," in the process canvas by dragging and dropping, and configure its associated target sub-plan template and execution parameters to complete the arrangement of plan logic.

[0054] The control layer receives contingency plan creation and configuration instructions from the interaction layer and atomically processes the execution components of sub-plans. A complete emergency operation process is encapsulated as an independent functional unit, bound to the parent plan only by name reference, without copying its internal steps. Based on this, the control layer integrates the configured sub-plans into the task flow of the parent plan in a nested manner, forming a hierarchical emergency plan structure and generating corresponding parent-child plan related emergency plan tasks, achieving modular organization and reuse among plans.

[0055] After receiving a user-initiated contingency plan execution command, the execution layer can leverage distributed task queue mechanisms such as Celery to break down the associated parent-child contingency plan tasks into multiple schedulable subtasks. It then invokes contingency plan execution tools like Ansible to execute the specific operations item by item on a remote server. Simultaneously, the execution layer continuously monitors the running status of each sub-contingency plan execution component within the task, obtaining real-time execution progress, result logs, and exception information for each sub-contingency plan through message channels, and feeding this information upwards for status display and process control.

[0056] The emergency response system with parent-child plan association in this application embodiment constructs a three-level architecture of interaction layer, control layer and execution layer working together, realizing atomic encapsulation of plans, multi-level nested orchestration and remote automated execution, supporting process reuse, status tracking and safe scheduling in complex emergency scenarios, and improving the flexibility, maintainability and execution reliability of the emergency response system.

[0057] In some embodiments of this application, the interaction layer is further configured to: provide an interactive interface; receive operation instructions from the user through the interactive interface; and display the execution status of each sub-plan execution component in the emergency plan task associated with the parent-child plan.

[0058] The interaction layer utilizes the Vue front-end framework to build a graphical console, providing a visual interface for contingency plan orchestration and execution monitoring, and integrates with Nginx to route and distribute user requests. This interface receives user commands for creating, configuring, and executing contingency plans. During plan execution, it dynamically displays the real-time execution status of each child contingency plan execution component within the parent-child contingency plan's associated tasks. Specifically, in the parent contingency plan flowchart, each child contingency plan execution component is presented as an independent node, and its display status is dynamically updated based on information reported from the underlying layer. This status can include, for example, "Pending Execution," "Executing," "Success," or "Failure." Clicking on a component allows users to further view detailed execution logs and progress information for each step within the called child contingency plan, thus achieving a hierarchical status display from the parent to the child process.

[0059] This application embodiment achieves complete visualization of the execution status of multi-level contingency plans through a graphical interface, solving the problem of invisible nested execution status in traditional systems. This enables operation and maintenance personnel to grasp the operational progress and abnormal situations of sub-contingency plans in real time, improving the transparency and controllability of the emergency response process.

[0060] In some embodiments of this application, the control layer is further configured to: set different execution templates according to the task type in the business scenario, encapsulate them into multiple different execution components in an atomic manner, and store them in the data structure of the plan template, wherein the execution components include sub-plan execution components; and in response to the user's plan creation and configuration instructions, determine the sub-plan execution component selected by the user and configure it.

[0061] Based on common emergency task types in production environments, multiple standardized execution templates are predefined and encapsulated into functionally independent execution components in an atomic manner. These execution components cover typical operational units in emergency response, such as script execution, API calls, database high-availability switching, configuration detection, application start / stop, and sub-plan invocation. Each component corresponds to specific task logic and parameter structure. The control layer treats these execution components as reusable building blocks and manages and stores them uniformly within the data structure of the plan templates.

[0062] When a user initiates a plan creation or configuration request through the interaction layer, the control layer receives the instruction, parses the target component type selected by the user from the component library, such as binding and configuring the "sub-plan execution component", including associating the specific sub-plan template name, setting the synchronous or asynchronous execution mode, filling in the necessary input parameters, etc., and finally completing the instantiation and integration of the component in the parent plan context.

[0063] In addition, each of the above task components can have a custom pop-up window, and users can define the parameters and other configurations required for the actual business scenario according to the content of the pop-up window.

[0064] This application's embodiments abstract common emergency tasks into standardized, reusable atomic execution components, enabling modular management and flexible combination of contingency plan construction units, significantly improving the standardization and efficiency of contingency plan design. At the same time, by storing various component configuration information based on a unified data structure, it supports rapid retrieval and dynamic invocation, providing basic support for the efficient orchestration and cross-scenario reuse of complex emergency processes.

[0065] In some embodiments of this application, the plan creation and configuration instruction includes the execution mode of the sub-plan component, and the control layer is further configured to: in response to the user's plan creation and configuration instruction, configure the execution mode of the sub-plan execution component selected by the user, wherein the execution mode is synchronous execution or asynchronous execution.

[0066] When responding to user commands for creating and configuring plans, the control layer provides configuration functionality for the execution mode of the selected sub-plan execution components. After selecting a sub-plan execution component in the graphical interface, the user can set its execution mode to "synchronous execution" or "asynchronous execution." When configured for synchronous execution, the control layer will block the parent plan's process during subsequent task scheduling, waiting for the sub-plan to complete and return to its final state before continuing to execute subsequent components. When configured for asynchronous execution, the control layer only triggers the sub-plan's start command without waiting for its execution result; the parent plan will continue to execute other subsequent components, achieving non-blocking parallel processing.

[0067] Furthermore, since the sub-plan execution component has the same process node attributes as other types of components (such as script execution, API calls, etc.), users can connect it with the preceding and following components through graphical connections, thereby constructing various execution logic structures such as serial, parallel, or conditional branching, forming a flexible multi-level nested process.

[0068] This application embodiment supports synchronous and asynchronous dual-mode configuration of sub-plan execution components and combines graphical process orchestration capabilities to achieve diversified execution order control between parent and child plans and between components. This significantly improves the execution freedom and process design flexibility of emergency plans and meets the differentiated needs for timing control, parallel efficiency and dependency management in different business scenarios.

[0069] In some embodiments of this application, the execution layer is further configured to: determine the execution mode of each sub-plan execution component included in the emergency plan task associated with the parent and child plans; if the execution mode of the sub-plan execution component is synchronous execution, the parent plan suspends execution until the sub-plan execution component returns the final execution result; if the execution mode of the sub-plan execution component is asynchronous execution, the parent plan triggers the execution of the sub-plan execution component and continues to execute subsequent steps, and the sub-plan execution component runs independently in a distributed task queue.

[0070] Combination Figure 2 and Figure 3 The present application provides flowcharts for a synchronous execution method and an asynchronous execution method, respectively.

[0071] For sub-plan execution components using the "synchronous execution" method, the execution layer retains the current execution context of the parent plan during scheduling and suspends the execution of subsequent components of the parent plan after starting the sub-plan task. The system continuously monitors the task status of the sub-plan, and only resumes the parent plan process and decides whether to continue executing subsequent steps after receiving its final result (success, failure, or timeout). For sub-plan execution components using the "asynchronous execution" method, the execution layer immediately releases the blockage on the parent plan after triggering its task submission to the distributed task queue, allowing the parent plan to continue executing subsequent components without waiting, achieving non-blocking concurrent processing.

[0072] like Figure 2 and Figure 3 As shown, regardless of synchronous or asynchronous mode, the sub-plan is initiated by the task scheduler through the same technical path as the parent plan, namely through the control layer issuing, the execution layer receiving, the task queue distributing, and the remote tool executing. The dotted line in the figure indicates that the sub-plan reuses the complete start-up link of the parent plan, reflecting its execution capability as an independent schedulable unit.

[0073] This application embodiment achieves flexible control over the invocation process of child plans by dynamically distinguishing between synchronous and asynchronous execution strategies based on configuration. It supports both order assurance in scenarios with strong dependencies and parallel process advancement in scenarios with high concurrency. Combined with the capabilities of distributed task queues, it effectively improves the response efficiency and resource utilization of emergency execution processes, and enhances the operational controllability and adaptability of complex plans.

[0074] In some embodiments of this application, the control layer is further configured to: in response to the user's plan creation and configuration instructions, when configuring the sub-plan execution component, establish a binding relationship between the sub-plan execution component and the user-selected sub-plan execution component by referencing the name of the sub-plan execution component, wherein the binding relationship is stored in the data structure of the plan template in the form of a foreign key.

[0075] When responding to user commands for creating and configuring plans, the control layer employs a name-based referencing mechanism to bind sub-plans to their corresponding configuration components. Specifically, when a user selects a sub-plan as the object to be invoked in the graphical interface, the system writes the unique name of that sub-plan into the configuration field of the corresponding component in the current parent plan's workflow. This name is stored as a foreign key in the plan template's data structure to identify the specific sub-plan template resource it is associated with. This binding method does not involve content copying; it only establishes a logical association. Therefore, the same sub-plan can be referenced simultaneously by multiple different parent plans through its name.

[0076] Furthermore, during subsequent maintenance, if the sub-plan template undergoes internal modifications (such as step adjustments or parameter updates), since the reference in the parent plan still points to the original name, the control layer automatically loads the latest version of the sub-plan definition during execution, without requiring reconfiguration or saving of the parent plan, thus achieving transparent transmission of changes.

[0077] This application embodiment establishes a logical binding relationship between parent and child plans by using foreign keys in the form of names. This enables independent maintenance of child plans and cross-plan reuse. It supports the flexible arrangement of multiple different child plans in a parent plan and ensures that changes to child plans can be seamlessly applied to all reference scenarios. This avoids the problems of repeated modifications and version inconsistencies, and significantly improves the maintainability, consistency and modularity of the plan system.

[0078] In some embodiments of this application, the control layer is further configured to: configure the approver information corresponding to the emergency plan task by calling the approval tool when the user creates or modifies the plan template, script execution component, or initiates the plan execution instruction.

[0079] When users perform key operations such as creating or modifying contingency plan templates, defining and configuring script execution components, and initiating contingency plan execution commands, this application embodiment also provides an interface for configuring approver information. After the user completes the relevant operations and selects the corresponding approver, the control layer encapsulates the operation type (e.g., "template creation," "script modification," or "contingency plan execution"), the operation subject, the initiator's identity, and the selected approver's identifier into an approval task. It then calls the embedded or integrated approval tool service to write the task into the approval process queue. After the approval task is generated, the system displays the pending items and current processing progress to the approver and initiator respectively in the approval tool menu of the operation and maintenance platform. The approver can view the task details to determine whether to agree to execution, and clicking the "Approve" button triggers an update to the approval status; the initiator can track the approval process in real time. Only after the approval status is marked as "Approved" is the corresponding operation released to the next stage (e.g., saving configuration or starting execution), thereby achieving process-oriented control of high-risk operations.

[0080] This application embodiment integrates approval functions at the control layer, incorporating key steps such as contingency plan creation, script definition, and execution initiation into a standardized approval process. This enables pre-approval and access control of emergency operations, effectively preventing risks of misoperation and unauthorized execution, and improving the standardization, security, and traceability of emergency plan management.

[0081] In summary, the key features of the parent-child contingency plan association system of this application are as follows:

[0082] (1) Contingency plan native atomic architecture

[0083] 1) All pre-plans automatically have atomicity after creation and can be nested by any parent pre-plan.

[0084] This application was designed from the outset with the core concept of "contingency plan as component": each contingency plan, once created, inherently possesses the attributes of an atomic functional unit without additional encapsulation or transformation. This means that each contingency plan can serve as an independent, complete, and indivisible emergency operation module, directly functioning as a "sub-contingency plan execution component" that can be called and nested by other parent contingency plans. For example, once a "database switchover contingency plan" is created, it can be repeatedly referenced by multiple high-level processes such as the "core system disaster recovery contingency plan" and the "channel service switchover contingency plan," achieving cross-scenario reuse.

[0085] 2) Achieve standardized calls through unified Django control.

[0086] The atomic behavior of all contingency plans is uniformly managed and scheduled by the Django framework in the control layer. Django provides a unified API interface to handle contingency plan call requests, including parameter parsing, permission verification, task generation, and status feedback. Regardless of which parent contingency plan initiates the call, the child contingency plan is instantiated and started through the same control logic, ensuring consistency and standardization in the call process. This centralized control mechanism avoids behavioral differences caused by multi-source calls, improving the stability and maintainability of the system.

[0087] Unlike existing technologies that require manually "packaging" processes into components, this application achieves native built-in atomicity capabilities, enabling all plans to inherently support nested reuse, greatly reducing the barrier to entry and development costs.

[0088] (2) Lightweight nested relationship management

[0089] 1) Specifying the type as sub_plan in the notification establishes a parent-child relationship.

[0090] This application uses a minimalist approach to define parent-child plan relationships: when a user adds a component to a parent plan and sets its type to "sub_plan", the system recognizes that component as a child plan call node. Subsequently, only the name of the target child plan needs to be configured to complete the logical binding. The entire process requires no complex configuration files or explicit dependency declarations; the nested execution mechanism is triggered solely by the type identifier, significantly simplifying orchestration operations.

[0091] 2) The database only stores the preliminary structure and does not store the two-level relationships.

[0092] The system further optimizes data storage by not explicitly maintaining "parent-child" relationship tables or hierarchical relationship graphs in the database. Each plan template independently stores its process structure and component configuration, while the parent-child relationship is dynamically resolved at runtime, temporarily constructed through the "sub_plan" type in the component and the names of the child plans it references. This decoupled design avoids relationship synchronization problems caused by frequent modifications and also reduces the complexity of metadata management.

[0093] By using a "type-driven + runtime resolution" approach, lightweight modeling of parent-child relationships is achieved, which ensures the flexibility of nested functions while avoiding the data consistency burden and expansion limitations caused by strong associations in traditional solutions.

[0094] The emergency response system with parent-child contingency plans linked in this application has achieved at least the following technical effects:

[0095] (1) Hot-swappable sub-plan execution component: Some fixed plan steps are made into sub-plans, which effectively reduces the redundancy of the plan and improves the reuse rate.

[0096] By abstracting common and stable emergency operation processes (such as "GaussDB master-slave switchover" and "Nacos service restart") into independent sub-plan templates and providing them as atomic components for multiple parent plans to call, "plug-and-play" functionality is achieved. When multiple business scenarios involve the same handling logic, there is no need to repeatedly write the same steps; integration can be completed simply by adding the corresponding sub-plan execution component to the parent plan. This modular design significantly reduces the number of plans and maintenance costs, improves the reusability efficiency of common capabilities, and avoids the template bloat problem caused by process duplication.

[0097] (2) High degree of freedom in execution: The plan can be executed in parallel through graphical connection, and the sub-plans can be freely selected to be executed synchronously or asynchronously, so the plan execution has a high degree of freedom.

[0098] This application allows users to define the execution order between components via connectors in a graphical orchestration interface, constructing complex processes with serial, parallel, or branching structures. Specifically, sub-plans, as a special type of component, can be flexibly configured to execute synchronously or asynchronously. This mechanism provides emergency plans with greater scheduling flexibility, adapting to the different needs of disaster recovery scenarios regarding execution pace and resource utilization.

[0099] (3) Full process tracking: In addition to displaying the execution status of the parent plan, the visualization interface can also display the execution status of the sub-plans in detail.

[0100] During execution, the system not only provides feedback on the overall status of the parent plan, but also collects and aggregates the execution progress, result logs, and exception information of each step within each sub-plan in real time through a distributed task reporting mechanism. This status data is correlated through a unified execution context and presented hierarchically on a graphical interface, allowing users to click on any sub-plan execution component to view its internal operational details. This capability addresses the pain point of "invisible nested execution" in traditional systems, achieving end-to-end observability from the top-level process to the bottom-level actions, facilitating rapid fault location and assessment of response progress.

[0101] (4) The editing of the plans is independent of each other: the existing plan can only be edited in one plan and multiple people cannot participate, otherwise the reading and writing relationship will be destroyed. In this application, the sub-plans and parent plans, and the sub-plans and sub-plans are completely independent. Multiple people can modify different sub-plans, which greatly improves efficiency.

[0102] This application adopts an architecture design of "foreign key reference + independent storage." Each sub-plan template exists as an independent record in the database, and the parent plan is only bound to it by name, without content copying. Therefore, multiple users can simultaneously edit different sub-plans without file lock conflicts or data overwriting risks. Furthermore, modifications to the parent plan do not affect the sub-plan templates it references. This mechanism breaks the traditional "entire plan locking" limitation, supports parallel development and collaborative maintenance by teams, and significantly improves the efficiency of writing and iterating large-scale plans.

[0103] (5) Achieve full-process coverage of pre-approval, in-process inspection, and post-audit.

[0104] The system introduces an approval control mechanism at key operational nodes, covering the entire process from contingency plan creation, script definition, template modification, and contingency plan execution initiation. Each change or execution request requires a designated approver, and the approval task is automatically pushed to the unified approval menu of the operations and maintenance platform. Authorized personnel must review and confirm online before proceeding to the next stage. All operations are recorded and traced, including the operator, time, content changes, and approval history, forming a complete audit log. This mechanism achieves closed-loop management of emergency operations, including pre-operation compliance review, in-process status control, and post-operation traceability, effectively preventing the risks of misoperation and unauthorized access, and meeting the security and compliance requirements of financial-grade systems.

[0105] In summary, this application comprehensively improves the engineering level of the emergency response system from multiple dimensions such as reusability, execution flexibility, status visibility, collaboration efficiency, and security management, and constructs an intelligent emergency management system suitable for high-availability scenarios.

[0106] This application also provides a method for executing emergency plans that link parent and child plans, such as... Figure 4The diagram illustrates a flowchart of an emergency response plan execution method for parent-child plan association, as shown in this application embodiment. The method includes the following steps S410 to S430:

[0107] Step S410: Receive user operation instructions, including plan creation and configuration instructions and plan execution instructions;

[0108] Step S420: In response to the user's plan creation and configuration instructions, create and configure the sub-plan execution component in an atomic manner, generate the configured sub-plan, and nest the configured sub-plan into the corresponding parent plan to generate the emergency plan task associated with the parent and child plans.

[0109] Step S430: In response to the user's contingency plan execution command, based on the distributed task queue, the contingency plan execution tool is invoked to remotely execute the corresponding parent-child contingency plan tasks, and to monitor the execution status of each sub-contingency plan execution component in the parent-child contingency plan tasks.

[0110] In some embodiments of this application, receiving user operation instructions includes: providing an interactive interface; receiving the user operation instructions through the interactive interface; the emergency plan execution method associated with parent and child plans further includes: displaying the execution status of each sub-plan execution component in the emergency plan task associated with parent and child plans.

[0111] In some embodiments of this application, the step of creating and configuring sub-plan execution components in an atomic manner in response to the user's plan creation and configuration instructions, and generating configured sub-plans, includes: setting different execution templates according to the task types in the business scenario, encapsulating them in an atomic manner into multiple different execution components, and storing them in the plan template data structure, wherein the execution components include sub-plan execution components; and determining and configuring the sub-plan execution components selected by the user in response to the user's plan creation and configuration instructions.

[0112] In some embodiments of this application, the plan creation and configuration instruction includes the execution mode of the sub-plan component. The step of creating and configuring the sub-plan execution component in an atomic manner in response to the user's plan creation and configuration instruction to generate the configured sub-plan includes: in response to the user's plan creation and configuration instruction, configuring the execution mode of the sub-plan execution component selected by the user, wherein the execution mode is synchronous execution or asynchronous execution.

[0113] In some embodiments of this application, the step of responding to a user's contingency plan execution command and remotely executing the corresponding parent-child contingency plan tasks by calling a contingency plan execution tool based on a distributed task queue includes: determining the execution mode of each sub-contingency plan execution component included in the parent-child contingency plan task; if the execution mode of the sub-contingency plan execution component is synchronous execution, the parent contingency plan suspends execution until the sub-contingency plan execution component returns the final execution result; if the execution mode of the sub-contingency plan execution component is asynchronous execution, the parent contingency plan triggers the execution of the sub-contingency plan execution component and continues to execute subsequent steps, and the sub-contingency plan execution component runs independently in the distributed task queue.

[0114] In some embodiments of this application, the step of creating and configuring sub-plan execution components in an atomic manner in response to the user's plan creation and configuration instructions, and generating configured sub-plans, includes: in response to the user's plan creation and configuration instructions, when configuring the sub-plan execution components, establishing a binding relationship between the sub-plan execution components and the user-selected sub-plan execution components by referencing the names of the sub-plan execution components, wherein the binding relationship is stored in the data structure of the plan template in the form of name foreign keys.

[0115] In some embodiments of this application, the emergency plan execution method associated with the parent and child plans further includes: when a user creates or modifies a plan template, script execution component, or initiates a plan execution instruction, configuring the approver information corresponding to the emergency plan task by calling an approval tool.

[0116] It is understood that the above-mentioned emergency response plan execution method with parent-child contingency plan association can be executed by the emergency response plan system with parent-child contingency plan association provided in the aforementioned embodiments. The relevant explanations of the emergency response plan system with parent-child contingency plan association are applicable to the emergency response plan execution method with parent-child contingency plan association, and will not be repeated here.

[0117] Figure 5 This is a schematic diagram of the structure of a device according to an embodiment of this application. For example... Figure 5 As shown, the device includes one or more processors (or processing units), and may also include one or more memories coupled to the processors, and may also include a communication module coupled to the processors.

[0118] A communication module can be used to communicate with other devices or apparatuses, such as sending or receiving data and / or signals. A communication module may have at least one communication module for communication. A communication module may include any interface necessary for communicating with other devices. Exemplarily, a communication module may be a transceiver, circuit, bus, module, or other type of communication module.

[0119] The processor may include, but is not limited to, one or more of the following: a general-purpose computer, a special-purpose computer, a microcontroller, a digital signal processor (DSP), or a controller-based multi-core controller architecture. The device may have multiple processors, such as application-specific integrated circuit (ASIC) chips, which are time-dependent on a clock synchronized with the main processor.

[0120] The memory may include one or more non-volatile memories and one or more volatile memories. Examples of non-volatile memories include, but are not limited to, at least one of the following: read-only memory (ROM), electrically programmable read-only memory (EPROM), flash memory, hard disk, compact disc (CD), digital video disc (DVD), or other magnetic and / or optical storage. Examples of volatile memories include, but are not limited to, at least one of the following: random access memory (RAM), or other volatile memories that do not persist during the duration of a power outage.

[0121] A computer program consists of computer-executable instructions that are executed by an associated processor. Programs can be stored in ROM. A processor can perform any appropriate action and processing by loading the program into RAM.

[0122] Possible implementations of this application can be achieved through a program, enabling the communication device to execute any of the processes discussed in the foregoing embodiments. Possible implementations of this application can also be achieved through hardware or a combination of software and hardware.

[0123] In some implementations, the program may be tangibly contained in a computer-readable storage medium, which may include in a device (such as in memory) or other storage device accessible by the device. The program may be loaded from the computer-readable storage medium into RAM for execution. The computer-readable storage medium may include any type of tangible non-volatile memory, such as ROM, EPROM, flash memory, hard disk, CD, DVD, etc.

[0124] This application also provides a computer-readable storage medium storing computer instructions or program code thereon, which, when executed by a processor, causes the processor to perform the methods and functions involved in any of the above embodiments. A computer-readable medium can be any tangible medium that contains or stores a program for or relating to an instruction execution system, apparatus, or device. A computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. A computer-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. The computer-readable storage medium can be any available medium accessible to a computer or a data storage device such as a server or data center that integrates one or more available media. More detailed examples of computer-readable storage media include electrical connections with one or more wires, magnetic media (e.g., disks, floppy disks, hard disks, magnetic tapes, magnetic storage devices), optical media (e.g., optical storage devices, DVDs), semiconductor media (e.g., solid-state drives), random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), or any suitable combination thereof.

[0125] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. Embodiments of this application also provide at least one computer program product tangibly stored on a non-transitory computer-readable storage medium. This computer program product includes one or more computer-executable instructions, such as instructions included in a program module, which execute in a device on a target real or virtual processor to perform the processes, methods, and functions involved in any of the above embodiments. When the computer program instructions are loaded and executed on a computer, all or part of the flow or function according to the embodiments of this application is generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means.

[0126] This application also proposes a computer program product, including a computer program or instructions that, when run on a computer, cause the computer to perform the processes, methods, and functions described in the above embodiments. Typically, program modules include routines, programs, libraries, objects, classes, components, data structures, etc., that perform specific tasks or implement specific abstract data types. In various embodiments, the functionality of program modules can be combined or divided as needed. The machine-executable instructions for the program modules can be executed locally or in a distributed device. In a distributed device, the program modules can reside in both local and remote storage media.

[0127] Generally, the various embodiments of this application can be implemented in hardware or dedicated circuitry, software, logic, or any combination thereof. Some aspects can be implemented in hardware, while others can be implemented in firmware or software, which can be executed by a controller, microprocessor, or other computing device. Although various aspects of the embodiments of this disclosure are shown and described as block diagrams, flowcharts, or represented using some other illustration, it should be understood that the blocks, apparatuses, systems, techniques, or methods described herein can be implemented as, as non-limiting examples, in hardware, software, firmware, dedicated circuitry or logic, general-purpose hardware or controllers or other computing devices, or some combination thereof.

[0128] It should be noted that although embodiments of this application have been described above with reference to the accompanying drawings, these embodiments are not independent of each other, and they can be combined to obtain other embodiments. The methods, situations, categories, and classifications of embodiments in this application are only for the convenience of description and should not constitute a special limitation. Various methods, categories, situations, and features in embodiments can be combined with each other if logically consistent. The various embodiments of this application can be arbitrarily combined to achieve different technical effects. The embodiments of this application will not list various combinations.

[0129] Furthermore, although the operation of the methods of this disclosure is described in a specific order in the accompanying drawings, this does not require or imply that these operations must be performed in that specific order, or that all of the operations shown must be performed to achieve the desired result. Rather, the steps depicted in the flowcharts may be performed in a different order. Additionally or alternatively, certain steps may be omitted, multiple steps may be combined into one step, and / or one step may be broken down into multiple steps. It should also be noted that the features and functions of two or more devices according to this disclosure may be embodied in one device. Conversely, the features and functions of one device described above may be further divided and embodied by multiple devices.

[0130] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0131] The above description is merely an embodiment of this application and is not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. An emergency response plan system with parent-child plan association, characterized in that, The emergency response system associated with the parent-child contingency plan includes: The interaction layer is used to receive user operation instructions, which include pre-plan creation and configuration instructions as well as pre-plan execution instructions; The control layer is used to respond to the user's instructions for creating and configuring contingency plans, to create and configure sub-contingency plan execution components in an atomic manner, to generate configured sub-contingency plans, and to nest the configured sub-contingency plans into the corresponding parent contingency plans, thereby generating emergency contingency plan tasks associated with the parent and child contingency plans. The execution layer is used to respond to the user's contingency plan execution command, and based on the distributed task queue, to call the contingency plan execution tool to remotely execute the corresponding parent-child contingency plan tasks, and to monitor the execution status of each sub-contingency plan execution component in the parent-child contingency plan tasks.

2. The emergency response plan system with parent-child plan association as described in claim 1, characterized in that, The interaction layer is also used for: Provide an interactive interface; The user's operation instructions are received through the interactive interface; This displays the execution status of each sub-plan execution component in the emergency plan task associated with the parent and child plans.

3. The emergency response plan system with parent-child plan association as described in claim 1, characterized in that, The control layer is also used for: Different execution templates are set according to the task types in the business scenario, and encapsulated into multiple different execution components in an atomic manner, and stored in the data structure of the contingency plan template. The execution components include sub-contingency plan execution components. In response to the user's pre-plan creation and configuration instructions, determine and configure the sub-pre-plan execution components selected by the user.

4. The emergency response plan system with parent-child plan association as described in claim 3, characterized in that, The contingency plan creation and configuration instructions include the execution method of the sub-contingency plan components, and the control layer is also used for: In response to the user's pre-plan creation and configuration instructions, the execution mode of the sub-pre-plan execution component selected by the user is configured, wherein the execution mode is synchronous execution or asynchronous execution.

5. The emergency response plan system with parent-child plan association as described in claim 1, characterized in that, The execution layer is also used for: Determine the execution method of each sub-plan execution component included in the emergency plan task associated with the parent and child plans; If the execution mode of the sub-plan execution component is synchronous, the parent plan will pause execution until the sub-plan execution component returns the final execution result; If the execution mode of the sub-plan execution component is asynchronous, the parent plan will trigger the execution of the sub-plan execution component and continue to execute subsequent steps. The sub-plan execution component runs independently in the distributed task queue.

6. The emergency response plan system with parent-child plan association as described in claim 1, characterized in that, The control layer is also used for: In response to the user's plan creation and configuration instructions, when configuring the sub-plan execution component, a binding relationship is established between the sub-plan execution component and the user-selected sub-plan execution component by referencing the name of the sub-plan execution component. The binding relationship is stored in the data structure of the plan template in the form of a foreign key.

7. The emergency response plan system with parent-child plan association as described in claim 1, characterized in that, The control layer is also used for: When a user creates or modifies a contingency plan template, script execution component, or initiates a contingency plan execution command, the approver information corresponding to the emergency plan task can be configured by calling the approval tool.

8. A method for implementing an emergency response plan that links parent and child response plans, characterized in that, The emergency response plan execution methods associated with the parent-child emergency response plan include: Receive user operation instructions, which include plan creation and configuration instructions and plan execution instructions; In response to the user's instructions for creating and configuring contingency plans, sub-contingency plan execution components are created and configured in an atomic manner to generate configured sub-contingency plans, and the configured sub-contingency plans are nested into the corresponding parent contingency plans to generate emergency contingency plan tasks associated with the parent and child contingency plans. In response to the user's contingency plan execution command, based on a distributed task queue, the contingency plan execution tool is invoked to remotely execute the corresponding parent-child contingency plan tasks, and to monitor the execution status of each sub-contingency plan execution component in the parent-child contingency plan tasks.

9. An apparatus comprising: processor; And a memory configured to store computer-executable instructions, which, when executed, cause the processor to perform the emergency response execution method of claim 8, which is associated with a parent-child contingency plan.

10. A computer program product comprising a computer program / instructions, characterized in that, When the computer program / instruction is executed by the processor, it implements the emergency response plan execution method of any one of the parent-child contingency plans described in claims 1 to 7.

Images