Emergency plan updating method and device, storage medium and product
By generating solution update work orders and status maintenance work orders in a private cloud environment, emergency plans are dynamically updated, solving the problems of inaccurate and untimely maintenance of traditional emergency plans, and realizing real-time dynamic updates and effective execution of emergency plans.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-12-16
- Publication Date
- 2026-03-13
AI Technical Summary
Traditional emergency plans are not maintained accurately or in a timely manner in private cloud environments, which makes them unable to be effectively executed in the event of a failure and makes it impossible to detect expired plans in a timely manner, resulting in a disconnect between the plans and the actual environment.
In a private cloud environment, update work orders and status maintenance work orders are generated. By monitoring the operational status of the private cloud environment, emergency plans are dynamically updated, and the risk of plan failure caused by change events is proactively identified, thereby achieving automated identification and handling of emergency plans.
It enables real-time dynamic updates of emergency plans, ensuring their effective execution even under dynamic changes in the private cloud environment and preventing plan failures due to environmental changes.
Smart Images
Figure CN121664650A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of cloud platform operation and maintenance technology, and in particular to an emergency plan update method, device, storage medium and product. Background Technology
[0002] In modern cloud platform systems based on private cloud architectures, the high availability and business continuity of application services heavily rely on pre-defined contingency plans. These plans typically include specific failover procedures, dependent automation tool scripts, cloud resources involved, and preconditions. With the continuous advancement of application migration to the cloud and distributed architectures, application releases and operational changes are becoming more frequent, and operational channels are becoming more diversified. Changes in automation tools and application architectures can render existing contingency plans ineffective.
[0003] Currently, the maintenance of contingency plans typically employs a reactive response or periodic manual review model. Only after a failure occurs and the plan fails to execute does the operations and maintenance personnel retrospectively review and revise the plan; alternatively, a designated person periodically checks and updates relevant plan documents based on known change logs. This model heavily relies on the experience, memory, and initiative of programmers. Due to the frequent and complex changes in the private cloud environment, operations and maintenance personnel cannot promptly and accurately identify outdated contingency plans, leading to a disconnect between the plans and the actual environment, rendering them ineffective in the event of a real failure.
[0004] The above content is only used to help understand the technical solution of this application and does not represent an admission that the above content is prior art. Summary of the Invention
[0005] The main purpose of this application is to provide an emergency plan update method, device, storage medium and product, which aims to solve the technical problem that traditional emergency plans cannot be effectively implemented due to inaccurate or untimely maintenance.
[0006] To achieve the above objectives, this application proposes an emergency response plan updating method, which includes: In a private cloud environment, if a change event affects the emergency response plan, generate a plan update work order; The private cloud environment is subjected to operation status detection processing to obtain detection processing results, and a status maintenance work order is generated based on the detection processing results. The detection processing results include at least one of inspection results and check results. The inspection results are the processing results of health status inspection, and the check results are the processing results of switch condition check. The emergency response plan is dynamically updated based on the updated work orders and status maintenance work orders.
[0007] In one embodiment, the step of generating a solution update work order when a change event in a private cloud environment affects the emergency response plan includes: Acquire change events in the private cloud environment, wherein the types of change events include release events for automation tools and release events for applications; When the change event is a release event of an automated tool, an evaluation request for the handling actions and handling solutions of the automated tool is sent to the host computer, and the evaluation results output by the host computer are received. If the assessment results affect the emergency response plan, a plan update work order will be generated; When the change event is an application release event, a solution update work order is generated if the application deployment architecture, domain name, and cloud service resources meet the preset application generation conditions.
[0008] In one embodiment, the step of performing operational status detection processing on the private cloud environment to obtain the detection processing result includes: In the case that the operation status detection process includes inspection processing, the monitoring indicators and event data of the application in the private cloud environment are obtained; Based on the monitoring metrics and event data, the success rate, response time, and resource utilization of the application are inspected to obtain inspection results.
[0009] In one embodiment, the step of performing operational status detection processing on the private cloud environment to obtain the detection processing result further includes: In the case where the operation status detection process includes an inspection process, the domain name mounting status, availability zone distribution quantity, and switching strategy of the application in the private cloud environment are checked to obtain the inspection results.
[0010] In one embodiment, the step of generating a status maintenance work order based on the detection processing result includes: If the detection and processing results include inspection results, and the inspection results do not meet the preset health conditions, a status maintenance work order is generated based on the inspection results. If the detection and processing results include inspection results, and the inspection results do not meet the preset switching conditions, a status maintenance work order is generated based on the inspection results. If the detection and processing results include inspection results and check results, and the inspection results do not meet the preset health conditions and the check results do not meet the preset switching conditions, a status maintenance work order is generated based on the inspection results and the check results.
[0011] In one embodiment, the step of dynamically updating the emergency plan based on the scheme update work order and the status maintenance work order includes: Update the processing results of the work order according to the above scheme, and update the handling steps or configuration information related to the change event in the emergency plan; Based on the processing results of the status maintenance work order, the environmental prerequisites upon which the execution of the emergency plan depends are corrected or recorded.
[0012] In one embodiment, after the step of dynamically updating the emergency plan based on the plan update work order and the status maintenance work order, the method further includes: The updated emergency response plan was verified and tested, and the test results were obtained. The effectiveness indicators of the updated emergency response plan will be evaluated based on the test results. If the effectiveness indicators do not meet the preset effectiveness conditions, an optimization work order is generated and the emergency plan is optimized based on the optimization work order to obtain a new emergency plan. Based on the new emergency plan, return to the step of performing a verification test on the updated emergency plan and obtaining the test results.
[0013] In addition, to achieve the above objectives, this application also proposes an electronic device, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the emergency plan update method as described above.
[0014] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the emergency plan update method described above.
[0015] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the emergency plan update method described above.
[0016] One or more technical solutions proposed in this application have at least the following technical effects: In this embodiment, when a change event in the private cloud environment affects the emergency response plan, a plan update work order is generated. The private cloud environment undergoes operational status detection processing to obtain the detection results, and a status maintenance work order is generated based on these results. The detection results include at least one of inspection results and check results; the inspection results are the processing results of health status inspections, and the check results are the processing results of switch condition checks. Based on the plan update work order and the status maintenance work order, the emergency response plan is dynamically updated. By proactively identifying the risk of plan failure caused by change events such as application releases and tool upgrades, the system avoids problems where the plan fails due to dynamic environmental changes and goes undetected, thus achieving automated identification and handling of emergency response plan failure risks. By performing operational status detection on the private cloud environment and generating status maintenance work orders based on the detection results, the system can continuously detect whether key preconditions such as application health and resource status are met, and proactively trigger repairs when conditions are missing, achieving continuous and proactive verification of the preconditions for emergency response plan execution. Emergency plans are dynamically updated based on solution update work orders and status maintenance work orders, enabling them to automatically evolve and continuously update with the dynamic changes in the cloud environment. This achieves real-time dynamic updates of emergency plans and ensures that they can be effectively executed even under dynamic changes in the private cloud environment. Attached Figure Description
[0017] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.
[0018] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0019] Figure 1 This is a flowchart illustrating the first embodiment of the emergency response plan update method of this application; Figure 2 A simplified flowchart illustrating the solution update work order generation method provided in Embodiment 1 of this application; Figure 3 A simplified flowchart illustrating the emergency response plan update method provided in Embodiment 1 of this application; Figure 4 This is a flowchart illustrating the second embodiment of the emergency response plan update method of this application; Figure 5 This is a schematic diagram of the emergency plan update method provided in Embodiment 1 of this application; Figure 6This is a schematic diagram of the device structure of the hardware operating environment involved in the emergency plan update method in this application embodiment. Detailed Implementation
[0020] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.
[0021] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.
[0022] The main solution in this application embodiment is: In a private cloud environment, if a change event affects the emergency response plan, generate a plan update work order; The private cloud environment is subjected to operational status detection and processing to obtain the detection and processing results. A status maintenance work order is generated based on the detection and processing results. The detection and processing results include at least one of the inspection results and the check results. The inspection results are the processing results of the health status inspection, and the check results are the processing results of the switch condition check. Emergency response plans are dynamically updated based on solution update work orders and status maintenance work orders.
[0023] In modern cloud platform systems based on private cloud architectures, the high availability and business continuity of application services heavily rely on pre-defined contingency plans. These plans typically include specific failover procedures, dependent automation tool scripts, cloud resources involved, and preconditions. With the continuous advancement of application migration to the cloud and distributed architectures, application releases and operational changes are becoming more frequent, and operational channels are becoming more diversified. Changes in automation tools and application architectures can render existing contingency plans ineffective.
[0024] Currently, the maintenance of contingency plans typically employs a reactive response or periodic manual review model. Only after a failure occurs and the plan fails to execute does the operations and maintenance personnel retrospectively review and revise the plan; alternatively, a designated person periodically checks and updates relevant plan documents based on known change logs. This model heavily relies on the experience, memory, and initiative of programmers. Due to the frequent and complex changes in the private cloud environment, operations and maintenance personnel cannot promptly and accurately identify outdated contingency plans, leading to a disconnect between the plans and the actual environment, rendering them ineffective in the event of a real failure.
[0025] This application provides a solution where, in the case of a change event affecting the emergency response plan in a private cloud environment, a plan update work order is generated. The private cloud environment undergoes operational status detection processing to obtain the detection results, and a status maintenance work order is generated based on these results. The detection results include at least one of inspection results and check results; the inspection results are the processing results of health status inspections, and the check results are the processing results of switchover condition checks. Based on the plan update work order and the status maintenance work order, the emergency response plan is dynamically updated. By proactively identifying the risk of plan failure caused by change events such as application releases and tool upgrades, the system avoids problems where the plan fails due to dynamic environmental changes and remains undetected, thus achieving automated identification and handling of emergency response plan failure risks. By performing operational status detection on the private cloud environment and generating status maintenance work orders based on the detection results, the system can continuously detect whether key preconditions such as application health and resource status are met, and proactively trigger repairs when conditions are missing, achieving continuous and proactive verification of the preconditions for emergency response plan execution. Emergency plans are dynamically updated based on solution update work orders and status maintenance work orders, enabling them to automatically evolve and continuously update with the dynamic changes in the cloud environment. This achieves real-time dynamic updates of emergency plans and ensures that they can be effectively executed even under dynamic changes in the private cloud environment.
[0026] It should be noted that the execution subject of this embodiment can be a computing service device with data processing, network communication and program running functions, such as a tablet computer, personal computer, mobile phone, etc., or an electronic device capable of realizing the above functions.
[0027] Based on this, this application provides a method for updating an emergency response plan, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the emergency response plan update method of this application.
[0028] In this embodiment, the emergency plan update method includes steps S10 to S30: Step S10: If a change event in the private cloud environment has an impact on the emergency response plan, generate a plan update work order; It should be noted that the embodiments of this application do not operate in the order of steps S10 to S30. That is, when a change event occurs in the private cloud environment or an abnormality occurs in the operating status of the private cloud environment, a corresponding work order will be generated to dynamically update the emergency plan. A private cloud environment refers to a cloud computing infrastructure built or dedicated by an enterprise, providing resource-based services such as computing, storage, and networking. In the embodiments of this application, it specifically refers to an environment running business applications that require high availability. A change event refers to any operation or process in a private cloud environment that may cause changes in system configuration, application behavior, or dependencies. This mainly includes release events for automation tools and release events for applications. Release events for automation tools refer to the creation, updating, or decommissioning of standardized scripts, processes, or software packages used for operation and maintenance. Release events for applications refer to code version updates, configuration changes, and deployment activities such as the creation, modification, or destruction of cloud resources associated with business applications. An emergency response plan is a structured document or executable script that guides a series of actions and procedures to be performed to restore service in the event of a specific failure, such as server crash or service unavailability. These actions include switching traffic, restarting the service, the order of actions, and decision logic.
[0029] Understandably, in practical applications, by monitoring changes in the private cloud platform in real time, when a change event is detected, such as an automated script being uploaded or a new version of an application being deployed, the private cloud platform does not directly execute the change event. Instead, it first compares and analyzes it with the contingency plan to determine whether the change will cause a step, dependency, or prerequisite of a certain plan to become invalid. If the analysis concludes that it will, a solution update work order will be automatically created in the operation and maintenance work order.
[0030] In one feasible implementation, see Figure 2 , Figure 2 This is a simplified flowchart of the scheme update work order generation method provided in Embodiment 1 of this application. Step S10 may include steps S11 to S14: Step S11: Obtain change events in the private cloud environment, where the types of change events include release events for automation tools and release events for applications; Step S12: When the change event is the release event of the automation tool, send an evaluation request for the handling action and handling plan of the automation tool to the host computer, and receive the evaluation result output by the host computer. Step S13: If the assessment results have an impact on the emergency response plan, generate a plan update work order; Step S14: When the change event is an application release event, if the application deployment architecture, domain name, and cloud service resources meet the preset application generation conditions, generate a solution update work order.
[0031] It should be noted that the solution update work order is used to track tasks that require modifications to the emergency plan itself due to changes in events, such as modifying the sequence of steps in the emergency plan or updating scripts. The preset application generation conditions are used to determine whether the application deployment architecture, domain name, and cloud service resources meet the requirements for generating a solution update work order.
[0032] Understandably, change events are acquired by embedding query programs at key nodes in the pipeline of the private cloud environment or by subscribing to data change logs in the configuration management database. The types of change events captured include release events for automated tools and application release events. The acquired change events include the change subject (e.g., application name, tool name) and the change type (e.g., release, update, decommissioning). Using the change subject as a keyword, a full-text search or dependency query is performed in the emergency plan database to find all emergency plans that reference that subject. If it is a release event for an automated tool, all related emergency plans found through full-text search or dependency query and their specific handling actions are displayed on the change executor's interface. The system provides a manual confirmation interface, allowing the change executor to determine whether the change to the automated tool will cause scripts or calling methods in related solutions to become invalid. If it will cause scripts or calling methods in related solutions to become invalid, the assessment result is "impact exists"; if it will not cause scripts or calling methods in related solutions to become invalid, the assessment result is "no impact exists". Simultaneously, the private cloud platform will also evaluate this automation tool change. If the evaluation result indicates an impact, a solution update ticket will be generated; if the evaluation result indicates no impact, no solution update ticket will be generated. By adopting a system prompt and manual confirmation model for the automation tool release event, the accuracy of the evaluation results is improved.
[0033] Furthermore, for application release events, the system retrieves the application's architecture description files before and after the release. By comparing the two versions of the files using a rules engine, it automatically determines whether the high-availability deployment architecture has changed, such as from a single availability zone to multiple availability zones, the list of domain names used for external services, or the types and identifiers of the cloud service resources it depends on. If any such changes are detected, it determines that the preset application generation conditions are met, and a solution update work order is generated. By employing an automatic comparison mode using a rules engine for application release events, the efficiency of comparing high-availability deployment architectures, domain names, and cloud service resources is improved, thereby enhancing overall evaluation efficiency.
[0034] Step S20: Perform operational status detection processing on the private cloud environment, obtain the detection processing results, and generate a status maintenance work order based on the detection processing results. The detection processing results include at least one of the inspection results and the check results. The inspection results are the processing results of the health status inspection, and the check results are the processing results of the switch condition check. It should be noted that health status inspection refers to the process of querying the monitoring system to obtain quantitative indicators and events reflecting the operational status of application services, and determining whether they are in a normal service state based on preset thresholds. These quantitative indicators include query rate per second, average response time, and CPU utilization. If any of these indicators fails to meet the preset threshold, a corresponding alarm event will occur. Switchover condition check refers to verifying whether the private cloud environment has the necessary technical configuration and resource status for a successful switchover in a fault-tolerant scenario. Status maintenance work orders are used to track tasks that require repair of the operating system or resource configuration due to abnormal environmental conditions.
[0035] Understandably, each application in the private cloud environment undergoes proactive scanning at fixed intervals. This scanning operates on two parallel dimensions: first, checking the application's operational health, such as slow response times or alerts; and second, verifying that its technical architecture meets the stringent requirements for failover, such as domain name configuration and multi-availability zone distribution. If either dimension detects an anomaly or fails to meet preset conditions, a status maintenance work order is automatically generated, specifying which application, health metric, or failover condition is problematic. Health status inspection determines whether the target application is currently in a state capable of providing normal service. By analyzing real-time monitoring metrics and events, it identifies existing operational issues that may affect service stability, such as CPU utilization exceeding 95%, which indicates an abnormal health status. Even if the contingency plan is correct, performing a failover in an unhealthy private cloud environment will exacerbate the failure. Failover condition checks verify whether the application in the private cloud environment is pre-configured with the necessary architecture and resources to support failover. It checks the application's "static" configuration or "ready" state in the private cloud environment, rather than real-time performance. For example, check whether an application claiming to have "dual backup within the same city" capability actually has two instances configured in different availability zones on its load balancer backend; or check whether the business domain name has correctly resolved to the current service instance. If these preconditions are not met, any failover scheme relying on them will inevitably fail upon triggering. The title, description, and assigned object in the status maintenance work order are dynamically generated based on which specific condition is not met. For example, for an abnormal health status, the work order title could be "Emergency application A's CPU is overloaded, requiring emergency scaling," and assigned to the application operations team. For a failover condition, the work order title could be "Risk application B's domain name is not mounted, lacking disaster recovery capability," and assigned to the platform or operations team. This design ensures that different types of problems can be accurately identified and assigned to the appropriate handlers, improving remediation capabilities and guaranteeing real-time dynamic updates to emergency plans.
[0036] In one feasible implementation, the steps of performing operational status detection processing on the private cloud environment and obtaining the detection processing results include: In the context of operational status detection and processing, including inspection processing, acquire monitoring metrics and event data of applications in the private cloud environment; Based on monitoring metrics and event data, the success rate, response time, and resource utilization of the application are inspected to obtain inspection results.
[0037] It should be noted that the system obtains monitoring metrics and event data of applications in the private cloud environment by calling the application programming interface (API) of the integrated monitoring system. It selectively pulls or receives key performance indicator data of the target application within the most recent inspection cycle, as well as all alarm events generated within the same time period. Based on the monitoring metrics and event data, the system performs inspections on the application's success rate, response time, and resource utilization. The inspection results are executed by an embedded rule engine, which compares the acquired raw data with a set of preset health conditions to determine whether to generate a status maintenance work order. The application success rate inspection calculates the proportion of successful transactions to total transactions for the application within the inspection cycle. The preset health condition is that the overall application success rate should not be lower than 99%. If the calculated result is lower than the threshold, the inspection result for this dimension is considered abnormal. The response time inspection analyzes the latency distribution of application requests. The preset health condition is that the response time should not exceed 200 milliseconds. If it exceeds the threshold, the inspection result for this dimension is considered abnormal. Resource utilization monitoring involves the rule engine checking the application's computing resource consumption, such as CPU utilization and memory utilization. A preset health condition is that CPU utilization should not exceed 80%. If resource utilization exceeds this threshold, the monitoring result for this dimension is considered abnormal. Simultaneously, the rule engine parses event data; if there are unresolved critical alarms, the monitoring result will also be abnormal. The final monitoring result is a judgment, typically indicating whether the preset health conditions are met or not. If any dimension's monitoring result is abnormal, the overall system is deemed to fail to meet the preset health conditions, and a status maintenance work order is generated.
[0038] Understandably, monitoring an application's success rate, response time, and resource utilization across three dimensions constitutes a quantifiable core technical benchmark for assessing its health. Compared to monitoring a single metric, this approach can more comprehensively and earlier identify potential system vulnerabilities that could affect the smooth execution of contingency plans. The preset health conditions are not fixed; their specific thresholds and rules can be customized and dynamically adjusted based on different applications' service level agreements, business importance, and historical operational baselines.
[0039] In one feasible implementation, the step of performing operational status detection processing on the private cloud environment and obtaining the detection processing results further includes: In the context of operational status detection and processing, which includes inspection processes, the domain name mounting status, availability zone distribution, and switching strategies of applications in the private cloud environment are checked, and the inspection results are obtained.
[0040] It's important to note that checking the domain name mounting status verifies whether the business domain name has been correctly resolved and bound to the currently running application. Checking the number of availability zones verifies whether the application is deployed in multiple availability zones. Availability zones are physically isolated areas within the same region, and multi-availability zone deployment is fundamental to ensuring high availability. Checking the failover policy verifies whether the current resource configuration meets the requirements of the private cloud environment for performing specific failover operations, such as hot migration and disaster recovery failover.
[0041] Understandably, the process involves calling the DNS resolution interface of the domain name system to obtain the current DNS records for the business domain name. Simultaneously, the control plane interface of the load balancer or service mesh is called to obtain a list of registered backend application instances. By comparing the current DNS records of the business domain name with the list of registered backend application instances, it is verified whether the domain name accurately points to all expected healthy application instances. If any domain name is not resolved or resolves to an incorrect instance, this check result is marked as abnormal. The availability zone information of all running instances of the target application is obtained by querying the metadata service or resource orchestration service of the private cloud platform. The number of different availability zones these instances are distributed across is counted, and based on the application's preset high availability level, it is determined whether the actual distribution meets the requirements. If instances are concentrated in a single availability zone, this check result is marked as abnormal. Based on the application's disaster recovery design, it is verified whether its resource configuration complies with the platform-level policies necessary for performing specific failover operations. For example, it checks whether block storage has enabled cross-availability zone replication, whether the database has configured synchronous replication links, or whether the cloud host has been added to a resource pool supporting hot migration, achieved by calling the policy query interface of the corresponding cloud service. If the resource configuration does not support the predetermined failover action, this check result is marked as abnormal. If any check result is abnormal, the overall check result will fail to meet the preset switching conditions, automatically triggering the generation of a status maintenance work order. By assessing the application's technical feasibility across three dimensions to execute the emergency plan, the core premise is to proactively detect and generate status maintenance work orders before a failure occurs, thus improving the efficiency of emergency plan execution.
[0042] In one feasible implementation, the step of generating a status maintenance work order by detecting the processing result includes: If the detection and processing results include the inspection results, and the inspection results do not meet the preset health conditions, a status maintenance work order is generated based on the inspection results. If the detection and processing results include the inspection results, and the inspection results do not meet the preset switching conditions, a status maintenance work order is generated based on the inspection results. If the detection and processing results include inspection results and check results, and the inspection results do not meet the preset health conditions and the check results do not meet the preset switching conditions, a status maintenance work order is generated based on the inspection results and check results.
[0043] It is understandable that health checks and switchover condition checks of the private cloud environment are performed in parallel. When either result fails to meet the preset conditions, a status maintenance work order will be generated.
[0044] Step S30: Dynamically update the emergency plan based on the solution update work order and status maintenance work order.
[0045] Understandably, the remediation results of solution update work orders and status maintenance work orders are automatically and synchronously fed back to the emergency plan's knowledge base. This ensures that every remediation action against a risk is directly translated into an effective dynamic update of the plan. The knowledge base consists of a large amount of high-value data accumulated during the plan's update process. This high-value data includes the correlation between change event types and plan update types, the most likely abnormal states during the operation of the private cloud platform, and the corresponding plan updates required for different types of abnormal states. During each update, plan update logs, inspection failure records, and exercise result data are structured and stored in the knowledge base. This knowledge base can be used to recommend validated plan templates for new applications and to issue alerts for situations where work orders are frequently triggered due to similar state issues.
[0046] In one feasible implementation, see Figure 3 , Figure 3 This is a simplified flowchart of the emergency response plan update method provided in Embodiment 1 of this application. Step S30 may include steps S31 to S32: Step S31: Based on the processing result of the work order update, update the handling steps or configuration information related to the change event in the emergency plan; Step S32: Based on the processing results of the status maintenance work order, correct or record the environmental prerequisites upon which the emergency plan execution depends.
[0047] It should be noted that for solution update work orders triggered by change events, the processing results, such as modified scripts and updated resource lists, directly relate to the executable content of the solution itself. Therefore, by updating the handling steps and configuration information related to change events in the emergency plan, the emergency plan can be updated, such as replacing outdated commands and adjusting process branch logic. For status maintenance work orders triggered by abnormal environment conditions, the processing results, such as fixing domain name configurations and expanding resources, reflect the restoration of the solution execution environment.
[0048] Understandably, by implementing zoned updates to the emergency response plan, precise updates to different dimensions of the plan have been achieved.
[0049] Based on the first embodiment of this application, in the second embodiment of this application, the content that is the same as or similar to that in the first embodiment described above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 4 , Figure 4 This is a flowchart illustrating the second embodiment of the emergency response plan update method of this application. After step S30, the emergency response plan update method further includes steps S40 to S70: Step S40: Verify and test the updated emergency response plan to obtain the test results; Step S50: Evaluate the effectiveness indicators of the updated emergency response plan based on the test results; Step S60: If the effectiveness indicators do not meet the preset effectiveness conditions, generate an optimization work order and optimize the emergency plan based on the optimization work order to obtain a new emergency plan. Step S70: Based on the new emergency plan, return to the execution step of verifying and testing the updated emergency plan to obtain the test results.
[0050] For example, a simulated fault is automatically injected into the pre-release environment, triggering the newly updated contingency plan. The entire execution trajectory of the plan, the time consumed at each step, resource change status, and the final recovery result are monitored and recorded, forming structured test result data. Based on a preset evaluation model, one or more key effectiveness indicators are calculated from the test results. The calculated effectiveness indicators are compared with preset effectiveness conditions. If they are not met, it indicates that the current plan still has room for optimization. The system automatically generates an optimization work order, which not only indicates the "failure" but also correlates the test result data to analyze the bottleneck. Based on this work order, plan maintenance personnel or automated scripts will make targeted improvements to the weak points of the plan, thereby generating a new contingency plan. When the new contingency plan is generated, the system automatically uses it as input to re-trigger the verification test process in step S40. This means that the optimized plan will immediately undergo a new round of empirical verification.
[0051] Understandably, by evaluating the effectiveness indicators of the updated emergency response plan based on test results, emergency response capabilities are measured, providing a clear and definite basis for subsequent optimization decisions regarding the dynamic updating of the emergency response plan. The process of returning to the updated emergency response plan to perform verification tests and obtain test results will continue until the resulting emergency response plan's effectiveness indicators meet preset effectiveness conditions, thus improving the emergency response plan's update capability.
[0052] Specifically, refer to Figure 5 , Figure 5This is a schematic diagram of the emergency plan update method provided in Embodiment 1 of this application. "Preservation" refers to adjusting the emergency plan for the private cloud environment based on changes in events or operational status. The dynamic changes in events are the changing factors, which can lead to changes in the objects and tools to be handled, such as changes in deployment architecture, framework type, and application status. These changes all represent changes in the operational status of the private cloud environment. Changes in handling tools include atomic changes and platform configuration changes, which also represent changes in the tools of the private cloud environment. Correspondingly, for each event change, a corresponding plan update work order and a status maintenance work order are generated. Based on the plan update work order, preservation measures include atomic release impact assessment and platform configuration variable impact assessment, used to evaluate the impact of changes in the private cloud environment on the existing emergency plan. If the assessment result indicates an impact, a corresponding plan update work order is generated. Application architecture and status checks, and technical level checks, involve performing operational status detection processing on the private cloud environment to obtain detection results. A status maintenance work order is then generated based on these detection results. The detection results include at least one of inspection results and check results. Inspection results are the processing results of health status inspections, and check results are the processing results of switchover condition checks. This application determines whether a preservation anomaly occurs due to event changes, generates a corresponding work order based on the anomaly, completes application maintenance according to the work order, generates a new emergency plan, and verifies the new emergency plan, thus completing the process loop.
[0053] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the emergency response plan update method of this application. Any simple modifications based on this technical concept are within the protection scope of this application.
[0054] This application provides an electronic device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the emergency plan update method in Embodiment 1 above.
[0055] The following is for reference. Figure 6 The diagram illustrates a structural schematic of an electronic device suitable for implementing embodiments of this application. The electronic devices in these embodiments may include, but are not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Descriptions), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 6 The electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.
[0056] like Figure 6 As shown, the electronic device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 1002 or a program loaded from a storage device 1003 into a random access memory (RAM) 1004. The RAM 1004 also stores various programs and data required for the operation of the electronic device. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to the I / O interface 1006: input devices 1007 including, for example, a touchscreen, touchpad, keyboard, mouse, image sensor, microphone, accelerometer, gyroscope, etc.; output devices 1008 including, for example, a liquid crystal display (LCD), speaker, vibrator, etc.; storage devices 1003 including, for example, magnetic tape, hard disk, etc.; and communication devices 1009. Communication device 1009 allows electronic devices to communicate wirelessly or wiredly with other devices to exchange data. While electronic devices with various systems are shown in the figures, it should be understood that implementation or possession of all the systems shown is not required. More or fewer systems may be implemented alternatively.
[0057] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from ROM 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.
[0058] The electronic device provided in this application employs the emergency plan dynamic update method described in the above embodiments, aiming to solve the technical problem that traditional emergency plans cannot be effectively implemented due to inaccurate or untimely maintenance. Compared with the prior art, the beneficial effects of the electronic device provided in this application are the same as those of the emergency plan update method provided in the above embodiments, and other technical features of the electronic device are the same as those disclosed in the method of the previous embodiment, and will not be repeated here.
[0059] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.
[0060] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.
[0061] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, which are used to execute the emergency plan update method in the above embodiments.
[0062] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.
[0063] The aforementioned computer-readable storage medium may be included in an electronic device or may exist independently without being assembled into an electronic device.
[0064] The aforementioned computer-readable storage medium carries one or more programs. When the aforementioned one or more programs are executed by an electronic device, the electronic device causes the electronic device to: assess the impact of change events in the private cloud environment on the emergency response plan, and generate a plan update work order based on the assessment results; perform health status inspections and switchover condition checks on the private cloud environment, and generate a status maintenance work order based on at least one of the inspection results and the check results; and dynamically update the emergency response plan based on the plan update work order and the status maintenance work order.
[0065] Computer program code for performing the operations of this application can be written in one or more programming languages or a combination thereof, including object-oriented programming languages such as Java, Smalltalk, and C++, and conventional procedural programming languages such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).
[0066] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.
[0067] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.
[0068] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., computer programs) for executing the above-described emergency plan update method. This aims to solve the technical problem that traditional emergency plans cannot be effectively executed due to inaccurate or untimely maintenance. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the emergency plan update method provided in the above embodiments, and will not be repeated here.
[0069] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the emergency plan update method described above.
[0070] The computer program product provided in this application aims to solve the technical problem that traditional emergency response plans cannot be effectively implemented due to inaccurate or untimely maintenance. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as those of the emergency response plan update method provided in the above embodiments, and will not be repeated here.
[0071] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.
Claims
1. A method for updating an emergency response plan, characterized in that, The emergency response plan update method includes: In a private cloud environment, if a change event affects the emergency response plan, generate a plan update work order; The private cloud environment is subjected to operation status detection processing to obtain detection processing results, and a status maintenance work order is generated based on the detection processing results. The detection processing results include at least one of inspection results and check results. The inspection results are the processing results of health status inspection, and the check results are the processing results of switch condition check. The emergency response plan is dynamically updated based on the updated work orders and status maintenance work orders.
2. The emergency response plan updating method as described in claim 1, characterized in that, When a change event in a private cloud environment affects the emergency response plan, the steps for generating a plan update work order include: Acquire change events in the private cloud environment, wherein the types of change events include release events for automation tools and release events for applications; When the change event is a release event of an automated tool, an evaluation request for the handling actions and handling solutions of the automated tool is sent to the host computer, and the evaluation results output by the host computer are received. If the assessment results affect the emergency response plan, a plan update work order will be generated; When the change event is an application release event, a solution update work order is generated if the application deployment architecture, domain name, and cloud service resources meet the preset application generation conditions.
3. The emergency response plan updating method as described in claim 1, characterized in that, The step of performing operational status detection processing on the private cloud environment to obtain the detection processing result includes: In the case that the operation status detection process includes inspection processing, the monitoring indicators and event data of the application in the private cloud environment are obtained; Based on the monitoring metrics and event data, the success rate, response time, and resource utilization of the application are inspected to obtain inspection results.
4. The emergency response plan updating method as described in claim 1, characterized in that, The step of performing operational status detection processing on the private cloud environment to obtain the detection processing result further includes: In the case where the operation status detection process includes an inspection process, the domain name mounting status, availability zone distribution quantity, and switching strategy of the application in the private cloud environment are checked to obtain the inspection results.
5. The emergency response plan updating method as described in claim 1, characterized in that, The step of generating a status maintenance work order based on the detection and processing results includes: If the detection and processing results include inspection results, and the inspection results do not meet the preset health conditions, a status maintenance work order is generated based on the inspection results. If the detection and processing results include inspection results, and the inspection results do not meet the preset switching conditions, a status maintenance work order is generated based on the inspection results. If the detection and processing results include inspection results and check results, and the inspection results do not meet the preset health conditions and the check results do not meet the preset switching conditions, a status maintenance work order is generated based on the inspection results and the check results.
6. The emergency response plan updating method as described in claim 1, characterized in that, The step of dynamically updating the emergency plan based on the updated work order and the status maintenance work order includes: Update the processing results of the work order according to the above scheme, and update the handling steps or configuration information related to the change event in the emergency plan; Based on the processing results of the status maintenance work order, the environmental prerequisites upon which the execution of the emergency plan depends are corrected or recorded.
7. The emergency response plan updating method as described in claim 1, characterized in that, After the step of dynamically updating the emergency plan based on the updated work order and the status maintenance work order, the method further includes: The updated emergency response plan was verified and tested, and the test results were obtained. The effectiveness indicators of the updated emergency response plan will be evaluated based on the test results. If the effectiveness indicators do not meet the preset effectiveness conditions, an optimization work order is generated and the emergency plan is optimized based on the optimization work order to obtain a new emergency plan. Based on the new emergency plan, return to the step of performing a verification test on the updated emergency plan and obtaining the test results.
8. An electronic device, characterized in that, The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the emergency plan update method as described in any one of claims 1 to 7.
9. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the emergency plan update method as described in any one of claims 1 to 7.
10. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the steps of the emergency plan update method as described in any one of claims 1 to 7.