Activity guarantee platform, method and system

Abstract

The invention discloses an activity guarantee platform, method and system, and relates to the field of data processing, the activity guarantee platform comprises a control center and a cooperative working mode of a plurality of function modules, each function module corresponds to a guarantee node, and the node represents an independent and standard operation link in an activity guarantee process. The activity guarantee platform receives activity parameters input by a user, automatically generates tasks, schedules corresponding modules to execute the tasks, and summarizes results, so that a complete automatic guarantee closed loop is formed. According to the method, the operation and maintenance operation risk can be effectively reduced, and the stability of a service system in a high-concurrency scene and the activity guarantee processing efficiency are improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of data processing, and in particular to an activity guarantee platform, method and system. BACKGROUND

[0002] With the development of Internet business, various business systems often have to appear sudden traffic scenarios such as large-scale promotion, new product release, etc. These activities have high requirements for the stability and pressure bearing capacity of the business system. In order to ensure the smooth operation of the business system during the related activities, the operation and maintenance personnel need to perform a series of guarantee operations during the related activities, such as capacity evaluation, expansion preparation, monitoring configuration and emergency plan execution, etc.

[0003] At present, the guarantee work of these activities mainly relies on manual experience, and the processes and standards performed by different personnel are different, which is easy to miss links or make evaluation errors, affecting the stability of the business system; and because the operation tools of each link of the activity guarantee are scattered, manual switching between multiple platforms is required during emergency handling, which is cumbersome, time-consuming and inefficient, and it is difficult to meet the timeliness requirements of fault response. It can be seen that the current activity guarantee relying on operation and maintenance personnel will affect the stability of the business system and also reduce the response efficiency. SUMMARY

[0004] In view of the above problems, the present application provides an activity guarantee platform, method and system to realize the purpose of improving the stability of the business system in the high concurrency activity scenario and the efficiency of the activity guarantee processing. The specific scheme is as follows:

[0005] The first aspect of the present application provides an activity guarantee platform, comprising: a control center and a plurality of function modules, each function module corresponds to a guarantee node, and the guarantee node represents an independent operation link in the activity guarantee process; wherein,

[0006] The control center is configured to provide information of a plurality of function modules for user selection, receive activity parameters input by the user, generate a guarantee node task corresponding to the function module selected by the user and the activity parameters input by the user, provide the activity parameters corresponding to the guarantee node task to the function module corresponding to the guarantee node task when executing the guarantee node task, and obtain the activity guarantee result provided by the function module.

[0007] The function module is configured to execute the activity guarantee operation corresponding to the function module according to the activity parameters provided by the control center, and feed back the activity guarantee result obtained by the execution to the control center.

[0008] In a possible implementation, the function module comprises a capacity evaluation submodule.

[0009] The capacity assessment submodule is used to compare the preset system node capacity data with the received activity estimated capacity data to obtain the comparison result; based on the comparison result, it determines whether an expansion operation needs to be performed and generates the corresponding expansion pending task.

[0010] In one possible implementation, the functional module further includes: an emergency response submodule;

[0011] The emergency response submodule is used to generate an emergency response plan containing system dependencies based on the target interface, the emergency operation script, and the activity parameters; wherein, the target interface is used to integrate at least one emergency operation tool; and the emergency operation script represents the template information of the emergency response plan.

[0012] In one possible implementation, the functional module further includes: a report generation submodule;

[0013] The report generation submodule is used to generate a target report containing problem flow records and a review after the activity ends; the target report includes comparative analysis data of the actual performance data of the business system and the estimated data.

[0014] In one possible implementation, the control center is further configured to combine multiple assurance node tasks into an assurance process according to a target order based on user instructions, and control the corresponding functional modules to execute in the order of the assurance process, so as to obtain the assurance results of each functional module.

[0015] In one possible implementation, it also includes: a user interface;

[0016] The user interface is used to provide a visual process editing interface; wherein, the visual process editing interface is used to receive user editing operations on the assurance process to obtain the target assurance process, and the editing operation includes at least one of adding assurance node tasks, deleting assurance node tasks, and adjusting the execution order of assurance node tasks.

[0017] In one possible implementation, the control center communicates with the message push platform. The control center is also used to send the pending tasks corresponding to the guarantee node tasks to the target receiving end through the message push platform, and to receive the push result information fed back by the message push platform.

[0018] In one possible implementation, the functional module is further configured to, when executing the protection node task, if an execution abnormality of the protection node task is detected, record the status data of the current business system and include the status data in the activity protection result.

[0019] A second aspect of this application provides an activity protection method, comprising:

[0020] Information on multiple functional modules is displayed for users to choose from, with each module corresponding to a specific activity protection operation.

[0021] Receive activity parameters input by the user;

[0022] Generate support node tasks corresponding to the functional modules selected by the user and the activity parameters input by the user;

[0023] The task of the protection node is executed, and the activity parameters are sent to the corresponding functional modules to perform the corresponding activity protection operation;

[0024] Integrate the event support results returned by various functional modules to obtain event support record information.

[0025] A third aspect of this application provides an activity protection system, comprising:

[0026] The activity support platform as described in any one of the above statements;

[0027] At least one external platform, which is used to provide data support or execution environment for the functional modules in the activity assurance platform;

[0028] By employing the above technical solutions, this application provides an event assurance platform, method, and system. The event assurance platform includes a control center and a collaborative working mode for multiple functional modules. Each functional module corresponds to an assurance node, which represents an independent and standardized operational step in the event assurance process. The event assurance platform automatically generates tasks, schedules the corresponding modules for execution, and aggregates the results by receiving user-input event parameters, thereby forming a complete automated assurance closed loop. This effectively reduces operational risks and improves the stability of business systems under high-concurrency scenarios and the efficiency of event assurance processing. Attached Figure Description

[0029] The above and other features, advantages, and aspects of the embodiments of this disclosure will become more apparent from the accompanying drawings and the following detailed description. Throughout the drawings, the same or similar reference numerals denote the same or similar elements. It should be understood that the drawings are schematic, and the originals and elements are not necessarily drawn to scale.

[0030] Figure 1 This is a schematic diagram of the structure of an activity support platform provided in an embodiment of this application;

[0031] Figure 2 A schematic diagram of a user interface provided for an embodiment of this application;

[0032] Figure 3 A schematic diagram illustrating an activity progress guarantee provided in an embodiment of this application;

[0033] Figure 4 A user interface visualization calendar diagram provided for embodiments of this application;

[0034] Figure 5 This is a flowchart illustrating an activity protection method provided in an embodiment of this application. Detailed Implementation

[0035] The embodiments of this application are described below with reference to the accompanying drawings. The terminology used in the implementation section of this application is for explaining specific embodiments only and is not intended to limit the scope of this application.

[0036] The embodiments of this application will now be described with reference to the accompanying drawings. Those skilled in the art will recognize that, with technological advancements and the emergence of new scenarios, the technical solutions provided in the embodiments of this application are equally applicable to similar technical problems.

[0037] The terms "first," "second," etc., used in this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such terms are interchangeable where appropriate; this is merely a way of distinguishing objects with the same attributes in the embodiments of this application. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion, so that a process, method, system, product, or apparatus that comprises a series of units is not necessarily limited to those units, but may include other units not explicitly listed or inherent to those processes, methods, products, or apparatuses.

[0038] This application provides an activity assurance platform, method, and system suitable for scenarios with sudden surges in business access (such as online promotions and customer business promotion activities). It can achieve standardized and online management of the entire activity assurance process, reduce operational risks, and ensure the stable operation of business systems.

[0039] This application's event support platform comprises a control center and multiple functional modules. These modules cover all independent stages of the event support process (such as capacity assessment, emergency handling, and report generation). Combined with capabilities such as visual operation, process customization, and message push, it achieves fully online management of event support from parameter input, task generation, process execution, to result feedback. This solution can be applied to scenarios such as e-commerce, finance, and government affairs that need to handle sudden surges in business access, such as e-commerce platform promotions and related service promotion activities, effectively reducing operational risks and improving the stability of business systems under high concurrency scenarios.

[0040] See Figure 1 It shows a schematic diagram of the architecture of an activity assurance platform provided in an embodiment of this application. It should be noted that, in Figure 1Only the key modules of the event support platform are shown; other modules, such as communication, input / output, display, and storage modules, are not listed. Figure 1 As shown in the diagram. The event support platform may include a control platform 10 and multiple functional modules 11, wherein... Figure 1 The number of functional modules shown is not the same as the number of functional modules in actual application scenarios. Figure 1 For illustrative purposes only, the number of specific functional modules can be set according to the corresponding business scenario requirements, and this application embodiment does not limit this.

[0041] Control Center 10 is the core coordination and scheduling component of the event support platform. It undertakes decision-making, scheduling, monitoring, and aggregation functions for the entire event support process. It is the core module connecting user operations, functional module execution, and interaction with external related platforms or systems. Each functional module in the event support platform corresponds to a support node. The support node represents an independent operational link in the event support process. Each link can be executed independently and provide independent feedback results, ensuring that the support process is decomposable and traceable. For example, the platform pre-defines 12 event support nodes, such as event business assessment, link capacity assessment, expansion delivery assessment, link stress test assessment, and emergency response, into the platform to form a standardized support node library.

[0042] Specifically, functional module 11 refers to the application unit within the event assurance platform that encapsulates specific assurance functions (such as capacity assessment and monitoring configuration). The control center 10 can provide information on multiple functional modules for users to select from. This information refers to the data displayed through a user interface (UI) in the form of lists, menus, or charts, showing the functional modules and their functions. Specifically, the control center can obtain metadata (such as module identifier, name, description, required parameters, etc.) of all available functional modules from the event assurance platform's registration center and render it through the front-end interface for users to view and select. For example, when a user initiates an event assurance request on the platform, the control center first displays the functional module information corresponding to all 12 assurance nodes (such as "Capacity Assessment Submodule - used to determine whether the system needs expansion" and "Emergency Operations Module - used to formulate emergency plans"), allowing users to select the required module based on their event needs (such as large-scale promotional events or regular promotional activities), avoiding omissions due to reliance on personnel experience.

[0043] The control center can also receive activity parameters input by the user and generate assurance node tasks corresponding to the user-selected functional modules and the input activity parameters. The activity parameter values ​​refer to key data describing a specific activity, such as estimated user traffic (Transactions Per Second (TPS) / Query Per Second (QPS), activity duration, involved core business systems, and activity entry URL. An assurance node task is an executable work unit generated by the control center, configured with the functional module to be executed and specific activity parameters. For example, the control center packages the user-selected functional module identifier and submitted activity parameters into a task object, assigns it a unique task ID, and stores it in a task queue or database. When executing an assurance node task, the control center can provide the corresponding activity parameters to the corresponding functional module and obtain the activity assurance results provided by the functional module. Functional module 11 executes the corresponding activity assurance operation based on the activity parameters provided by the control center and feeds back the obtained activity assurance results to the control center. For example, the control center provides a parameter input interface, and users need to fill in the above information; for example, if an e-commerce platform initiates a "major promotion" activity guarantee requirement, the user inputs "Activity type: major promotion, estimated visitor volume: 5 million UV, core links: homepage, product details, order placement, payment, guarantee level: level 1". After receiving these parameters, the control center combines the user's selected functional modules (such as capacity assessment module, emergency handling module) to generate corresponding guarantee node tasks (such as "capacity assessment task - estimate system capacity based on 5 million UV" and "emergency handling task - develop fault solutions for the order placement link").

[0044] Specifically, after the control center generates a support node task, it stores the task in the task queue. The control center's task scheduler retrieves the task from the task queue and, based on the functional module ID specified in the task, sends the task ID and activity parameters to the corresponding functional module instance via Remote Procedure Call (RPC), message queue, or API call. Upon receiving the instructions and parameters from the control center, the functional module invokes its internal logic or interacts with external systems to complete the operation. After completion, it encapsulates the results (success, failure, data, report, etc.) into a standard format and returns them to the control center. The control center receives the return results from each functional module and stores them in association with the original task. For complex multi-task processes, it can also integrate these results into a unified report.

[0045] For example, when a control center provides information on multiple functional modules for users to choose from, it can offer a unified entry point and global perspective through an integrated user interface (UI). See also Figure 2This illustration shows a user interface provided in an embodiment of this application. The user interface displays information such as a list of tasks to be done, today's duty information, friend links (emergency links), support logs, and a duty calendar. For example, the list of tasks to be done may include corresponding support node tasks, today's duty information may include information on maintenance personnel to be contacted in emergencies, and friend links may include links to other platforms, such as databases and computing tools. Furthermore, users can quickly view the tasks that the current role needs to complete, the names of the activities requiring support today, the duty system and personnel, emergency links, and monthly activity support information and duty status.

[0046] This application provides an event assurance platform, which includes a control center and a collaborative working mode of multiple functional modules. Each functional module corresponds to an assurance node, representing an independent and standardized operational step in the event assurance process. The event assurance platform receives user-input event parameters, automatically generates tasks, schedules the corresponding modules for execution, and aggregates the results, thus forming a complete automated assurance closed loop. This effectively reduces operational risks and improves the stability of business systems under high-concurrency scenarios and the efficiency of event assurance processing.

[0047] The capacity assessment submodule in this embodiment is one of the functional modules of the event support platform. For example, it could be a "link capacity assessment" node among the 12 fixed support nodes, used to determine whether the carrying capacity of the business system meets the demand during the event. By comparing preset system basic data with user-input estimated data, it automatically generates expansion suggestions to avoid system crashes due to insufficient capacity, solving the problem of traditional capacity assessment relying on human experience. Specifically, this capacity assessment submodule compares preset system node capacity data with received event estimated capacity data to obtain a comparison result; based on the comparison result, it determines whether expansion operations are needed and generates corresponding expansion tasks.

[0048] The pre-set system node capacity data refers to the maximum carrying capacity data of each node of the business system (such as application servers, database servers, and gateways) pre-stored on the platform. For example, "Application server A can support a maximum TPS of 800" and "Database server B can support a maximum number of concurrent connections of 1000". This data is obtained through the system performance testing platform to ensure data accuracy. The platform pre-sets common activity links and the maximum TPS supported by each node in the system to form a standardized capacity database. The activity estimated capacity data refers to the expected load data of each node of the business system during the activity, which is input by the user. For example, "Application server A is expected to have a TPS of 750 during the activity" and "Database server B is expected to have a number of concurrent connections of 900". This data is estimated by the user based on historical activity data, marketing efforts, and other factors. During capacity assessment, the estimated TPS of each node must be combined with the activity guarantee level and activity links to ensure that the estimated data matches the actual needs of the activity. Then, these two sets of data are compared to obtain the comparison results. The comparison results determine whether capacity expansion is needed and generate corresponding expansion tasks. Among them, the capacity expansion task refers to the pending task generated by the capacity assessment submodule when the estimated capacity data exceeds the preset system node capacity data. This task includes the expansion node, expansion specifications, and responsible person, for example, "Application server A needs to be expanded by 1 unit, specifications: 4 cores 8G, responsible person: Operations engineer Zhang San." If expansion is required, the expansion item is pushed to the system administrator as a pending task to ensure timely implementation. This enables automated comparison of capacity data, correction of estimated data based on activity security levels, avoidance of manual calculation errors, and improved accuracy of expansion judgments. Based on preset system data and common links, it reduces the amount of repetitive input for users and improves operational efficiency.

[0049] The functional modules in this application embodiment also include an emergency handling submodule, which is used to generate an emergency handling plan containing system dependencies based on the target interface, emergency operation script, and the activity parameters; wherein, the target interface is used to integrate at least one emergency operation tool; the emergency operation script represents the template information of the emergency handling plan. Specifically, the emergency handling submodule belongs to the "Emergency Operation" node among the 12 fixed guarantee nodes, and is used to deal with sudden failures during the activity. By integrating emergency tools, pre-setting operation scripts, and sorting out system dependencies, it generates a directly executable emergency handling plan, reducing failure response time, reducing business interruption losses, and solving the problem of traditional emergency handling requiring switching operations across multiple platforms.

[0050] The target interface refers to a unified interface pre-developed by the platform for integrating external emergency operation tools, such as monitoring platforms (e.g., RMS platform), rate limiting platforms, degradation platforms, and Luban platforms, to achieve "integrated emergency tools" without switching between multiple platforms. It integrates frequently used tools and pages from emergency plans, including monitoring platforms, rate limiting platforms, degradation platforms, and Luban platforms, forming a "one-stop" emergency operation entry point. Emergency operation scripts refer to pre-built, directly executable emergency processing templates, such as "server offline script: used to remove faulty servers from the cluster" and "traffic switching script: used to redirect traffic from abnormal links to backup links." These scripts contain fixed execution logic and only require replacing activity parameters (e.g., server IP, link ID) to use. Frequently used operations such as traffic switching and server offline / remote operations are scripted and integrated into the support platform through direct embedding or link redirection, improving fault response efficiency. The emergency response submodule pre-stores the full-link dependency diagram of the business system. When generating an emergency plan, it first analyzes the dependency relationships of the core links of the activity, such as "the payment link strongly depends on the risk control system and weakly depends on the coupon system". If the risk control system fails, the plan must include strong dependency handling measures such as "activating the backup risk control interface". If the coupon system fails, the plan can choose weak dependency handling measures such as "temporarily disabling the coupon function and prioritizing payment". Finally, a complete emergency operation manual containing system dependency handling logic is formed, which can be viewed or downloaded online.

[0051] In this embodiment, the functional modules also include a report generation submodule, used to generate a target report on problem flow records and debriefing after the activity concludes. The target report includes comparative analysis data comparing the actual performance data of the business system with the estimated data. The report generation submodule belongs to the "post-event debriefing" node among the 12 fixed assurance nodes, used for debriefing and summarizing after the activity. By automatically recording the fault handling process and comparing the actual system performance with the estimated data, it generates a structured problem flow record and debriefing report, enabling the accumulation and reuse of assurance experience and solving the omission or loss problems caused by traditional debriefings conducted in offline document formats such as PPT and Word. During the event, the report generation submodule receives real-time anomaly information from various functional modules (such as fault alarms from the emergency handling submodule and over-threshold reminders from the capacity assessment submodule), and automatically creates an issue flow form. The form includes fields such as "issue description, impact analysis, issue type, issue cause, decision-making and resolution process, and experience summary." Operations personnel fill in the issue analysis and resolution process through the platform. After completion, the system automatically records the person who filled in the form and the time of completion, which cannot be modified arbitrarily. After the event ends, the submodule automatically summarizes all forms and generates an "Issue Flow Record Table," which supports online viewing, searching, and exporting. After the event, the report generation submodule retrieves actual operational data (such as actual TPS, response time, and error rate) from the Nebula platform via an interface. This data is then compared with the estimated data input by the user, generating a comparison table (e.g., "Estimated TPS: 500, Actual TPS: 580, Deviation: +16%", "Estimated Response Time: 200ms, Actual Response Time: 180ms, Deviation: -10%"). Simultaneously, the module analyzes the reasons for the deviations (e.g., "Actual traffic exceeded expectations due to additional social media advertising") and proposes optimization suggestions (e.g., "Next event requires adjusting estimated data based on promotional channels"). Finally, the module integrates "problem flow records," "data comparison analysis," and "optimization suggestions" to generate the "Event Support Review Report." This report is automatically stored in the platform's online archive to prevent offline document loss.

[0052] In this embodiment, the report generation submodule in the event support platform can be used to record problems and review data in a structured manner, avoiding the loss of offline documents and achieving the purpose of making support experience and other data traceable and reusable, thereby reducing the workload of manually compiling reports.

[0053] In this embodiment, the control center is also used to combine multiple support node tasks into a support process according to a target order based on user instructions, and control the corresponding functional modules to execute in the order of the support process to obtain the activity support results of each functional module. For example, the control center combines multiple independent tasks from 12 preset fixed support nodes into a support process (such as business assessment, capacity assessment, emergency handling, duty arrangement, and debriefing report) according to a specific order based on user instructions, and controls the functional modules to execute in sequence, ensuring that the support process fits the actual needs of the activity and solving the problem of traditional support processes being scattered and relying on manual connection. Here, the target order refers to the execution order of support node tasks set by the user according to the activity support logic, such as "complete the capacity assessment first, and then formulate the emergency plan", to avoid the ineffective operation caused by the process reversal (such as formulating an expansion emergency plan without assessing the capacity); the support process is specially customized for different support objectives and support level requirements to ensure process adaptability. For example, the control center provides a process sequence configuration interface. The left side of the interface displays 12 fixed support nodes. Users can drag and drop the selected support node tasks to adjust their order according to the activity type and support level. For instance, if a user selects "Capacity Assessment Task, Emergency Handling Task, On-Duty Check-in Task" for a "Small Regular Promotion Activity," considering the small scale of the activity, they can drag and drop to adjust the order to "Capacity Assessment Task (first determine if capacity expansion is needed), On-Duty Check-in Task (then arrange maintenance on-duty personnel), Emergency Handling Task (finally develop a simplified plan)." The control center records this target sequence and generates the support process, avoiding resource waste caused by using a unified process for large and small activities. This means the control center sends task execution instructions to the corresponding functional modules sequentially according to the target sequence. Only after the previous node task is completed and a pass result is reported will the next node task be triggered, ensuring rigorous process logic. See also... Figure 3 The control center can display the progress of the event support in the form of electricity consumption through the "Event Evaluation Progress Monitoring Page", which makes it easy for users to keep track of the process progress in real time.

[0054] In this embodiment, the event support platform further includes a user interface for providing a visual process editing interface. This interface receives user editing operations on the support process to obtain the target support process. The editing operations include at least one of adding support node tasks, deleting support node tasks, and adjusting the execution order of support node tasks. The visual process editing interface displays the support process graphically, for example, using rectangles to represent support node tasks and arrows to represent node order. Users can directly drag and drop on the interface without writing code or inputting commands. The interface also includes an "Event Evaluation Progress Monitoring" area, displaying the event support progress in the form of battery power, achieving integrated display of process editing and progress monitoring. Editing operations include adding support node tasks (drag and drop new nodes from the node library onto the canvas), deleting support node tasks (selecting a node and clicking the "Delete" button), and adjusting the execution order (drag and drop nodes to change their position on the canvas; the arrows update automatically). All operations take effect in real time, and the interface synchronously displays the latest workflow. Simultaneously, the homepage integrates five main sections: a to-do list, today's duty information, friend links, support calendar, and duty calendar, allowing users to quickly view core information while editing the workflow. In this embodiment, the graphical user interface reduces the learning curve, enabling non-technical personnel (such as operations staff) to independently configure support workflows, thus solving the problem of traditional workflow configuration relying on technical personnel.

[0055] For example, see Figure 4 The diagram illustrates a user interface visualization calendar that displays the event calendar function. Users can quickly identify the distribution of events (e.g., the 5.18 event covers multiple dates in May) through this calendar, and then adjust the node order and completion deadline of the guarantee process. For example, if a user finds that the 5.18 event has a long cycle, they can add a "mid-term capacity review" node when editing the process to ensure the stability of system performance during the middle of the event.

[0056] In this embodiment, the control center communicates with a message push platform. The control center also sends the pending tasks corresponding to the support node tasks to the target receiving end through the message push platform, and receives the push result information from the message push platform. For example, the control center communicates with a message push platform (such as a mobile work platform), and accurately sends the pending tasks (such as capacity expansion tasks or shift tasks) corresponding to the support node tasks to the responsible persons through the message push platform. This implements a "single responsibility system," ensuring timely task delivery and traceability of responsibility, thus solving the problems of task omissions and unclear responsibilities in traditional support systems.

[0057] In this embodiment, the message push platform refers to a platform used to deliver notifications of pending tasks, such as a mobile work platform. It supports functions such as text messages, task reminders, and read receipts, and can accurately locate the recipient (e.g., by matching employee ID or department information). By connecting to the mobile work platform and internal management channels, it realizes the workflow of pending tasks and targeted message push, ensuring the accuracy and timeliness of message delivery. For example, after generating a support node task, the control center automatically extracts the core task information (e.g., "Task Name: Expanding Application Server, Responsible Person: Li Si, Deadline: 2024-06-17 18:00, Priority: High") and sends it to the message push platform via an interface. The platform then sends the information to the responsible person in the form of a message. This strictly implements a single responsibility system, ensuring that no task node is missed or responsibility is unclear, while also avoiding the problem of lost evaluation data due to misoperation by other colleagues.

[0058] In this embodiment, the functional module is further configured to, when executing the assurance node task, if an execution anomaly is detected, record the current status data of the business system and include the status data in the activity assurance result. That is, in this embodiment, the functional module has anomaly detection and data recording capabilities. When executing 12 preset fixed assurance node tasks, if an operational anomaly is detected (such as inability to obtain system data during capacity assessment or tool call failure during emergency handling), it will automatically record the current status data of the business system (such as server CPU utilization and interface error rate) and include it in the activity assurance result, providing a basis for subsequent fault investigation and solving the problem of insufficient data support in traditional anomaly handling.

[0059] Each functional module can be pre-set with exception handling rules, such as data acquisition timeout (10 seconds), interface call success code (200), and TPS threshold range (e.g., estimated TPS ±20%). When executing a task, the module monitors the operation progress and return results in real time. If an exception rule is triggered (e.g., timeout, error code not 200, TPS exceeding the threshold), it immediately marks "task execution exception" and pauses the current operation to prevent the exception from escalating. For example, when the link capacity assessment module calls the Nebula platform interface to obtain historical data, if no response is received within 10 seconds, it is immediately judged as "data acquisition exception" and the assessment operation is stopped. After a functional module marks an anomaly, it immediately retrieves system, application, and business layer data from the RMS platform at the time the anomaly occurred via an interface. For example, "2024-06-18 10:05, application server 01's CPU utilization is 95%, memory utilization is 85%, payment interface response time is 500ms, error rate is 8%, current online users are 100,000, core link TPS is 300". At the same time, the functional module records the anomaly occurrence time, anomaly type (e.g., "data acquisition anomaly"), anomaly node (e.g., "link capacity assessment module"), and current execution step (e.g., "acquiring historical TPS data"). This information is integrated with the status data to form an anomaly record, which is included in the activity assurance results and fed back to the control center. The control center marks the node as "anomaly" on the "Activity Assessment Progress Monitoring Page" and displays an anomaly summary (e.g., "Link capacity assessment: data acquisition timed out, CPU utilization 95%"). This allows for real-time anomaly detection, preventing anomalies from continuously impacting subsequent support processes, reducing the risk of escalating failures, supplementing anomaly information into support results, ensuring the traceability of the support process, providing anomaly analysis basis for subsequent reviews, and promoting continuous optimization of support plans.

[0060] The following describes the activity support platform of this application using a scenario example. For instance, a business system needs to carry out a 5.18 online promotion event, and it is expected that the number of visits to the business system during the event will increase by 3 times compared to usual. The core business chain is "user login - product browsing - order placement and payment - order confirmation". The activity support platform needs to complete the entire lifecycle support to reduce the risk of operation and maintenance and ensure the stable operation of the business under high concurrency scenarios.

[0061] After initiating the assurance process, the initial assessment is performed through the activity business assessment module within the functional modules. This module first inputs the tiered assurance plan for the business system into the system in advance, and then assesses the assurance level of the business activities from seven dimensions based on the activity implementation information provided by the business departments. At the same time, it automatically generates the entire activity chain based on the activity type and key activity entry points, and combines the activity assurance level and activity chain to perform a two-dimensional expansion of the assurance plan, assessing the estimated TPS (transactions per second) of each node, and ultimately achieving customized implementation assurance, providing a basis for subsequent steps.

[0062] After the business assessment is completed, the capacity assessment submodule proceeds with capacity data collection and analysis. This module pre-defines common activity links and the maximum supported TPS of each node in the system. By connecting to external data platforms to query historical activity data and the actual highest TPS of each node, it renders and displays the link topology and TPS data (estimated, historical maximum, and maximum supported). Subsequently, based on the TPS comparison results fed back by the capacity assessment submodule, the control center matches the target link from three tiered guarantee links:

[0063] No need for capacity expansion load testing link: If the estimated TPS value of each node is lower than the historical highest TPS value and also lower than the maximum supportable TPS value, the activity is judged as not requiring capacity expansion load testing, omitting the two steps of capacity expansion delivery assessment and load testing situation assessment.

[0064] No expansion required: When the estimated TPS value of each node is lower than the maximum supportable TPS value, but higher than the historical highest TPS value, the activity will be judged as not requiring expansion. To ensure the accuracy of the maximum supportable TPS value, a new stress test is required, so the expansion delivery assessment step will be omitted.

[0065] Requires expansion of the link: If the estimated TPS value of each node is higher than the maximum supportable TPS value, the activity is judged to require expansion, and the corresponding complete activity guarantee link needs to be completed.

[0066] Based on the hierarchical link determination results, the monitoring configuration is implemented through the monitoring and alarm evaluation module in the functional modules. This module presents business layer monitoring indicators (response time, TPS, error codes, etc.), application layer monitoring indicators (JVM, thread pool, etc.), and system layer monitoring indicators (CPU, memory, etc.) in the form of a form on the page, reminding system personnel to complete the monitoring configuration; at the same time, it has an embedded indicator dashboard, which supports jumping to external monitoring platforms to view monitoring rules, ensuring that system anomalies can be captured in real time during the event.

[0067] To address unexpected failures, an emergency support mechanism is established through an emergency handling submodule. This module integrates frequently used tools in the emergency plan (monitoring platform, rate limiting platform, degradation platform, etc.) to achieve unified emergency tools; it also scripts high-frequency emergency operations such as traffic switching and server shutdown / reconnection, integrating them into the platform through embedding or linking; and it develops emergency operation manuals based on the strength and weakness of inter-system dependencies for specific activities, significantly improving failure response efficiency.

[0068] Before the event begins, manpower arrangements are completed through the emergency duty check-in module in the functional modules. This module generates duty status forms for related systems, the system department, and the network department based on the event's security level, specifying the duty personnel and their duty hours; and pushes message reminders through the message push platform to ensure that each stage of the event has dedicated personnel on duty to respond promptly to emergencies.

[0069] After the event, a debriefing was conducted using the report generation submodule. This module automatically generates two processes: the issue flow process records the problems encountered during the event support, and the debriefing report process reviews the system performance during the support period, compares the prediction model with the stress test data, summarizes the problems that were not identified and prepared for in advance, and provides support for optimizing subsequent support work.

[0070] Throughout the process, the control center coordinates intelligent approval and hierarchical link management: on the one hand, by connecting to the message push platform and the permission management system, it realizes the workflow of pending tasks and targeted message push, implements the single responsibility system, and avoids the risk of loss of assessment data; on the other hand, based on the TPS data fed back by the capacity assessment submodule, it matches the target link from the three hierarchical guarantee links (no expansion required for stress testing link, no expansion required for link, and expansion required for link). If this activity is determined to be a "no expansion required link", the expansion delivery assessment step is omitted, which improves guarantee efficiency while ensuring quality.

[0071] This application also provides an activity assurance method, see [link to relevant documentation]. Figure 5 The method may include the following steps:

[0072] S101. Display information about multiple functional modules for the user to choose from.

[0073] Each functional module corresponds to an activity protection operation.

[0074] S102, Receive activity parameters input by the user.

[0075] S103. Generate the guarantee node tasks corresponding to the functional modules selected by the user and the activity parameters input by the user.

[0076] S104. Execute the protection node task and send the activity parameters to the corresponding functional module to perform the corresponding activity protection operation.

[0077] S105. Integrate the activity assurance results returned by various functional modules to obtain activity assurance record information.

[0078] It should be noted that the relevant execution steps in this activity protection method can be found in the description of the relevant functional modules in the aforementioned activity protection platform, and will not be detailed here.

[0079] Correspondingly, this application embodiment also provides an event support system, which includes the event support platform in the foregoing embodiments and at least one external platform. The external platform is used to provide data support or execution environment for the functional modules in the event support platform. The event support platform communicates and interacts with the external platform through a preset interface.

[0080] For example, platforms such as the Nebula platform for acquiring historical activity data, the PerfMaIT system for performing load testing, the RMS platform for monitoring, the mobile work platform for message push, and the channel management system for synchronizing permissions are the basic support for the implementation of the activity assurance platform's functions. For instance, the link capacity assessment module relies on historical data from the Nebula platform, and the capacity expansion and delivery assessment module relies on the load testing environment of the PerfMaIT system. In this embodiment, external platforms provide data and environmental support, avoiding the "isolated operation" of the activity assurance platform and ensuring that the 12 fixed assurance node functions can be implemented (without the Nebula platform, the link capacity assessment cannot be executed, and without the PerfMaIT system, load testing verification cannot be completed). Standardized preset interfaces ensure stable data interaction, reduce the complexity of cross-platform integration, and facilitate the addition of external platforms in the future (such as adding a log analysis platform later, only a new interface needs to be developed for access). Each external platform works collaboratively with the assurance platform to form a complete assurance ecosystem, improve the standardization and automation level of activity assurance, and solve the pain point of traditional assurance relying on manual operation of multiple platforms.

[0081] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to the method section.

[0082] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0083] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented directly by hardware, a software module executed by a processor, or a combination of both. The software module can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art.

[0084] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. An event security platform, characterized in that, The application relates to a control center and a plurality of function modules, each of which corresponds to a guarantee node representing an independent operation link in an active guarantee process; wherein The control center provides information of the plurality of function modules for user selection, receives active parameters input by the user, generates a guarantee node task corresponding to the function module selected by the user and the active parameters input by the user, provides the active parameters corresponding to the guarantee node task to the function module corresponding to the guarantee node task when the guarantee node task is executed, and obtains an active guarantee result provided by the function module; The function module executes the active guarantee operation corresponding to the function module according to the active parameters provided by the control center, and feeds back the active guarantee result obtained by execution to the control center. The function module comprises a capacity evaluation sub-module; 2. The event security platform of claim 1, wherein, The capacity evaluation sub-module compares preset system node capacity data with received active estimated capacity data to obtain a comparison result, determines whether expansion operation needs to be executed according to the comparison result, and generates a corresponding expansion to-be-done task. The function module further comprises an emergency processing sub-module; 3. The event security platform of claim 1, wherein, The emergency processing sub-module generates an emergency processing scheme containing system dependency relationship based on a target interface, an emergency operation script and the active parameters; wherein the target interface is used for integrating at least one emergency operation tool; and the emergency operation script represents template information of the emergency processing scheme. The function module further comprises a report generation sub-module; 4. The event security platform of claim 1, wherein, The report generation sub-module generates a problem flow record and a target report of a review after an activity ends; and the target report comprises comparison and analysis data of actual performance data and estimated data of a business system. The control center is further used for combining a plurality of guarantee node tasks into a guarantee process according to a user instruction and a target order, and controlling corresponding function modules to execute in the order of the guarantee process to obtain active guarantee results of the function modules.

5. The event security platform of claim 1, wherein, Further comprising:

6. The event security platform of claim 5, wherein, A user interface; The user interface provides a visual process editing interface; wherein the visual process editing interface is used for receiving an editing operation of the guarantee process by the user to obtain a target guarantee process, and the editing operation comprises at least one of adding a guarantee node task, deleting a guarantee node task and adjusting an execution order of a guarantee node task. The control center is in communication connection with a message pushing platform; and the control center is further used for sending a to-be-done task corresponding to the guarantee node task to a target receiving end through the message pushing platform, and receiving pushing result information fed back by the message pushing platform.

7. The event security platform of claim 1, wherein, The function module is further used for recording state data of a current business system and containing the state data in the active guarantee result when detecting that a guarantee node task is abnormally executed.

8. The event security platform of claim 1, wherein, The application discloses a guarantee node task generation method and device, a guarantee node task execution method and device, a guarantee node task editing method and device, and a guarantee node task pushing method and device.

9. An event security method characterized by, ​ ​ ​ generating a guarantee node task corresponding to the function module selected by the user and the activity parameter input by the user; executing the guarantee node task, and sending the activity parameter to the corresponding function module to execute a corresponding activity guarantee operation; integrating activity guarantee results returned by each function module to obtain activity guarantee record information.

10. An event security system, characterized by The application relates to an activity guarantee platform. The application relates to an activity guarantee platform. The application relates to an activity guarantee platform. The application relates to an activity guarantee platform. The application relates to an activity guarantee platform. The application relates to an activity guarantee platform. The application relates to an activity guarantee platform. The application relates to an activity guarantee platform. The application relates to an activity guarantee platform. The application relates to an activity guarantee platform. The application relates to an activity guarantee platform. The application relates to an activity guarantee platform. The application relates to an activity guarantee platform. The application relates to an activity guarantee platform. The application relates to an activity guarantee platform. The application relates to an activity guarantee platform. The application relates to an activity guarantee platform. The application relates to an activity guarantee platform. The application relates to an activity guarantee platform. The application relates to an activity guarantee platform. The application relates to an activity guarantee platform. The application relates to an activity guarantee platform. The application relates to an activity guarantee platform. The application relates to an activity guarantee platform. The application relates to an activity guarantee platform

Images