发版后自动回归

每次发版，流水线自动拿线上录下的真实请求，把测试环境里的新版本测一遍。结果和线上一致，就继续发布；不一致，就停下，并在报告和群里说明哪个接口变了。接入 AI 后，还会说明是哪次提交改的。

一次真实发版的回放报告

一次真实的发版

上图就来自这次发版：

线上的计价服务一直在录制请求。
开发提交了 0026097「调整会员价计算」，把会员价的取整从四舍五入改成了向下取整。
新版本部署到测试环境后，流水线自动回放了线上最近一小时录下的 237 个请求（报告里叫「用例」）。约 2 分钟后，流水线停下，输出的结论是 NEEDS_ACTION，意思是结果有变化、需要人来确认：
text
```
回放结论：NEEDS_ACTION
```
打开报告：/order/price 回放的 81 个请求里，有 79 个的应付金额 payable 比线上少了 1。流水线停下约 10 分钟后，AI 查明原因是提交 0026097 改了取整方式，并定位到改动的那一行 PricingService.java:12；通知渠道随即收到了结论和分析结果。
这个改动不是有意的。开发改回来重新发版，这次结论是 CLEAN，流水线继续发布。

如果改动是有意的，在报告里点「标记通过」，再在流水线里放行即可。

这次运行用的是演示环境：应用 ID 为 sp-diag-e2e-app，有 3 个接口；线上和测试实例在同一台机器上，线上流量用脚本模拟；只回放最近 1 小时的录制；通知渠道用的是 Webhook。截图里差异标题旁的「已连续 10 次」，是因为演示环境此前用同一个改动跑过多次，真实项目里第一次出现时不会是 10。

需要准备什么

前提：SoftProbe 是私有化部署的。SaaS 版暂时不能从流水线触发回放。

以下都只做一次，之后每次发版自动进行。

线上录制：在生产环境的服务上挂好 Agent，启动参数里加上 -Dsp.tags.env=prod，标明这是线上录的请求。见接入 Java Agent。
测试环境：测试环境的服务也挂上 Agent，用同一个应用 ID，加上 -Dsp.tags.env=test。测试环境不需要录制，免得把回放的请求又录一遍：在「配置 → 录制配置」里给 env=test 加一条规则，采样率（每分钟录几条）设为 0。见录制配置。
列出必须测到的接口：产品里叫「主链路接口」。没有这张清单时，SoftProbe 只能按数量判断测得够不够：一次回放实际测到的接口不到 10 个、或者请求不到 30 个，即使全部通过，结论也是「覆盖不足」。所以测到的接口少时一定要列；列了之后，改为检查清单里的接口是否都测到了。见主链路接口。
接入 AI（建议）：接入模型、给应用绑定代码仓库。报告会自动忽略时间戳、随机 ID 这类每次都会变的字段（AI 降噪），并说明差异是不是代码改动引起的。见配置 AI 诊断与代码仓库。
先跑通一次：把线上正在运行的同一个版本部署到测试环境，用下一节的脚本跑一次。报告里的差异逐个看：确认是时间戳、随机 ID 这类不影响业务的噪音后，配成对比规则忽略掉；再跑，直到结论是 CLEAN。这一步做好，之后发版才不会反复被同样的噪音拦下。
群通知：在「设置 → 通知」里加飞书或钉钉群机器人。见回放结果通知。

接进流水线

在「部署到测试环境」之后、「发布到下一个环境」之前，加一步运行这个脚本：

bash

export SP_BACKEND=http://sp-backend.internal:8090   # SoftProbe 后端地址
export SP_APP_ID=order-service                      # 应用 ID
export SP_TARGET=http://order-service.test:8080     # 测试环境里新版本的地址
export SP_CASE_TAGS='{"env":"prod"}'                # 只回放线上录的请求
bash ci/softprobe-replay.sh

脚本等回放结束后，按结论决定流水线往下走还是停下：

结论	流水线
`CLEAN`：没发现问题	继续发布
`NEEDS_ACTION`、`REVIEW_ONLY`：结果有变化	停下，看报告
其他：这次没测成	停下，查原因

脚本的其他参数（提交、分支、流水线链接、超时时间），以及 Jenkins、GitLab CI、GitHub Actions 里怎么写，见发版后自动回放。使用前先看那一页的准备工作：All-in-One 部署要先设置 SP_REPLAY_OPENAPI=true 并重启，运行脚本的机器要装好 bash、curl 和 jq。

流水线停下以后

结果有变化（NEEDS_ACTION、REVIEW_ONLY）：打开报告看变了什么。是有意的改动，点「标记通过」，再在流水线里放行；不是，就修好重新发版。
测得太少（LOW_COVERAGE、NO_CASES）：线上录到的请求太少，或者主链路接口没回放到。检查线上是否在录制、SP_CASE_TAGS 是否写对、主链路接口是否登记对了。
测试环境有问题（ENVIRONMENT_FAILURE、INTERRUPTED）：大量接口报同一种错，或者回放没跑完。先确认测试环境里的服务正常、网络能通；如果大量接口都返回 500，也可能是新版本本身出错。处理后再重跑流水线。

报告怎么看，见回放报告。

常见问题

流水线这一步要等多久？

回放本身的时间，加上等 AI 降噪的时间。上面的例子里，第一次约 2 分钟；修复后那次全部通过，反而等了约 8 分钟，其中回放 1 分 36 秒，其余都在等 AI 降噪收尾。脚本默认最多等 30 分钟。

群通知为什么比流水线晚？

流水线只等回放和 AI 降噪，不等 AI 查原因。结果有变化、并且接入了 AI 时，群通知会等 AI 分析结束再发（查不出原因也会发），最多等 20 分钟，所以通常比流水线晚几分钟到十几分钟。

AI 一定能查出原因吗？

不一定。查不出原因的差异，报告里会单独列为「原因未查明」。另外，AI 读的是绑定分支上的代码，绑定的分支要和部署到测试环境的一致。每天自动分析默认最多 10 次，发版多的话可以在报告的流程设置里调高。

有意的改动上线后，下次发版还会报同样的差异吗？

会，直到线上旧版本录下的请求都不在回放范围里（默认回放最近 24 小时的录制）。「标记通过」只对当次回放有效；报告会在这处差异旁标出「已连续 N 次」，方便认出来。

群里只想收到有问题的通知？

在通知渠道里打开「只在失败时发」。

发版后自动回归 ​

一次真实的发版 ​

需要准备什么 ​

接进流水线 ​

流水线停下以后 ​