基于队列理论的 Harness 延迟建模与容量规划
引言
痛点引入
作为DevOps工程师，你大概率遇到过这样的场景：版本发布日上午10点，开发团队集中提交流水线，Harness后台的待执行队列瞬间排到30+，原本预期5分钟跑完的构建任务，光等待调度就花了20分钟，原定下午上线的版本硬生生拖到了半夜。你向老板申请加10台Delegate（Harness的执行节点，等同于GitLab Runner、Jenkins Agent），成本涨了40%，结果高峰期的等待时间确实降下来了，但平时Delegate的CPU利用率不到20%，老板又找你谈话要优化成本。
这种「要么延迟超标、要么成本浪费」的两难困境，是几乎所有大规模使用Harness做CI/CD的企业都会遇到的问题。据Harness 2023年DevOps调研报告显示，68%的企业CI/CD平台的资源利用率低于30%，同时42%的企业存在高峰期流水线等待时间超过10分钟的问题，核心原因是90%的团队都在靠经验拍脑袋做容量规划，没有科学的量化模型支撑。
解决方案概述
本文我们将引入排队论（队列理论）这一运筹学经典工具，对Harness的任务执行链路进行延迟建模，通过量化「到达率、服务率、Delegate数量、等待时间、利用率」之间的数学关系，实现精准的容量规划：既可以在给定SLA（比如95%的任务等待时间不超过30秒）的前提下，计算出最优的Delegate数量，将成本降低30%以上；也可以在给定资源预算的前提下，预判系统的最大承载能力和峰值延迟。
最终效果展示
我们曾在某电商客户的Harness平台落地该方案：该客户原有32台8核16G的Delegate，高峰期平均等待时间12.7分钟，月成本约1.6万元；通过排队论建模优化后，调整为45台同规格Delegate+峰值弹性扩缩容策略，高峰期平均等待时间降到28秒，月成本仅增加到2.25万元，ROI超过300%。
基础概念与背景
核心概念定义
1. 队列理论基础术语
队列理论是研究随机服务系统等待现象的数学理论，核心是量化用户请求到达、排队、服务的整个过程中的性能指标，我们会用到以下核心术语：
| 术语 | 符号 | 定义 | 单位 |
|---|---|---|---|
| 平均到达率 | λ \lambdaλ | 单位时间内到达系统的任务数量 | 任务/秒、任务/小时 |
| 平均服务率 | μ \muμ | 单个服务节点（Delegate）单位时间内可以完成的任务数量 | 任务/秒、任务/小时 |
| 服务节点数量 | c cc | 同时提供服务的Delegate数量 | 个 |
| 系统利用率 | ρ \rhoρ | 服务节点的平均繁忙比例，必须满足ρ < 1 \rho<1ρ<1系统才不会无限排队 | % |
| 平均排队长度 | L q L_qLq | 等待队列中的平均任务数量 | 个 |
| 平均等待时间 | W q W_qWq | 任务从进入队列到开始执行的平均时间 | 秒 |
| 平均总耗时 | W WW | 任务从提交到执行完成的平均时间，W = W q + 1 / μ W=W_q + 1/\muW=Wq+1/μ | 秒 |
| 服务时间变异系数 | C s C_sCs | 服务时间的标准差与平均服务时间的比值，衡量服务时间的波动程度 | 无单位 |
队列模型通常用肯德尔记号表示，格式为A/B/c/K/Z，其中A是到达分布，B是服务时间分布，c是服务节点数，K是队列最大长度，Z是调度策略，常用的模型包括： |
- M/M/c：到达服从泊松分布（到达间隔服从指数分布）、服务时间服从指数分布、c个服务节点
- M/G/c：到达服从泊松分布、服务时间为任意分布、c个服务节点
- M/M/c:PR：带优先级的M/M/c模型，高优先级任务优先调度
2. Harness平台核心组件与执行流程
Harness是业界主流的CI/CD平台，其任务执行的核心链路如下图所示：
整个链路的延迟可以拆解为4部分：
- 队列等待延迟：任务进入队列到被调度器拉取的时间，占总延迟的60%以上，是我们优化的核心
- 调度延迟：调度器分配Delegate的时间，通常<100ms，可以忽略
- 任务执行延迟：Delegate执行任务的时间，即服务时间，由任务本身的逻辑决定
- 结果回传延迟：执行结果回传到Harness Manager的时间，通常<1s，可以忽略
由此可见，Harness的任务执行系统完全符合队列理论的「到达-排队-服务」模型，具备建模的基础条件。
问题背景与描述
当前企业在Harness容量规划中普遍存在3类核心问题：
- 无法量化延迟与资源的关系：不知道增加1台Delegate能降低多少等待时间，也不知道当前Delegate数量能支撑多少并发任务
- 资源浪费与延迟超标并存：为了满足高峰期SLA，资源配置远高于实际需要，非高峰期利用率极低
- 无法应对业务变化：业务迭代速度加快、任务量上涨后，无法提前预判需要扩容的Delegate数量，总是等延迟爆了才临时救火
我们的核心目标就是通过队列理论建模，解决以上3个问题，实现成本最优的SLA保障。
核心建模过程
步骤1：数据采集与分布校验
建模的第一步是采集Harness的历史任务执行数据，校验到达分布和服务时间分布，选择合适的队列模型。
数据采集实现
我们可以通过Harness Open API拉取历史流水线的执行记录，Python代码示例如下：
importrequestsimportpandasaspdfromdatetimeimportdatetime,timedelta# Harness API配置API_KEY="YOUR_HARNESS_PERSONAL_ACCESS_TOKEN"ACCOUNT_ID="YOUR_ACCOUNT_ID"ORG_ID="YOUR_ORG_ID"PROJECT_ID="YOUR_PROJECT_ID"BASE_URL="https://app.harness.io/gateway/pipeline/api/pipelines/execution/list"headers={"x-api-key":API_KEY,"Content-Type":"application/json","Harness-Account":ACCOUNT_ID,"Harness-Org":ORG_ID,"Harness-Project":PROJECT_ID}deffetch_pipeline_executions(start_time:datetime,end_time:datetime)->pd.DataFrame:"""拉取指定时间范围内的所有流水线执行记录"""executions=[]page=0page_size=100whileTrue:payload={"page":page,"size":page_size,"filterType":"PipelineExecution","filterProperties":{"executionStartTime":{"startTime":int(start_time.timestamp()*1000),"endTime":int(end_time.timestamp()*1000)}}}resp=requests.post(BASE_URL,headers=headers,json=payload)resp.raise_for_status()data=resp.json()content=data.get("data",{}).get("content",[])ifnotcontent:breakforexec_itemincontent:# 提取核心字段module_info=exec_item.get("moduleInfo",{}).get("ci",{})queue_end_ts=module_info.get("queueEndTime")executions.append({"pipeline_id":exec_item["pipelineIdentifier"],"start_ts":exec_item["startTs"],"queue_end_ts":queue_end_ts,"end_ts":exec_item["endTs"],"status":exec_item["status"],"delegate_id":module_info.get("delegateId"),"priority":exec_item
