SLA index standardization method and system
Through the SLA index standardization method and system, the problem of lack of data support in APP testing is solved, the standardized processing and output of data is realized, and the data analysis efficiency and product quality are improved.
Patent Information
- Application Number
- CN202510555811.6
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-04-29
- Publication Date
- 2025-08-15
AI Technical Summary
The lack of clear data support in the prior art makes it difficult to confirm whether the APP test quality meets the standards, affecting product quality, especially in performance testing and failure statistical analysis.
The SLA index standardization method and system are adopted, including the comprehensive performance index module, the fault statistics analysis module and the SLA index overview module. By obtaining the index data and fault statistics content from the client and server, standardizing processing and output, providing the current cycle, the previous cycle data and month-on-month growth.
It improves the comparability and consistency of data, simplifies the complexity of data analysis, improves data analysis efficiency, and can quickly identify trend changes and abnormalities, ensuring product quality meets standards.
Smart Images

Figure CN120492332A_ABST
Abstract
Description
Technical Field
[0001] The present disclosure relates to the field of software testing technology, and in particular to a method and system for standardizing SLA indicators. Background Art
[0002] In modern software development, testing and fault management are key steps in ensuring application quality and stability. As apps become increasingly complex, testing teams need effective tools and methods to ensure product quality.
[0003] However, related technologies often lack clear data support during the testing process to demonstrate the final test results, making it impossible to confirm whether the app's test quality meets the standards, resulting in difficulty in ensuring the app's product quality. Therefore, how to provide clear data support during the testing process to demonstrate the final test results to confirm whether the app's test quality meets the standards and thus improve the app's product quality has become an urgent problem that needs to be solved. Summary of the Invention
[0004] In view of this, the present disclosure provides an SLA indicator standardization method and system to solve the problem of how to provide clear data support to display the final test results during the testing process to confirm whether the APP test quality meets the standards, thereby improving the product quality of the APP.
[0005] On the one hand, the present disclosure provides an SLA indicator standardization method, which is applied to an SLA indicator standardization system. The system includes: an SLA indicator overview module, a comprehensive performance indicator module, and a fault statistics analysis module. The method includes: the comprehensive performance indicator module obtains client indicator data and server indicator data of each APP in multiple APPs according to a first preset type; the fault statistics analysis module obtains fault statistics and fault analysis results of each APP under multiple dimensions according to a second preset type; the SLA indicator overview module screens and performs preset calculations on the client indicator data, server indicator data, fault statistics, and fault analysis results according to at least one preset SLA core indicator to determine a standardized output result for each SLA core indicator; wherein the standardized output result includes at least one of the following: current cycle data, previous cycle data, month-on-month growth rate, and growth data in the same period as the previous cycle.
[0006] On the other hand, the present disclosure further provides an SLA indicator standardization system, which includes: an SLA indicator overview module, a comprehensive performance indicator module and a fault statistics analysis module, wherein: the comprehensive performance indicator module is used to obtain client indicator data and server indicator data of each APP in multiple APPs according to a first preset type; the fault statistics analysis module is used to obtain fault statistics and fault analysis results of each APP under multiple dimensions according to a second preset type; the SLA indicator overview module is used to screen and preset calculations on client indicator data, server indicator data, fault statistics and fault analysis results according to at least one preset SLA core indicator, and determine the standardized output result of each SLA core indicator; wherein the standardized output result includes at least one of the following: current cycle data, previous cycle data, month-on-month growth rate and growth data in the same period as the previous cycle.
[0007] On the other hand, the present disclosure further provides a computer device, including: a memory and a processor, the memory and the processor are communicatively connected to each other, the memory stores computer instructions, and the processor executes the above-mentioned SLA indicator standardization method by executing the computer instructions.
[0008] On the other hand, the present disclosure further provides a computer-readable storage medium having computer instructions stored thereon, the computer instructions being used to enable a computer to implement the above-mentioned SLA indicator standardization method.
[0009] Another aspect of the present disclosure further provides a computer program product, including computer instructions, which are used to enable a computer to execute the above-mentioned SLA indicator standardization method.
[0010] The SLA indicator standardization method and system of the above-mentioned embodiments of the present disclosure centrally manages the indicator data, fault statistics, and analysis results of both the client and server, ensuring that data of different types and sources can be processed and displayed under the same standards. Through standardized output, all indicators can be accurately quantified, reducing data deviations caused by different data collection standards and methods, thereby improving the comparability and consistency of data during the APP testing process. Based on the clear data, it can be determined whether the APP test quality meets the standards, thereby improving the product quality of the APP.
[0011] Furthermore, the Service Level Agreement (SLA) indicator overview module simplifies data analysis by filtering and calculating various data across multiple dimensions. Furthermore, by automatically calculating and displaying data for the current period, previous period, month-over-month growth, and year-over-year growth, users can quickly identify trend changes, abnormal fluctuations, and increases or decreases in various indicators, significantly improving data analysis efficiency and reducing the workload of manual analysis. BRIEF DESCRIPTION OF THE DRAWINGS
[0012] In order to more clearly illustrate the specific embodiments of the present disclosure or the technical solutions in the related technologies, the following briefly introduces the drawings required for use in the specific embodiments or related technical descriptions. Obviously, the drawings described below are some embodiments of the present disclosure. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.
[0013] Figure 1a An exemplary schematic diagram showing the architecture of an SLA indicator standardization system applied to an SLA indicator standardization method according to an embodiment of the present disclosure is shown.
[0014] Figure 1b This is a flow chart of a SLA indicator standardization method provided by an embodiment of the present disclosure.
[0015] Figure 2 An exemplary schematic diagram showing the architecture of an SLA indicator standardization system applied to another SLA indicator standardization method according to an embodiment of the present disclosure is shown.
[0016] Figure 3 An exemplary schematic diagram showing the architecture of an SLA indicator standardization system applied to yet another SLA indicator standardization method according to an embodiment of the present disclosure is shown.
[0017] Figure 4 A structural diagram of an SLA indicator standardization system provided by an embodiment of the present disclosure is shown.
[0018] Figure 5 A structural diagram of another SLA indicator standardization system provided by an embodiment of the present disclosure is shown. DETAILED DESCRIPTION
[0019] In modern software development, testing is an essential step in ensuring product quality and stability. With the widespread adoption of mobile internet applications and cloud computing services, the complexity of both clients and servers continues to increase. Traditional testing methods and tools are no longer sufficient to efficiently and accurately assess product quality. Consequently, more and more companies are relying on automated testing, performance testing, and real-time monitoring to track and optimize the operational quality of applications. SLA metrics are widely used to measure system responsiveness, availability, and stability. By using SLA metrics as key performance indicators, teams can gain a comprehensive understanding of product performance in real-world use, helping developers and testers identify potential performance bottlenecks and optimize code and architecture in a timely manner, thereby improving user experience and application stability.
[0020] Then, in response to the above situation, the relevant technologies often have the following problems in the solution process:
[0021] 1. In related technologies, client and server testing tasks usually lack specific data support, especially in performance testing. The test results cannot be clearly displayed, making it difficult for the testing team and the development team to confirm whether the product has passed the quality standards. They are also unable to effectively evaluate whether the application can run stably after it is launched, thus affecting the product testing results and making it difficult to ensure the product quality of the APP.
[0022] 2. For online applications currently in operation, related technologies also lack systematic fault statistics and analysis methods, resulting in the team being unable to accurately judge changes in product faults during continuous updates and upgrades. There is a lack of data to prove whether the continuous optimization of the application has produced actual results, further affecting the product quality of online apps.
[0023] To solve the above problems, a SLA indicator standardization method is provided in various embodiments of the present disclosure, which is applied to an SLA indicator standardization system. The system includes: an SLA indicator overview module, a comprehensive performance indicator module and a fault statistics analysis module. The method includes: a comprehensive performance indicator module, which obtains client indicator data and server indicator data of each APP in multiple APPs according to a first preset type; a fault statistics analysis module, which obtains fault statistics content and fault analysis results of each APP under multiple dimensions according to a second preset type; an SLA indicator overview module, which screens and presets calculations on client indicator data, server indicator data, fault statistics content and fault analysis results according to at least one preset SLA core indicator, and determines the standardized output result of each SLA core indicator; wherein the standardized output result includes at least one of the following: current cycle data, previous cycle data, month-on-month growth rate and growth data in the same period as the previous cycle.
[0024] To make the purpose, technical solutions, and advantages of the embodiments of the present disclosure more clear, the technical solutions in the embodiments of the present disclosure will be clearly and completely described below in conjunction with the drawings in the embodiments of the present disclosure. Obviously, the described embodiments are part of the embodiments of the present disclosure, not all of the embodiments. Based on the embodiments of the present disclosure, all other embodiments obtained by those skilled in the art without making creative efforts shall fall within the scope of protection of the present disclosure.
[0025] Please refer to Figure 1a , Figure 1a FIG2 is an exemplary schematic diagram showing the architecture of an SLA indicator standardization system applied to an SLA indicator standardization method according to an embodiment of the present disclosure. Figure 1a As shown in FIG, the SLA indicator standardization system includes: a comprehensive performance indicator module, a fault statistics analysis module and an SLA indicator overview module.
[0026] In this embodiment, the SLA indicator standardization system can be used as a software system or platform for uniformly collecting, calculating, and outputting standardized data for multiple preset SLA core indicators.
[0027] Among them, the comprehensive performance indicator module in the SLA indicator standardization system can be used to collect and organize APP performance data; the fault statistics analysis module can be used to collect and analyze fault-related data during APP operation; the SLA indicator overview module can be used to filter, process and uniformly output each collected data to form standardized core SLA indicators and provide multi-period comparison.
[0028] Further references Figure 1b , Figure 1b The following is a flow chart of a method for standardizing SLA indicators provided by an embodiment of the present disclosure. The method may include the following steps:
[0029] Step S101: A comprehensive performance indicator module obtains client indicator data and server indicator data of each of a plurality of APPs according to a first preset type.
[0030] In this embodiment, the first preset type may refer to a preset classification basis followed when collecting client indicator data and server indicator data.
[0031] The app client refers to the app itself running on the user's device. App client metrics can be divided into two types: Android app client metrics and iOS app client metrics.
[0032] An app's server side refers to the backend server system that supports the app's normal operation. This can include at least one of the following: a server, gateway, database, or microservice system. Server-side metrics data can refer to monitoring data about the server, backend application interfaces, and their operational status.
[0033] For example, client-side indicator data may include but is not limited to: APP crash rate, APP success rate, startup time, etc.; server-side indicator data may include but is not limited to: interface request success rate, daily throughput, etc.
[0034] Step S102: The fault statistics analysis module obtains the fault statistics content and fault analysis results of each APP in multiple dimensions according to the second preset type.
[0035] In this embodiment, the second preset type may refer to a preset classification basis followed when obtaining the fault statistics content and fault analysis results of each APP.
[0036] Fault statistics can refer to directly recorded quantitative data about faults. For example, these data may include, but are not limited to, the total number of faults and the total duration of faults. Fault analysis results, on the other hand, refer to information that has been further attributed and organized based on fault statistics. For example, these results may include, but are not limited to, the percentage of fault causes and the duration of fault recovery.
[0037] In step S103, the SLA indicator overview module screens and performs preset calculations on the client indicator data, server indicator data, fault statistics and fault analysis results according to at least one preset SLA core indicator, and determines the standardized output result of each SLA core indicator.
[0038] In this embodiment, SLA core indicators refer to a set of specific, quantifiable core indicators used to measure whether the actual operating performance of a product, system or service within a certain period of time meets the agreed service level standards. The purpose of setting SLA indicators can be to help developers, testers, operators, product managers and other parties to uniformly control the quality goals of the APP during the APP development and testing process, and to identify and intervene in anomalies in a timely manner.
[0039] For example, SLA core indicators may include but are not limited to: "APP crash rate <0.1%", "APP startup time <2 seconds", "total failure time in a single month <1 hour", etc.
[0040] The standardized output results include at least one of the following: current cycle data, previous cycle data, month-on-month growth rate and growth data of the same previous cycle.
[0041] Among them, the current cycle refers to the ongoing time period, such as the current day, current week, current month, etc.; the previous cycle refers to the previous time period adjacent to the current cycle, such as yesterday, last week, last month, etc.; the month-on-month growth rate refers to comparing the data of the current cycle with the data of the previous cycle to calculate the percentage of growth or decrease; the growth data same as the previous cycle refers to comparing the current cycle with the previous identical current cycle (such as this day last year, the current month last year, etc.).
[0042] Furthermore, the SLA indicator overview module filters and presets calculations on client indicator data, server indicator data, fault statistics and fault analysis results, and outputs standardized current cycle data, previous cycle data, month-on-month growth rate and growth data for the same period as the previous cycle for each SLA core indicator.
[0043] In the service flow segmentation and landing selection method and system based on multi-orbit satellites of the above-mentioned embodiment of the present disclosure, the indicator data, fault statistics and analysis results of the client and server are centrally managed to ensure that data of different types and sources can be processed and displayed under the same standard. Through standardized output, all indicators can be accurately quantified, reducing the data deviation caused by different data collection standards and methods, thereby improving the comparability and consistency of data in the APP testing process. According to clear data, it can be determined whether the APP test quality meets the standards, thereby improving the product quality of the APP. Through the service level agreement (Service Level Agreement, SLA) indicator overview module, various types of data under multiple dimensions are screened and calculated, simplifying the complexity of data analysis. In addition, by automatically calculating and displaying the current cycle data, the previous cycle data, the month-on-month increase and the growth data of the previous cycle, users can quickly identify trend changes, abnormal fluctuations and the improvement or decline of various indicators, greatly improving the efficiency of data analysis and reducing the workload of manual analysis. By outputting standardized SLA indicators, current product problems can be intuitively reflected, making it easier for developers to respond to product problems in a timely manner, reducing the impact on the business, helping to reduce subsequent costs and losses caused by software quality issues, and enhancing the trust and satisfaction of the demanders in the service.
[0044] In a possible implementation of the above step S101, please refer to Figure 2 , Figure 2 An exemplary schematic diagram showing the architecture of an SLA indicator standardization system applied to another SLA indicator standardization method according to an embodiment of the present disclosure is shown as follows: Figure 2 As shown, the comprehensive performance indicator module includes: a client indicator unit and a server indicator unit.
[0045] In the above step S101, the comprehensive performance index module obtains the client index data and the server index data of each of the multiple apps according to the first preset type, including the following steps:
[0046] Step a1, the comprehensive performance indicator module dynamically obtains the real-time data of the APP through the integrated third-party platform and determines the project status of the APP based on the real-time data.
[0047] Among them, the SLA indicator standardization system is connected with multiple third-party data source platforms.
[0048] The comprehensive performance indicator module regularly and dynamically obtains real-time data of each APP from multiple third-party data source platforms based on preset time intervals.
[0049] Illustratively, the third-party data source platform may include, but is not limited to: Jira, Grafana; wherein Jira may be a tool for project management, issue tracking, and task management, and Grafana may be an open source data visualization tool, typically used to monitor and analyze information from various data sources.
[0050] Furthermore, the project status of an app can include "under testing" and "released." Under testing means the app has not yet been officially put into production and is currently in the testing phase. Released means the app has completed development and testing and has been officially released to the production environment for user use.
[0051] Step a2, the client indicator unit, if the project status of the APP is online, determines the client indicator data of the APP according to the type and / or time period of the APP, and displays the client indicator data in the form of a chart.
[0052] The app type refers to the operating system version corresponding to the app, and can include Android and iOS. The time period can include, but is not limited to, daily, weekly, and monthly. For example, you can determine client indicator data for the current day, the past week, or the past month.
[0053] Furthermore, the client indicator data includes at least one of the following: APP crash rate, APP success rate, TP95, startup time, APP startup times, APP slow request number, and APP access trend page views (Page View, PV).
[0054] Among them, the APP crash rate represents the ratio of the number of times the APP crashes each time to the total number of times it is used; the APP success rate represents the ratio of the number of times the APP does not crash to the total number of times it is used; TP95 represents the 95% percentile of the response time, which is used to measure that 95% of the request response time is lower than this value, helping to identify the range of slow requests; the startup time represents the time from the startup of the APP to the complete loading and user interaction; the number of APP startups represents the total number of times the APP is started within a specific time period; the number of APP slow requests represents the number of requests in the APP whose response time exceeds the preset time threshold; the APP access trend PV represents the number of visits to the APP page within a specific time period.
[0055] Here, the preset time threshold can be set according to actual needs, for example, it can be 1 second.
[0056] Furthermore, chart types may include but are not limited to: line charts, bar charts, pie charts, etc.
[0057] Step a3, the server-side indicator unit, if the project status of the APP is online, determines the server-side indicator data of the APP according to the time period and / or department to which the APP belongs, and displays the server-side indicator data in the form of a chart.
[0058] The department to which an app belongs can refer to the internal organizational unit related to the development, testing, maintenance, or operation of the app. For example, departments may include, but are not limited to, development departments, testing departments, and operations departments. Each department may include at least one team or group. For example, a development department may include, but is not limited to, a front-end development team and a back-end development team.
[0059] Furthermore, the server-side indicator unit may set the time period and / or department to which the APP belongs as a screening condition, and obtain the server-side indicator data of the APP that meets the above screening conditions from the third-party platform.
[0060] Among them, the server-side indicator data includes at least one of the following: core interface request success rate, core interface TP95, overall request success rate, overall interface TP95, overall slow request rate, and daily throughput.
[0061] Here, the core interface request success rate represents the proportion of successful responses among the core interface requests; the core interface TP95 represents the response time of requests with a response time less than or equal to TP95 among all requests; the overall request success rate represents the success rate of all interface requests; and the daily throughput represents the total number of requests processed each day.
[0062] In the service flow segmentation and landing selection method and system based on multi-orbit satellites of the above-mentioned embodiment of the present disclosure, through integration with multiple third-party platforms, real-time data of each APP can be obtained regularly and dynamically from multiple data source platforms. This dynamic acquisition method can ensure the timeliness and accuracy of the data, eliminate the delays or errors of manual updates, and enable the system to reflect the operating status and performance of the application in real time. The subdivision of client and server indicator data enables the system to conduct detailed analysis of different application performances, and the system can generate different types of charts based on these detailed data, making each indicator more intuitive and easy to understand. The system supports querying server indicator data according to the department to which it belongs, which can facilitate leaders to make corresponding work arrangements.
[0063] In a possible implementation of step S101 above, the method further includes:
[0064] Comprehensive performance indicator module, if the APP project status is testing, obtain the APP's test-related data.
[0065] In this embodiment, if the project status of the APP is under testing, the comprehensive performance indicator module dynamically pulls the test-related data of the APP through the integrated third-party platform, and can determine the work progress of the tester, the bug follow-up efficiency and development quality data of the R&D party.
[0066] For example, test-related data may include at least one of the following: number of test cases, test case coverage, test case execution rate, bug efficiency, number of unexecuted test cases, number of successful / failed / blocked test case executions, number of P0-level cases, total number of bugs, ratio of total number of bugs to number of test cases, defect repair rate, number of unfixed bugs, ratio of P1 and P2 bugs, and number of P1 or P2 bugs resolved in more than 1 day.
[0067] Among them, the number of test cases refers to the total number of test cases designed and entered into the system under the current project; test case coverage refers to the proportion of requirements or function points covered by test cases to all requirements or function points; test case execution rate refers to the proportion of test cases that have been actually executed to the total number of test cases; bug efficiency refers to the proportion of submitted bugs that are confirmed to be valid problems; the number of unexecuted test cases refers to the number of test cases that have not yet started execution; the number of successful / failed / blocked test case executions refers to the number of test cases that passed the test / the number of test cases that failed to execute the test / the number of test cases that cannot be executed temporarily; the number of P0 level use cases refers to the number of critical use cases with the highest priority (P0); the total number of bugs refers to the number of all defects found and recorded during the current test process; the ratio of total number of bugs to number of test cases refers to the average number of bugs found in each test case; the defect repair rate refers to the proportion of defects that have been developed and repaired to the total number of defects; the number of unfixed bugs refers to the number of defects that are still in an open state; the P1 and P2 bug ratio refers to the proportion of medium and high priority (P1, P2) defects to the total number of defects; P1 or P2 that are resolved for more than 1 day The number of bugs refers to the number of high-priority bugs that took more than one day to be fixed from defect submission.
[0068] Exemplarily, the priority of the fault may be from P0 to P5, where P0 has the highest priority and P5 has the lowest priority.
[0069] In the multi-orbit satellite-based service flow segmentation and landing selection method and system of the above-mentioned embodiment of the present disclosure, by collecting indicators such as bug efficiency, defect repair rate, and number of unfixed bugs, the R&D team's defect processing speed and repair quality are measured, which facilitates management personnel to follow up on the progress of APP testing.
[0070] In a possible implementation of the above step S102, please refer to Figure 3 , Figure 3 An exemplary schematic diagram showing the architecture of an SLA indicator standardization system applied to another SLA indicator standardization method according to an embodiment of the present disclosure is shown as follows: Figure 3 As shown, the fault statistics analysis module includes a fault statistics unit and a fault analysis unit.
[0071] In step S102 above, the fault statistics analysis module obtains the fault statistics and fault analysis results of each APP in multiple dimensions according to the second preset type, including the following steps:
[0072] Step b1, the fault statistics unit determines multiple dimensions according to the second preset type, obtains the APP online fault index data of each APP in the multiple dimensions, sorts the APP online fault index data of each APP according to the fault type and fault level in the second preset type, and determines the fault statistics content of each APP.
[0073] The second preset type includes at least one of the following: time period, department, business, fault type, and fault level.
[0074] Here, the fault statistics of each APP may include: an overview of the number of faults in each dimension, the number and proportion of each fault type, the number and proportion of each fault level, fault change trends, etc.
[0075] Furthermore, the fault statistics of each APP may be displayed in a chart format.
[0076] Here, through the fault statistics of the APP, the overall fault situation and defect type and level distribution of different businesses in each center can be clearly seen, which can be used as a basis for evaluating product delivery quality and also provide direction for quality improvement.
[0077] Step b2: The fault analysis unit analyzes the fault statistics of each APP according to multiple preset analysis methods to determine the fault analysis results of each APP.
[0078] Among them, the preset analysis methods may include but are not limited to: trend analysis, proportion analysis, high-frequency fault identification, impact range assessment, etc.
[0079] Furthermore, the fault analysis results of the APP may include but are not limited to: fault concentration areas, fault trends, causes of faults, etc.
[0080] In the multi-orbit satellite-based service flow segmentation and landing selection method and system described in the above-mentioned embodiments of the present disclosure, the fault statistics unit accurately collects online fault data for each app based on multiple dimensions, such as time period, department, business, fault type, and fault level, ensuring comprehensive coverage and clear stratification. The statistical results can intuitively reflect the overall fault status and quality level of each center and business line, providing reliable data support for product delivery quality assessment, thereby improving the accuracy of SLA standardization output.
[0081] In a possible implementation of step S102, the fault analysis unit analyzes the fault statistics of each app according to multiple preset analysis methods to determine a fault analysis result for each app, including at least one of the following:
[0082] The fault analysis unit determines the total fault duration, total fault count, and total fault recovery time of all APPs in any department within any time period as the fault analysis result;
[0083] The fault analysis unit determines the specific fault duration, specific fault number, and specific fault recovery time of any APP under any department within any time period as the fault analysis result;
[0084] Fault analysis unit, which determines the overall fault cause classification of any department within any time period;
[0085] The fault analysis unit determines the total fault duration, total fault number, and total fault recovery time of all departments within any time period as the fault analysis result;
[0086] The fault analysis unit determines the ranking and comparative analysis of the fault duration and fault number of all APPs of any department within any time period as the fault analysis result.
[0087] In this embodiment, the overall fault duration, overall number of faults, and overall fault recovery time of all APPs of any department within any time period are determined as the fault analysis result. This can mean selecting a department and determining how many faults all APPs of the target department have had within the target time period, how long they have been down in total, and how long it takes on average to recover.
[0088] Here, the overall stability level of the sector can be assessed.
[0089] Determine the specific fault duration, number of faults, and recovery time of any APP under any department within any time period as the fault analysis result. This can mean selecting a department, then selecting an APP in the target department, and then looking at the fault situation of the target APP alone.
[0090] Here, you can evaluate the health of the target APP.
[0091] Determining the overall failure cause classification of any department within any time period may refer to classifying and statistically analyzing the causes of all failures in the target department.
[0092] Here, you can find out the main fault cause categories for later optimization.
[0093] Determining the overall failure duration, overall failure count, and overall failure recovery time of all departments within any time period as a failure analysis result may mean ranking all departments and determining the department with the longest failure duration or the most failure count.
[0094] Here, through horizontal comparison, we can identify the risk departments that are most likely to cause APP failures.
[0095] Determine the ranking and comparative analysis of the fault duration and fault frequency of all apps in any department within any time period as the fault analysis result. This can mean selecting a target department, sorting the fault duration and fault frequency of all apps within the target department, and determining the apps with the most problems and the most stable apps.
[0096] Here, risky apps can be identified through internal management.
[0097] The multi-orbit satellite-based service flow segmentation and landing selection method and system of the above-mentioned embodiments of the present disclosure establishes a systematic, quantifiable, and traceable fault analysis method by covering various analysis granularities and perspectives, including the department as a whole, a single app, the main cause of faults, cross-departmental comparisons, and internal departmental rankings. This improves the comprehensiveness and scientific nature of fault management. The fault analysis results directly reflect the weak links in the quality of app operations, helping to establish a closed-loop governance system among management and technical teams at all levels, continuously promoting a reduction in fault rates and an improvement in system stability.
[0098] In one embodiment, a SLA indicator standardization system 400 is provided, which corresponds one-to-one to the SLA indicator standardization method in the above embodiment. Figure 4 As shown, the system includes a comprehensive performance indicator module 401, a fault statistics analysis module 402 and an SLA indicator overview module 403, wherein each functional module is described in detail as follows:
[0099] Comprehensive performance indicator module 401, used to obtain client indicator data and server indicator data of each APP in a plurality of APPs according to a first preset type;
[0100] The fault statistics analysis module 402 is configured to obtain fault statistics and fault analysis results for each APP in multiple dimensions according to a second preset type;
[0101] The SLA indicator overview module 403 is used to screen and preset calculations on client indicator data, server indicator data, fault statistics and fault analysis results based on at least one preset SLA core indicator, and determine the standardized output results of each SLA core indicator; wherein the standardized output results include at least one of the following: current cycle data, previous cycle data, month-on-month growth rate and growth data in the same period as the previous cycle.
[0102] In one embodiment, the comprehensive performance indicator module 401 includes: a client indicator unit 4011 and a server indicator unit 4012, wherein:
[0103] Comprehensive performance indicator module 401 is used to dynamically obtain real-time data of the APP through an integrated third-party platform and determine the project status of the APP based on the real-time data;
[0104] The client indicator unit 4011 is used to determine the client indicator data of the APP based on the APP type and / or time period if the project status of the APP is online, and display the client indicator data in the form of a chart. The client indicator data includes at least one of the following: APP crash rate, APP success rate, TP95, startup time, number of APP startups, number of APP slow requests, and APP access trend PV;
[0105] The server-side indicator unit 4012 is used to determine the server-side indicator data of the APP based on the time period and / or department to which the APP belongs if the project status of the APP is online, and to display the server-side indicator data in the form of a chart; wherein the server-side indicator data includes at least one of the following: core interface request success rate, core interface TP95, overall request success rate, overall interface TP95, overall slow request rate, and daily throughput.
[0106] In one embodiment, the comprehensive performance indicator module 401 is also used to obtain test-related data of the APP if the project status of the APP is under testing; wherein the test-related data includes at least one of the following: the number of test cases, test case coverage, test case execution rate, bug efficiency, number of unexecuted test cases, number of successful / failed / blocked test case executions, number of P0-level test cases, total number of bugs, ratio of total number of bugs to number of test cases, defect repair rate, number of unfixed bugs, ratio of P1 and P2 bugs, and number of P1 or P2 bugs resolved in more than 1 day.
[0107] In one embodiment, the fault statistics analysis module 402 includes a fault statistics unit 4021 and a fault analysis unit 4022, wherein:
[0108] The fault statistics unit 4021 is configured to determine multiple dimensions based on a second preset type, obtain online fault indicator data for each app in the multiple dimensions, sort the online fault indicator data for each app based on the fault type and fault level in the second preset type, and determine the fault statistics for each app; wherein the second preset type includes at least one of the following: time period, department, business, fault type, and fault level;
[0109] The fault analysis unit 4022 is used to analyze the fault statistics of each APP according to multiple preset analysis methods to determine the fault analysis results of each APP.
[0110] In one embodiment, the fault analysis unit 4022 is configured to perform at least one of the following:
[0111] Determine the total fault duration, total number of faults, and total fault recovery time of all apps in any department within any time period as the fault analysis results;
[0112] Determine the specific fault duration, number of faults, and recovery time of any APP under any department within any time period as the fault analysis result;
[0113] Determine the overall failure cause classification for any department within any time period;
[0114] Determine the total fault duration, total number of faults, and total fault recovery time of all departments within any time period as the fault analysis results;
[0115] Determine the ranking and comparative analysis of the fault duration and fault number of all APPs in any department within any time period as the fault analysis result.
[0116] It should be noted that: the SLA indicator standardization system provided in the above embodiment only uses the division of the above program modules as an example to illustrate when implementing the corresponding SLA indicator standardization method. In actual applications, the above processing can be assigned to different program modules as needed, that is, the internal structure of the above system can be divided into different program modules to complete all or part of the above-described processing. In addition, the system provided in the above embodiment and the corresponding Figure 1b The embodiments of the method shown belong to the same concept, and their specific implementation processes are detailed in the method embodiments, which will not be repeated here.
[0117] The present disclosure also provides a computer device having the above Figure 4 The SLA indicator standardization system shown.
[0118] See also Figure 5 , Figure 5 FIG. 4 shows a structural diagram of another SLA indicator standardization system provided by an embodiment of the present disclosure, such as Figure 5As shown, the computer device includes: one or more processors 10, memory 20, and interfaces for connecting various components, including high-speed interfaces and low-speed interfaces. Various components utilize different buses to communicate with each other and can be installed on a common mainboard or installed in other ways as needed. The processor can process the instructions executed in the computer device, including instructions stored in or on the memory to display the graphical information of a GUI on an external input / output device (such as, a display device coupled to an interface). In some optional embodiments, if necessary, multiple processors and / or multiple buses can be used together with multiple memories and multiple memories. Equally, multiple computer devices can be connected, and each device provides part of the necessary operations (for example, as a server array, a group of blade servers, or a multi-processor system). Figure 5 A processor 10 is taken as an example.
[0119] The processor 10 may be a central processing unit, a network processor, or a combination thereof. The processor 10 may further include a hardware chip. The hardware chip may be an application-specific integrated circuit, a programmable logic device, or a combination thereof. The programmable logic device may be a complex programmable logic device, a field programmable gate array, a general purpose array logic, or any combination thereof.
[0120] The memory 20 stores instructions that can be executed by at least one processor 10, so as to enable at least one processor 10 to execute the method shown in the above embodiment.
[0121] The memory 20 may include a program storage area and a data storage area, wherein the program storage area may store an operating system and application programs required for at least one function; the data storage area may store data created based on the use of the computer device, etc. In addition, the memory 20 may include a high-speed random access memory, and may also include a non-transient memory, such as at least one disk storage device, a flash memory device, or other non-transient solid-state storage device. In some optional embodiments, the memory 20 may optionally include a memory remotely located relative to the processor 10, and these remote memories may be connected to the computer device via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.
[0122] The memory 20 may include a volatile memory, such as a random access memory; the memory may also include a non-volatile memory, such as a flash memory, a hard disk or a solid-state drive; the memory 20 may also include a combination of the above types of memory.
[0123] The computer device further includes an input device 30 and an output device 40. The processor 10, the memory 20, the input device 30 and the output device 40 may be connected via a bus or other means. Figure 5 The bus connection is taken as an example.
[0124] The input device 30 can receive input digital or character information and generate key signal input related to user settings and function control of the computer device, such as a touch screen, a keypad, a mouse, a trackpad, a touch pad, an indicator stick, one or more mouse buttons, a trackball, a joystick, etc. The output device 40 can include a display device, an auxiliary lighting device (e.g., an LED), and a tactile feedback device (e.g., a vibration motor). The above-mentioned display device includes but is not limited to a liquid crystal display, a light emitting diode, a display, and a plasma display. In some optional embodiments, the display device can be a touch screen.
[0125] The computer device further includes a communication interface for the computer device to communicate with other devices or a communication network.
[0126] The embodiments of the present disclosure also provide a computer-readable storage medium. The above-mentioned method according to the embodiments of the present disclosure can be implemented in hardware, firmware, or implemented as a computer code that can be recorded in a storage medium, or implemented as a computer code that is originally stored in a remote storage medium or a non-temporary machine-readable storage medium and downloaded through a network and will be stored in a local storage medium, so that the method described herein can be stored in such software processing on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. Among them, the storage medium can be a magnetic disk, an optical disk, a read-only storage memory, a random access memory, a flash memory, a hard disk or a solid-state drive, etc.; further, the storage medium can also include a combination of the above-mentioned types of memory. It can be understood that a computer, a processor, a microprocessor controller or programmable hardware includes a storage component that can store or receive software or computer code. When the software or computer code is accessed and executed by a computer, a processor or hardware, the method shown in the above embodiment is implemented.
[0127] A portion of the present disclosure may be applied as a computer program product, such as a computer program instruction, which, when executed by a computer, can call or provide the method and / or technical solution according to the present disclosure through the operation of the computer. Those skilled in the art should understand that the form in which the computer program instruction exists in a computer-readable medium includes but is not limited to a source file, an executable file, an installation package file, etc. Accordingly, the way in which the computer program instruction is executed by the computer includes but is not limited to: the computer directly executes the instruction, or the computer compiles the instruction and then executes the corresponding compiled program, or the computer reads and executes the instruction, or the computer reads and installs the instruction and then executes the corresponding installed program. Here, the computer-readable medium can be any available computer-readable storage medium or communication medium that can be accessed by the computer.
[0128] Although the embodiments of the present disclosure have been described with reference to the accompanying drawings, those skilled in the art may make various modifications and variations without departing from the spirit and scope of the present disclosure, and such modifications and variations are all within the scope defined by the appended claims.
Claims
1. A SLA indicator standardization method, characterized in that: Applied to the SLA indicator standardization system, the system includes: an SLA indicator overview module, a comprehensive performance indicator module and a fault statistics analysis module, and the method includes: A comprehensive performance indicator module, which obtains client indicator data and server indicator data of each of the multiple apps according to a first preset type; A fault statistics analysis module is configured to obtain fault statistics and fault analysis results of each of the APPs under multiple dimensions according to a second preset type; The SLA indicator overview module screens and performs preset calculations on the client indicator data, the server indicator data, the fault statistics, and the fault analysis results based on at least one preset SLA core indicator to determine the standardized output results of each SLA core indicator; wherein the standardized output results include at least one of the following: current cycle data, previous cycle data, month-on-month growth rate, and growth data in the same period as the previous cycle.
2. The method according to claim 1, characterized in that The comprehensive performance indicator module includes: a client indicator unit and a server indicator unit. The comprehensive performance indicator module obtains client indicator data and server indicator data of each APP in a plurality of APPs according to a first preset type, including: The comprehensive performance indicator module dynamically obtains the real-time data of the APP through an integrated third-party platform and determines the project status of the APP based on the real-time data; A client indicator unit, if the project status of the APP is online, determines the client indicator data of the APP according to the type and / or time period of the APP, and displays the client indicator data in the form of a chart; wherein the client indicator data includes at least one of the following: APP crash rate, APP success rate, TP95, startup time, number of APP startups, number of APP slow requests, and APP access trend PV; The server-side indicator unit determines the server-side indicator data of the APP according to the time period and / or department to which the APP belongs, if the project status of the APP is online, and displays the server-side indicator data in the form of a chart; wherein the server-side indicator data includes at least one of the following: core interface request success rate, core interface TP95, overall request success rate, overall interface TP95, overall slow request rate, and daily throughput.
3. The method according to claim 2, characterized in that The method further comprises: The comprehensive performance indicator module obtains the test-related data of the APP if the project status of the APP is under testing; wherein, the test-related data includes at least one of the following: the number of test cases, test case coverage, test case execution rate, bug efficiency, the number of unexecuted test cases, the number of successful / failed / blocked test case executions, the number of P0-level test cases, the total number of bugs, the ratio of the total number of bugs to the number of test cases, the defect repair rate, the number of unfixed bugs, the ratio of P1 and P2 bugs, and the number of P1 or P2 bugs resolved in more than 1 day.
4. The method according to claim 2, characterized in that The fault statistics analysis module includes a fault statistics unit and a fault analysis unit. The fault statistics analysis module obtains fault statistics content and fault analysis results of each APP under multiple dimensions according to the second preset type, including: a fault statistics unit, determining multiple dimensions according to a second preset type, obtaining APP online fault indicator data in the multiple dimensions for each APP, sorting the APP online fault indicator data for each APP according to the fault type and fault level in the second preset type, and determining fault statistics for each APP; wherein the second preset type includes at least one of the following: time period, department, business, fault type, and fault level; The fault analysis unit analyzes the fault statistics of each of the APPs according to a plurality of preset analysis methods to determine a fault analysis result of each of the APPs.
5. The method according to claim 4, characterized in that The fault analysis unit analyzes the fault statistics of each of the APPs according to a plurality of preset analysis methods to determine a fault analysis result for each of the APPs, including at least one of the following: The fault analysis unit determines the total fault duration, total fault count, and total fault recovery time of all APPs in any department within any time period as the fault analysis result; The fault analysis unit determines the specific fault duration, specific fault number, and specific fault recovery time of any APP under any department within any time period as the fault analysis result; The fault analysis unit determines the overall fault cause classification of any department within any time period; The fault analysis unit determines the total fault duration, total fault number, and total fault recovery time of all departments within any time period as the fault analysis result; The fault analysis unit determines a ranking comparison analysis of the fault duration and the number of faults of all APPs of any department within any time period as a fault analysis result.
6. A SLA indicator standardization system, characterized in that: The system includes: a comprehensive performance indicator module, a fault statistics analysis module and an SLA indicator overview module, wherein: A comprehensive performance indicator module, configured to obtain client indicator data and server indicator data of each of the plurality of apps according to a first preset type; A fault statistics analysis module is used to obtain fault statistics and fault analysis results of each of the APPs under multiple dimensions according to a second preset type; The SLA indicator overview module is used to screen and preset calculations on the client indicator data, the server indicator data, the fault statistics and the fault analysis results based on at least one preset SLA core indicator, and determine the standardized output results of each SLA core indicator; wherein the standardized output results include at least one of the following: current cycle data, previous cycle data, month-on-month growth rate and growth data in the same period as the previous cycle.
7. A computer device, characterized in that: include: A memory and a processor, wherein the memory and the processor are communicatively connected to each other, the memory stores computer instructions, and the processor executes the SLA indicator standardization method according to any one of claims 1 to 5 by executing the computer instructions.
8. A computer-readable storage medium, characterized in that The computer-readable storage medium stores computer instructions, and the computer instructions are used to enable a computer to execute the SLA indicator standardization method according to any one of claims 1 to 5.
9. A computer program product, characterized in that The method comprises computer instructions, wherein the computer instructions are used to enable a computer to execute the SLA indicator standardization method according to any one of claims 1 to 5.