A function release control method, device, equipment and medium

Abstract

The present application relates to the field of software function design, in particular to a function release control method, device, equipment and medium. The present application first acquires a release scene and a unique scene identifier, relies on the identifier to call a release switch and generates a release logic code, can independently customize function start-stop rules according to scenes, and breaks the rigid mode of traditional unified control. After the code is tested and packaged as an online version, the specified tenant is configured with permissions, the function opening range is accurately determined, the customer dimension is differentiated for release, the function does not need to be pushed in full amount, and the normal use of the remaining tenants is avoided. At the same time, business operation logs are continuously recorded, which is convenient for subsequent state monitoring and problem troubleshooting, the overall configuration process does not need complex modification, and the control cost is effectively reduced. In summary, flexible and accurate control of function release is realized, and the problems of rigid mode, high cost and easy influence on customer use of the traditional mode are solved.

Description

Technical Field

[0001] This invention relates to the field of software function design, and specifically to a method, apparatus, equipment, and medium for controlling the release of functions. Background Technology

[0002] Currently, mainstream SaaS systems generally adopt a static resource allocation model and a simple resource expansion strategy. The resource allocation rules are fixed and the adjustment methods are singular, making it impossible to adaptively adjust resources in response to dynamic changes in business scenarios. As the customer base covered by SaaS services continues to expand, the functional usage needs, access scale, and permission requirements of different customers show significant differences. The existing model is difficult to flexibly deploy new functions for different customers.

[0003] In the process of launching and scaling up new requirements and features, traditional solutions either uniformly open up all features, which can easily lead to system resource consumption and affect the user experience of some customers; or adopt an overall gray-scale switching approach, which involves cumbersome configuration processes and high transformation costs. These solutions cannot accurately and cost-effectively scale up features according to customer dimensions, nor can they effectively avoid the interference of feature launches on the normal business operations of existing customers. Overall, there are obvious shortcomings in flexibility, adaptability and control capabilities. Summary of the Invention

[0004] In view of this, embodiments of the present invention provide a method, apparatus, device and medium for managing the release of features, in order to solve the problems of rigid resource allocation and feature release methods in traditional SaaS systems, which cannot accurately and flexibly release new features for different customers, resulting in high management costs and easy impact on normal customer use.

[0005] In a first aspect, embodiments of the present invention provide a method for controlling the ramp-up of functionalities, the method comprising: Obtain the newly added volume increase scenarios and the scenario identifiers corresponding to the newly added volume increase scenarios; The scenario identifier is used to obtain the volume increase switch, and the volume increase switch is used to generate the volume increase logic code for the new business function of the target page corresponding to the new volume increase scenario; Test the volume increase logic code. If the volume increase logic code passes the test, the tested volume increase logic code will be packaged into an online version. Configure the specified tenants with the increased capacity permissions based on the online version to limit the scope of the newly added business functions, and continuously record the business operation logs after the increased capacity permissions take effect.

[0006] Furthermore, the step of obtaining the volume increase switch using the scene identifier and generating the volume increase logic code for the new business function of the target page corresponding to the new volume increase scene through the volume increase switch includes: The scene identifier is passed to the volume control center interface to generate a switch query command; Execute the switch query command to read the configuration platform data and obtain the status value of the output switch; Based on the stated state values, functional judgment logic is written to obtain basic code snippets; By integrating the basic code snippet with the page function code of the target page, the scaling logic code for the new business function is obtained.

[0007] Furthermore, configuring the allowance for a specified tenant based on the online version includes: Get the tenant information to be configured; Based on the tenant information to be configured, a corresponding login request is sent to the volume configuration platform; In response to the login result returned by the volume scaling configuration platform, the volume scaling scenario configuration page is displayed; Based on the aforementioned volume expansion scenario configuration page, the specified tenant is identified and functional permissions are enabled. Permission configuration instructions are generated, and the parameters are saved by executing the permission configuration instructions to obtain the effective volume expansion permissions.

[0008] Furthermore, the continuous recording of business operation logs after the volume expansion permission takes effect includes: After the increased volume authorization takes effect, collect the operational data of the target page and the newly added business function; The operational data is categorized according to tenant identifier, operation time, and functional node to obtain structured log data. Redundant data is then removed from the structured log data to generate business operation logs.

[0009] Furthermore, the method also includes: The business operation logs are parsed and abnormal records are filtered to obtain log entries related to the problem. Analyze the relevant log entries to pinpoint the cause of the anomaly and obtain the root cause information of the problem; A processing scheme for generating a response based on the root cause information of the problem.

[0010] Furthermore, the analysis of relevant log entries identifies the cause of the anomaly, obtaining root cause information, including: Extract key fields from the log entries related to the problem to obtain a log feature dataset. The key fields include: tenant number, access sequence, and interface return code. The log feature dataset is compared item by item with the benchmark data to identify data deviation items; By tracing data deviations through function call chains and permission configuration rules, the fault occurrence point can be determined, and information on the abnormal point can be obtained. Based on the information about the abnormal process, the fault triggering conditions and underlying causes are analyzed to obtain the root cause information of the problem.

[0011] Furthermore, the processing scheme for generating a response based on the root cause information of the problem includes: Based on the key information in the root cause of the problem, problem assessment data is generated, wherein the key information includes the fault type, affected tenants, and functional scope. The risk levels of the aforementioned issues are assessed and classified using volume control requirements to determine the priority of handling. Refer to the aforementioned handling priorities to query the corresponding temporary emergency measures and long-term optimization methods; Based on the actual business situation, the temporary emergency measures and long-term optimization methods are modified to obtain a problem-solving solution.

[0012] Secondly, embodiments of the present invention provide a control device for increasing the amount of functionality, the device comprising: The acquisition module is used to acquire newly added volume increase scenarios and the scenario identifiers corresponding to the newly added volume increase scenarios; The processing module is used to obtain the volume increase switch using the scene identifier and to obtain the volume increase logic code for the new business function of the target page corresponding to the new volume increase scene; The generation module is used to test the volume expansion logic code. If the volume expansion logic code passes the test, the tested volume expansion logic code is packaged into an online version. The management module is used to configure the release permissions for specified tenants based on the online version, so as to limit the scope of the newly added business functions, and continuously record the business operation logs after the release permissions take effect to obtain release operation data.

[0013] Thirdly, embodiments of the present invention provide a computer device, including: a memory and a processor, the memory and the processor being communicatively connected to each other, the memory storing computer instructions, and the processor executing the computer instructions to perform the method described in the first aspect or any corresponding embodiment thereof.

[0014] Fourthly, embodiments of the present invention provide a computer-readable storage medium storing computer instructions that cause a computer to perform the method described in the first aspect or any of its corresponding embodiments.

[0015] This application first obtains the scaling scenarios and unique scenario identifiers. Based on these identifiers, it retrieves the scaling switch and generates scaling logic code. It allows for independent customization of function start / stop rules according to each scenario, breaking the rigid model of traditional unified management. After testing and packaging the code into an online version, permissions are configured for specific tenants, precisely defining the scope of function access and achieving differentiated scaling from a customer perspective. This eliminates the need for full-scale function pushes, avoiding interference with other tenants' normal use. Simultaneously, it continuously records business operation logs, facilitating subsequent status monitoring and troubleshooting. The overall configuration process requires no complex modifications, effectively reducing management costs. In summary, it achieves flexible and precise control over function scaling, solving the problems of rigid models, high costs, and potential disruption to customer usage associated with traditional methods. Attached Figure Description

[0016] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0017] Figure 1 This is a flowchart illustrating a method for controlling the ramp-up of functions according to some embodiments of the present invention; Figure 2 This is a flowchart illustrating another method for controlling the release of functionalities according to some embodiments of the present invention; Figure 3 This is a flowchart illustrating another method for controlling the volume of data according to some embodiments of the present invention; Figure 4 This is a structural block diagram of a function release control device according to an embodiment of the present invention; Figure 5 This is a schematic diagram of the hardware structure of a computer device according to an embodiment of the present invention. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0019] According to embodiments of the present invention, a method, apparatus, device, and medium for controlling the release of functionalities are provided. It should be noted that the steps shown in the flowcharts in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowcharts, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0020] This embodiment provides a method for controlling the scaling up of functionality. Figure 1 This is a flowchart of a method for controlling the release of functionalities according to an embodiment of the present invention, such as... Figure 1 As shown, the process includes the following steps: Step S101: Obtain the newly added volume increase scenario and the scenario identifier corresponding to the newly added volume increase scenario.

[0021] In this embodiment, the business requirements are first broken down and analyzed to identify the new scenarios that need to be launched and released. The business uses, applicable pages, and service targets corresponding to different scenarios are distinguished, and a full-scale review and classification of scenario information is completed. Then, a unique character code is assigned to each new scenario as a scenario identifier according to preset encoding rules. The encoding process combines and arranges elements such as scenario classification, launch batch, and functional attributes to ensure that the identifier is unique and identifiable.

[0022] Next, the basic information of the completed volume expansion scenarios is bound and associated with the corresponding scenario identifiers to establish a mapping relationship between scenario content and identifiers. At the same time, the completeness and accuracy of the mapping data are verified, and duplicate, missing, and erroneous information entries are removed. After data regularization, the complete content of the newly added volume expansion scenarios and the corresponding scenario identifiers are finally extracted, completing all data collection work in this step.

[0023] Step S102: Obtain the volume release switch using the scene identifier, and generate the volume release logic code for the new business function of the target page corresponding to the new volume release scene through the volume release switch.

[0024] In this embodiment, a ramp-up switch is obtained using a scenario identifier. The ramp-up logic code for the new business function on the target page corresponding to the new ramp-up scenario is generated using the ramp-up switch. The process includes: passing the scenario identifier to the ramp-up center interface to generate a switch query instruction; executing the switch query instruction to read configuration platform data and obtain the status value of the ramp-up switch; writing functional judgment logic based on the status value to obtain a basic code snippet; and integrating the basic code snippet with the page function code of the target page to obtain the ramp-up logic code for the new business function.

[0025] Specifically, following the established communication protocol, data format, and field rules of the interface, the scene identifier is structurally encapsulated, supplementing essential auxiliary information such as message headers, verification fields, and version identifiers, and completing data encoding and format adaptation. Integrity verification is performed on the encapsulated message to remove incorrect formatting and incomplete data, ensuring that parameters can be parsed correctly. Parameter routing and distribution are completed based on the interface routing rules, sending the processed scene identifier completely to the scaling center interface. The interface extracts core identifier information, combines it with business retrieval rules, query types, and data return requirements, and arranges instruction content to generate an independently executable on / off query instruction bound to the current scene, clearly defining the retrieval scope and data output standards within the instruction.

[0026] The system analyzes the search criteria, scene association information, and data reading range in the switch query command. Following the search logic, it traverses the storage data tables of the configuration platform to locate the configuration entry matching the current scene identifier. It reads all the original configuration data within the entry, decodes it, splits and cleans the data, removing redundant characters, invalid comments, and cached data. Multiple sets of associated configurations are merged and deduplicated, and data integrity and consistency are verified, investigating issues such as missing configurations and data anomalies. From the standardized configuration data, the core markers and values ​​representing the operating mode are selected. After unifying the data format, the standard format of the volume control switch status values ​​is extracted and output.

[0027] Based on the state values, functional judgment logic was written to obtain basic code snippets. The business meanings corresponding to the volume control switch state values ​​were analyzed, different operating modes such as enabled, disabled, and gray-scale release were distinguished, and the code execution branches and flow rules corresponding to each state were outlined. A conditional judgment framework was built following programming language syntax specifications, branch judgment statements were designed around the state values, variable types, operation rules, and jump logic were defined, and the execution direction of each branch was clarified. The logic code was written line by line, the internal data flow path was analyzed, and issues such as missing conditions, logical contradictions, and invalid boundary judgments were investigated. The code was formatted and modularized, breaking it down into functionally independent and structurally concise code units, resulting in reusable and logically complete basic code snippets.

[0028] By integrating basic code snippets with the page functionality code of the target page, the scaling logic code for the new business function is obtained. The architecture, runtime sequence, variable naming, and interface dependencies of the two types of code are analyzed to determine code connection points and data interaction channels. Following the original execution order of the page, the basic code snippets are embedded into the pre-call stage of function calls, unifying global variables, function names, and parameter passing rules to eliminate syntax conflicts and missing dependencies. The data flow links between modules are established, code splicing and structural fusion are completed, and the integrated code undergoes syntax verification and logical deduction to fix vulnerabilities and anomalies at the connection points, resulting in scaling logic code that adapts to the page's runtime environment and has a closed logical loop.

[0029] Step S103: Test the volume increase logic code. If the volume increase logic code passes the test, package the tested volume increase logic code into an online version.

[0030] In this embodiment, a simulated runtime environment is built for the generated scaling logic code. The environment parameters are fully aligned with the system version, interface configuration, data interaction rules, and permission system of the online runtime environment. First, syntax compilation tests are performed to check for basic issues such as syntax errors, formatting abnormalities, and missing dependencies. Then, unit tests are executed to verify the running effect of each logical branch, judgment condition, and interface call within the code, simulating code execution under different on / off states and different access scenarios.

[0031] Following this, integration testing was conducted, embedding the code into the target page and new business functions to verify the overall linkage effect, data transmission status, and function start / stop effects. A comprehensive review was conducted to identify and address various issues such as logical defects, operational lag, and function failures. Problems discovered during testing were addressed and optimized item by item, with repeated retesting until all test items met the standards. The successfully tested deployment logic code was then processed, with standardized code comments, version markings, and configuration parameters. Following online deployment specifications, it was modularly packaged, encrypted, and version-numbered, completing the code encapsulation process and generating a directly deployable online version.

[0032] Step S104: Configure the expansion permissions for specified tenants based on the online version to limit the scope of new business functions and continuously record the business operation logs after the expansion permissions take effect.

[0033] In this embodiment of the application, configuring the ramp-up permissions of a specified tenant based on the online version includes: obtaining the tenant information to be configured; sending a corresponding login request to the ramp-up configuration platform based on the tenant information to be configured; responding to the login result fed back by the ramp-up configuration platform and displaying the ramp-up scenario configuration page; determining the specified tenant and enabling the function permissions based on the ramp-up scenario configuration page, generating permission configuration instructions, and executing the permission configuration instructions to complete parameter saving and obtain the effective ramp-up permissions.

[0034] Following preset data field specifications, core information such as tenant unique IDs, identity verification characters, and access permission tags are extracted. Scattered original tenant information is integrated and grouped, with standardized data format and character encoding. Information integrity is verified, missing fields are filled, and formatting errors are corrected. Combining the access protocol and request specifications of the deployment platform, the integrated tenant information is encapsulated into a standard login message, adding auxiliary content such as message verification code, request type identifier, and access timeliness parameters. Message encoding is performed according to network transmission rules, matching the platform's specified communication port and access address. Data transmission is initiated according to request timing rules, and the login request carrying tenant information is fully pushed to the deployment platform, completing the request delivery.

[0035] The system decodes and parses the login feedback data packets returned by the platform, extracting data such as the login status code, identity verification result, and page access permission identifier to determine the validity of the login result. If the status code indicates successful login verification, the system retrieves the platform's front-end page resource files, loads the matching page components, function menus, and data display modules based on the tenant's corresponding access permission tags, renders the interface elements according to the page layout rules, and simultaneously loads all currently created scaling scenario directories and corresponding configuration entries, fully displaying the visualized scaling scenario configuration page. Simultaneously, the system records login session information to maintain data connectivity between the page and the backend service, ensuring normal interaction for subsequent configuration operations.

[0036] The system iterates through the tenant list loaded on the page, uses preset filtering criteria to locate the specific tenant entry requiring permission configuration, and associates the selected target tenant with the corresponding new business function and scaling scenario. It then selects the function access permission option, configures the permission effective period, usage limit, access scope, and other auxiliary constraint parameters as needed, and encapsulates and combines all configuration parameters according to the backend command format to generate a permission configuration command carrying tenant information, function identifier, and permission parameters. The command is then sent back to the backend configuration storage area according to data interaction rules, completing parameter writing and persistent storage. The system automatically verifies parameter compliance and updates the permission status flag, making the configuration officially effective and granting the controlled scope of function opening permissions.

[0037] In this embodiment of the application, the business operation log is continuously recorded after the volume expansion permission takes effect, including: after the volume expansion permission takes effect, collecting the operation data of the target page and the newly added business function; classifying the operation data according to the tenant identifier, operation time and function node to obtain structured log data, and removing redundant data from the structured log data to generate business operation logs.

[0038] After the increased permissions take effect, operational data for the target page and newly added business functions is collected. Once the permission status is updated and officially effective, a full-dimensional data collection mechanism is initiated. Following a uniform sampling frequency, the entire process of the target page's behavior—from loading, rendering, and redirection to interaction—is continuously captured. Simultaneously, various raw data related to new business function initiation calls, parameter transmissions, command executions, interface responses, and status feedback are captured. The collection process fully retains the original messages, response durations, operational status markers, interaction parameters, and underlying call records for each operation, without filtering, modifying, or merging the raw data.

[0039] Separate independent data cache partitions to distinguish between page behavior data and function operation data, avoid mixing and interference between different types of data, and continuously aggregate all real-time generated raw information in chronological order to obtain a complete set of raw operation data that has not been processed.

[0040] The operational data is categorized according to tenant identifier, operation time, and functional node to obtain structured log data. Redundant data is then removed from the structured log data to generate business operation logs. Using tenant identifier as the primary classification dimension, operation time as the sorting basis, and functional node as the subdivision standard, the raw operational data is hierarchically organized and grouped. Standard field labels are added to each data entry, and the time format, character encoding, data units, and field arrangement order are standardized. This process transforms the scattered and disorganized raw data into structured log data with a unified format, clear hierarchy, and well-organized fields.

[0041] Subsequently, data cleaning operations are performed to accurately identify and remove various redundant contents in the structured data, such as duplicate records, null fields, invalid placeholders, test-type garbage data, and expired cached data. At the same time, the integrity and validity of the remaining data are verified, and incomplete or invalid entries are filtered out. After multiple rounds of cleaning and verification, the compliant data is archived and integrated in a time series to obtain the business operation log.

[0042] In the embodiments of this application, such as Figure 2 As shown, the method also includes: Step S201: Parse the business operation logs and filter out abnormal records to obtain log entries related to the problem.

[0043] In this embodiment, the existing business operation logs are fully parsed and decomposed. The logs are read layer by layer, including tenant identifiers, operation times, functional nodes, interface response parameters, permission verification results, program error codes, and data flow status, among other multi-dimensional fields. This unifies the field parsing rules and data reading standards for various log types, achieving a structured reconstruction of the original log data. Based on preset business anomaly judgment rules, anomaly data filtering thresholds and judgment models are established. Log data is compared item by item with normal operation benchmark data to identify various anomaly records such as interface call failures, permission verification anomalies, function loading timeouts, data return errors, and operational lag / interruption. Log data from normal operation is filtered out, and all records matching anomaly characteristics are aggregated. This process removes duplicate anomaly data and filters invalid anomaly logs, ultimately outputting log entries related to matching business failures.

[0044] Step S202: Analyze the relevant log entries to locate the cause of the anomaly and obtain the root cause information of the problem.

[0045] In this embodiment, analyzing problem-related log entries to locate the cause of the anomaly and obtain the root cause information includes: extracting key fields from the problem-related log entries to obtain a log feature dataset, wherein the key fields include: tenant number, access sequence, and interface return code; comparing the log feature dataset with the benchmark data item by item to identify data deviation items; using the function call chain and permission configuration rules to trace the data deviation items, determine the fault occurrence link, and obtain the anomaly link information; and analyzing the fault triggering conditions and underlying causes based on the anomaly link information to obtain the root cause information.

[0046] Specifically, all relevant log entries after screening are subjected to structured parsing. The underlying data structure of each log entry is disassembled, and three core key fields—tenant ID, access sequence, and API return code—are extracted. Redundant comments, invalid characters, and irrelevant auxiliary fields are removed. The data format of all fields is standardized: access sequences are converted to different time zones and formatted; tenant IDs are validated and their characters are normalized; and API return codes are numerically normalized. After extracting fields from individual log entries, they are batch-summarized and integrated. Data is sorted and normalized according to chronological order, duplicate fields and incomplete or invalid data are removed, and a log feature dataset is constructed.

[0047] The system retrieves pre-stored baseline data for normal operation during increased functionality. This baseline data includes compliant standard parameters such as standard tenant access parameters, normal access time sequence intervals, and valid interface return code intervals. Each tenant number, access time sequence, and interface return code in the log feature dataset is compared item by item with the baseline data dimensions to verify whether each parameter conforms to the normal operation standard range. Abnormal data that does not conform to the baseline rules, such as exceeding the compliance range, parameter mismatch, abnormal return codes, and disordered access time sequences, is marked. The statistical differences in content, value, and characteristics are analyzed. All comparison anomalies are summarized, duplicate deviation data is merged and deduplicated, and all valid data deviation items are identified and filtered out.

[0048] Based on the complete front-end and back-end call chain logic of the newly added business functions, combined with the verification rules, parameter activation mechanism, and tenant permission matching logic of the increased permission configuration, a full-chain traceability was performed on the selected data deviation items. The corresponding permission configuration parameters were located according to the tenant number corresponding to the deviation item. The complete execution flow of function call, permission verification, interface request, and data return was restored by combining the access sequence, and the running status of each execution node was checked against the standard call chain. Anomalies in each link, including permission verification, interface request, data response, and function rendering, were investigated, the specific execution link where the deviation occurred was identified, and the link location of the fault, associated configuration parameters, and running status were recorded to obtain complete information on the abnormal link.

[0049] Based on the identified anomaly information, a deep review of the overall operational logic of the fault chain is conducted, integrating comprehensive analysis of permission configuration rules, code execution logic, interface interaction mechanisms, and page operation rules. Potential issues such as parameter configuration defects, logic execution vulnerabilities, data interaction anomalies, and permission matching failures corresponding to the anomaly are dissected, clarifying the pre-fault operational conditions, environmental conditions, and parameter conditions. The complete process of the anomaly from triggering and propagation to the final error is traced, determining whether the problem stems from configuration errors, code defects, data anomalies, or environment adaptation issues. Simultaneously, the core underlying causes, scope of impact, and derivative problems of the fault are identified, and the integrated analysis yields the root cause information of the problem.

[0050] Step S203: Generate a response solution based on the root cause information of the problem.

[0051] In this embodiment of the application, the processing scheme for generating a response based on the root cause information of the problem includes: generating problem assessment data based on the key content in the root cause information of the problem, wherein the key content includes the fault type, affected tenants and functional scope; classifying the risk level of the problem assessment using the volume control requirements to obtain the handling priority; querying the corresponding temporary emergency measures and long-term optimization methods with reference to the handling priority; and modifying the temporary emergency measures and long-term optimization methods according to the actual business situation to obtain the problem handling scheme.

[0052] Specifically, the core content of the root cause information is broken down, and the fault type is categorized, distinguishing between different fault categories such as permission configuration anomalies, code logic anomalies, interface interaction anomalies, and data loading anomalies. The total number of tenants affected by the fault is statistically analyzed to clarify the scope of the tenant group covered by the fault. Simultaneously, the newly added business function modules, page nodes, and function usage scenarios corresponding to the fault are defined to pinpoint the complete functional impact range. The three core information categories—fault type, affected tenant range, and functional impact range—are integrated, supplemented with auxiliary assessment parameters such as fault duration and frequency of occurrence. The data is then standardized and packaged according to the specified format to generate comprehensive, standardized, and risk assessment data.

[0053] Based on the system's preset capacity control specifications, business risk control standards, and online function operation and maintenance guidelines, and combined with the fault severity, tenant scale, functional impact scope, and fault frequency in the problem assessment data, a comprehensive judgment is made. According to the control rules, faults are divided into three risk levels: high-risk, medium-risk, and low-risk. High-risk involves widespread tenant function failure and core business interruption; medium-risk involves partial tenant function anomalies and minor business damage; and low-risk involves isolated and occasional anomalies with no impact on core business. The order of fault handling is determined according to the risk level, clarifying the standards for emergency handling, routine handling, and delayed handling, ultimately generating corresponding problem handling priorities.

[0054] Based on the established priorities, match corresponding temporary emergency response measures and long-term optimization and rectification methods from the operation and maintenance contingency plan library. Temporary measures focus on quickly stopping losses and restoring business, while long-term measures focus on eradicating faults and preventing recurrence. Considering the current online business operation status, tenant usage scenarios, and the actual situation of the large-scale configuration environment, adapt and modify the measures, removing operational content that does not conform to the on-site environment, and supplementing with implementation steps, parameter standards, and operating specifications that fit the actual business. Clarify the solution execution process, operation nodes, acceptance standards, and responsible parties, integrate the optimized emergency measures and long-term rectification methods, and streamline the complete execution logic to obtain a complete problem-solving solution that can be directly implemented and adapted to the business scenario.

[0055] As an example, such as Figure 3 As shown, operators log in to the scaling configuration platform, select the target runtime environment, and then carry out scaling scenario configuration. If it is a brand new scaling requirement, a new scaling scenario is created and a unique scenario identifier is bound. If it is an iteration of an existing function, the scaling strategy of the existing scenario is changed. When the scenario is taken offline for the entire time, the code is taken offline and the scenario configuration is removed. After all configurations are completed, the scaling data is saved in a unified manner. The platform pushes the scaling configuration data with the scenario identifier to the SaaS system to complete the distribution of the full scaling configuration information and simultaneously complete the acquisition of the new scaling scenario and the scenario identifier.

[0056] After a SaaS system user logs into the main application, the system reads the pushed volume expansion configuration and verifies whether a corresponding volume expansion scenario exists. If no matching scenario exists, the subsequent volume expansion logic is not executed. If a matching scenario exists, the volume expansion center SDK is called. After the SDK initializes a singleton volume expansion center, it initiates a configuration retrieval request. If the request is successful, it iterates through all volume expansion scenarios, calculates various volume expansion strategies based on tenant, blacklist / whitelist, and user dimensions, and persistently stores the volume expansion switch and resource configuration for each scenario. The scenario identifier is passed to the volume expansion center interface to generate a switch query command, reads the configuration platform data to obtain the volume expansion switch status value, writes functional judgment logic based on the status value to obtain basic code snippets, integrates the basic code snippets with the original functional code of the target page, and generates the volume expansion logic code corresponding to the new business function.

[0057] The system leverages the built-in Mock plugin of the SaaS system to perform pre-testing of the scaling logic code. It allows switching between scaling scenarios and enabling simulation to debug different scaling switches. If debugging fails, the simulation can be directly closed, the system refreshed, and the code readjusted. After all scaling logic code has passed testing, the compliant code is packaged into an online version. Operators then access the scaling configuration platform again, pass the tenant information to be configured, initiate a login request, and enter the scaling scenario configuration page based on the login result returned by the platform. They select the specified tenant to enable the new business function permission, generate permission configuration instructions, and save the configuration parameters to complete the scaling permission configuration for the specified tenant and define the scope of the new business function to be open to the outside world.

[0058] The SaaS system reads the scenario-based volume control switch and new / old page resource configurations stored in the SDK, executes the corresponding volume control processing logic, and filters and redirects the left-side menu resources and role / account resources based on the volume control rules. It distinguishes between new and old resources and matches different volume control allow / block rules. The A page, B page, and sub-functions within each tenant display the corresponding newly added business functions according to the effective volume control permissions. The system continuously collects real-time operation data of the target page and the newly added business functions throughout the entire process. The raw operation data is classified according to tenant identifier, operation time, and function node. After removing redundant data, a structured business operation log is generated.

[0059] Periodically parse the generated business operation logs, filter out abnormal records to obtain problem log entries; extract key fields such as tenant number, access sequence, and interface return code from the logs to construct a log feature dataset; compare the dataset with standard benchmark data item by item to identify data deviations; combine the function call chain and permission configuration rules to trace deviations and pinpoint faulty links; combine fault triggering conditions and underlying causes to output root cause information; generate problem assessment data based on fault type, affected tenants, and functional scope within the root cause information; combine with the volume control specifications to prioritize risk handling; match corresponding temporary emergency handling measures and long-term optimization plans; combine with the corrective measures based on on-site business conditions; output the final problem handling solution for implementation; and continuously output monitoring and log reporting data throughout the entire process.

[0060] This embodiment also provides a function scaling control device, which is used to implement the above embodiments and preferred embodiments, and will not be repeated as already described. As used below, the term "module" can be a combination of software and / or hardware that implements a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0061] This embodiment provides a control device for increasing the functionality of devices, such as... Figure 4 As shown, it includes: The acquisition module 401 is used to acquire the newly added volume increase scenario and the scenario identifier corresponding to the newly added volume increase scenario; Processing module 402 is used to obtain the volume release switch by using the scene identifier, and obtain the volume release logic code of the new business function of the target page corresponding to the new volume release scene; Module 403 is used to test the volume increase logic code. If the volume increase logic code passes the test, the tested volume increase logic code will be packaged into an online version. The management module 404 is used to configure the release permissions for specified tenants based on the online version, so as to limit the scope of opening new business functions, and continuously record the business operation logs after the release permissions take effect, so as to obtain the release operation data.

[0062] In this embodiment, the processing module 402 is used to input the scene identifier into the volume release center interface and generate a switch query instruction; execute the switch query instruction to read the configuration platform data and obtain the status value of the volume release switch; write functional judgment logic based on the status value to obtain a basic code fragment; and integrate the basic code fragment with the page function code of the target page to obtain the volume release logic code for the new business function.

[0063] In this embodiment, the control module 404 is used to obtain tenant information to be configured; send a corresponding login request to the volume configuration platform based on the tenant information to be configured; respond to the login result fed back by the volume configuration platform and display the volume scenario configuration page; determine the specified tenant and enable the function permission based on the volume scenario configuration page, generate permission configuration instructions, and execute the permission configuration instructions to complete parameter saving and obtain the effective volume permissions.

[0064] In this embodiment of the application, the control module 404 is used to collect the operation data of the target page and the newly added business function after the expansion permission takes effect; classify the operation data according to the tenant identifier, operation time and function node to obtain structured log data, and remove redundant data from the structured log data to generate business operation logs.

[0065] In this embodiment of the application, the control device for increasing the functionality further includes: a parsing module, used to parse the business operation logs and filter abnormal records to obtain problem-related log entries; analyze the problem-related log entries to locate the cause of the abnormality and obtain the root cause information of the problem; and generate a response processing scheme based on the root cause information of the problem.

[0066] In this embodiment, the parsing module is used to extract key fields from problem-related log entries to obtain a log feature dataset. The key fields include: tenant number, access sequence, and interface return code. The log feature dataset is compared item by item with the benchmark data to identify data deviation items. The data deviation items are traced using the function call chain and permission configuration rules to determine the fault occurrence link and obtain abnormal link information. Based on the abnormal link information, the fault triggering conditions and underlying causes are analyzed to obtain the root cause information of the problem.

[0067] In this embodiment, the parsing module is used to generate problem assessment data based on key content in the root cause information of the problem. The key content includes the fault type, affected tenants and functional scope; classify the risk level of the problem assessment using the volume control requirements to obtain the handling priority; query the corresponding temporary emergency measures and long-term optimization methods with reference to the handling priority; and modify the temporary emergency measures and long-term optimization methods according to the actual business situation to obtain the problem handling plan.

[0068] Please see Figure 5 , Figure 5 This is a schematic diagram of the structure of a computer device provided in an optional embodiment of the present invention, such as... Figure 5As shown, the computer device includes one or more processors 10, memory 20, and interfaces for connecting the components, including high-speed interfaces and low-speed interfaces. The components communicate with each other via different buses and can be mounted on a common motherboard or otherwise installed as needed. The processors can process instructions executed within the computer device, including instructions stored in or on memory to display graphical information of a GUI on external input / output devices (such as display devices coupled to the interfaces). In some alternative implementations, multiple processors and / or multiple buses can be used with multiple memories and multiple memory modules, if desired. Similarly, multiple computer devices can be connected, each providing some of the necessary operations (e.g., as a server array, a group of blade servers, or a multiprocessor system).

[0069] Processor 10 may be a central processing unit, a network processor, or a combination thereof. Processor 10 may further include a hardware chip. The hardware chip may be an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. The programmable logic device may be a complex programmable logic device (CAMP), a field-programmable gate array (FPGA), a general-purpose array logic (GDA), or any combination thereof.

[0070] The memory 20 stores instructions executable by at least one processor 10 to cause the at least one processor 10 to perform the method shown in the above embodiments.

[0071] The memory 20 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on the use of the computer device as shown by a landing page for an app. Furthermore, the memory 20 may include high-speed random access memory and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some alternative embodiments, the memory 20 may optionally include memory remotely located relative to the processor 10, which can be connected to the computer device via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0072] The memory 20 may include volatile memory, such as random access memory; the memory may also include non-volatile memory, such as flash memory, hard disk or solid-state drive; the memory 20 may also include a combination of the above types of memory.

[0073] The computer device also includes a communication interface 30 for communicating with other devices or communication networks.

[0074] This invention also provides a computer-readable storage medium. The methods described above according to embodiments of the invention can be implemented in hardware or firmware, or implemented as computer code that can be recorded on a storage medium, or implemented as computer code downloaded via a network and originally stored on a remote storage medium or a non-transitory machine-readable storage medium and then stored on a local storage medium. Thus, the methods described herein can be processed by software stored on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. The storage medium can be a magnetic disk, optical disk, read-only memory, random access memory, flash memory, hard disk, or solid-state drive, etc.; further, the storage medium can also include combinations of the above types of memory. It is understood that computers, processors, microprocessor controllers, or programmable hardware include storage components capable of storing or receiving software or computer code, which, when accessed and executed by the computer, processor, or hardware, implements the methods shown in the above embodiments.

[0075] Although embodiments of the invention have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of the invention, and such modifications and variations all fall within the scope defined by the appended claims.

Claims

1. A method for controlling the release of functionalities, characterized in that, The method includes: Obtain the newly added volume increase scenarios and the scenario identifiers corresponding to the newly added volume increase scenarios; The scenario identifier is used to obtain the volume release switch, and the volume release logic code for the new business function of the target page corresponding to the new volume release scenario is generated through the volume release switch; Test the volume increase logic code. If the volume increase logic code passes the test, the tested volume increase logic code will be packaged into an online version. Configure the specified tenants with the increased capacity permissions based on the online version to limit the scope of the newly added business functions, and continuously record the business operation logs after the increased capacity permissions take effect.

2. The method according to claim 1, characterized in that, The step of obtaining the volume increase switch using the scene identifier and generating the volume increase logic code for the new business function of the target page corresponding to the new volume increase scene through the volume increase switch includes: The scene identifier is passed to the volume control center interface to generate a switch query command; Execute the switch query command to read the configuration platform data and obtain the status value of the output switch; Based on the stated state values, functional judgment logic is written to obtain basic code snippets; By integrating the basic code snippet with the page function code of the target page, the scaling logic code for the new business function is obtained.

3. The method according to claim 1, characterized in that, The configuration of the specified tenant's allowance based on the online version includes: Get the tenant information to be configured; Based on the tenant information to be configured, a corresponding login request is sent to the volume configuration platform; In response to the login result returned by the volume scaling configuration platform, the volume scaling scenario configuration page is displayed; Based on the aforementioned volume expansion scenario configuration page, the specified tenant is identified and functional permissions are enabled. Permission configuration instructions are generated and executed to complete parameter saving, thereby obtaining effective volume expansion permissions.

4. The method according to claim 1, characterized in that, The continuous recording of business operation logs after the volume expansion permission takes effect includes: After the increased volume authorization takes effect, collect the operational data of the target page and the newly added business function; The operational data is categorized according to tenant identifier, operation time, and functional node to obtain structured log data. Redundant data is then removed from the structured log data to generate business operation logs.

5. The method according to claim 1, characterized in that, The method further includes: The business operation logs are parsed and abnormal records are filtered to obtain log entries related to the problem. Analyze the relevant log entries to pinpoint the cause of the anomaly and obtain the root cause information of the problem; A processing scheme for generating a response based on the root cause information of the problem.

6. The method according to claim 5, characterized in that, The analysis of relevant log entries identifies the cause of the anomaly and obtains root cause information, including: Extract key fields from the log entries related to the problem to obtain a log feature dataset. The key fields include: tenant number, access sequence, and interface return code. The log feature dataset is compared item by item with the benchmark data to identify data deviation items; By using the function call chain and permission configuration rules to trace data deviations, the fault occurrence point can be determined and information about the abnormal point can be obtained. Based on the information about the abnormal process, the fault triggering conditions and underlying causes are analyzed to obtain the root cause information of the problem.

7. The method according to claim 5, characterized in that, The processing scheme for generating a response based on the root cause information of the problem includes: Based on the key information in the root cause of the problem, problem assessment data is generated, wherein the key information includes the fault type, affected tenants, and functional scope. The risk levels of the aforementioned issues are assessed and classified using volume control requirements to determine the priority of handling. Refer to the aforementioned handling priorities to query the corresponding temporary emergency measures and long-term optimization methods; Based on the actual business situation, the temporary emergency measures and long-term optimization methods are modified to obtain a problem-solving solution.

8. A control device for increasing the functionality of devices, characterized in that, The device includes: The acquisition module is used to acquire newly added volume increase scenarios and the scenario identifiers corresponding to the newly added volume increase scenarios; The processing module is used to obtain the volume increase switch using the scene identifier and to obtain the volume increase logic code for the new business function of the target page corresponding to the new volume increase scene; The generation module is used to test the volume expansion logic code. If the volume expansion logic code passes the test, the tested volume expansion logic code is packaged into an online version. The management module is used to configure the release permissions for specified tenants based on the online version, so as to limit the scope of the newly added business functions, and continuously record the business operation logs after the release permissions take effect to obtain release operation data.

9. A computer device, characterized in that, include: A memory and a processor, the memory and the processor being communicatively connected to each other, the memory storing computer instructions, the processor executing the computer instructions to perform the method of any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions for causing the computer to perform the method of any one of claims 1 to 7.

Images