Methods, computing devices, and storage media for traffic peak event contingency generation

Abstract

Embodiments of the present application relate to a method, a computing device and a storage medium for traffic peak event plan generation. The method comprises: obtaining event information, historical traffic data and service link information related to a target traffic peak event; obtaining a predicted traffic curve corresponding to the target traffic peak event according to the obtained event information and historical traffic data; inputting the predicted traffic curve and the service link information into a predetermined large language model to generate a corresponding structured plan; performing a logical check on the structured plan to deploy the structured plan that passes the logical check to a sandbox environment for testing; and in response to the test result for the sandbox environment satisfying a predetermined test condition, determining that the structured plan meets the release requirement. Thus, the traffic peak event plan generation efficiency, automation level and manual dependence can be significantly improved.

Description

Technical Field

[0001] Embodiments of the present invention relate to the field of artificial intelligence, and more specifically to a method, computing device, and storage medium for generating contingency plans for traffic peak events. Background Technology

[0002] With the development of e-commerce, online payment, marketing campaigns, and asset management, business systems typically face a surge in traffic within a short period during peak traffic events such as large-scale promotional activities and holiday promotions (also known as high-traffic events). To ensure stable system operation, it is usually necessary to develop contingency plans in advance, including traffic limiting, service degradation, and resource expansion.

[0003] The generation of existing traffic peak event contingency plans typically requires significant manual intervention. For example, before an event occurs, engineers query historical traffic data for similar events and manually estimate the peak traffic based on the scale of the current event. Subsequently, based on business processes such as order placement, payment, marketing, and asset changes, as well as the capacity of each service, they manually set rate limiting thresholds, degradation strategies, and scaling rules to form a contingency plan. Before the plan goes live, it also requires manual review and load testing, with repeated modifications based on the test results. During the event, on-duty engineers continuously monitor real-time traffic and system operating status, and manually adjust relevant parameters when actual traffic deviates from the expected levels.

[0004] However, the above methods have many problems: traffic forecasting and contingency plan development rely heavily on engineers' experience, resulting in low processing efficiency and difficulty in standardization; the traffic forecasting method is crude and cannot cope with new events or multiple events overlapping; the entire process involves multiple stages and multiple engineers, leading to high verification costs and limited coverage before the contingency plan goes live; after the contingency plan goes live, it usually adopts a fixed configuration, and when there is a deviation between the actual traffic and the forecast results, it is still necessary to continuously monitor and adjust manually, resulting in a slow response speed.

[0005] In summary, the existing methods for generating contingency plans for traffic peak events have the following shortcomings: they are highly dependent on manual intervention, have low efficiency in generating contingency plans, and have slow response speeds during actual operation. Summary of the Invention

[0006] To address the aforementioned issues, this invention provides a method, computing device, and storage medium for generating traffic peak event contingency plans, which can significantly improve the efficiency and automation of traffic peak event contingency plan generation and reduce reliance on manual intervention.

[0007] According to a first aspect of the present invention, a method for generating a contingency plan for a traffic peak event is provided, comprising: acquiring event information, historical traffic data, and service link information related to a target traffic peak event; acquiring a predicted traffic curve corresponding to the target traffic peak event based on the acquired event information and historical traffic data; inputting the predicted traffic curve and service link information into a predetermined large language model to generate a corresponding structured contingency plan, the structured contingency plan including one or more of rate limiting rules, degradation rules, and capacity expansion rules; performing a logical check on the structured contingency plan to deploy the structured contingency plan that passes the logical check to a sandbox environment for testing, the sandbox environment being isolated from the production environment where the structured contingency plan is actually deployed; and determining that the structured contingency plan meets release requirements in response to the test results for the sandbox environment meeting predetermined test conditions.

[0008] In some embodiments, the event information includes an event text description. Obtaining the predicted traffic curve corresponding to the target traffic peak event based on the acquired event information and historical traffic data includes: inputting the event text description into a predetermined large language model for retrieval in a historical event database to identify multiple reference historical events; determining a traffic amplification factor based on the scale of the target traffic peak event, the actual traffic peaks of the multiple reference historical events, and traffic changes; and determining the predicted traffic curve corresponding to the target traffic peak event based on the base traffic and the traffic amplification factor.

[0009] In some embodiments, in response to determining that the target traffic peak event overlaps with at least one other traffic peak event in time, the following are performed: dividing users into multiple non-overlapping user groups based on information about user participation in the traffic peak event, with each user assigned to only one user group; determining the degree of user overlap between the multiple traffic peak events based on the event participation of users in different user groups; and determining the traffic amplification factor generated by the superposition of the multiple traffic peak events based on the degree of user overlap, and determining the predicted traffic curve based on the traffic amplification factor.

[0010] In some embodiments, the method for generating contingency plans for traffic peak events further includes: obtaining a business request action corresponding to each traffic peak event, so as to record the user identifier, order identifier, and interface identifier corresponding to each business request action; in response to determining that multiple business request actions have the same user identifier, order identifier, and interface identifier, merging multiple business requests into the same real request in order to optimize the predicted traffic demand; and predicting the system capacity demand based on the optimized predicted traffic demand.

[0011] In some embodiments, obtaining the predicted traffic curve corresponding to the target traffic peak event based on the acquired event information and historical traffic data includes: acquiring real-time traffic data during the operation of the target traffic peak event; filtering out abnormal data from the real-time traffic data and determining the reliability of the real-time traffic data based on the amount of effective data, the degree of traffic fluctuation, and the integrity of the monitoring data; and fusing the real-time traffic data with historical traffic data based on the determined reliability to update the predicted traffic curve for the subsequent operation period of the target traffic peak event.

[0012] In some embodiments, inputting the predicted traffic curve and service link information into a predetermined large language model to generate a corresponding structured plan includes: determining the call relationship between services and resource constraint information based on the service link information; inputting the predicted traffic curve, call relationship and resource constraint information into a predetermined large language model; and generating a structured plan via the predetermined large language model, wherein each rule in the structured plan includes at least the target object, triggering condition and processing parameters.

[0013] In some embodiments, performing logical checks on structured plans includes: constructing a service relationship graph based on the call relationships and resource constraint information between services; associating the rules contained in the structured plan with each service node in the service relationship graph; and detecting whether the structured plan has one or more of the following logical problems based on the service relationship graph: circular dependency, excessive resource allocation, rule conflict, and unreachable core business links.

[0014] In some embodiments, deploying a structured contingency plan that has passed logical checks to a sandbox environment for testing includes: constructing a sandbox environment corresponding to the production environment at a preset scaling ratio; scaling the predicted traffic curve based on the preset scaling ratio and generating test traffic based on the time-series distribution of historical real traffic; and deploying the structured contingency plan to the corresponding execution component in the sandbox environment and injecting test traffic to obtain test operation metrics of the structured contingency plan.

[0015] In some embodiments, the method for generating contingency plans for traffic peak events further includes: adjusting the structured contingency plan based on the test results in response to determining that the test results in the sandbox environment do not meet the predetermined test conditions; repeatedly performing logic checks, sandbox testing, and structured contingency plan adjustments within a preset maximum number of attempts; and determining the optimal structured contingency plan from multiple versions of structured contingency plans in response to the fact that the predetermined test conditions are still not met after reaching the preset maximum number of attempts, and outputting test diagnostic information corresponding to the optimal structured contingency plan.

[0016] In some embodiments, the method for generating a traffic peak event contingency plan further includes: after the structured contingency plan is launched and running in the production environment, obtaining the actual operating traffic based on a preset period to calculate the traffic deviation between the actual operating traffic and the corresponding predicted traffic; and in response to determining that the traffic deviation is within a predetermined safe and adjustable range, adjusting the parameters corresponding to the time period that has not yet occurred in the structured contingency plan according to the traffic deviation, so that the adjusted parameters do not exceed the safe and adjustable range of the corresponding parameters.

[0017] According to a second aspect of the invention, a computing device is provided, the computing device comprising: at least one processing unit; at least one memory coupled to the at least one processing unit and storing instructions for execution by the at least one processing unit, the instructions, when executed by the at least one processing unit, causing the device to perform steps according to the method of the first aspect.

[0018] According to a third aspect of the present invention, a computer-readable storage medium is provided, on which a computer program is stored, which, when executed by a machine, implements the method according to the first aspect.

[0019] As described above, the shortcomings of traditional methods for generating contingency plans for traffic peak events are: strong reliance on manual intervention, low efficiency in plan generation, and slow response speed during actual operation.

[0020] To at least partially address one or more of the aforementioned problems and other potential issues, an exemplary embodiment of the present invention proposes a method for generating contingency plans for traffic peak events. This method involves: acquiring event information, historical traffic data, and service link information related to a target traffic peak event; obtaining a predicted traffic curve corresponding to the target traffic peak event based on the acquired event information and historical traffic data; inputting the predicted traffic curve and service link information into a predetermined large language model to generate a corresponding structured contingency plan, which includes one or more of rate limiting rules, degradation rules, and capacity expansion rules; performing a logical check on the structured contingency plan to deploy the logically checked plan to a sandbox environment for testing, the sandbox environment being isolated from the production environment where the structured contingency plan is actually deployed; and determining that the structured contingency plan meets release requirements in response to the test results in the sandbox environment meeting predetermined test conditions.

[0021] Therefore, the above solution establishes an automated closed loop from traffic prediction, contingency plan generation, logic checking, sandbox testing to release decision. By introducing a large language model to automatically generate structured contingency plans, and performing logic checks and sandbox environment testing before release, the solution achieves standardization and automation of contingency plan generation, improves the efficiency of contingency plan writing, reduces reliance on manual labor, and improves the stability of contingency plans after they are launched by discovering contingency plan defects in advance through sandbox testing.

[0022] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

[0023] The above and other features, advantages, and aspects of the various embodiments of the present invention will become more apparent from the accompanying drawings and the following detailed description. In the drawings, the same or similar reference numerals denote the same or similar elements.

[0024] Figure 1 A schematic diagram of a system for implementing a method for generating traffic peak event contingency plans according to an embodiment of the present invention is shown.

[0025] Figure 2 A flowchart of a method for generating traffic peak event contingency plans according to an embodiment of the present invention is shown.

[0026] Figure 3 A flowchart of a method for obtaining a predicted traffic curve corresponding to a target traffic peak event according to an embodiment of the present invention is shown.

[0027] Figure 4 A flowchart of a method for updating the predicted flow curve for a flow peak event according to an embodiment of the present invention is shown.

[0028] Figure 5 A flowchart of a method for generating structured plans according to an embodiment of the present invention is shown.

[0029] Figure 6 A flowchart of a method for performing logical checks on structured plans according to an embodiment of the present invention is shown.

[0030] Figure 7 A flowchart of a method for sandbox testing of a structured proposal according to an embodiment of the present invention is shown.

[0031] Figure 8 A block diagram of an electronic device according to an embodiment of the present invention is shown. Detailed Implementation

[0032] The following description, in conjunction with the accompanying drawings, illustrates exemplary embodiments of the present invention, including various details to aid understanding. These details should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of the invention. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0033] The term "comprising" and its variations as used herein signify open inclusion, i.e., "including but not limited to". Unless otherwise stated, the term "or" means "and / or". The term "based on" means "at least partially based on". The terms "one example embodiment" and "one embodiment" mean "at least one example embodiment". The term "another embodiment" means "at least one additional embodiment". The terms "first", "second", etc., may refer to different or the same objects. Other explicit and implicit definitions may also be included below.

[0034] As described above, the shortcomings of traditional methods for generating contingency plans for traffic peak events are: strong reliance on manual intervention, low efficiency in plan generation, and slow response speed during actual operation.

[0035] To at least partially address one or more of the aforementioned problems and other potential issues, an exemplary embodiment of the present invention proposes a method for generating contingency plans for traffic peak events. This method involves: acquiring event information, historical traffic data, and service link information related to a target traffic peak event; obtaining a predicted traffic curve corresponding to the target traffic peak event based on the acquired event information and historical traffic data; inputting the predicted traffic curve and service link information into a predetermined large language model to generate a corresponding structured contingency plan, which includes one or more of rate limiting rules, degradation rules, and capacity expansion rules; performing a logical check on the structured contingency plan to deploy the logically checked plan to a sandbox environment for testing, the sandbox environment being isolated from the production environment where the structured contingency plan is actually deployed; and determining that the structured contingency plan meets release requirements in response to the test results in the sandbox environment meeting predetermined test conditions.

[0036] Therefore, the above solution establishes an automated closed loop from traffic prediction, contingency plan generation, logic checking, sandbox testing to release decision. By introducing a large language model to automatically generate structured contingency plans, and performing logic checks and sandbox environment testing before release, the solution achieves standardization and automation of contingency plan generation, improves the efficiency of contingency plan writing, reduces reliance on manual labor, and improves the stability of contingency plans after they are launched by discovering contingency plan defects in advance through sandbox testing.

[0037] Figure 1 A schematic diagram of a system 100 for implementing a method for generating traffic peak event contingency plans according to an embodiment of the present invention is shown. Figure 1 As shown, system 100 includes computing device 110, historical database 130, network 140, and user equipment 150.

[0038] User equipment 150 is configured to receive user input (e.g., event information, activity configuration, etc.); then send the user input to computing device 110 via network 140, where computing device 110 extracts event information from the user input; alternatively, user equipment 150 can invoke its onboard tools, models, and / or applications to parse and extract the user input, and send the obtained event information to computing device 110. User equipment 150 is also used to receive information such as predicted traffic curves, structured plans, and test results from computing device 110, and to interact with computing device 110 during plan generation, testing, and adjustment processes.

[0039] Regarding user devices 150, these include devices such as mobile phones, laptops, tablets, and desktop computers. Regarding users, these include engineers, administrators, and maintenance personnel.

[0040] Regarding historical database 130, it stores, for example, historical traffic data, historical event information, and a historical contingency plan library. Historical traffic data includes monitoring indicators such as the number of orders, payments, red envelope receipts, red envelope redemptions, and asset changes for similar past events. Historical event information includes, for example, event name, event type, event rule description, expected participation scale, and event start and end times. The historical contingency plan library stores multiple historical structured contingency plans, each of which includes, for example, action type, target audience, triggering conditions, specific parameters, and priority.

[0041] The computing device 110 receives input information from the user. The user can directly operate the computing device 110 to input information, or the user can input information through the user device 150 and send the user's input information to the computing device 110 through the user device 150.

[0042] The computing device 110 may have one or more processing units, including dedicated processing units such as graphics processing units (GPUs), field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), general-purpose computing on graphics processing units (GPGPUs), and general-purpose processing units such as CPUs. Additionally, one or more virtual machines may run on each computing device 110.

[0043] In some embodiments, the computing device 110 includes, for example, a data acquisition module 112, a traffic prediction module 114, a contingency plan generation module 116, a logic checking module 118, a sandbox testing module 120, and a release determination module 122.

[0044] The data acquisition module 112 is used to acquire event information, historical traffic data and service link information related to the target traffic peak event.

[0045] The traffic prediction module 114 is used to obtain the predicted traffic curve corresponding to the target traffic peak event based on the acquired event information and historical traffic data.

[0046] The contingency plan generation module 116 is used to input the predicted traffic curve and service link information into a predetermined large language model in order to generate a corresponding structured contingency plan. The structured contingency plan includes one or more of the following: traffic limiting rules, degradation rules, and capacity expansion rules.

[0047] Logic checking module 118 is used to perform logic checks on structured plans.

[0048] The sandbox testing module 120 is used to deploy structured plans that have passed logic checks to a sandbox environment for testing. The sandbox environment is isolated from the production environment where the structured plans are actually deployed.

[0049] Release determination module 122 is used to determine that the structured plan meets the release requirements in response to the test results for the sandbox environment meeting the predetermined test conditions.

[0050] Figure 2 A flowchart of a method 200 for generating traffic peak event contingency plans according to an embodiment of the present invention is shown. Method 200 may be derived from, for example... Figure 1 The computing device 110 shown can be used for execution, and can also be used in Figure 8 The method is performed at the illustrated electronic device 800. It should be understood that method 200 may also include additional steps not shown and / or the steps shown may be omitted, and the scope of the invention is not limited in this respect.

[0051] In step 202, computing device 110 acquires event information, historical traffic data, and service link information related to the target traffic peak event.

[0052] Regarding target traffic peak events, these are business events that are expected to generate high business traffic within a specific time period, such as large-scale promotional activities, holiday events, red envelope campaigns, centralized collection activities, e-commerce activities, etc.

[0053] Regarding event information, it includes basic information used to describe the target traffic peak event, such as the event name, event type, event text description, expected participation scale, event start and end time, event rule description, and other information related to the target traffic peak event.

[0054] Historical traffic data includes, for example, actual traffic data corresponding to historical traffic peak events, average traffic data, traffic change data during historical traffic peak times, order volume, number of payment transactions, number of red envelope claims, number of red envelope redemptions, number of asset changes, and other monitoring indicators over a period of time. Historical traffic data can be organized by time, such as recording business traffic by minute, 5-minute, or other time granularities.

[0055] Service link information describes the business services involved in the target traffic peak event and the call relationships between these services. In some embodiments, service link information includes the call relationship of "order placement → inventory deduction → payment call (marketing service verifies user-received red envelopes during payment) → asset change," as well as the current capacity level of each link, the number of requests per second that the payment gateway can currently handle, the number of instances of the marketing service currently deployed, and resource constraint information. Resource constraint information includes, for example, the current number of service instances, the number of requests the service can handle, available computing resources, and the maximum scalable resource limit.

[0056] Therefore, by simultaneously acquiring event information, historical traffic data, and service link information, the above solution can provide a data foundation corresponding to the target traffic peak event and the actual business system for subsequently obtaining predicted traffic curves and generating structured contingency plans.

[0057] In step 204, the computing device 110 obtains the predicted traffic curve corresponding to the target traffic peak event based on the acquired event information and historical traffic data.

[0058] Regarding event information, it also includes, for example, event text descriptions, such as textual descriptions of the event, which are used by the large language model for historical event retrieval and matching.

[0059] Regarding the predicted traffic curve, it is used to characterize the distribution of predicted traffic over time in various business links such as e-commerce, payment, marketing, and assets during a future preset time period (e.g., the next 72 hours, with one data point every 5 minutes). It may also include upper and lower fluctuation ranges for reference in subsequent testing. The method for predicting the traffic curve corresponding to the target traffic peak event will be further explained below with reference to Figure 3, and will not be repeated here.

[0060] Therefore, the above scheme transforms peak traffic events into predicted traffic curves that change over time, which can provide a quantitative basis for traffic limiting rules, degradation rules, and capacity expansion rules in subsequent structured contingency plans.

[0061] In step 206, the computing device 110 inputs the predicted traffic curve and service link information into a predetermined large language model to generate a corresponding structured plan, which includes one or more of the following: rate limiting rules, degradation rules, and capacity expansion rules.

[0062] The pre-trained large language model can be, for example, a pre-trained large language model capable of understanding input content such as event text descriptions, traffic curves, and service link information, and outputting structured solutions. This pre-trained large language model can be based on models such as the Claude Opus5, GPT series models, or Qwen series models.

[0063] Regarding rate limiting rules, they are used, for example, to restrict requests exceeding a preset threshold when the number of requests to the target object (such as the "marketing service red envelope redemption interface"). Regarding degradation rules, they are used, for example, to degrade the service capabilities of the target object when preset trigger conditions are met, such as "degrading to read-only" or "returning the default result." Regarding scaling rules, they are used, for example, to increase the target number of instances of the target object to improve processing capacity when preset trigger conditions are met.

[0064] Regarding structured contingency plans, they are, for example, a set of rules that can be directly parsed and executed by a program. Each rule includes: action type (one of rate limiting, degradation, or scaling), target object (e.g., "marketing service red envelope redemption interface"), triggering condition (e.g., "the interface's request volume per second exceeds 80% of the predicted peak and lasts for 10 seconds"), specific parameters (rate limiting threshold, degradation level, target number of instances), priority, and whether it needs to wait for other actions to take effect first. The following will discuss the method for generating structured contingency plans in conjunction with... Figure 5 Further explanation is not provided here.

[0065] Therefore, the above solution automatically generates structured plans through a large language model, replacing engineers' handwriting, improving the efficiency of plan writing, and the output format is uniform, which is convenient for program parsing and execution.

[0066] In step 208, computing device 110 performs a logic check on the structured plan so that the structured plan that passes the logic check can be deployed to a sandbox environment for testing. The sandbox environment is isolated from the production environment where the structured plan is actually deployed.

[0067] Regarding logical checks, one approach is to treat each service as a node, construct a graph representing the call relationships and resource consumption relationships between services, and attach each contingency plan rule to the corresponding node or relationship. This automatically checks for issues such as circular dependencies, excessive resource allocation, contradictory rules, and whether core processes will be mistakenly affected. The following will discuss methods for logical checks on structured contingency plans. Figure 6 Further explanation is not provided here.

[0068] In some embodiments, when the logic check fails, the problem type and the involved nodes / rules are fed back to the predefined large language model, driving it to regenerate a structured contingency plan accordingly; after the logic check passes, the contingency plan enters the sandbox test.

[0069] Therefore, the above solution adds a logic check step before the contingency plan for the target traffic peak event goes live, which can automatically discover hidden conflicts between rules and avoid failures caused by logic defects after the contingency plan goes live.

[0070] In step 210, the computing device 110 determines that the structured plan meets the release requirements in response to the test results for the sandbox environment meeting the predetermined test conditions.

[0071] The pre-defined test conditions include, for example, the core link response latency not exceeding a certain multiple of the baseline, the error rate not exceeding a preset threshold, capacity expansion completed within a preset time, and resource utilization not exceeding a safe level.

[0072] In some embodiments, if the sandbox test fails, the system automatically feeds back the failure information to the large language model, driving it to regenerate a tailored solution and re-perform logic checks and sandbox testing until the test results meet the predetermined test conditions or the maximum number of attempts is reached. The method for sandbox testing structured solutions will be discussed below. Figure 7 Further explanation is not provided here.

[0073] Therefore, the above solution fully verifies its actual effectiveness before the plan goes live through automatic sandbox testing and feedback iteration, reducing the probability of failure after launch.

[0074] In some embodiments, after the structured plan is launched in the production environment, the computing device 110 obtains the actual operating flow based on a preset period to calculate the flow deviation between the actual operating flow and the corresponding predicted flow. If the computing device 110 determines that the flow deviation is within a predetermined safe and adjustable range, it adjusts the parameters corresponding to the time period in the structured plan that has not yet occurred according to the flow deviation, so that the adjusted parameters do not exceed the safe and adjustable range of the corresponding parameters.

[0075] Regarding the preset period, it is, for example, a fixed period such as 30 seconds.

[0076] Regarding actual operational traffic, it could be, for example, the actual traffic collected at preset intervals after a structured plan is deployed in the production environment.

[0077] Regarding flow deviation, it is, for example, the relative deviation between the actual operating flow and the predicted flow at the same time. For example, this relative deviation can be smoothed to avoid instantaneous jitter triggering adjustments.

[0078] Regarding the adjustable safety range, it refers to, for example, the upper and lower limits of parameters that each rule is allowed to adjust without re-performing logic checks and sandbox testing. The adjustable safety range is, for example, pre-marked for each rule during the generation of structured contingency plans.

[0079] Regarding parameters for time periods that have not yet occurred, such as parameters configured in the structured contingency plan for time periods that have not yet occurred, such as the rate limiting threshold for subsequent time periods, when to start scaling up, and how many instances to scale up to, etc., without adjusting the parameters for time periods that have already occurred.

[0080] In some embodiments, when the traffic deviation exceeds a predetermined safe adjustable range, it is determined that the adaptive fine-tuning range has been exceeded, an alarm is triggered, and a new round of traffic prediction is recommended. It should be understood that in this case, the above scheme does not make forced adjustments beyond the safe adjustable range to ensure the safety boundary of automatic fine-tuning during operation.

[0081] Therefore, after the structured contingency plan for the target traffic peak event is put into operation, the above solution can automatically fine-tune the contingency plan parameters without the need for continuous manual monitoring. At the same time, the adjustment range is limited by a safe and adjustable range to ensure operational safety.

[0082] In the above solution, the present invention links traffic prediction, contingency plan generation, logic checking, sandbox testing, and online determination of traffic peak events into an automated link, eliminating the need for engineers to manually write contingency plans, perform load tests, and conduct reviews. This helps to improve the efficiency and accuracy of contingency plan generation. Furthermore, through the dual verification of logic checking and sandbox testing, the risk of logical or performance defects in the contingency plan itself can be reduced.

[0083] Figure 3 A flowchart of a method 300 for obtaining a predicted flow curve corresponding to a target flow peak event according to an embodiment of the present invention is shown. Method 300 may be derived from, for example... Figure 1 The computing device 110 shown can be used for execution, and can also be used in Figure 8 The method is performed at the illustrated electronic device 800. It should be understood that method 300 may also include additional steps not shown and / or the steps shown may be omitted, and the scope of the invention is not limited in this respect.

[0084] In step 302, the computing device 110 inputs the event text description into a predetermined large language model for retrieval in a historical event database, thereby identifying multiple reference historical events.

[0085] Regarding the historical event database, it stores event information for multiple historical traffic peak events and corresponding historical traffic data. Each historical event is associated with monitoring indicators such as actual traffic peak data, event scale data, average traffic data, traffic change data during historical traffic peak times, order volume, number of payment transactions, number of red envelope receipts, number of red envelope redemptions, and number of asset changes over a period of time.

[0086] Regarding reference historical events, these are, for example, historical traffic peak events that are similar to the target traffic peak event in terms of event text description. For instance, if the target traffic peak event is "Anniversary Sale," then the historical event database will be searched for several historical sale events with the most similar text descriptions as reference historical events.

[0087] In step 304, the computing device 110 determines the flow amplification factor based on the scale of the target flow peak event, the actual flow peaks of multiple reference historical events, and the flow changes.

[0088] Regarding the flow amplification factor, it is used, for example, to characterize the amplification factor of a target flow peak event relative to the base flow.

[0089] Regarding traffic changes, it can be used to characterize the trend of traffic changes during a reference historical event, such as the actual peak growth rate of similar events, the traffic value of each time period, and the traffic changes throughout the entire event cycle.

[0090] For example, if multiple traffic peak events overlap during the same period, the degree of overlap between each traffic peak event is determined by a pre-defined large language model (e.g., overlap of user groups, whether rules promote each other), thereby obtaining the traffic amplification coefficient after the overlap effect; the final predicted traffic = historical or recent basic traffic × traffic amplification coefficient after the overlap effect, and can also provide an upper and lower fluctuation range, which is convenient for subsequent testing.

[0091] In step 306, the computing device 110 determines the predicted flow curve corresponding to the target flow peak event based on the base flow rate and the flow amplification factor.

[0092] Regarding the base flow, it can be historical or recent, such as the average daily flow, average flow, or actual flow over recent periods. For example, "predicted flow = historical or recent base flow × flow amplification factor".

[0093] For example, when the target traffic peak event is similar to a historical event, the computing device 110 directly takes the peak data of that historical event and calculates the traffic amplification factor based on the actual growth of similar historical events in recent times to calculate the predicted traffic.

[0094] For example, when the target traffic peak event is a completely new event without direct historical data, the computing device 110 inputs the event text description into a predefined large language model and automatically retrieves one or more reference historical events with the most similar text descriptions from the historical event database. For example, the ratio of the "actual peak / event size" of the reference historical events is taken as the traffic amplification factor of the target traffic peak event.

[0095] Therefore, the above solution uses a large language model to understand the event text description and automatically retrieves reference historical events from the historical event database to determine the traffic amplification factor and generate a predicted traffic curve based on the basic traffic. This can replace manual estimation of traffic peaks based on experience. Furthermore, for new events without direct historical data, it can also find the most similar historical events as references based on the event text description to obtain relatively reliable prediction results, thereby reducing the arbitrariness of manual experience judgment. This improves the accuracy and efficiency of traffic prediction for traffic peak events.

[0096] In some embodiments, if the computing device 110 determines that the target traffic peak event overlaps with at least one other traffic peak event in time, it performs the following actions: dividing users into multiple non-overlapping user groups based on information about user participation in the traffic peak event, with each user assigned to only one user group; determining the degree of user overlap between the multiple traffic peak events based on the event participation of users in different user groups; and determining the traffic amplification factor generated by the superposition of the multiple traffic peak events based on the degree of user overlap, and determining the predicted traffic curve based on the traffic amplification factor.

[0097] For example, when multiple festivals or events occur simultaneously, resulting in multiple overlapping traffic peaks, computing device 110 examines which activities each user participated in (i.e., traffic peaks). For instance, users are categorized into distinct groups such as "participating only in A," "participating only in B," and "participating in both A and B." Each user is placed in only one group. It should be understood that when user-level data is unavailable, the number of overlapping users can be estimated using aggregated data such as audience segments, channels, and regions, providing both lower and higher estimates. For example, if the proportion of users in the "participating in both A and B" group is high, it indicates a high degree of user overlap, and the combined impact of the two activities is significant. Therefore, the degree of user overlap between multiple traffic peaks can be estimated using various methods.

[0098] For example, Activity A is expected to have 10,000 participants, and Activity B is expected to have 8,000 participants. 3,000 people will participate in both activities. The system will not simply add 10,000 and 8,000 together. Instead, it will divide the participants into groups, for example: 7,000 who only participated in A, 5,000 who only participated in B, and 3,000 who participated in both. Therefore, the actual number of participants is 15,000. If the same order uses discounts from both A and B, the order placement and payment are counted only once in terms of capacity. To calculate the contribution to the activities, this single request can be attributed to A at 40% and B at 60%. If the same user places another order, the new order is still counted separately.

[0099] Therefore, the above scheme can avoid the traffic prediction deviation caused by simply taking the maximum value or linear addition by analyzing user grouping and user overlap, making the prediction more accurate when multiple events overlap.

[0100] For example, if privacy or data isolation prevents the acquisition of anonymized user intersections, methods that do not expose specific users, such as audience packet intersection statistics, privacy set intersection calculations, Bloom filters, and / or secure multi-party computation, can be used to obtain only the "number of people participating in multiple activities simultaneously" or its estimated range. Subsequent traffic calculations will still follow the same deduplication and activity allocation rules.

[0101] In some embodiments, the computing device 110 acquires the service request action corresponding to each traffic peak event, so as to record the user identifier, order identifier and interface identifier corresponding to each service request action; if it is determined that multiple service request actions have the same user identifier, order identifier and interface identifier, the multiple service requests are merged into the same real request in order to optimize the predicted traffic demand; and based on the optimized predicted traffic demand, the system capacity demand is predicted.

[0102] Regarding user identifiers, they are used, for example, to uniquely identify the user who initiates the business request action.

[0103] Regarding order identifiers, they are used, for example, to uniquely identify the order corresponding to a business request action.

[0104] Regarding interface identifiers, they are used, for example, to uniquely identify the interface invoked by a business request action.

[0105] Regarding real requests, they are, for example, the actual business requests after deduplication of duplicate business requests. For instance, if the same user initiates a verification action for the same order through the same interface in events A and B, these two business requests are merged into one real request and only counted once in the predicted traffic. If the same user has two orders, or actually calls two different interfaces, they are still counted separately to avoid underestimating the traffic.

[0106] Regarding system capacity requirements, this can be, for example, the total number of deduplicated real requests the system needs to handle during peak traffic events. In some embodiments, if an order uses discounts from both event A and event B, the real request is counted only once in terms of system capacity. To clearly see the contribution of each event to traffic, the request can be proportionally allocated to event A and event B according to rules such as discount amount and trigger order, with the sum of the allocation ratios being 100%. This way, the contribution of each event can be seen without double-adding the total traffic.

[0107] For example, each traffic peak event can trigger separate business request actions, such as coupon redemption, order placement, payment, verification, and asset change, and each business request action can be recorded with the user, order, interface, and occurrence time. Another example is when multiple business request actions share the same conditions, such as the same user, the same order, the same interface, or the same business action, the records of multiple business requests can be merged into a single actual request. For instance, if the same user has two orders, or if two different interfaces are actually called, the traffic demand is still calculated separately.

[0108] For example, when predicting system capacity demand, the total number of deduplicated actual requests is counted. If an order participates in both traffic peak event A and traffic peak event B, it is only counted once in terms of system capacity. To obtain the contribution of each traffic peak event, this request can be proportionally distributed to traffic peak events A and B according to rules such as discount amount and trigger order, and the sum of the distribution ratios must equal 100%. This way, the contribution of each traffic peak event is obtained without double-adding the total traffic.

[0109] For non-core requests such as claim reminders and marketing inquiries that can be executed later, computing device 110 can move some non-core requests from the most congested times to less busy times before or after, provided that the deadline and user frequency limit are not exceeded. It should be understood that core requests that cannot be postponed, such as payments and asset changes, are not included in the time adjustment. Therefore, the above solution only merges truly duplicate requests or adjusts the time of deferable requests, without deleting genuine business requests; thus, it avoids the same user's traffic being counted repeatedly, making capacity planning more accurate, avoiding both overestimation leading to resource waste and underestimation leading to system failure.

[0110] Therefore, the above solution merges duplicate business requests through three dimensions: user identifier, order identifier, and interface identifier. Only truly duplicate requests are merged into the same real request, while retaining requests corresponding to different orders and different interfaces of the same user. This can avoid both overestimation caused by repeated traffic calculation when multiple events overlap and underestimation caused by excessive merging, thereby optimizing the prediction of traffic demand and making the prediction of system capacity demand more accurate.

[0111] Figure 4 A flowchart of a method 400 for updating a predicted flow curve for a flow peak event according to an embodiment of the present invention is shown. Method 400 may be derived from, for example... Figure 1 The computing device 110 shown can be used for execution, and can also be used in Figure 8 The method is performed at the illustrated electronic device 800. It should be understood that method 400 may also include additional steps not shown and / or the steps shown may be omitted, and the scope of the invention is not limited in this respect.

[0112] In step 402, the computing device 110 acquires real-time traffic data during the operation of the target traffic peak event.

[0113] Regarding real-time traffic data, it could be, for example, the actual traffic data of each business link collected by the system at preset intervals after the target traffic peak event begins.

[0114] For example, after the target traffic peak event begins, two types of data are compared at regular intervals: one is how much traffic similar historical events typically generate at the current stage, and the other is how much traffic the target traffic peak event actually generates in recent time periods.

[0115] In step 404, the computing device 110 performs abnormal data filtering on the real-time traffic data and determines the reliability of the real-time traffic data based on the amount of valid data, the degree of traffic fluctuation, and the integrity of the monitoring data.

[0116] Regarding anomaly data filtering, it is used to exclude false traffic generated by missing monitoring data, abnormal data collection, and fault retries. For example, missing data caused by monitoring equipment failure, data generated by abnormal data collection, and duplicate traffic generated by fault retries are all filtered to prevent them from contaminating subsequent prediction adjustments.

[0117] Regarding credibility, it is used to characterize whether filtered real-time traffic data is trustworthy. For example, the credibility of real-time traffic data can be determined based on one or more dimensions such as the size of the effective data volume, the degree of traffic fluctuation, and the completeness of monitoring data. The larger the effective data volume, the smoother the traffic fluctuation, and the more complete the monitoring data, the higher the credibility.

[0118] In step 406, the computing device 110 merges real-time traffic data with historical traffic data based on the determined level of confidence to update the predicted traffic curve for the subsequent running time period of the target traffic peak event.

[0119] In some embodiments, when fusing real-time and historical traffic data, time periods closer to the current moment reference real-time traffic data more, while time periods further away from the current moment retain the original trend of historical traffic events. For example, if the latter half of a similar historical traffic peak event typically sees a decrease in traffic, the high traffic will not be carried over to the end of the event simply because a short-term peak has just occurred. Another example is that if remaining unclaimed, unredeemed, or incomplete business volume is obtained, the subsequent predicted total volume is checked to see if it matches these remaining volumes; if it is too high or too low, an overall correction is made. Furthermore, a new traffic prediction version can be generated only when the traffic deviation exceeds a set value for multiple consecutive time periods.

[0120] In some embodiments, the update magnitude of a single predicted traffic curve needs to be less than a predetermined adjustment magnitude threshold, and the predicted data for periods that have already occurred should not be modified to ensure the stability of the predicted version. If the activity rules, participating audience, or business path of the target traffic peak event changes significantly, small adjustments based on the predetermined adjustment magnitude threshold should be stopped, and the user groups and the entire traffic curve should be recalculated. It should be understood that after updating the predicted traffic curve, the grouping, deduplication criteria, activity allocation ratio, historical references, and real-time adjustment basis should be recorded, and the same version of the predicted traffic curve should be used in subsequent contingency plan generation, contingency plan inspection, and sandbox testing.

[0121] For example, historical and real-time data can be processed using different combinations of algorithms such as moving average, Kalman filtering, and / or Bayesian updates. The underlying principle is to first smooth short-term fluctuations before determining the trend. Regardless of the algorithm combination used, only future traffic is modified, not data that has already occurred. Simultaneously, remaining traffic volume is considered, and limits are placed on how long it takes to trigger and the minimum amount of change required to modify the predicted traffic curve each time.

[0122] For example, a service might historically have 40 QPS at 10:00 AM, but recently it's actually around 52 QPS. The above approach doesn't immediately change all subsequent times to 52 QPS. Instead, it first determines if this upward trend continues and whether the monitoring data is reliable. For instance, after confirming the data is accurate, the predicted traffic for closer future time periods can be adjusted upwards to approximately 47 QPS, while for more distant future time periods, the predicted traffic is only slightly increased to approximately 42 QPS, continuing to retain the historical pattern of a decrease or re-emergence of peak traffic in the latter half of the period. Only when the deviation continuously reaches the set conditions is a new prediction version generated.

[0123] Therefore, the above scheme filters out abnormal data and judges the credibility of real-time traffic data during the operation of traffic peak events. Based on the credibility, it merges real-time traffic data with historical traffic data to update the predicted traffic curve for subsequent operating periods. This can eliminate the interference of false traffic on prediction, use real-time data to correct recent predictions and retain historical trend patterns, thereby improving the accuracy of predictions during operation and maintaining the stability of prediction versions.

[0124] Figure 5 A flowchart of a method 500 for generating structured plans according to an embodiment of the present invention is shown. Method 500 may be derived from, for example... Figure 1 The computing device 110 shown can be used for execution, and can also be used in Figure 8 The method is performed at the illustrated electronic device 800. It should be understood that method 500 may also include additional steps not shown and / or the steps shown may be omitted, and the scope of the invention is not limited in this respect.

[0125] In step 502, the computing device 110 determines the calling relationship between services and resource constraint information based on the service link information.

[0126] Regarding the calling relationship, it includes, for example, the dependency and calling order between services, such as "Place order → Pay → Asset change".

[0127] Information regarding resource constraints includes, for example, the maximum scalable resource limit and the current capacity level.

[0128] In step 504, computing device 110 inputs the predicted traffic curve, call relationships, and resource constraint information into a predetermined large language model.

[0129] For example, reference historical events can also be input into a predefined large language model.

[0130] In step 506, the computing device 110 generates a structured plan via a predetermined large language model. Each rule in the structured plan includes at least the target object, triggering conditions, and processing parameters.

[0131] For example, computing device 110 retrieves several reference historical events with high similarity to the target traffic peak event from the historical event database as reference examples; and explicitly specifies the output format in the prompt, so that the large language model only outputs structured plans that conform to the format; after the large model outputs, computing device 110 performs format verification (e.g., whether the fields are complete and whether the values ​​are within a reasonable range), and requires the large language model to re-output the structured plans that fail the format verification.

[0132] Therefore, the above scheme enables the large language model to combine parameters such as service links and resource constraints when generating contingency plans, thereby generating structured contingency plans that are more in line with the actual system operation and improving the executability of the contingency plans.

[0133] In some embodiments, before each invocation of the predetermined large language model, the computing device 110 generates upper limits for the number of tokens used in the input and output content; determines security rules, resource limits, current failure locations, and their upstream and downstream relationships as mandatory input content; determines historical cases, explanatory text, and details of unrelated services as optional input content, and sorts the optional content according to their relevance to the current event, their importance to the judgment, and the number of tokens required; within the upper limit for the number of tokens used, the optional input content is added to the input content according to the sorting result. The input content must include at least the mandatory input content. A token is the smallest unit of measurement for text processed by the model; a token can be a character, a word, or a sub-word fragment.

[0134] For example, in order to control token consumption during the process of generating and adjusting structured plans through multiple calls to the large language model, a token usage list is generated before each call to the large language model, and a token usage limit is set for the input and output content respectively.

[0135] The required information includes, for example, security rules, resource limits, the current failure location, and its upstream and downstream relationships. This information cannot be removed to save tokens. Security rules are, for example, constraints necessary for the stable operation of the system; resource limits are, for example, the maximum number of scalable resources; the current failure location and its upstream and downstream relationships are, for example, the services involved in the sandbox test failure and their dependent services.

[0136] The optional content includes, for example, historical cases, explanatory text, and details of unrelated services. The system sorts the optional content according to its relevance to the current event, its importance to the judgment, and the number of tokens required. Within the token usage limit, the optional content is added to the input according to the sorting result. For example, historical case studies of the same type as the current event are sorted first, while explanatory text is sorted last.

[0137] Therefore, the above scheme enables the large language model to make only semantic decisions and only accept necessary inputs in the first round, which can reduce the token consumption of a single round of calls; and optional input content can be added as appropriate according to the upper limit of token usage and the relevance of optional content, thereby saving token consumption.

[0138] In some embodiments, during the first round of invocation, only the affected services and necessary constraint information of the current target traffic peak event are sent to the predetermined large language model, and the predicted traffic curve retains only the peak, inflection point, phase characteristics, and upper and lower limits. For example, a traffic curve that originally contained a data point every 5 minutes for the next 72 hours is sent to the large language model only retaining the peak time, traffic inflection point, and representative values ​​of different phases.

[0139] In some embodiments, deterministic computations such as user grouping, traffic calculation, and resource conversion are performed by ordinary programs, rather than being repeatedly executed by the large language model. This saves tokens and avoids errors in deterministic computations by the large language model.

[0140] In some embodiments, during subsequent rounds of generating structured plans, unchanged content is stored in the system cache, and only newly added change information, such as activity change information, rule conflict information, and sandbox test failure indicators, is sent to the pre-defined large language model. The pre-defined large language model only outputs differential instructions. Subsequently, a preset program merges the differential instructions into the previous version of the structured plan and re-executes logic checks and sandbox tests based on the merged structured plan. The differential instructions are used to indicate which rule to add, which parameter to modify, or which rule to delete. For example, when a plan needs to be regenerated after a sandbox test failure, only the interfaces involved in the failure, the types of exceedance indicators, the magnitude of exceedance, and the relevant minimum upstream and downstream information are sent to the large language model, instead of resending all link information.

[0141] In some embodiments, if any of the following conditions are met, the computing device 110 stops calling the predetermined large language model and switches to manual processing: the required input content exceeds the upper limit of the token usage; the cumulative token usage limit is reached; the preset maximum number of attempts is reached; or there is no improvement after two consecutive rounds.

[0142] In some embodiments, the number of input tokens actually used in each round, the number of output tokens, the number of tokens saved by the cache, and the content that was deleted are recorded; the saving ratio is calculated based on the number of tokens expected to be needed when sending complete data in each round and the actual number of tokens after using the simplification and differential methods.

[0143] For example, suppose the entire system has 80 services, but this campaign only affects 12 of them. The first round only sends the capacity limits, peak traffic, and a few relevant historical cases for these 12 services. After sandbox testing, if issues are found, such as with payment rule R17, the second round only sends a reference to the previous plan, necessary upstream and downstream information for the payment service, failure indicators, and R17, ensuring that the planned large language model only modifies the parameters related to R17. For example, a system using the solution provided in this application records the information "how many tokens are needed to send all data in each round" and "how many tokens were actually used for the difference in data sent," calculating the savings percentage accordingly; the campaign stops when the cumulative budget is reached or when there is no improvement after two consecutive rounds.

[0144] Therefore, the above solution, while ensuring that key information such as security rules and resource constraints are not lost, effectively reduces the token consumption of the pre-defined large language model in the process of plan generation and iteration through token budgeting, mandatory / optional content classification, differential sending, cache reuse, and incremental output. It avoids the interruption of the automatic process due to token overrun and improves the efficiency and controllability of multi-round calls.

[0145] Figure 6 A flowchart of a method 600 for performing a logic check on a structured plan according to an embodiment of the present invention is shown. Method 600 may be performed by, for example... Figure 1 The computing device 110 shown can be used for execution, and can also be used in Figure 8 The method is performed at the illustrated electronic device 800. It should be understood that method 600 may also include additional steps not shown and / or the steps shown may be omitted, and the scope of the invention is not limited in this respect.

[0146] In step 602, computing device 110 constructs a service relationship graph based on the calling relationships between services and resource constraint information.

[0147] In step 604, the computing device 110 associates the rules contained in the structured plan with each service node in the service relationship graph.

[0148] In step 606, the computing device 110 detects whether the structured plan has one or more of the following logical problems based on the service relationship graph: circular dependency, excessive resource allocation, rule conflict, and unreachable core business links.

[0149] Circular dependency refers to deadlock caused by rules waiting for each other to take effect; resource allocation exceeding the limit refers to the total resources required by expansion rules exceeding the available limit; rule conflict refers to conflicting rules existing simultaneously on the same interface; and core business link unreachable refers to the interruption of core links caused by degradation rules.

[0150] For example, computing device 110 treats e-commerce, payment, marketing, and asset services as nodes, constructs a graph of the call relationships and resource usage relationships between services, and attaches each rule in the generated structured contingency plan to the corresponding node or relationship for logical checks, including: ① whether there are circular dependencies (e.g., the downgrade rule for marketing service red envelope redemption needs to wait for the downgrade rule for asset change to take effect first, while the downgrade rule for asset change needs to wait for red envelope redemption to take effect first, forming a deadlock); ② whether there is excessive resource allocation (e.g., the total resources required by several expansion rules exceed the actual available limit); ③ whether there are contradictory rules (e.g., for the same interface, one rule requires "downgrade to read-only", while another rule simultaneously requires "normal write access"); ④ whether core links will be accidentally damaged (e.g., whether the core link "order placement → payment → asset change" will become unreachable under the normal triggering path due to a certain downgrade rule, resulting in problems such as successful deduction but no asset arrival).

[0151] Therefore, the above solution can automatically detect logical problems before the contingency plan is deployed, avoid failures after deployment due to rule conflicts or dependency deadlocks, and improve the reliability of the contingency plan.

[0152] Figure 7 A flowchart of a method 700 for sandbox testing of a structured proposal according to an embodiment of the present invention is shown. Method 700 may be performed by, for example... Figure 1 The computing device 110 shown can be used for execution, and can also be used in Figure 8 The method is performed at the illustrated electronic device 800. It should be understood that method 700 may also include additional steps not shown and / or the steps shown may be omitted, and the scope of the invention is not limited in this respect.

[0153] In step 702, the computing device 110 constructs a sandbox environment corresponding to the production environment at a preset scaling ratio.

[0154] In step 704, the computing device 110 scales the predicted traffic curve based on a preset scaling ratio and generates test traffic based on the time-series distribution of historical real traffic.

[0155] Regarding sandbox environments, they are, for example, test environments isolated from the production environment, built at a preset scale, such as 1:10, to simulate the real operating environment. A small number of instances of core services are deployed proportionally in the test environment, while non-core parts are simplified and simulated, thereby conducting actual tests on contingency plans without affecting the production environment.

[0156] In step 706, the computing device 110 deploys the structured plan to the corresponding execution component in the sandbox environment and injects test traffic to obtain the test operation indicators of the structured plan.

[0157] Test performance metrics include response latency, error rate, resource utilization, and expansion time.

[0158] For example, the sandbox testing process includes: ① Deploying a small number of instances of core services such as e-commerce, payment, marketing, and assets in the test environment at a preset scaling ratio r (e.g., 1:10). The number of instances is the number of instances in the production environment × r, rounded up, with at least one instance. Non-core parts can be simulated using simplified methods. ② Scaling down the predicted traffic curve of the target traffic peak event by the same ratio and generating test traffic by combining the time-series distribution characteristics of historical real traffic. Injecting this test traffic into the test environment and simultaneously overlaying the upper limit of the prediction interval for stress testing. ③ Deploying the structured contingency plan that has passed the logic check to the rate limiting / degradation / expansion components in the test environment to make it truly effective, in order to capture real system behavior (such as the cold start time of expansion and the chain reaction of degradation switching), rather than just performing numerical calculations. ④ Continuously collecting indicators such as response latency, error rate, resource utilization, and expansion time, and comparing them with preset pass standards (such as core link response latency not exceeding a certain multiple of the baseline, error rate not exceeding a preset threshold, expansion completed within a preset time, and resource utilization not exceeding a safe level).

[0159] Therefore, the above solution can capture real system behavior, such as the time taken for cold starts during expansion and the chain reaction of degradation, by deploying real systems in a sandbox and injecting test traffic, rather than just performing numerical calculations, thus improving the effectiveness of the test.

[0160] In some embodiments, if the computing device 110 determines that the test results in the sandbox environment do not meet the predetermined test conditions, it adjusts the structured plan according to the test results; repeats the logic check, sandbox test, and structured plan adjustment within a preset maximum number of attempts; and if the predetermined test conditions are still not met after reaching the preset maximum number of attempts, it determines the structured plan with the best test results from multiple versions of structured plans and outputs test diagnostic information corresponding to the structured plan with the best test results.

[0161] For example, failure information (involving nodes / interfaces, types of out-of-limit indicators, extent of out-of-limit, and specific rule parameters that were in effect at the time) is organized into a structured feedback to the large language model, and the adjustment direction is clearly indicated, such as the rate limiting threshold should be lowered and capacity expansion should be triggered in advance.

[0162] Therefore, the above scheme can automatically iterate and adjust the contingency plan when the test fails, and output the optimal contingency plan and diagnostic report after reaching the maximum number of attempts, avoiding infinite loops, and providing a basis for manual review.

[0163] Figure 8 A schematic step diagram of an example electronic device 800 that can be used to implement embodiments of the contents of this specification is shown. For example, as Figure 1The computing device 110 shown can be implemented by an electronic device 800. As shown, the electronic device 800 includes a central processing unit (CPU) 801, which can perform various appropriate actions and processes according to computer program instructions stored in a read-only memory (ROM) 802 or loaded from a storage unit (RAM) 808 into a random access memory (RAM) 803. The RAM 803 can also store various programs and data required for the operation of the electronic device 800. The CPU 801, ROM 802, and RAM 803 are interconnected via a bus 804. An input / output (I / O) interface 805 is also connected to the bus 804.

[0164] Multiple components in electronic device 800 are connected to input / output interface I / O 805, including: input unit 806, such as keyboard, mouse, microphone, etc.; output unit 807, such as various types of monitors, speakers, etc.; storage unit 808, such as disk, optical disk, etc.; and communication unit 809, such as network card, modem, wireless transceiver, etc. Communication unit 809 allows electronic device 800 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0165] The various processes and procedures described above, such as methods 200 to 700, can be executed by the central processing unit CPU 801. For example, in some embodiments, methods 200 to 700 can be implemented as computer software programs tangibly contained in a machine-readable medium, such as storage unit 808. In some embodiments, part or all of the computer program can be loaded and / or installed on the electronic device 800 via read-only memory ROM 802 and / or communication unit 809. When the computer program is loaded into random access memory RAM 803 and executed by the central processing unit CPU 801, one or more actions of methods 200 to 700 described above can be performed.

[0166] This invention relates to methods, apparatus, systems, electronic devices, computer-readable storage media, and / or computer program products. The computer program product may include computer-readable program instructions for performing various aspects of the invention.

[0167] Computer-readable storage media can be tangible devices capable of holding and storing instructions for use by an instruction execution device. Computer-readable storage media can be, for example—but not limited to—electrical storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of computer-readable storage media include: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disc read-only memory (CD-ROM), digital multifunction disc (DVD), memory sticks, floppy disks, mechanical encoding devices, such as punch cards or recessed protrusions storing instructions thereon, and any suitable combination of the foregoing. The computer-readable storage media used herein are not to be construed as transient signals themselves, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides or other transmission media (e.g., light pulses through fiber optic cables), or electrical signals transmitted through wires.

[0168] The computer-readable program instructions described herein can be downloaded from computer-readable storage media to various computing / processing devices, or downloaded via a network, such as the Internet, local area network, wide area network, and / or wireless network, to an external computer or external storage device. The network may include copper transmission cables, fiber optic transmission, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge computing devices. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards them to computer-readable storage media in the respective computing / processing device.

[0169] The computer program instructions used to perform the operations of this invention may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++, etc., and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The computer-readable program instructions may 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 a remote computer, the remote computer may 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 may be connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, electronic circuitry, such as programmable logic circuitry, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), is personalized by utilizing state information from the computer-readable program instructions. This electronic circuitry can execute the computer-readable program instructions to implement various aspects of the invention.

[0170] Various aspects of the present invention are described herein with reference to flowchart illustrations and / or step diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It should be understood that each step in the flowchart illustrations and / or step diagrams, as well as combinations of steps in the flowchart illustrations and / or step diagrams, can be implemented by computer-readable program instructions.

[0171] These computer-readable program instructions can be provided to a processing unit of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that, when executed by the processing unit of the computer or other programmable data processing apparatus, they create means for implementing the functions / actions specified in one or more steps of the flowchart and / or diagram of steps. These computer-readable program instructions can also be stored in a computer-readable storage medium that causes a computer, programmable data processing apparatus, and / or other device to operate in a particular manner. Thus, the computer-readable medium storing the instructions comprises an article of manufacture that includes instructions for implementing aspects of the functions / actions specified in one or more steps of the flowchart and / or diagram of steps.

[0172] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, thereby causing the instructions executed on the computer, other programmable data processing apparatus, or other device to perform the functions / actions specified in one or more steps of a flowchart and / or a diagram of steps.

[0173] The flowcharts and step 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 the present invention. In this regard, each step in the flowchart or step diagram may represent a module, segment, or part of an instruction, which contains one or more executable instructions for implementing the specified logical function. In some alternative implementations, the functions indicated in the step may occur in a different order than those indicated in the drawings. For example, two consecutive step steps 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 step in the step diagram and / or flowchart, and combinations of steps in the step diagram and / or flowchart, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0174] The various embodiments of the present invention have been described above. These descriptions are exemplary and not exhaustive, nor are they limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is chosen to best explain the principles, practical application, or technical improvements to the embodiments in the market, or to enable others skilled in the art to understand the embodiments disclosed herein.

Claims

1. A method for generating contingency plans for traffic peak events, characterized in that, The method includes: Obtain event information, historical traffic data, and service link information related to the target traffic peak event; Based on the acquired event information and historical traffic data, obtain the predicted traffic curve corresponding to the target traffic peak event; The predicted traffic curve and service link information are input into a predetermined large language model to generate a corresponding structured plan, which includes one or more of the following: rate limiting rules, degradation rules, and capacity expansion rules. The structured contingency plan undergoes a logical check, and the structured contingency plan that passes the logical check is then deployed to a sandbox environment for testing. This sandbox environment is isolated from the production environment where the structured contingency plan is actually deployed. In response to the test results for the sandbox environment meeting the predetermined test conditions, it is determined that the structured contingency plan meets the release requirements.

2. The method according to claim 1, characterized in that, The event information includes an event text description. Based on the acquired event information and historical traffic data, the predicted traffic curve corresponding to the target traffic peak event is obtained, including: The event text description is input into a predefined large language model for retrieval in a historical event database, thereby identifying multiple reference historical events; Based on the scale of the target traffic peak event, the actual traffic peaks and traffic changes of the multiple reference historical events, a traffic amplification factor is determined; and The predicted flow curve corresponding to the target flow peak event is determined based on the base flow rate and the flow amplification factor.

3. The method according to claim 1, characterized in that, Also includes: In response to determining that the target traffic peak event overlaps with at least one other traffic peak event in time, the following are performed: Based on information about user participation in peak traffic events, users are divided into multiple non-overlapping user groups, with each user assigned to only one user group; Based on the participation of users in traffic peak events corresponding to different user groups, determine the degree of user overlap between multiple traffic peak events; as well as The traffic amplification factor generated by the superposition of multiple traffic peak events is determined based on the degree of user overlap, and the predicted traffic curve is determined based on the traffic amplification factor.

4. The method according to claim 3, characterized in that, Also includes: Obtain the business request action corresponding to each traffic peak event, so as to record the user identifier, order identifier and interface identifier corresponding to each business request action; In response to the determination that multiple business request actions have the same user identifier, order identifier, and interface identifier, the multiple business requests are merged into a single real request in order to optimize the predicted traffic demand; as well as Based on the optimized predicted traffic demand, predict the system capacity demand.

5. The method according to claim 1, characterized in that, Based on the acquired event information and historical traffic data, the predicted traffic curve corresponding to the target traffic peak event is obtained, including: During the execution of the target traffic peak event, real-time traffic data is acquired; The real-time traffic data is filtered for abnormal data, and the reliability of the real-time traffic data is determined based on the amount of valid data, the degree of traffic fluctuation, and the integrity of the monitoring data; and Based on the determined level of confidence, the real-time traffic data is fused with historical traffic data to update the predicted traffic curve for the subsequent running period of the target traffic peak event.

6. The method according to claim 1, characterized in that, The predicted traffic curve and service link information are input into a predetermined large language model to generate a corresponding structured plan, including: The service link information is used to determine the calling relationships between services and resource constraint information. The predicted traffic curve, call relationships, and resource constraint information are input into the predetermined large language model; and A structured plan is generated through the predetermined large language model. Each rule in the structured plan includes at least the target object, triggering conditions, and processing parameters.

7. The method according to claim 6, characterized in that, The logical checks performed on the structured proposal include: Construct a service relationship graph based on the calling relationships and resource constraint information between the services; Associating the rules contained in the structured plan with each service node in the service relationship graph; and Based on the service relationship graph, detect whether the structured contingency plan has one or more of the following logical problems: circular dependency, excessive resource allocation, rule conflict, and unreachable core business links.

8. The method according to claim 1, characterized in that, Deploying structured contingency plans that pass logic checks to a sandbox environment for testing includes: A sandbox environment corresponding to the production environment is constructed using a preset scaled-down version. The predicted traffic curve is scaled based on the preset scaling ratio, and test traffic is generated based on the time-series distribution of historical real traffic; and The structured contingency plan is deployed to the corresponding execution component in the sandbox environment, and the test traffic is injected to obtain the test operation metrics of the structured contingency plan.

9. The method according to claim 1, characterized in that, Also includes: In response to determining that the test results in the sandbox environment do not meet the predetermined test conditions, the structured contingency plan is adjusted according to the test results; Repeatedly perform logic checks, sandbox tests, and structured contingency plan adjustments within the preset maximum number of attempts; as well as If the predetermined test conditions are not met after reaching the preset maximum number of attempts, the optimal structured plan for the test results is determined from multiple versions of structured plans, and test diagnostic information corresponding to the optimal structured plan for the test results is output.

10. The method according to claim 1, characterized in that, Also includes: After the structured plan is launched and running in the production environment, the actual operating traffic is obtained based on a preset period to calculate the traffic deviation between the actual operating traffic and the corresponding predicted traffic. as well as In response to determining that the flow deviation is within a predetermined safe adjustable range, the parameters corresponding to the time period that has not yet occurred in the structured plan are adjusted according to the flow deviation so that the adjusted parameters do not exceed the safe adjustable range of the corresponding parameters.

11. A computing device, comprising: At least one processing unit; At least one memory coupled to the at least one processing unit and storing instructions for execution by the at least one processing unit, the instructions, when executed by the at least one processing unit, causing the device to perform the steps of the method according to any one of claims 1 to 10.

12. A computer-readable storage medium having a computer program stored thereon, the computer program implementing the method according to any one of claims 1 to 10 when executed by a machine.

Images