同样一批人，同样的速度。负荷从 50% 抬到 90%， 平均等待涨 九倍；再抬到 95%，再翻一倍。没人偷懒，没人变笨， 只是把余量用光了 —— 而余量正是排队系统里唯一在吸收波动的东西。
这一页把一份「到达 / 开始 / 完成」的日志读进来， 量出负荷、波动和工时，然后告诉你现在站在那条曲线的哪个位置， 以及四个杠杆各能买到多少。
先看前提
✓
900 件做完的活
至少 20 件
✓
到达率前 0.46 → 后 0.48
前后半段的到达率别差过 1.6 倍
✓
负荷 61.5%
得低于 100%
并行数 3 是从日志里读出来的：同一时刻最多 3 件在做。要是实际人手比这多，右边改一下。
队伍不长，负荷有余量
负荷 61.5%，平均等 1.07。在这个区间里，等待对负荷还不敏感 —— 真要缩短，把活做得更匀比少接活更划算，下面的排序就是这么出来的。
量出来的
61.5%
负荷 ρ
到达率 ÷ 产能
0.47
到达 件/小时
产能 0.76
3.94
单件工时 小时
3 个并行
0.73
工时的变异系数
到达的是 1.00；1.0 是「完全随机」
等多久
1.07
小时
重抽 95% 区间
0.87 – 1.34
区间是把这批数据重抽 2000 次得到的，不是把误差往两边一摊 —— 1/(1−ρ) 会把 ρ 的一点点抖动在高的一侧放大成一大截，在低的一侧几乎不动， 所以真实的区间是歪的，对称的误差棒在这里是假的。
日志里实际等的
中位 0，
平均 0.86，
p90 3.23 小时
公式说 1.07，日志里实际是 0.86（587 个忙期，95% 区间 0.46 – 1.27）。对得上 —— 这条队伍确实是这个模型描述的样子，所以下面那些「换个负荷会怎样」也就有得谈。
这里比的是忙期，不是件数：一个忙期里的等待是一起涨一起落的， 把 900 件当成 900 个独立观测会把误差算小好几倍。 这份日志里队伍空过 587 次，独立的观测就是这么多。
换个负荷会等多久
这条队伍自己的波动和自己的工时不动，只挪负荷。 所以这不是一张示意图，是这批人在别的负荷下会等多久。
50%
0.57
60%
0.99
70%
1.74
75%
2.37
80%
3.34
85%
4.98
90%
8.29
93%
12.6
95%
18.3
97%
31.7
98%
48.4
90% 到 95%，负荷只多了五个点，等待翻一倍。 这一段里 1/(1−ρ) 说了算，而它在 85% 之后就不讲道理了。
四个杠杆
按效果排，不是按代价排 —— 代价只有你知道。 「多一个人」在只有一个人的时候排第一，因为那是把团队翻倍。
多一个人
0.26
缩短 76%
并行数 3 → 4
每件快一成
0.69
缩短 36%
单件工时降到 0.9S
少接一成活
0.76
缩短 29%
到达率降到 0.9λ
波动小一成
0.87
缩短 19%
到达和工时的变异系数各降一成
「每件快一成」永远比「少接一成活」多买一点点： 两者把负荷降得一样多，但前者还顺带把整个乘式里的工时也缩了一成。 「波动小一成」买到的是固定的一截，跟负荷无关 —— 它只动波动那一项。所以在半载的队伍里它比少接活划算，在满载的队伍里反过来。
它算的是什么
单服务台是 Kingman 那条式子，多服务台是 Sakasegawa 的近似 （在 m = 1 时它精确退化成前者，测试里验的就是这一条）：
等待 = ρ/(1−ρ) × (ca²+cs²)/2 × 工时
有多满、有多不匀、 有多久 —— 三项是相乘的。 这意味着把工时的波动减半，跟把负荷降到对应那一档，买到的是同一个量级的东西。 后者要开会砍需求，前者常常只要把「大活拆小」写进流程里。
它不知道的事。 稳态公式描述的是长期平均， 所以窗口里负荷一直在变的时候它没有意义 —— 这一页会直接拒答而不是给个数。 它也不知道你的队伍是不是先来先做：不过按什么顺序做不改平均等待， 只要没人闲着。插队不省时间，只是把时间挪到被插的那件活上， 改的是分布不是均值，所以 p90 和中位数都摆在上面。
贴进来的东西只用来算这一次，不写盘、不记日志、不存任何地方。 整个页面没有一行 JavaScript：算在服务器上做完，发过来的就是结果。