Test task scheduling and resource allocation method based on DevOps

Abstract

The invention relates to a test task scheduling and resource allocation method based on DevOps, which comprises the following steps of: firstly judging the irreversibility of tasks before scheduling, if the tasks fail to be scheduled, retry or rollback of downstream multiple tasks can be caused, namely identifying the tasks as irreversible tasks and pre-scheduling independently, if the tasks fail to be scheduled, terminating subsequent scheduling, and if the tasks fail to be scheduled successfully, returning to a scheduling queue; for tasks in the queue, a scheduling influence domain is identified according to a dependency relationship and a resource overlapping degree, and when a preset threshold value is exceeded, scheduling window convergence control is triggered, the concurrency scale is limited, and the scheduling density is reduced; before the tasks are matched with the computing resources, the execution performance of each resource node is monitored, and if the nodes have a high failure rate or performance degradation in multiple tasks, the nodes are set to be in a suppression state and are temporarily rejected from the resource allocation pool; in the scheduling process, the affinity is calculated according to the historical execution success rate and stability of the task on the resources, the task is preferentially scheduled to the corresponding resource group if the task exceeds a threshold value, and the binding is removed and the suitability is re-evaluated when the performance is abnormal, so that efficient scheduling and resource optimization configuration are realized.

Description

Technical Field

[0001] This invention relates to the field of software engineering technology, specifically to a DevOps-based method for test task scheduling and resource allocation. Background Technology

[0002] Current technologies, such as CN112052081A (a task scheduling method, apparatus, and electronic device), primarily rely on the average runtime of tasks on different executors and CPU thread usage to select the most suitable executor. While this improves scheduling responsiveness and task matching accuracy, it still suffers from being overly static, lacking contextual awareness, and unable to adapt to dynamic DevOps environments. In practical DevOps continuous integration and continuous deployment projects, test tasks are not only computationally intensive operations but are also significantly affected by complex dependencies between tasks, resource sharing conflicts, historical execution characteristics, and irreversible impacts. This method's scheduling strategy ignores upstream and downstream influence paths in the task topology graph, lacks a mechanism to identify the cascading effects of task failures, and fails to identify critical node tasks. Consequently, cascading failures are prone to occur at high-risk nodes, reducing the system's steady-state scheduling capability.

[0003] This method uses current CPU thread usage and average execution time as scheduling metrics, lacking continuous monitoring and trend modeling of resource node performance. It cannot predict scheduling instability caused by resource fluctuations in scenarios with frequent cold starts, slow image loading, or performance degradation under high concurrency. This is especially problematic in microservice architectures where container resource lifecycles are short and cold start bottlenecks are severe. Furthermore, this patent does not differentiate between initial task loading and repeated scheduling, failing to provide structural optimization for cold start duration. The method also lacks an affinity modeling mechanism between resources and tasks. In real-world DevOps scenarios, the same type of task often exhibits significant performance differences across different resource nodes. This solution only performs static matching based on average execution time, failing to reflect the personalized adaptability between tasks and resources and lacking continuous learning and adaptive capabilities. In contrast, affinity-based scheduling models can comprehensively model historical success rates, performance stability, and failure distribution, resulting in more accurate and robust resource allocation, adaptable to scenarios with a wide range of task characteristics.

[0004] This method fails to regulate the concurrency scale during scheduling and lacks a control mechanism for scheduling window density changes. When a large number of tasks enter the queue simultaneously, it may intensify resource contention and scheduling jitter, leading to decreased execution performance. In contrast, a scheduling window convergence mechanism can dynamically adjust based on the task's influence domain, effectively controlling scheduling density and reducing upstream and downstream dependency conflicts and system scheduling rhythm disruptions. This patent also fails to consider task execution stability modeling, making it unable to identify resources with large performance fluctuations and high failure rates during multiple scheduling cycles. Furthermore, it lacks node suppression or temporary removal mechanisms within the scheduling cycle, potentially leading to repeated selection of inefficient resource nodes and a decline in scheduling quality. From an architectural perspective, this method emphasizes a one-time task data-driven matching mechanism, lacking state memory, task history evolution modeling, and critical path analysis capabilities. It cannot form a truly dynamic scheduling system, especially in multi-tenant shared resource pools and complex CI / CD pipeline scenarios. Its strategy is simple and lacks flexibility, making it prone to scheduling failures under complex dependencies or sudden changes in system load. Summary of the Invention

[0005] The purpose of this invention is to provide a DevOps-based method for test task scheduling and resource allocation, thereby addressing some of the shortcomings and deficiencies mentioned in the background art.

[0006] The technical solution adopted by the present invention to solve the above-mentioned technical problems is as follows: a test task scheduling and resource allocation method based on DevOps, including: before the test task enters the scheduling, the irreversibility of the task to be scheduled is determined. When it is determined that its failure will cause multiple downstream tasks to retry or roll back, the task is marked as an irreversible task and scheduled independently in advance. If the execution fails, the subsequent task scheduling is terminated. If it succeeds, it is re-added to the scheduling queue. The scheduling influence domain of tasks in the scheduling queue is identified based on their dependencies and resource overlap. When the influence domain of a task exceeds a preset threshold, scheduling window convergence control is triggered to limit the concurrency scale and reduce scheduling density. Before matching tasks with computing resources, the execution performance of each resource node is monitored. When a node has a high failure rate or performance degradation in multiple tasks, the node is set to a suppressed state and temporarily removed from the resource allocation pool. During task scheduling, the affinity between tasks and resources is calculated based on the historical success rate and stability of task execution on resources. When the affinity exceeds the threshold, the task is prioritized for scheduling to the corresponding resource group. If the performance is abnormal, the binding is removed and the adaptability is reassessed.

[0007] Furthermore, the irreversibility determination includes a joint evaluation of the dependency depth of the test task, the impact range of historical failures, and the cost of retrying; if the number of downstream tasks that an irreversible task depends on exceeds a preset threshold, the task is marked as a critical node task; and during the pre-scheduled independent scheduling, the irreversible task is bound to the critical resources it depends on for execution, so as to remove the judgment deviation caused by resource drift.

[0008] Furthermore, the scheduling influence domain is jointly determined by the fan-out degree and resource sharing degree of the task in the dependency graph, wherein the scheduling window convergence control reduces the scheduling density by dynamically adjusting the concurrent scheduling threshold.

[0009] Furthermore, the execution performance of the resource node includes the average task response time, failure rate, cold start duration, and maximum concurrency; the affinity between the task and the resource is calculated based on the past execution success rate, failure impact, and stability fluctuation range of the specified resource.

[0010] Furthermore, during task scheduling, the system performs optimal resource scheduling based on the affinity between tasks and resource nodes. This affinity is a comprehensive quantitative indicator characterizing the degree of matching between tasks and resources, and its calculation is as follows:

[0011] in: Indicates task With resource nodes Affinity rating between them; Indicates at time The task is on the resource node. The execution success rate is used to reflect the historical probability of reliable execution of a task. This indicates that the task is on the resource node. The degree of fluctuation in execution stability is estimated based on the statistical variance and abnormal volatility indicators of task runtime; , These are weighting coefficients, used to adjust the importance of execution success rate and stability in affinity calculation; This is a historical information decay factor used to control the strength of memory for past task performance; its weight decays exponentially over time. This is the deadline for the current scheduling period, used as the upper limit for integration. ,in This indicates that the task is in the resources The cumulative number of failures on The failure penalty coefficient is used to form the incentive compression term. This reduces the affinity score of high-failure resources; When the affinity value When the affinity threshold is higher than the system's set threshold, the task will be prioritized for execution on the corresponding resource node. At the same time, at the end of each scheduling cycle, the system dynamically adjusts the parameters in the affinity function based on the task execution results to optimize the matching between the task and the resource.

[0012] Furthermore, the cold start duration is divided into image loading time and initialization script execution time, which are recorded separately to determine the bottleneck position of resource node cold start; the maximum concurrency is dynamically calculated based on the fluctuation of the resource utilization curve of historical tasks; the calculation of the stability fluctuation range is based on the standard deviation of the execution duration and the number of reschedulings after task failure.

[0013] Furthermore, the image loading time is further subdivided into container scheduling waiting time and file system pull time, which are recorded separately to evaluate image storage performance bottlenecks; the initialization script execution time also includes environment variable injection time and test framework activation time, which are used to identify the impact of configuration complexity on cold start performance.

[0014] Furthermore, the resource utilization curve is time series data, and fluctuation modeling is performed using a sliding window and exponentially weighted moving average algorithm; the resource utilization includes multiple dimensions such as CPU utilization, memory utilization, and disk I / O, which are jointly used as parameters for estimating concurrency capacity; the maximum concurrency evaluation results of the resource nodes are subdivided by task type and stored in resource scheduling tags to guide typed scheduling.

[0015] Furthermore, the dependency depth assessment of the test task includes analyzing the hierarchical position of the task in the dependency chain and the number and execution order of the downstream tasks triggered, in order to determine the scope of propagation impact in the pipeline structure; the assessment of the scope of impact of historical failures is calculated based on the product of the number of retries of downstream tasks caused by failures in past executions and the average execution time, forming a failure diffusion coefficient.

[0016] Furthermore, if the number of tasks identified as critical nodes continuously exceeds a set proportion, the system adjusts the pipeline structure and triggers task splitting or parallelization strategies to reduce system coupling; the identification process of critical node tasks combines the time distribution characteristics of historical task failures to schedule and isolate the critical nodes that appear.

[0017] The beneficial effects of this invention are as follows: Before test tasks enter scheduling, a multi-dimensional assessment of task irreversibility, including dependency depth, the scope of historical failure impact, and retry costs, can effectively identify and prioritize critical tasks for scheduling. This allows for rapid exposure of systemic risks in the early stages of the testing process, avoiding resource waste caused by a large number of invalid tasks. Combined with a critical resource binding mechanism, it prevents resource drift from affecting the accuracy of judgments, improving the certainty and foresight of scheduling decisions. The scheduling influence domain identification and window convergence control mechanism can dynamically adjust the density of concurrent tasks, effectively reducing the test avalanche effect caused by the simultaneous failure of densely dependent tasks, and improving the overall stability and recoverability of the DevOps pipeline.

[0018] A dynamic affinity modeling mechanism based on task historical behavior is introduced. Combining the success rate and stability fluctuations of tasks on specific resource nodes, a nonlinear integral function with exponential decay and failure compression factors is used to quantify affinity, thereby giving the scheduling system memory and corrective capabilities for resource adaptation. By combining phased performance analysis of cold starts, time-series modeling of resource concurrency capabilities, and categorized scheduling strategies, fine-grained management and dynamic scheduling at the resource level are further achieved. This comprehensively improves the accuracy, stability, and resource utilization efficiency of task scheduling, greatly enhancing the responsiveness and quality assurance capabilities of the testing phase in DevOps continuous delivery. Attached Figure Description

[0019] Figure 1 This is a flowchart of the test task scheduling process based on DevOps in this invention.

[0020] Figure 2 This is an activity diagram of the affinity-driven task scheduling of the present invention.

[0021] Figure 3 This is an activity diagram of the task scheduling process for cold start and load-driven tasks in this invention.

[0022] Figure 4 This is an activity diagram of the critical task scheduling and resource binding process in Embodiment 1 of the present invention.

[0023] Figure 5 This is a flowchart of the task performance and risk management process of the scheduling system in Embodiment 2 of the present invention. Detailed Implementation

[0024] The specific embodiments of the present invention will now be described in detail with reference to the accompanying drawings.

[0025] Combined with appendix Figure 1This invention relates to a DevOps-based test task scheduling and resource allocation method. Before a test task enters the scheduling phase, the system performs an irreversibility determination operation on each task to be scheduled. This irreversibility determination is a process of comprehensive analysis based on task dependencies, historical failure behavior, and scheduling structure. The system determines whether a task failure will trigger retries, rollbacks, cascading failures, or cause a significant disruption to the entire test link due to the detection of the number of downstream tasks that the task depends on or affects, the failure responses of these tasks in the historical pipeline, and rollback trigger frequency data.

[0026] If a task is determined to be highly irreversible, the system will mark it as an irreversible task and adjust its scheduling strategy. Instead of scheduling it in the original queue order, it will be moved to a higher priority position in the scheduling process for independent scheduling. Independent scheduling means that the task does not compete for resources with other tasks or enter the batch scheduling flow; instead, it has priority to exclusively occupy critical resources and execute, thereby verifying its stability and execution success at an early stage and avoiding the cascading effects of its failure.

[0027] During this pre-scheduling process, the system binds the critical resources upon which the irreversible task depends, ensuring that the actual execution environment of the task is consistent with the evaluation environment. This prevents irreversibility determination from becoming invalid or distorted due to resource allocation drift. The resource binding process includes fixing the resource nodes, image configurations, and environment variable sets that the task has previously run stably, in order to maintain the repeatability and stability of execution conditions.

[0028] If the irreversible task fails to execute in independent scheduling, the system will immediately suspend the scheduling operations of all subsequent dependent or downstream tasks in the current test pipeline to prevent the further propagation of potential errors. This can be combined with strategies to trigger test alarms, rollbacks, or manual intervention mechanisms. If the irreversible task successfully executes in pre-scheduling, the system will register its execution status as successful, re-mark the task as a schedulable task, return it to the scheduling queue, and allow the system to continue the normal task scheduling process. Simultaneously, it will release the critical resources it occupied, enabling subsequent tasks to continue to be scheduled and executed based on its successful result.

[0029] The system identifies the scheduling influence domain for each task in the queue. This identification process comprehensively considers the dependency structure between tasks and the resource range competed by the tasks. The system analyzes the position of the task in the dependency chain, the number of its upstream and downstream tasks, the fan-out degree of the dependency path, and the logical coupling strength. Furthermore, it identifies the degree of overlap between the computing resources required by the current task during the scheduling process and other tasks, including resource type, resource grouping, concurrent channels, and network bandwidth sharing factors.

[0030] Based on the above analysis, the system generates a scheduling impact domain index for each task, describing the scope of the impact or interference caused by the task's scheduling behavior. This index includes both the logical dependency propagation range and the probability of scheduling interference in terms of resources. When the scheduling impact domain of a task exceeds the system's set threshold, it means that once the task is scheduled, it will interfere with the normal execution of multiple tasks or cause queuing and blocking. At this time, the system will trigger the scheduling window convergence control mechanism. This mechanism dynamically compresses the number of tasks that can be scheduled simultaneously in the current scheduling queue, limiting the concurrent execution of high-impact tasks with other tasks, thereby reducing the scheduling conflict density and stabilizing the throughput rate of the scheduling process.

[0031] Before scheduling, the system monitors available computing resource nodes in real time to obtain their performance metrics. These metrics include average task response time, resource utilization efficiency, recent task failure rate, cold start time, and concurrent processing capacity. When a resource node experiences consecutive task failures, significant performance fluctuations, or increased response latency, the system marks it as suppressed according to preset rules. In suppressed state, the node is temporarily removed from the resource allocation pool for the current scheduling cycle to prevent it from providing scheduling support and further causing task failures or scheduling imbalances. This removal is a soft removal mechanism; if the node's performance stabilizes in subsequent evaluation cycles, it will be allowed to re-enter the scheduling resource pool.

[0032] The system incorporates an affinity-driven resource matching mechanism during task scheduling to improve the accuracy of scheduling decisions and execution stability. Affinity characterizes the degree of matching between a test task and a resource node, and is a dynamic score calculated based on the task's success rate and execution stability on that resource node during historical scheduling. The system continuously collects historical task logs and resource monitoring data, extracting the completion status, response time, timeout or failure status, and resource usage curve stability indicators for each task on the resource node, constructing a behavioral profile of multiple interactions between tasks and resources.

[0033] Based on this behavioral profile, the system uses statistical functions to quantify the success probability and performance fluctuation range of the task on the target resource node, and then weights and fuses the two types of data to generate an affinity score. If a resource node has a high success rate and low operational volatility for the task, the system considers that the node to have a high affinity with the task. When the system finds that the affinity score between a task and a resource node is higher than a preset threshold, it prioritizes assigning the task to the resource group to which the corresponding resource node belongs in the scheduling strategy, thereby improving execution stability and reducing the risk of scheduling failure.

[0034] During actual scheduling, the system continues to monitor the task execution status in real time. When a task is running on a resource deemed to have high affinity, if significant performance anomalies are detected, such as a sudden increase in response time, a significant rise in the number of failures, or irregular fluctuations in resource utilization, the system will remove the binding relationship between the task and that resource and recalculate the affinity score between the task and other available resource nodes. The system adjusts resource adaptability based on the latest score results to ensure that the task can still obtain the optimal scheduling execution position after changes in the resource environment.

[0035] Combined with appendix Figure 2 Before tasks enter the scheduling phase, the system performs an irreversibility determination to identify tasks that have a critical impact on system stability in the overall testing process. The core of the irreversibility determination lies in jointly evaluating the dependency depth of the test task, the scope of historical failures, and the cost of retrying. By analyzing the dependency graph of the test tasks, the system determines the hierarchical position of the task in the pipeline structure, calculates the number and dependency strength of its upstream and downstream tasks, and thus obtains the task's dependency depth. A greater dependency depth indicates that the task is located on the critical path of the test link, and its impact on the execution of subsequent tasks is more significant.

[0036] The system analyzes the propagation impact of task failures in past runs based on historical execution records. This analysis includes statistically analyzing the number of downstream task retries, latency, and additional execution overhead required for pipeline recovery following a task failure, to quantify the diffusion effect of the failure and form a historical failure impact range index. The system combines the computational resources consumed by the task during historical execution due to failures or rollback operations, the time spent on manual intervention, and the resource consumption during retry processes to calculate a retry cost score. By jointly weighting and evaluating these three indicators—dependency depth, failure impact range, and retry cost—the system generates a comprehensive irreversibility score to distinguish between ordinary and high-risk tasks.

[0037] When the system detects that the number of downstream dependent tasks for a given task exceeds a set threshold and the overall irreversibility score reaches a high-risk level, the system will identify the task as a critical node task. Identified critical node tasks are given higher priority in the scheduling strategy and are scheduled to enter the pre-emptive independent scheduling process. During independent scheduling, the system binds the irreversible task to the resource node with the most stable performance and highest success rate in its historical execution to ensure the determinism and consistency of the task's runtime environment. This binding operation fixes the critical resources and their configuration environment that the task depends on, including the runtime container, image version, dependency libraries, and network resource channels, thereby eliminating execution result deviations caused by resource drift or scheduling randomness.

[0038] When a critical node task executes successfully in independent scheduling, the system records its execution result and resource status information, and updates the parameters of the irreversibility determination model for self-learning optimization of subsequent scheduling decisions. If execution fails, the system immediately suspends the scheduling of downstream tasks that depend on this task and generates a task risk report to trigger manual intervention or an automatic rollback mechanism.

[0039] The system introduces a mechanism for determining the scheduling influence domain and a scheduling window convergence control strategy. The scheduling influence domain is a key indicator used to measure the degree of chain interference or resource contention caused by a task during scheduling execution. After generating the scheduling queue, the system analyzes the fan-out degree of each task in the dependency structure graph and its resource sharing degree with other tasks.

[0040] Fan-out degree characterizes the breadth of downstream dependencies propagated by a task, referring to the number of downstream tasks directly or indirectly triggered from the task node. When constructing a test task dependency graph, the system extracts dependency paths between tasks based on test cases, build scripts, and pipeline configurations, and calculates the fan-out degree of each task through topology analysis. A larger fan-out degree indicates that if a task fails, its impact will propagate through multiple paths, thus resulting in a wider potential impact range during scheduling.

[0041] Resource sharing degree is used to characterize the degree of overlap between the resources required by a task and those of other tasks. The system constructs a resource intersection graph between tasks by analyzing the compute nodes, storage locations, image containers, and network interfaces requested during task scheduling. If a task shares the same set of critical resources with multiple other tasks, especially on nodes with low concurrent resources or in unstable resource pools, it is more likely to cause resource contention during execution, leading to queuing blockages or performance bottlenecks.

[0042] The scheduling impact domain is jointly modeled using the two dimensions mentioned above. The system generates an impact domain score by weighted fusion of fan-out degree and resource sharing degree. If the scheduling impact domain score of a task exceeds the system's preset threshold, it indicates that its scheduling process has a high risk of system interference. At this time, the system will trigger the scheduling window convergence control mechanism. This mechanism actively compresses the concurrent scale of the scheduling window by dynamically adjusting the threshold of the number of tasks that can be scheduled concurrently, avoiding the simultaneous execution of multiple high-impact tasks, thereby effectively reducing scheduling density and system pressure. After each scheduling cycle, the system fine-tunes the concurrency threshold based on scheduling failure rate, resource utilization fluctuations, and task latency feedback, so that the entire scheduling process achieves a dynamic balance between performance and stability.

[0043] The system achieves precise scheduling and intelligent resource matching for test tasks by jointly modeling the performance of resource nodes and their task affinity. The system monitors and quantitatively evaluates the operational characteristics of each resource node using multi-dimensional indicators to construct a resource performance profile. The performance of resource nodes includes four core parameters: average task response time, task failure rate, cold start duration, and maximum concurrency. Average response time measures the overall response efficiency of a node when handling different types of test tasks. The system calculates the node's response stability under different load conditions by recording the time interval from task scheduling to result return. Failure rate reflects the reliability level of a node executing tasks over a period of time, obtained by comparing the total number of task executions with the number of failures. Cold start duration evaluates the node's startup performance when initially loading the environment. The system records the startup time in two parts: the image loading phase and the initialization script execution phase, to identify potential performance bottlenecks. Maximum concurrency represents the upper limit of tasks a node can handle simultaneously without causing performance degradation. The system dynamically calculates this based on the fluctuations in the resource utilization curves of historical tasks to reflect the node's true concurrent carrying capacity.

[0044] After obtaining the aforementioned node performance metrics, the system further calculates the affinity between tasks and resource nodes to reflect the task's adaptability to specific resources. Affinity calculation is based on three key dimensions: historical task execution success rate on a specified resource node, the degree of failure impact, and the range of stability fluctuations. Execution success rate characterizes the reliable probability of a task completing on that resource node; the system quantifies this by statistically analyzing the ratio of successful task executions to the total number of executions based on historical scheduling results. The degree of failure impact reflects the scope of influence and recovery costs of subsequent task chains after a task failure; the system calculates this by analyzing the number of rescheduling attempts and the length of dependency rollback paths after a task failure. The range of stability fluctuations assesses the performance dispersion when a task is executed multiple times on the same resource node; the system jointly models this using the standard deviation of task execution time and the amplitude of runtime resource load fluctuations to obtain resource stability metrics.

[0045] During the scheduling phase, the system comprehensively evaluates the task's affinity score and the execution performance parameters of resource nodes to determine the optimal matching relationship. When a task has a high affinity score on a specific resource node and that node is within a stable performance range, the system will prioritize scheduling the task to that node for execution, thereby improving the task success rate and execution efficiency. During task execution, the system continuously monitors the real-time performance of the node. If there is a significant increase in response time, an increase in failure rate, or a deterioration in stability, the system will adjust the affinity parameters and recalculate the resource suitability to ensure continuous optimization and dynamic balance of the scheduling strategy.

[0046] Before executing a test task, the system jointly models the historical execution characteristics of the task with the performance of resource nodes, and performs optimal resource scheduling through an affinity-driven mechanism. The system introduces affinity as a comprehensive quantitative indicator representing the degree of matching between the task and the resource, used to determine whether a task is suitable for allocation to a particular resource node. This affinity is calculated during the scheduling process using the following formula:

[0047] in: Indicates task With resource nodes Affinity rating between them; Indicates time At that time, the task is on the resource node. The execution success rate is used to reflect the probability of a task being executed reliably. This indicates that the task is on the resource node. The degree of fluctuation in execution stability is estimated by the statistical variance and volatility trend of the task runtime. , To adjust the parameters, the influence weights of success rate and stability in the overall score were controlled separately; This is the information decay coefficient, which controls the weight decay of historical execution performance over time; The deadline for the current scheduling period is defined as the upper limit of the points. ,in Indicates task At resource nodes The cumulative number of failures on This is a failure penalty factor used to dynamically compress the negative impact of historical failures in the final affinity score.

[0048] This formula weights task success rate and stability, and incorporates time-based attenuation processing, allowing the system to prioritize recent task performance while reducing interference from earlier data. During execution, the affinity score between a task and a resource node is considered. If the affinity threshold is higher than the system's set threshold, the task will be prioritized for execution in the resource group where the resource node is located.

[0049] At the end of each scheduling cycle, the system will adjust the parameters in the model based on the latest task execution results. , , and Dynamic corrections are made and the success rate and volatility curves are updated to form a feedback loop between tasks and resources, thereby improving the expressive power and predictive accuracy of the affinity model.

[0050] function The derivation process includes: function This involves two key factors: first, the success rate of task execution by resource nodes. This is used to measure the resource availability of the task. The reliability of the resource node during task execution is twofold: firstly, the reliability of the resource node itself; and secondly, the performance stability fluctuation of the resource node during task execution. It can be calculated based on the variance of task runtime and the dynamic performance of system load jitter.

[0051] To reflect the differences in the importance of historical data, a time decay function is used. Historical samples are assigned time weights, with data closer to the current scheduling cycle receiving greater weights. Simultaneously, tasks are grouped into time periods. The scheduling performance information within the task is continuously integrated to form a comprehensive judgment on the task resource matching, thus yielding the integral part:

[0052] in, and This is a moderating factor used to control the degree to which success rate and volatility indicators affect affinity. Control the rate of historical data decay. To prevent the scheduling system from favoring nodes that have a history of success but have recently experienced frequent failures, an incentive compression term is introduced:

[0053] This item is The structure is designed to compress the affinity of frequently failing nodes to a lower value, where For the number of failures, This is the failure sensitivity weight. This structure ensures that even if a task experiences multiple failures and its historical average performance remains superior, it will not be mistakenly identified as a preferred resource by the system. Finally, the time-weighted integral is multiplied and combined with the failure compression factor to form the affinity calculation formula between the task and the resource node.

[0054] Combined with appendix Figure 3During the cold start phase before resource nodes execute new tasks, the system subdivides the cold start duration into two sub-metrics: image loading time and initialization script execution time. Image loading time refers to the time elapsed from the time the task scheduling request is issued to the successful retrieval and loading of the target container image. This metric reflects the node's overall performance in terms of image repository access bandwidth, file system response rate, and local cache hit rate. Initialization script execution time refers to the time spent by the node performing pre-task preparation processes after the image is loaded, including multiple stages such as environment variable injection, dependency library loading, test framework activation, and pre-detection script execution. The system records the original timestamps of both sub-metrics and continuously updates the average and fluctuation range to identify whether there are performance bottlenecks and their locations during the cold start process.

[0055] The system establishes time-series curves for multi-dimensional resource indicators such as CPU utilization, memory utilization, and disk I / O load for each node. It extracts the resource usage trajectory within the current task activity cycle using a sliding window and employs an exponentially weighted moving average method to smooth the fluctuation trend. During the evaluation process, the system statistically analyzes the rate of increase and instantaneous peak density of the resource curves, combining this with the average task dwell time and execution load intensity to dynamically predict the maximum number of concurrent tasks a node can accommodate while maintaining stable operation. This maximum concurrency is not statically configured but is updated in real-time based on historical behavior and mapped to resource scheduling tags to support typed scheduling and scheduling window control strategies.

[0056] In terms of task stability assessment, the system uses the standard deviation of task execution time on resource nodes and the number of rescheduling attempts after failure as core calculation elements to jointly form a stability fluctuation range index. The standard deviation of execution time reflects the performance fluctuation range during each task run; a larger variance indicates lower stability of the task on the resource node. The number of rescheduling attempts after task failure measures the node's sensitivity to anomaly recovery. If the same task fails multiple times on a given node and requires frequent transfer to other nodes, it indicates poor adaptability of that node to such tasks, and its participation weight should be reduced in subsequent scheduling.

[0057] During the image loading process, the system breaks down the image loading time into two sub-items: container scheduling wait time and file system fetch time. Container scheduling wait time refers to the delay between the scheduler receiving the task scheduling instruction and the target compute node becoming ready and allocating compute resource slots. This time is mainly affected by the scheduler's queuing depth, the efficiency of node idle resource search, and scheduling adjustment strategies. File system fetch time refers to the total time required from the scheduler initiating the image fetch request to the target node completing the fetching, verification, and mounting of the entire image data. This time is mainly limited by the image repository's bandwidth performance, the target node's network throughput, and the hit rate of the local cache mechanism. By independently recording these two time sub-items, the system establishes a time profile for the node's cold start phase. Combined with statistical data from multiple scheduling cycles, it determines whether there are performance bottlenecks in the image loading path for resource nodes. If a certain time item is significantly higher than the system average for multiple consecutive cycles, it is considered that the node has a bottleneck in the image scheduling process, and the scheduler will adjust subsequent scheduling strategies based on this result.

[0058] In the post-processing stage of cold start, the system further breaks down the execution time of the initialization script and incorporates the modeling of evaluation metrics for configuration complexity. The initialization script execution time includes not only the runtime of the task's startup script but also two key stages: environment variable injection time and test framework activation time. Environment variable injection time refers to the time consumed by the system to inject various runtime parameters, path configurations, and security credentials into the task within the container. This time depends on the number of parameters defined in the task, the hierarchical structure of configuration items, and the efficiency of the node's execution of the injection script. Test framework activation time refers to the overall time taken for the pre-built test execution framework in the container, such as unit test drivers, integration test engines, or regression test controllers, from initialization to readiness. This time is mainly constrained by the size of the test framework, dependency loading mechanisms, and node disk access performance. The system performs statistical analysis on these two time periods, constructing an environment injection complexity factor and a framework activation cost function to identify the adaptation performance of test tasks with fine-grained configurations and complex dependency structures on different nodes. This data is ultimately used in the cold start performance profile to guide the system in dynamically avoiding nodes with long latency in the cold start path during scheduling.

[0059] The system continuously collects resource usage data in a time-series manner and constructs a resource utilization curve. This curve covers multiple dimensions of indicators, including CPU utilization, memory utilization, and disk I / O load. It records the continuous values ​​of each indicator at different task stages using timestamps, thus forming the load evolution trajectory of resource nodes over a long period. To extract the trend characteristics of resource load and suppress short-term fluctuation noise, the system uses a sliding window mechanism to slice the resource utilization curve in stages. Within each window, an exponentially weighted moving average algorithm is applied for smoothing, giving higher weight to recent indicator changes and thus reflecting the effective load trend of resources in the current cycle.

[0060] After obtaining the smoothed resource utilization curve, the system aggregates and analyzes the historical execution process of different types of test tasks on each resource node. By associating task type labels with resource curve fluctuation characteristics, it identifies the load response patterns caused by specific tasks on different resource nodes and predicts the maximum number of concurrent tasks that a resource node can support under the current resource allocation structure. This maximum concurrency is not set with a uniform threshold, but is differentiated based on the resource consumption behavior corresponding to the task type. For example, there are significant differences in the concurrency capabilities of CPU-intensive tasks and I / O-intensive tasks on the same node. Therefore, the system subdivides and records the concurrency capability results according to task type and generates a maximum concurrency configuration file with task type labels.

[0061] The system writes the maximum concurrency evaluation results of each resource node under different task types into a resource scheduling tag set in the form of structured tags. This tag set is called in subsequent scheduling processes to participate in type-based adaptation judgment during resource matching. When the system detects a task of known type to be executed in the scheduling queue, the scheduler prioritizes matching resource nodes that have the tag for that task type and whose current concurrent load has not yet reached the upper limit. This ensures that the task meets performance constraints while improving resource utilization efficiency and avoiding stability degradation caused by resource overload.

[0062] Before scheduling, the system performs dependency depth assessment and historical failure impact range calculation on test tasks, aiming to quantify the potential propagation risk of the task to downstream processes from both structural and behavioral dimensions. The dependency depth assessment is based on the established directed dependency graph structure between tasks. The system traverses this graph to analyze the node position of each task to be scheduled, identifies its hierarchical position in the dependency chain, and counts the number of direct and indirect downstream tasks triggered by it. Simultaneously, it records the triggering order and dependency edge weights among these downstream tasks, thereby constructing a structural propagation path graph for the task.

[0063] The system further dynamically assesses the impact of historical failures, focusing on quantifying the cascading impact of a task failure on downstream tasks. The system collects execution log data from multiple historical scheduling cycles, extracts retry events triggered by the task failure, and calculates the number of retries and average recovery time for all affected tasks after each failure. By multiplying and summing the retry counts and average recovery times of all downstream tasks, the system calculates the failure propagation coefficient, reflecting the global execution cost of a single failure. A higher propagation coefficient indicates a high-risk node in the pipeline, and the scheduler prioritizes classifying it as an irreversible critical task, combining it with dependency depth assessment results for independent scheduling and fault-tolerant reinforcement. Through the combination of structural dependency analysis and behavioral impact modeling, The system identifies all test tasks marked as critical nodes within the current scheduling cycle through dependency analysis and failure impact modeling. These tasks typically occupy positions in the dependency chain with high fan-out, strong resource contention, and high failure costs; their failure will amplify interference to multiple downstream tasks. In each scheduling cycle, the system calculates the proportion of critical node tasks in the scheduling queue and compares it to a set criticality density threshold. If this proportion consistently exceeds the threshold for multiple consecutive scheduling cycles, the system determines that the current pipeline structure has a problem of excessive local coupling.

[0064] Once this determination is made, the system triggers a pipeline structure optimization process to re-divide and reconstruct the structural region where the critical task set is located. This optimization process includes the application of task splitting and parallelization strategies. Task splitting refers to rewriting single test tasks that are complex, resource-sensitive, or have a wide range of dependencies in segments according to logical functions, module boundaries, or execution steps, thereby reducing their propagation range in the structure graph. Parallelization strategies refer to transforming critical tasks that were originally executed serially into concurrently scheduled tasks, while ensuring that dependencies do not conflict, thereby shortening the overall execution time and reducing the degree of crosstalk coupling between tasks.

[0065] The system statistically analyzes the time points of failures of critical node tasks over multiple scheduling cycles and examines whether they occur in peak periods or critical version cycles. If it is found that the failure events of a critical task are concentrated in the high-pressure scheduling phase, the task will be set as a scheduling isolation object, and the system will prioritize scheduling it to low-load cycles or using isolated computing resource nodes for execution. Example 1:

[0066] Combined with appendix Figure 4In the continuous integration pipeline of a large internet company, the team deployed an automated testing platform based on DevOps. This platform schedules thousands of test tasks daily, covering various test types such as API verification, performance regression testing, and security scanning. The team needed to deploy a version update involving core accounting logic at 2 AM. To ensure the robustness of tests on the critical path, the platform performed an irreversibility check on the set of tasks to be scheduled.

[0067] In this update, Task_A in the task set involves consistency verification of accounting data. Its downstream dependencies include three subsystem integration test tasks: Task_B, Task_C, and Task_D, further affecting approximately 18 functional regression test modules. The platform assesses the dependency depth of Task_A. Analysis of the task dependency graph shows that the maximum depth of the downstream path of Task_A is 4 levels, and the total number of tasks affected by downward propagation is 21.

[0068] The platform has entered the historical failure impact assessment phase. Retrieving the historical execution logs of Task_A from the past 30 days reveals that a failure of this task results in an average of 3.5 downstream tasks retrying, with each downstream task retry taking approximately 4 minutes and rescheduling resource usage time being 2 minutes. Therefore, the estimated failure propagation impact of this task is: Impact of failure = Average number of retries × Average time = 3.5 × 4 = 14 minutes If we consider the wasted resources and time introduced by rescheduling, and multiply by the resource load factor of 1.5, the estimated cost of task failure is about 21 logical minutes, which is significantly higher than the average of 8 minutes for the same batch of tasks.

[0069] The platform dynamically evaluates retry costs. Because Task_A heavily utilizes database resources, each failed retry requires a cold start of the container and reloading of intermediate state files, making the cost of a single retry 2.6 times that of a normal task. The platform sets a retry cost threshold of 2 times, meaning Task_A clearly exceeds the warning line.

[0070] Based on the above evaluation results, the system, according to the preset judgment rules, judges Task_A as an irreversible task and detects that the number of its dependent downstream tasks has exceeded the set threshold of 10, thus marking it as a critical node task.

[0071] In terms of scheduling strategy, the platform treats Task_A as an independent scheduling unit, and its execution no longer shares a scheduling window with other tasks. Since this task depends on database resource group R3, the platform forcibly binds Task_A to the historically successful R3-Node-02 node during resource matching to avoid execution errors caused by differences in resource allocation. The system disables the scheduling permissions of this task on unbound nodes, thereby avoiding performance fluctuations introduced by resource drift.

[0072] The final scheduling log shows that Task_A took 132 seconds to execute without failure, and all 21 downstream tasks entered the regular scheduling queue. Compared to the previous three releases where Task_A failure led to an overall test rollback, this independent scheduling and resource binding strategy effectively reduced the risk of fault propagation.

[0073] The system constructs a real-time dependency graph for all tasks to be scheduled and performs quantitative analysis of the scheduling impact domain of core tasks. Taking Task_B as an example, this task has a fan-out degree of 7 in the dependency graph, meaning that its triggering will affect 7 downstream subtasks in parallel. Through the resource access tracing system, it is found that Task_B shares 3 high-frequency resource nodes with other tasks, including R1-Node-01, R3-Node-02, and R4-Node-03, indicating a high degree of resource sharing and a relatively high probability of scheduling conflicts.

[0074] Therefore, the system quantifies the scheduling influence domain of Task_B as follows: Influence domain = Fan-out degree × Resource sharing degree = 7 × 3 = 21 When the value of the influence domain exceeds the platform's set threshold of 20, the system triggers the scheduling window convergence control mechanism, which reduces the concurrent scheduling limit of the batch containing the task from the original 12 tasks to 8 tasks, and simultaneously lengthens the task start interval from an average of one task every 10 seconds to one task every 20 seconds, in order to reduce resource scheduling density and alleviate scheduling competition.

[0075] During the scheduling and control process, the platform continuously and dynamically samples and monitors the performance metrics of each resource node. Taking resource node R1-Node-01 as an example, its average response time for the past 30 tasks was 3.2 seconds, its failure rate was 6.7%, its cold start time was 15.8 seconds, and its maximum concurrency was 9, indicating a moderately weak performance. In contrast, R3-Node-02 had an average response time of only 1.9 seconds, a failure rate of 2.1%, a cold start time of 10.3 seconds, and a maximum concurrency of 12, demonstrating superior performance stability compared to other nodes.

[0076] When scheduling Task_C, the system extracts its historical performance data across different nodes and calculates its affinity score with each node based on success rate, failure impact range, and execution stability fluctuations. According to the internal scoring formula, Task_C's affinity score with R3-Node-02 is 0.84, while its affinity score with R1-Node-01 is only 0.57, both lower than the system's set affinity preference threshold of 0.75. The system prioritizes scheduling Task_C to R3-Node-02 for execution and sets its binding priority to medium. After scheduling is complete, the system records that Task_C's execution time is 92 seconds, with a 100% success rate and lower-than-expected response latency. Based on this feedback, the platform corrects the parameters in the affinity model to further improve subsequent scheduling accuracy.

[0077] In the test platform, Task_D is an integration test task that relies on an external simulation service, requiring resource nodes to have strong response performance and execution stability. To avoid assigning it to resources with poor historical performance, the system calculates its affinity on each candidate resource node during the scheduling phase and determines the priority scheduling order based on the affinity score.

[0078] Taking candidate resource node R5-Node-04 as an example, the system extracts the following input data based on its past five scheduling Task_D records to calculate affinity: At any moment Execution success rate recorded separately The values ​​are 0.98, 0.95, 0.96, 0.93, and 0.94. At the same time, the corresponding degree of performance stability fluctuation The values ​​are 0.02, 0.04, 0.03, 0.06, and 0.05. Set the weighting coefficient to

[0079] Historical information decay factor

[0080] Task deadline

[0081] Total number of failures Failure penalty coefficient ,therefore

[0082] Calculate the excitation compression term:

[0083] Next, we calculate the integral part:

[0084] Since the data is sampled at discrete times, numerical integration can be used to approximate it as a summation:

[0085] Substitute the data into the calculation:

[0086] Sum the results above:

[0087] The final affinity is calculated as follows:

[0088] The system's affinity optimization threshold is set to 1.2. Clearly, R5-Node-04's score exceeds this threshold. Therefore, the system prioritizes assigning Task_D to this node for execution and assigns a priority tag to the resource. At the end of the scheduling cycle, the system updates the affinity model parameters for this resource node in the next cycle based on the data returned from the actual task execution results, including a latest success rate of 0.97 and a volatility decrease to 0.018, ensuring continuous self-optimization of the model. Example 2:

[0089] Combined with appendix Figure 5 Based on Example 1, in a certain scheduling process, the system recorded a total cold start time of 31.4 seconds for Task_D on R5-Node-04. This time was further divided into two phases: image loading time of 18.7 seconds and initialization script execution time of 12.7 seconds. During the image loading phase, container scheduling wait time accounted for 6.2 seconds, and file system pull time was 12.5 seconds. The system thus inferred that the access latency of the image stored in the remote repository was the current bottleneck for cold starts. If the file system pull time is observed to exceed 10 seconds multiple times consecutively, the scheduling system will tag the node to indicate a storage I / O performance problem, and subsequent scheduling will prioritize avoiding this node to shorten the cold start latency.

[0090] The system entered the initialization script execution analysis phase. Environment variable injection took 4.3 seconds, and test framework activation took 8.4 seconds, indicating that the Task_D test framework loads slowly in the current environment. Referring to the average activation time of 5.2 seconds for the same task on other resources, the system determined that there is a configuration complexity issue in the current environment. The system will recommend adjustments based on container image caching and configuration template optimization suggestions, such as merging the activation script or lazy loading some dependency packages.

[0091] Regarding the assessment of maximum concurrency, the system statistically analyzed the resource utilization curves of R5-Node-04 over nearly 200 task runs, and modeled the fluctuations using a 10-second sliding window. Utilization data included CPU utilization fluctuating between 42% and 89%, memory utilization between 51% and 92%, and peak disk I / O reaching 120MB / s read / write. After smoothing using an exponentially weighted moving average (EWMA) algorithm, the system determined that the node could support 6 Task_D concurrent runs without resource starvation under stable single-task load. However, if the system detected that the resource conflict rate caused by concurrent tasks exceeded 20% within a certain period, the maximum concurrency would be dynamically reduced to 4, and the scheduling label record would be updated.

[0092] To more accurately assess execution stability, the system calculated the standard deviation of Task_D's execution time on node R5-Node-04 to be 3.6 seconds, and recorded that in the past 10 tasks, 2 failed and required rescheduling, with an average rescheduling time of 26 seconds. Based on this, the system calculated the stability fluctuation index as follows:

[0093] The index exceeded the task's set fluctuation threshold by 40 seconds, so the system triggered the steady-state assessment module, recommending to suspend the node for scheduling such high-sensitivity tasks and mark it as a performance risk node.

[0094] To dynamically model the concurrency capabilities of Task_E on resource node R5-Node-06, the system constructed three main resource utilization time series: CPU utilization, memory utilization, and disk I / O rate. The data sampling period was set to once every 5 seconds, continuously recording a total of 34,560 sampling points over 48 hours. The initial curves exhibited regular fluctuations, with the CPU utilization curve showing multiple peaks during high-concurrency periods, reaching a maximum of 94.3% and a minimum of 36.2%, exhibiting significant fluctuations.

[0095] The system smooths the resource utilization rate for each type using a sliding window-based local statistical and exponentially weighted moving average algorithm. The sliding window length is set to 300 seconds, and each window contains an average of 60 sampling points. Within each window, the system first calculates the local mean and local standard deviation, and then superimposes them in a decreasing weighting coefficient manner to generate a stable trend line. During peak periods, the CPU sliding mean is 78.5%, memory is 69.2%, and disk I / O maintains a read / write rate of 85MB per second.

[0096] The system constructs a joint load index by combining the stable trend lines of the three types of resources and sets a threshold to determine whether a node is operating under high pressure. During a certain period, Task_E averaged 18% CPU usage, 25% memory usage, and 22MB / s disk I / O per instance. Based on this, the system calculates the theoretical maximum concurrency of the node within this window period to be 4.2. To ensure stability, the system reserves a certain amount of resource margin and ultimately sets the maximum concurrency of R5-Node-06 for Task_E to 4.

[0097] The system writes the evaluation result into the resource scheduling label of R5-Node-06. The label format is: TaskType=Task_E,MaxConcurrency=4,Confidence=0.91, where the confidence score is a reliability score calculated based on the fitting error of past models. In subsequent scheduling, the scheduler reads the resource label information to guide typed scheduling. That is, priority matching of the node will only be triggered when the Task_E task enters the scheduling queue, and the concurrency limit will be strictly controlled to not exceed the labeled concurrency limit.

[0098] Task_F is a regression test task that verifies the stability of the core business payment interface. This task is located at the third level node in the dependency graph. Its upstream depends on two user interface test tasks, and its downstream triggers up to 17 module-level test tasks. The system calculates its dependency depth based on the dependency chain hierarchy, finding a level value of 3, a fan-out number of 17, and an average trigger path length of 4 steps, indicating that it is at a critical propagation intersection in the task chain. Based on the preset propagation impact threshold of a fan-out number ≥ 10 accompanied by a propagation depth of 3 or more, the system identifies Task_F as a potentially critical node with high dependency depth.

[0099] To further assess the impact of historical failures, the system retrieved the most recent 20 failure records for Task_F. It was found that each failure triggered an average of 12.3 downstream retries, with an average retry time of 17.6 minutes. Therefore, the failure diffusion coefficient was calculated as follows:

[0100] This value is significantly higher than the system's set warning threshold of 180. Based on this, the system upgrades Task_F to a formal critical node task and triggers the scheduling isolation mechanism. In subsequent scheduling cycles, Task_F is forcibly pre-scheduled and bound to the historically best resource node R7-Node-09 for execution to avoid unpredictable risks caused by resource drift.

[0101] In five consecutive scheduling cycles, the number of critical node tasks exceeded 22% of the total tasks on average per cycle, while the system's allowable ratio was set to 15%. The system determined that the current pipeline structure posed a risk of over-coupling and thus triggered a task splitting and parallelization optimization strategy. The task group centered on Task_F was split into three sub-processes, with payment verification, order logic, and transaction status retrieval tasks each constructed as independent parallel branches, each with no more than five downstream dependencies. This not only compressed the fan-out width of critical nodes but also significantly reduced the risk of single points of failure in the system.

[0102] The system also incorporates a time distribution feature analysis mechanism in the identification of critical nodes. Density clustering of historical failure times for Task_F reveals that its high failure probability is concentrated between 9:00 AM and 11:00 AM every Monday, a period often accompanied by batch cleanup operations of the backend database. Therefore, the system's scheduling strategy delays or moves Task_F within this time period to other lower-load time windows to avoid external environmental interference.

[0103] The foregoing has shown and described the basic principles, main features, and advantages of the present invention. Those skilled in the art should understand that the present invention is not limited to the above embodiments. The embodiments and descriptions in the specification are merely illustrative of the principles of the invention. Various changes and modifications can be made to the invention without departing from its spirit and scope, and all such changes and modifications fall within the scope of the present invention as claimed. The scope of protection of this invention is defined by the appended claims and their equivalents.

Claims

1. A DevOps-based method for test task scheduling and resource allocation, characterized in that... include: Before a test task enters the scheduling process, the irreversibility of the task to be scheduled is determined. If it is determined that its failure will cause multiple downstream tasks to retry or roll back, the task is marked as an irreversible task and scheduled independently in advance. If the execution fails, the subsequent task scheduling is terminated. If it succeeds, it is re-added to the scheduling queue. The scheduling influence domain of tasks in the scheduling queue is identified based on their dependencies and resource overlap. When the influence domain of a task exceeds a preset threshold, scheduling window convergence control is triggered to limit the concurrency scale and reduce scheduling density. Before matching tasks with computing resources, monitor the execution performance of each resource node. When a node has a high failure rate or performance degradation in multiple tasks, set the node to a suppressed state and temporarily remove it from the resource allocation pool. During task scheduling, the affinity between tasks and resources is calculated based on the historical success rate and stability of task execution on resources. When the affinity exceeds the threshold, the task is prioritized for scheduling to the corresponding resource group. If the performance is abnormal, the binding is removed and the adaptability is reassessed.

2. The DevOps-based test task scheduling and resource allocation method according to claim 1, characterized in that... The irreversibility determination includes a joint assessment of the depth of dependency of the test task, the scope of impact of historical failures, and the cost of retrying; if the number of downstream tasks that an irreversible task depends on exceeds a preset threshold, the task will be marked as a critical node task. In contrast, when scheduling tasks independently in the front end, irreversible tasks are bound to the critical resources they depend on for execution, thus eliminating the judgment bias caused by resource drift.

3. The DevOps-based test task scheduling and resource allocation method according to claim 1, characterized in that... The scheduling influence domain is determined by the fan-out degree and resource sharing degree of the task in the dependency graph. The scheduling window convergence control reduces the scheduling density by dynamically adjusting the concurrent scheduling threshold.

4. The DevOps-based test task scheduling and resource allocation method according to claim 1, characterized in that... The performance of the resource nodes includes average task response time, failure rate, cold start duration, and maximum concurrency; the affinity between the task and the resource is calculated based on the past execution success rate, failure impact, and stability fluctuation range of the specified resource.

5. The DevOps-based test task scheduling and resource allocation method according to claim 1, characterized in that... The affinity is a comprehensive quantitative indicator characterizing the degree of matching between tasks and resources, calculated based on the following two types of parameters: Execution success rate reflects the probability of reliable execution on task resource nodes; Execution stability metrics are used to reflect the degree of performance fluctuation when a task is executed multiple times on a resource node; Resource optimization scheduling is performed based on the affinity value. When the affinity is higher than a preset threshold, the task is preferentially scheduled to the corresponding resource node for execution, and the affinity value is dynamically adjusted according to the execution result of the new task during the scheduling cycle.

6. The DevOps-based test task scheduling and resource allocation method according to claim 4, characterized in that... The cold start duration is divided into image loading time and initialization script execution time, which are recorded separately to determine the bottleneck position of resource nodes during cold start. The maximum concurrency is dynamically calculated based on the fluctuation of the resource utilization curve of historical tasks. The stability fluctuation range is calculated based on the standard deviation of the execution duration and the number of reschedulings after task failure.

7. The DevOps-based test task scheduling and resource allocation method according to claim 6, characterized in that... The image loading time is further divided into container scheduling waiting time and file system pull time, which are recorded separately to evaluate image storage performance bottlenecks. The initialization script execution time also includes environment variable injection time and test framework activation time, which are used to identify the impact of configuration complexity on cold start performance.

8. The DevOps-based test task scheduling and resource allocation method according to claim 6, characterized in that... The resource utilization curve is time series data, and fluctuation modeling is performed using a sliding window and exponentially weighted moving average algorithm. The resource utilization includes multiple dimensions such as CPU utilization, memory utilization, and disk I / O, which are used together as parameters for estimating concurrency capacity. The maximum concurrency evaluation results of the resource nodes are subdivided by task type and stored in resource scheduling tags to guide typed scheduling.

9. The DevOps-based test task scheduling and resource allocation method according to claim 2, characterized in that... The dependency depth assessment of the test task includes analyzing the hierarchical position of the task in the dependency chain and the number and execution order of the downstream tasks triggered, in order to determine the scope of propagation impact in the pipeline structure; the assessment of the scope of impact of historical failures is calculated based on the product of the number of retries of downstream tasks caused by failures in past executions and the average execution time, forming a failure diffusion coefficient.

10. The DevOps-based test task scheduling and resource allocation method according to claim 2, characterized in that... If the number of tasks identified as critical nodes continuously exceeds a set proportion, the system adjusts the pipeline structure and triggers task splitting or parallelization strategies to reduce system coupling. The identification process of critical node tasks combines the time distribution characteristics of historical task failures to schedule and isolate the critical nodes that appear.

Images