异步接口（提交→worker→终态）的性能回归怎么度量：端到端耗时被队列深度污染，门禁卡哪个指标、基线怎么建才稳？

背景

我做了 3 年测试开发，维护一条 B 端数据报表链路（Java 17 + Spring Boot 3.2 + MySQL 8.0），其中约 20% 的用例是异步接口：POST /report/generate 提交后返回 202 + taskId，后台 worker 消费队列处理（生成 + 落库 + 转存对象存储），客户端轮询 GET /report/{taskId} 拿到终态 SUCCESS/FAILED。同步接口那部分我已经照着社区里的做法把 P99 纳入了 CI 回归（参考 id=755 那套思路），但异步这条链路我卡住了。

现象

1. 提交接口本身恒定 30~50ms，没有任何劣化空间；真正的耗时全在 worker 侧，同一个任务「提交→终态」的端到端耗时，基线是 40s，上周一次发布后悄悄涨到了 95s——功能断言全绿，没有任何门禁拦住。
2. 我试着在 CI 里对端到端耗时做 P95 断言，但结果极不稳定：worker 是共享队列，CI 并发跑 10 个任务时，后提交的任务要排队，端到端耗时能散到 60s~180s。同样的代码、同样的数据，连跑 5 次回归有 2 次「误报」超阈值。
3. 我怀疑劣化点在 worker 内部（比如某次改动把一次批量写改成了逐条写），但端到端指标把「排队时间」和「处理时间」混在一起，我没法定位到底是谁的锅。

已尝试

• 端到端耗时 P95 断言（CI 串行跑单任务）：能跑，但基线本身波动 ±30%，门禁形同虚设；
• 只断言提交接口耗时：全绿，但拦不住 worker 侧劣化；
• 从 worker 日志里 grep 处理耗时：能拿到，但散落在日志里，没法进 CI 断言，也没有历史基线可比。

期望得到的答案形态

1. 你们对「提交→worker→终态」这类异步接口的性能回归，门禁到底卡哪个指标？是 worker 侧的处理耗时（从出队到完成）、还是端到端耗时、还是两者分开卡？
2. 如果卡 worker 侧处理耗时，这个指标一般怎么采出来并结构化（埋点落库 / 响应头回传 / 单独指标端点），CI 里怎么断言？
3. 基线怎么建才抗抖动：跑 N 次取中位数？取 P50 而不是 P95？还是要求 worker 独占队列（CI 专用队列 / 单消费者）才能测？大家踩过哪些「基线不稳」的坑，最后是怎么收敛的？
4. 有没有现成的判定规则（比如「环比基线劣化 >X% 且连续 N 次回归确认」才告警）能直接抄的？

希望有在异步任务链路上真正落地过性能回归的同学，给具体指标口径 + 采集方式 + 阈值设定依据，而不是「建议加监控」这类方向性建议。