Modular emergency plan system, modular emergency plan arrangement and execution method, equipment and computer program product

Abstract

The invention discloses a modularized emergency plan system, a modularized emergency plan arrangement and execution method, equipment and a computer program product, and the system comprises an interaction layer which is used for receiving a plan arrangement operation instruction of a user and forwarding the plan arrangement operation instruction to an application service layer; the application service layer is used for responding to the plan arrangement operation instruction, performing plan arrangement based on a plurality of predefined plan atomization components, generating an emergency plan task template, calling the emergency plan task template to perform plan execution, and obtaining a plan execution result; and the data storage layer is used for storing an emergency plan task template and a plan execution result. According to the invention, flexible arrangement and efficient execution of the emergency plan are realized through layered architecture design, the design of the interaction layer reduces the use threshold of a user and improves the efficiency and flexibility of plan arrangement, and the system supports other scenes to realize own emergency scenarized requirements through calling an API, and the universality and expansibility of the system are enhanced.

Description

Technical Field

[0001] This application relates to the field of financial information technology, and in particular to a modular emergency response system, a modular emergency response plan arrangement and execution method, equipment and computer program product. Background Technology

[0002] With the rapid development of information technology, the scale and complexity of enterprise IT systems continue to increase, especially in key industries such as finance, telecommunications, and the internet, where the requirements for high availability and business continuity are rising. In the face of sudden failures, network attacks, or data center anomalies, the ability to respond quickly and implement effective emergency response measures has become a crucial aspect of ensuring stable system operation.

[0003] Traditional emergency response methods rely heavily on manual operation or semi-automatic script execution, which has significant limitations. First, emergency procedures are typically triggered and implemented manually by operations and maintenance personnel based on experience. This process is time-consuming, and the response speed cannot meet the "minute-level or even second-level recovery" requirements of modern systems, leading to a wider impact of the failure and a decline in service quality. Second, emergency steps are often stored in text documents or fragmented scripts, lacking unified management and structured organization. The process arrangement is complex, prone to omissions and sequential errors, and highly dependent on the experience of specialized personnel, hindering knowledge transfer and team collaboration. Furthermore, the lack of visual monitoring during execution prevents operations and maintenance personnel from grasping the execution status of each step in real time. Once a failure or anomaly occurs, error localization is difficult, troubleshooting is costly, and further prolongs the fault recovery time.

[0004] To address these issues, the industry has begun exploring automated operations and maintenance (O&M) systems based on process orchestration. For example, existing technologies have proposed an O&M system based on business logic orchestration. This system includes a business process editor, which receives user input of O&M scenario design operations and generates target business processes; a process execution engine, which parses the business process and breaks it down into multiple process tasks, distributing them according to task type; an interface service bus, which registers and manages service interfaces and executes interface-type tasks; and a command task control server, which distributes command-type tasks to controlled servers for execution. This solution achieves automated scheduling of some O&M tasks, improving the consistency and controllability of process execution.

[0005] However, this existing technology still has several shortcomings. First, the process editor focuses on modeling general business logic and does not provide dedicated component libraries to support the characteristics of emergency scenarios. This results in a large amount of customized development still being required for high-frequency emergency operations such as disaster recovery switching and fault isolation, leading to poor flexibility. Second, although the task distribution mechanism can distinguish between interface services and command tasks, it does not provide fine-grained execution control capabilities, making it difficult to adapt to complex and ever-changing on-site environments. Third, the system lacks the ability to visualize and track the status of the entire contingency plan execution process. Users cannot intuitively understand the progress of the process, nor can they achieve fine-grained monitoring and intervention at the cross-component and cross-instance levels. Summary of the Invention

[0006] This application provides a modular emergency response plan system, a modular emergency response plan arrangement and execution method, equipment, and computer program product to achieve an emergency response plan system optimized for emergency scenarios, featuring modularity, visualization, and manageability and controllability. This reduces the threshold for process arrangement, improves handling efficiency, and enhances the transparency and maintainability of the execution process.

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

[0008] In a first aspect, embodiments of this application provide a modular emergency response plan system, including an interaction layer, an application service layer, and a data storage layer;

[0009] The interaction layer is used to receive the user's pre-plan arrangement operation instructions and forward the pre-plan arrangement operation instructions to the application service layer.

[0010] The application service layer is used to respond to the contingency plan orchestration operation instruction, orchestrate contingency plans based on multiple predefined contingency plan atomic components, generate emergency contingency plan task templates, and call the emergency contingency plan task templates to execute the contingency plans and obtain contingency plan execution results.

[0011] The data storage layer is used to store the emergency response plan task template and the execution results of the plan.

[0012] Optionally, the application service layer is further configured to:

[0013] Based on the system service tree, emergency response task templates are classified according to multiple dimensions, including scenario dimensions, which include at least one of disaster recovery switching scenarios, emergency card scenarios, and batch scheduling scenarios.

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

[0015] Display a visual interface;

[0016] The user's pre-plan arrangement operation instructions are received through the visual interface. The pre-plan arrangement operation instructions are used to arrange pre-defined atomic components. The atomic components include at least one of the following: script execution component, traffic scheduling component, registry center service component, database high availability switching component, application start / stop component, and API call component.

[0017] Optionally, the application service layer is further configured to:

[0018] In response to the pre-plan arrangement operation command, the corresponding pre-plan atomization components are assembled and configured based on a plurality of predefined pre-plan atomization components;

[0019] The emergency response task template is generated based on the configuration parameters of the atomization components and the connection relationships between them.

[0020] Optionally, the configuration parameters include the execution mode of each atomic component of the plan, and the execution mode includes direct execution mode and remote execution mode;

[0021] The direct execution mode means that it has no dependency on the execution environment, and the system directly allocates processes to execute script commands.

[0022] The remote execution mode requires the user to specify remote host information, which includes at least one of the following: host address, execution account, and execution path.

[0023] Optionally, the application service layer is further configured to:

[0024] During the execution of the contingency plan, execution control operations between atomic components are adopted to control the execution process between atomic components. The execution control operations between atomic components include at least one of the following: pause and then continue, redo steps, intelligent skip after failure, and automatic pause after failure.

[0025] The execution process within an atomic component is controlled by execution control operations within the atomic component. These execution control operations include at least one of instance-level failure replay, ignoring failed instances, and skipping all instances.

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

[0027] Receive user requests to view pre-plan information;

[0028] The application service layer is also used for:

[0029] In response to the request to view the contingency plan information, obtain the target contingency plan information that the user wants to view;

[0030] The target contingency plan information includes at least one of the following: a list of contingency plan templates, contingency plan task execution history, contingency plan task execution details, and operation records. The contingency plan task execution details include at least one of the following: overall execution status, atomic component execution status, specific instance execution status, and logs.

[0031] Secondly, embodiments of this application also provide a modular emergency response plan arrangement and execution method, the modular emergency response plan arrangement and execution method comprising:

[0032] Receive user's pre-planning operation instructions;

[0033] In response to the contingency plan arrangement operation command, the contingency plan is arranged based on multiple predefined contingency plan atomic components to generate an emergency contingency plan task template, and the emergency contingency plan task template is invoked to execute the contingency plan and obtain the contingency plan execution result;

[0034] Store the emergency response plan task template and the execution results of the plan.

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

[0036] A processor; and a memory configured to store computer-executable instructions, which, when executed, cause the processor to perform any of the aforementioned componentized contingency planning and execution methods.

[0037] Fourthly, embodiments of this application also provide a computer program product, including a computer program / instruction, which, when executed by a processor, implements any of the aforementioned componentized emergency plan arrangement and execution methods.

[0038] The at least one technical solution adopted in this application embodiment can achieve the following beneficial effects: The component-based emergency response plan system of this application embodiment includes an interaction layer, an application service layer, and a data storage layer; the interaction layer is used to receive user's emergency response plan arrangement operation instructions and forward the emergency response plan arrangement operation instructions to the application service layer; the application service layer is used to respond to the emergency response plan arrangement operation instructions, arrange emergency response plans based on multiple predefined atomic emergency response plan components, generate emergency response plan task templates, and call the emergency response plan task templates to execute the emergency response plans and obtain the execution results; the data storage layer is used to store the emergency response plan task templates and the execution results. The component-based emergency response plan system provided in this application embodiment, through a layered architecture design, realizes flexible arrangement and efficient execution of emergency response plans. The design of the interaction layer lowers the user's usage threshold, improves the efficiency and flexibility of emergency response plan arrangement, and the system supports handling large-scale concurrent requests, ensuring the timeliness and reliability of emergency response plan execution. In addition, the system also supports other scenarios to realize their own emergency scenario requirements by calling APIs, enhancing the system's versatility and scalability. Attached Figure Description

[0039] 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:

[0040] Figure 1 This is a schematic diagram of the architecture of a componentized emergency response system according to an embodiment of this application;

[0041] Figure 2 This is a schematic diagram illustrating the functional implementation of a modular emergency response system in an embodiment of this application;

[0042] Figure 3 This is a flowchart illustrating a modular emergency response plan arrangement and execution method according to an embodiment of this application;

[0043] Figure 4 This is a schematic diagram of a modular emergency response plan arrangement and execution process in an embodiment of this application;

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

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

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

[0047] This application provides a modular emergency response system, such as... Figure 1 The diagram illustrates the architecture of a component-based emergency response plan system according to an embodiment of this application. The system includes an interaction layer, an application service layer, and a data storage layer. The interaction layer receives user instructions for plan orchestration and forwards these instructions to the application service layer. The application service layer, in response to the instructions, orchestrates emergency response plans based on multiple predefined atomic plan components, generates emergency response plan task templates, and executes these templates to obtain execution results. The data storage layer stores the emergency response plan task templates and the execution results.

[0048] The component-based emergency response system provided in this application adopts a layered architecture design, mainly including an interaction layer, an application service layer, and a data storage layer. Each layer works together to achieve flexible arrangement and efficient execution of emergency response plans.

[0049] (1) Interaction layer:

[0050] The interaction layer serves as the interface between the user and the system, employing a web-based visual interface. Users perform pre-plan orchestration operations through this interface, such as dragging and dropping pre-plan atomic components, configuring component parameters, and generating pre-plan orchestration operation commands. After receiving these commands, the interaction layer forwards them to the application service layer for processing.

[0051] The interaction layer can be developed based on the Django framework, leveraging its powerful template engine and form processing capabilities to quickly build user-friendly interfaces. Simultaneously, it can be combined with front-end technologies (such as HTML, CSS, and JavaScript) to implement interactive effects and enhance the user experience.

[0052] (2) Application service layer:

[0053] The application service layer is the core of the system, responsible for responding to contingency plan orchestration commands from the interaction layer. Based on multiple predefined atomic components, it uses an orchestration engine to flexibly orchestrate contingency plans and generate emergency plan task templates. The orchestration engine supports a drag-and-drop + configuration-based efficient assembly method, allowing users to freely combine components according to actual needs to form contingency plans that meet specific scenarios. Furthermore, the application service layer is also responsible for calling the emergency plan task templates to execute the plans, using a distributed task queue (Celery) to process and schedule asynchronous tasks, ensuring the efficiency and reliability of contingency plan execution. During execution, the system collects execution results in real time, providing a basis for subsequent analysis and optimization.

[0054] The application service layer is developed in Python, leveraging the ORM (Object-Relational Mapping) capabilities of the Django framework to simplify database operations. Simultaneously, services are run via uwsgi or Gunicorn to enhance the system's concurrency capabilities. The emergency card service is a fully distributed service; all external access requests are forwarded and load-balanced through the access layer's Nginx or Apache, ensuring high availability and scalability. The contingency platform service supports horizontal scaling and can tolerate single-node failures, guaranteeing system stability.

[0055] (3) Data storage layer:

[0056] The data storage layer is responsible for storing emergency response plan task templates and execution results. It uses relational databases (such as OpenGauss and PostgreSQL) to store structured data, such as detailed information about the plan templates and component configuration parameters; at the same time, it uses Redis to implement caching and distributed locks to improve the system's response speed and concurrency control capabilities.

[0057] The data storage layer provides high-performance, highly reliable data storage services. Redis, as a caching and distributed lock implementation tool, significantly improves overall system performance through its high-speed memory access capabilities. The data storage layer is designed with backup and recovery mechanisms in mind, ensuring data security and integrity.

[0058] The component-based emergency response system provided in this application, through its layered architecture, enables flexible orchestration and efficient execution of emergency response plans. The interactive layer design lowers the user's barrier to entry, improves the efficiency and flexibility of plan orchestration, and the system supports handling large-scale concurrent requests, ensuring the timeliness and reliability of plan execution. Furthermore, the system supports other scenarios by calling APIs to fulfill their own emergency scenario requirements, enhancing the system's versatility and scalability.

[0059] In some embodiments of this application, the application service layer is further configured to: classify emergency plan task templates according to multiple dimensions based on the system service tree, wherein the dimensions include scenario dimensions, and the scenario dimensions include at least one of disaster recovery switching scenarios, emergency card scenarios, and batch scheduling scenarios.

[0060] The system service tree adopts a tree-like data structure, with the business system as the root node, and decomposes downwards into subsystems, modules, components, and other levels. Each node contains metadata such as a unique identifier, node type, and associated contingency plan template ID, forming a service topology model covering the entire system. For example, in a financial transaction system, the root node is the "Transaction System," and its child nodes include the "Clearing Subsystem," "Risk Control Subsystem," etc., with each subsystem further associated with specific contingency plan templates.

[0061] The application service layer deploys a classification engine that supports dynamic classification of contingency plan templates based on the following dimensions:

[0062] Scenario Dimension: Based on the applicable business scenarios of the contingency plan, it includes disaster recovery switching scenarios (such as database master-slave switching), emergency card scenarios (such as standardized handling procedures for sudden failures), batch scheduling scenarios (such as large-scale task batch execution), etc. Each scenario dimension can be configured with independent classification rules.

[0063] Granularity dimension: Based on the hierarchical structure of the system service tree, it supports classification at different granularities such as system level, subsystem level, and module level, so as to achieve precise matching between contingency plans and system architecture.

[0064] Category Dimension: Classified according to the type of contingency plan function, such as data recovery, service switching, traffic scheduling, etc., and supports custom extensions.

[0065] The categorized contingency plan templates are stored in the data storage layer, and query efficiency is optimized through indexing. When a contingency plan is executed, the system can automatically match the corresponding category of contingency plan template based on the current fault scenario. For example, when a database master node failure is detected, the system can quickly locate the database switchover contingency plan under the "disaster recovery switchover scenario," shortening the emergency response time.

[0066] This application's embodiments significantly improve the precision and efficiency of emergency response plan management by introducing a system service tree model and a multi-dimensional classification mechanism. Specifically, the system achieves deep integration between plan templates and business architecture, supporting rapid plan location through dimensions such as scenario, granularity, and category, avoiding the problems of scattered plans and difficult retrieval in traditional solutions. In complex scenarios such as disaster recovery switching and batch scheduling, the system can automatically match the optimal plan, reducing manual judgment time and shortening emergency response time.

[0067] In some embodiments of this application, the interaction layer is further configured to: display a visual interface; receive the user's pre-plan arrangement operation instructions through the visual interface, wherein the pre-plan arrangement operation instructions are used to arrange pre-defined atomic components, and the atomic components include at least one of the following: script execution component, traffic scheduling component, registry center service component, database high availability switching component, application start / stop component, and API call component.

[0068] The interaction layer works collaboratively with predefined atomic components of contingency plans through a visual interface to achieve flexible orchestration and efficient execution of emergency plans. The specific implementation mechanism is as follows:

[0069] The interaction layer employs a low-code visual orchestration interface, providing a canvas-style operation area and component toolbar. Users can drag and drop atomic components onto the canvas and configure the execution logic (serial / parallel) between components by connecting them. The interface supports real-time preview of the planned process and generates visual flowcharts to facilitate user verification of the orchestration logic. Additionally, the interface provides a component property configuration panel, allowing users to fine-tune the parameters of each component.

[0070] The system predefines multiple core atomic components, each encapsulating specific emergency response capabilities. Examples of atomic components include:

[0071] (1) Script execution component: Supports two modes: direct execution (the system allocates a process to run the script) and remote execution (the user specifies the host, account, and path, and remotely calls it through protocols such as SSH / WinRM). It is suitable for scenarios such as emergency card execution and custom scripts.

[0072] (2) Traffic scheduling component: Provides traffic allocation (such as switching traffic from a faulty node to a healthy node) and traffic isolation (such as isolating traffic of a specific user to an independent channel). Users can reuse pre-configured traffic rule templates.

[0073] (3) Registration Center Service Component: Encapsulates service registration and deregistration interfaces, supports one-click service online / offline operation, and is suitable for emergency handling under microservice architecture.

[0074] (4) Database high availability switching component: For databases such as OpenGauss / GaussDB, it provides the ability to switch between active-active or disaster recovery in the same city. Users can specify the target data center to achieve automatic switching.

[0075] (5) Application start-stop component: Supports application start-up, graceful stop (waiting for the current request to complete), forced stop, restart and other operations to meet the application lifecycle management needs in disaster recovery switching scenarios.

[0076] (6) API call component: Provides standard HTTP / RESTful API call capabilities. Users can configure request URL, parameters, header information, and capture response results for status judgment (such as determining subsequent processes based on HTTP status codes).

[0077] After users drag and drop components onto the canvas through the visual interface, they can configure the execution order (serial / parallel) between components by connecting them. The system supports conditional branching logic, such as determining whether to execute subsequent components based on the return result of an API call component. After orchestration, the system converts the flowchart into an executable task template and stores it in the data storage layer.

[0078] The interaction layer collaborates with the backend application service layer to dynamically allocate execution resources based on component type. For example, script execution components directly call local processes or remote host resources; database switching components automate operations through database middleware or cluster management interfaces; and API call components send requests through an HTTP client library. All component execution logs are displayed in real-time on a visual interface for user monitoring and debugging.

[0079] This application's embodiments achieve a "what you see is what you get" and "out-of-the-box" approach to emergency plan orchestration through deep integration of a visual interface and various types of atomic components. Users do not need to write complex code; they can quickly build plans that meet specific scenarios simply by dragging and dropping components and configuring parameters, significantly reducing the threshold for plan design and development costs. Multiple atomic components cover core emergency scenarios such as script execution, traffic scheduling, service governance, database switching, and application lifecycle management, supporting serial / parallel combinations and conditional branching logic, and can flexibly handle complex requirements such as disaster recovery switching, batch scheduling, and fault self-healing. Furthermore, the standardized design of the components supports reuse and expansion; enterprises can quickly build industry-specific emergency plan templates based on existing component libraries, improving the standardization level of emergency response.

[0080] In some embodiments of this application, the application service layer is further configured to: assemble and configure corresponding emergency plan atomic components based on a plurality of predefined emergency plan atomic components in response to the emergency plan orchestration operation instruction; and generate the emergency plan task template according to the configuration parameters of the emergency plan atomic components and the connection relationship between the emergency plan atomic components.

[0081] The application service layer predefines a variety of core contingency atomic components, including a script execution component, a traffic scheduling component, a registry center service component, a database high availability switching component, an application start / stop component, and an API call component.

[0082] After the interaction layer sends the pre-plan orchestration operation command, the application service layer starts the assembly engine. Based on the component type dragged by the user, it loads the corresponding component template from the component library and creates an instance; it parses the component parameters (such as script path, traffic rules, database connection information, etc.) entered by the user in the visual interface and populates them into the component instance attribute fields; based on the component connection relationship drawn by the user, it generates a directed acyclic graph (DAG) to represent the execution flow and clarifies the serial / parallel dependencies between components; for the flow of components containing condition judgments such as API calls, it dynamically generates branch logic nodes, such as "if the API returns a status code of 200, then execute the subsequent component A, otherwise execute component B".

[0083] After the assembly engine completes the component configuration, it converts the DAG structure into a pre-planned task template in JSON / XML format. The template can contain the following core information:

[0084] Component list: Component type, unique identifier, and configuration parameters;

[0085] Execution flow: component execution order, parallel branch definition;

[0086] Dependency relationships: rules for data transfer between components (e.g., the output of a preceding component is used as the input of a subsequent component);

[0087] Approver Information: Some plans require approval from an approver before they can be implemented.

[0088] The system then verifies the validity of the template, including parameter validity checks (such as remote host reachability), logical loop detection (such as no isolated components), and resource conflict investigation (such as the same database cannot be switched and backed up simultaneously), to ensure the template's executability.

[0089] The application service layer supports dynamically adding component types through extended interfaces. Enterprises can customize and develop components for specific scenarios (such as dedicated scheduling components for industry systems), which only need to implement standardized interfaces to be included in the component library. Simultaneously, the system provides template version management functionality, recording the changes and operators for each modification, and supporting rollback to historical versions.

[0090] This application's embodiments achieve efficient construction of emergency response plan task templates through the combination of atomic component encapsulation and a visual assembly engine, significantly improving the flexibility and efficiency of plan design. Users do not need to concern themselves with the underlying code implementation; they can quickly generate plan templates that meet the needs of complex scenarios simply by dragging and dropping components and configuring parameters. Meanwhile, the standardized design of the components ensures the reusability of the plans, allowing enterprises to build industry-specific plan template libraries based on existing component libraries, supporting one-click access and rapid adaptation.

[0091] In some embodiments of this application, the configuration parameters include the execution mode of each atomic component of the plan. The execution mode includes a direct execution mode and a remote execution mode. The direct execution mode indicates that it is independent of the execution environment and the system directly allocates processes to execute script commands. The remote execution mode indicates that the user needs to specify remote host information, which includes at least one of the following: host address, execution account, and execution path.

[0092] The script execution component provides a visual configuration panel during the pre-planning stage. Users can select the execution mode using radio buttons and fill in different parameters for different modes.

[0093] Direct execution mode: Users only need to upload script files or enter script content, without configuring additional environment parameters. The component encapsulates process allocation logic internally. The system automatically detects available local resources (such as CPU and memory thresholds), and under the condition that they are met, directly calls the operating system's process management interface to create an independent process to execute the script. Execution logs are fed back to the interaction layer in real time through the standard output stream.

[0094] Remote execution mode: Users need to configure the three key elements of the remote host (host address, execution account, and execution path), and can choose to upload a script file or specify an existing script path on the remote host. Before execution, the component automatically verifies the host trust relationship; if no trust is established, the user is prompted to configure passwordless login or certificate authorization.

[0095] This application's embodiments, through the design of a dual-mode script execution component, achieve flexible adaptation and efficient execution of script tasks in emergency response scenarios. The direct execution mode eliminates dependence on remote environments and is suitable for localized emergency operations (such as quickly stopping faulty services and generating temporary diagnostic logs). Its automated resource detection and process management mechanisms ensure that tasks are executed immediately when resources are sufficient, avoiding delays in response due to environment configuration issues. The remote execution mode, through standardized host information configuration and protocol integration, supports batch script execution across hosts and data centers (such as simultaneously restarting application nodes in multiple regions and uniformly updating configuration files). Its trust verification and permission control mechanisms effectively reduce security risks. The two modes can be seamlessly switched, allowing users to dynamically select the execution method based on the scope of the fault (single node / multiple nodes) and script complexity (depending on local / general environment), significantly improving the flexibility of emergency response.

[0096] In some embodiments of this application, the application service layer is further configured to: control the execution process between atomic components by adopting execution control operations between atomic components during the execution of the plan, wherein the execution control operations between atomic components include at least one of pausing and then continuing, step redoing, intelligent skipping after failure, and automatic pausing after failure; and control the execution process within atomic components by adopting execution control operations within atomic components, wherein the execution control operations within atomic components include at least one of instance-level failure redoing, ignoring failed instances, and skipping all instances.

[0097] The application service layer achieves dynamic fault tolerance and precise control of the emergency plan execution process by constructing a two-level execution control system between and within components.

[0098] The application service layer embeds a process control module in the pre-execution engine, providing the following core control capabilities for the execution process between components:

[0099] (1) Pause and then resume: When the user triggers a pause command (such as through an interaction layer button or a preset condition, such as detecting an abnormality in a key business indicator), the system immediately freezes the current execution state, records the intermediate states of all components (such as the output data of executed components and the dependencies of unexecuted components), and generates a pause snapshot stored in the database. After the user confirms to continue, the system restores the snapshot state and restarts the execution process from the paused node, ensuring seamless context transition.

[0100] (2) Step redo: Users can initiate a redo command for an executed component. The system first rolls back the impact of the component on the external system (such as undoing database changes or restoring traffic routing), then re-executes the component, and updates the input parameters of subsequent components based on the redo result. For example, if the database switching component fails due to network jitter, the connection parameters can be automatically refreshed and the system can try again during the redo.

[0101] (3) Intelligent skipping after failure: The system configures a failure threshold (e.g., 3 consecutive failures) and skipping conditions (e.g., non-critical path components) for each component. When the component fails to meet the threshold and the skipping conditions are met, the component is automatically marked as "skipped". The execution path is recalculated based on the DAG graph, bypassing the component to continue the subsequent process. At the same time, the reason for skipping is recorded for post-event analysis.

[0102] (4) Automatic pause after failure: For critical path components (such as master database switching), the system is configured with a strict failure policy. If the component fails to execute, the entire plan will be paused immediately and an alarm notification (such as SMS or email) will be triggered to the operation and maintenance personnel. At the same time, the execution engine will be locked to prevent accidental operation. Execution will be manually resumed after the problem is confirmed to be fixed.

[0103] Each atomic component integrates instance-level control logic, primarily supporting the following fine-grained operations:

[0104] (1) Instance-level failure replay: For components that support multi-instance execution (such as batch restarting 10 application nodes), if some instances fail (such as 3 nodes timed out), the system will automatically retry the failed instances (by default, 2 retry times with a 1-minute interval), and the results of successful instances will be retained. Finally, the status of all instances (number of successes / failures) will be summarized in the contingency plan execution report.

[0105] (2) Ignore failed instances: Users can mark "allow partial failure" during the component configuration stage. If some instances fail during execution, the system only records the information of the failed instances (such as IP address and error code) without interrupting the overall process. This is suitable for fault-tolerant scenarios of non-critical instances (such as monitoring nodes).

[0106] (3) Skip all instances: When the component detects that the preconditions are not met (such as the remote host being unreachable) or the user actively triggers the skip, the component directly marks all instances as "skipped" and returns an empty result to avoid ineffective execution and resource consumption. For example, if the traffic scheduling component detects that the target cluster load is too high, it can automatically skip the traffic switching operation.

[0107] This application's embodiments significantly enhance the fault tolerance and business continuity assurance level of emergency response plans through a multi-level execution control mechanism. Inter-component control operations enable the plan to flexibly respond to unpredictable failures, preventing overall process interruption due to the failure of a single component. For example, in disaster recovery failover scenarios, if a synchronization delay between the primary and backup databases causes failover, the system can automatically pause and wait for synchronization to complete before resuming, rather than directly terminating the plan. Intra-component control operations provide refined fault tolerance measures for batch operation scenarios, ensuring successful execution of critical instances while tolerating the failure of non-critical instances.

[0108] In some embodiments of this application, the interaction layer is further configured to: receive a user's request to view contingency plan information; the application service layer is further configured to: respond to the request to view contingency plan information and obtain the target contingency plan information that the user wants to view; wherein, the target contingency plan information includes at least one of a contingency plan template list, contingency plan task execution history, contingency plan task execution details, and operation records, and the contingency plan task execution details include at least one of an overall execution status, atomic component execution status, specific instance execution status, and logs.

[0109] The interaction layer provides a unified entry point for contingency plan queries, allowing users to initiate query requests by combining filtering conditions such as tags, types, scenarios, and time ranges. For example, users can select a combination of conditions such as "tag = financial transaction", "type = disaster recovery switchover", and "scenario = database failure" on the front-end page, and after clicking query, generate structured request parameters (JSON format) and send them to the application service layer.

[0110] After receiving the request, if the user is querying the list of pre-plan templates, the application service layer retrieves template records that match the filter criteria from the database, sorts them by creation time, and returns fields such as template ID, name, type, scene tag, and description.

[0111] If the query is for the execution history of a pre-planned task, it will link the task execution record table, filter historical tasks by template ID and time range, and return the task ID, start / end time, execution result (success / failure / pause), triggering method (manual / automatic), etc.

[0112] For querying task execution details, users can further query three levels of status data for the selected historical tasks, including the overall execution status of the plan, the execution status of atomic components, and the execution status of specific instances.

[0113] For querying log data, structured logs (sorted by timestamp) can be pulled from the log system based on the task ID. Filtering by component / instance and other dimensions is supported. Key fields can include log level, time, source component, content, etc.

[0114] This application's embodiments significantly improve the management efficiency and fault location speed of emergency plans through multi-dimensional visualization and precise traceability mechanisms for contingency plan information. Users can quickly filter relevant information for target contingency plans using combinations of tags, types, and scenarios, providing traceable and analyzable decision-making basis for emergency response and significantly improving the level of business continuity assurance.

[0115] For ease of understanding of the above embodiments, as Figure 2 The diagram illustrates the functional implementation of a component-based emergency response plan system according to an embodiment of this application. The emergency response plan system of this embodiment revolves around core functions such as plan templates, plan triggering, configuration management, task management, and flowcharts, achieving comprehensive and flexible emergency management functions, as detailed below:

[0116] (1) Contingency plan template function: The system has a variety of pre-built atomic components for contingency plans, such as script execution components, Apollo configuration modification components, and Nacos service components. Users can create contingency plan templates that meet specific emergency scenarios based on these components through visual operations (drag and drop) and necessary coding, so as to achieve standardized combination and rapid construction of contingency plans.

[0117] (2) Contingency plan triggering function: Supports two triggering methods: manual order placement and scheduled order placement. Manual order placement makes it easy for maintenance personnel to activate the contingency plan immediately in an emergency; scheduled order placement is suitable for regular emergency scenarios, such as periodic system maintenance and switching. At the same time, the system integrates an approval center to control the process of contingency plan triggering, ensuring the rationality and security of contingency plan execution, and has a task management function to track and manage the contingency plan tasks after triggering.

[0118] (3) Configuration management functions: These functions cover Apollo cluster configuration, script management, ECP cluster configuration, script approval records, Nacos service configuration, mutual exclusion groups, and alarm policy association. By centrally managing various configuration information, the system ensures the accuracy of configuration of relevant systems and components during the execution of emergency plans. At the same time, the script approval records ensure the compliance of script execution, and the mutual exclusion groups and alarm policy association further optimize the logic and response mechanism of emergency handling.

[0119] (4) Task management functions: including execution records, report export, interruption handling and status tracking. During the execution of the plan, the system records the execution information in real time, and users can perform data analysis and reporting through the report export function; if an abnormality occurs during the execution, interruption handling can be performed; the status tracking function allows users to keep track of the progress and status of the plan execution at any time.

[0120] (5) Flowchart Function: Provides functions such as template list display, flowchart generation, and flowchart download. Users can easily view the existing contingency plan template list, generate and download flowcharts as needed, and provide clear process guidance for emergency response.

[0121] This application also provides a modular method for arranging and executing emergency response plans, such as... Figure 3 The diagram illustrates a modular emergency response plan arrangement and execution method according to an embodiment of this application. The modular emergency response plan arrangement and execution method includes the following steps S310 to S330:

[0122] Step S310: Receive the user's pre-plan arrangement operation instruction;

[0123] Step S320: In response to the contingency plan arrangement operation instruction, contingency plan arrangement is performed based on multiple predefined contingency plan atomic components to generate an emergency contingency plan task template, and the emergency contingency plan task template is called to execute the contingency plan and obtain the contingency plan execution result.

[0124] Step S330: Store the emergency plan task template and the plan execution result.

[0125] In some embodiments of this application, the componentized emergency plan orchestration and execution method further includes: classifying emergency plan task templates according to multiple dimensions based on a system service tree, wherein the dimensions include scenario dimensions, and the scenario dimensions include at least one of disaster recovery switching scenarios, emergency card scenarios, and batch scheduling scenarios.

[0126] In some embodiments of this application, receiving the user's pre-plan arrangement operation instruction includes: displaying a visual interface; receiving the user's pre-plan arrangement operation instruction through the visual interface, wherein the pre-plan arrangement operation instruction is used to arrange pre-defined multiple pre-defined atomic components, wherein the pre-plan atomic components include at least one of an add script execution component, a traffic scheduling component, a registry center service component, a database high availability switching component, an application start / stop component, and an API call component.

[0127] In some embodiments of this application, the step of responding to the contingency plan arrangement operation instruction and arranging contingency plans based on a plurality of predefined contingency plan atomization components to generate an emergency contingency plan task template includes: responding to the contingency plan arrangement operation instruction and assembling and configuring corresponding contingency plan atomization components based on a plurality of predefined contingency plan atomization components; and generating the emergency contingency plan task template according to the configuration parameters of the contingency plan atomization components and the connection relationship between the contingency plan atomization components.

[0128] In some embodiments of this application, the configuration parameters include the execution mode of each atomic component of the plan. The execution mode includes a direct execution mode and a remote execution mode. The direct execution mode indicates that it is independent of the execution environment and the system directly allocates processes to execute script commands. The remote execution mode indicates that the user needs to specify remote host information, which includes at least one of the following: host address, execution account, and execution path.

[0129] In some embodiments of this application, the step of calling the emergency plan task template to execute the plan and obtain the plan execution result includes: during the plan execution process, taking execution control operations between atomic components to control the execution process between atomic components, wherein the execution control operations between atomic components include at least one of pausing and then continuing, redoing steps, intelligent skipping after failure, and automatic pausing after failure; taking execution control operations within atomic components to control the execution process within atomic components, wherein the execution control operations within atomic components include at least one of instance-level failure redo, ignoring failed instances, and skipping all instances.

[0130] In some embodiments of this application, the componentized emergency plan arrangement and execution method further includes: receiving a user's request to view plan information; responding to the request to view plan information, obtaining the target plan information that the user wants to view; wherein the target plan information includes at least one of a plan template list, a plan task execution history, a plan task execution detail, and an operation record, and the plan task execution detail includes at least one of an overall execution status, an atomic component execution status, a specific instance execution status, and a log.

[0131] For ease of understanding of the above embodiments, as Figure 4 As shown, a schematic diagram of a componentized emergency plan arrangement and execution process is provided in an embodiment of this application.

[0132] The system utilizes a link between "contingency plan organization" and "system task tree" to achieve multi-dimensional contingency plan classification. This association allows for the categorization and management of contingency plans from different dimensions, such as business systems and functional modules, making the organizational structure of contingency plans clearer and facilitating subsequent retrieval and use.

[0133] In the "Contingency Plan Definition" stage, users can integrate various atomic components of contingency plans (such as script execution components, traffic scheduling components, and registry center service components) through drag-and-drop and coding. These components can be combined according to actual needs to form standardized combinations of disaster recovery switchover contingency plan templates. Combination methods include serial and parallel approaches, allowing users to choose the appropriate execution order based on specific business scenarios to build contingency plan templates that meet different emergency scenarios.

[0134] The contingency plan execution triggering mechanism has two modes: manual order placement and scheduled order placement. Manual order placement allows maintenance personnel to trigger the contingency plan execution immediately when needed; scheduled order placement can automatically trigger the contingency plan execution according to preset time rules. Regardless of whether it is manual or scheduled order placement, an approval process is required before the contingency plan execution is triggered. The approval process ensures the rationality and security of the contingency plan execution; only after approval can the contingency plan enter the execution phase.

[0135] After approval, the system enters the visualized control phase of "contingency plan viewing and management." In this phase, the system provides multi-dimensional task monitoring interfaces, allowing operations and maintenance personnel to view the execution status of contingency plans in real time, including overall execution status, atomic component execution status, specific instance execution status, and log information. Simultaneously, the system pushes the execution results to relevant operations and maintenance personnel, enabling them to promptly understand the effectiveness of the contingency plan execution and take appropriate actions based on the results, achieving closed-loop management of the entire contingency plan lifecycle.

[0136] This application's embodiments achieve efficient management and execution of the emergency response plan system through multi-dimensional plan segmentation, flexible plan definition methods, a dual-mode plan execution triggering mechanism, and visualized control stages. Multi-dimensional segmentation makes plan management more organized, facilitating quick location and retrieval of required plans; the plan definition method combining drag-and-drop and code configuration improves the flexibility and efficiency of plan creation, enabling rapid adaptation to different emergency scenarios; the manual and timed dual-mode triggering mechanism meets the plan execution needs under different circumstances, while the approval process ensures execution security; visualized control and multi-dimensional monitoring interfaces enable operations and maintenance personnel to monitor plan execution in real time, promptly address issues, and the synchronous push of execution results further enhances the timeliness of emergency response. Overall, it achieves closed-loop management of the entire plan lifecycle, effectively improving the system's emergency response capabilities and reliability.

[0137] It is understood that the above-mentioned modular emergency plan arrangement and execution method can be executed by the modular emergency plan system provided in the foregoing embodiments. The relevant explanations of the modular emergency plan system are applicable to the modular emergency plan arrangement and execution method, and will not be repeated here.

[0138] In summary, the key points of this application are mainly as follows:

[0139] (1) In the process of emergency plan preparation and execution, efficiency and safety control are improved by using components and visualization.

[0140] (2) Component-based encapsulation and execution: The emergency response system encapsulates multiple atomic components for daily emergency response, disaster recovery switching and other scenarios, including script execution components, traffic scheduling components, registration center service components, database high availability switching components, application start and stop components, API call components, etc.

[0141] (3) Flexible execution: The flexibility of the plan execution is improved by using a variety of auxiliary means such as pausing, redoing, skipping, manual confirmation, and forced waiting;

[0142] (4) Improved efficiency, drag-and-drop orchestration lowers the barrier to entry, optimizes operation and maintenance costs, reuses common components, unified access to audit logs for operation, audit-friendly, and enhanced reliability;

[0143] The main technical advantages of this application are:

[0144] (1) Improved component reusability: By encapsulating various emergency operations into standard components, redundant development is avoided. In the past, scripts had to be written for each emergency, but now ready-made components can be called directly. For common operations such as "database switching", the components can also automatically perform parameter pre-validation, effectively preventing human errors such as entering the wrong IP address, and greatly improving the accuracy and efficiency of the operation.

[0145] (2) Efficient and intuitive process arrangement: Supports drag-and-drop connection of components, and the system can automatically generate DAG execution flowchart. Users only need to drag the components onto the canvas to quickly build a clear execution flow, making complex emergency processes simple and clear, and easy for users to understand and operate.

[0146] (3) Enhanced security: Review and approval processes are set up for key components and operations to ensure the rationality and safety of emergency operations. At the same time, audit logs are automatically generated during the execution process, providing a reliable basis for subsequent audits and problem tracing, which meets the company's security compliance requirements.

[0147] (4) Lowered barrier to entry: With the help of a visual interface, even novice users can complete relatively complex emergency procedure arrangement and handling operations by following the instructions. There is no need to deeply understand the underlying code and complex technical details, which reduces the technical ability requirements of personnel for emergency operations and enables more people to participate in emergency response work.

[0148] (5) Improved overall efficiency: Reduced workload in manually writing scripts and setting up processes. The use of standard components and drag-and-drop process arrangement significantly shortened the preparation and execution time of emergency plans, enabling the system to respond to various emergency events more quickly and improving the overall emergency response efficiency.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0163] The above description is merely an embodiment of this application and is not intended to limit 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 principle of this application should be included within the scope of the claims of this application.

Claims

1. A modular emergency response system, characterized in that, It includes the interaction layer, application service layer, and data storage layer; The interaction layer is used to receive the user's pre-plan arrangement operation instructions and forward the pre-plan arrangement operation instructions to the application service layer. The application service layer is used to respond to the contingency plan orchestration operation instruction, orchestrate contingency plans based on multiple predefined contingency plan atomic components, generate emergency contingency plan task templates, and call the emergency contingency plan task templates to execute the contingency plans and obtain contingency plan execution results. The data storage layer is used to store the emergency response plan task template and the execution results of the plan.

2. The modular emergency response system according to claim 1, characterized in that, The application service layer is also used for: Based on the system service tree, emergency response task templates are classified according to multiple dimensions, including scenario dimensions, which include at least one of disaster recovery switching scenarios, emergency card scenarios, and batch scheduling scenarios.

3. The modular emergency response system according to claim 1, characterized in that, The interaction layer is also used for: Display a visual interface; The user's pre-plan arrangement operation instructions are received through the visual interface. The pre-plan arrangement operation instructions are used to arrange pre-defined atomic components. The atomic components include at least one of the following: script execution component, traffic scheduling component, registry center service component, database high availability switching component, application start / stop component, and API call component.

4. The modular emergency response system according to claim 1, characterized in that, The application service layer is also used for: In response to the pre-plan arrangement operation command, the corresponding pre-plan atomization components are assembled and configured based on a plurality of predefined pre-plan atomization components; The emergency response task template is generated based on the configuration parameters of the atomization components and the connection relationships between the atomization components.

5. The modular emergency response system according to claim 4, characterized in that, The configuration parameters include the execution mode of each atomic component of the plan, and the execution mode includes direct execution mode and remote execution mode; The direct execution mode means that it has no dependency on the execution environment, and the system directly allocates processes to execute script commands. The remote execution mode requires the user to specify remote host information, which includes at least one of the following: host address, execution account, and execution path.

6. The modular emergency response system according to claim 1, characterized in that, The application service layer is also used for: During the execution of the contingency plan, execution control operations between atomic components are adopted to control the execution process between atomic components. The execution control operations between atomic components include at least one of the following: pause and then continue, redo steps, intelligent skip after failure, and automatic pause after failure. The execution process within an atomic component is controlled by execution control operations within the atomic component. These execution control operations include at least one of instance-level failure replay, ignoring failed instances, and skipping all instances.

7. The modular emergency response system according to claim 1, characterized in that, The interaction layer is also used for: Receive user requests to view pre-plan information; The application service layer is also used for: In response to the request to view the contingency plan information, obtain the target contingency plan information that the user wants to view; The target contingency plan information includes at least one of the following: a list of contingency plan templates, contingency plan task execution history, contingency plan task execution details, and operation records. The contingency plan task execution details include at least one of the following: overall execution status, atomic component execution status, specific instance execution status, and logs.

8. A modular emergency response plan arrangement and execution method, characterized in that, The modular emergency response plan arrangement and execution method includes: Receive user's pre-planning operation instructions; In response to the contingency plan arrangement operation command, the contingency plan is arranged based on multiple predefined contingency plan atomic components to generate an emergency contingency plan task template, and the emergency contingency plan task template is invoked to execute the contingency plan and obtain the contingency plan execution result; Store the emergency response plan task template and the execution results of the plan.

9. An apparatus comprising: processor; And a memory configured to store computer-executable instructions, which, when executed, cause the processor to perform the modular contingency plan arrangement and execution method according to any one of claims 1 to 7.

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 modular emergency plan arrangement and execution method described in any one of claims 1 to 7.

Images