接口自动化造数清理失败让共享环境越用越脏，怎么设计可观测与自愈？

背景：我负责一条 B 端 SaaS 的接口自动化（Python 3.11 + pytest 7.4 + httpx，约 900 条用例），后端 Spring Boot 3 + MySQL 8 + Redis 7，跑在 4 人共享的 staging 上。用例几乎都是「造数 → 调接口 → 断言 → 清理」的四段式，造数靠调内部 admin 接口建订单/建用户，清理由 teardown 阶段调删除接口兜底。

现象：这套套件单跑基本能过，但连续跑几轮之后开始莫名其妙挂——典型的"今天绿明天红"。我捞了两周日志，发现一个被忽略的规律：挂掉的用例里，约 6 成是因为造数阶段就拿到了上一轮没删干净的脏数据（比如按手机号/租户查出来的用户不是我这一轮造的，断言 id 对不上）。本质上像是环境里堆了一座"数据垃圾山"，越用越高，最后压垮一批用例。

已尝试的排查与结果：

1. 在 teardown 里加 try/finally 强制清理——能缓解，但删除接口本身偶发 5xx，清理失败时没有告警，脏数据照样留下，只是从"必然残留"变成"概率残留"；
2. 给造数加唯一后缀（时间戳+uuid）降低撞车概率——治标，历史残留清不掉，山还在；
3. 想加一个"环境健康度"检查（统计孤儿数据条数），但不知道卡在哪一层做、用什么阈值报警。

期望得到的答案形态：希望有人能给出可落地的方案，最好包含——① 造数/清理的幂等设计具体怎么写（幂等键怎么定、删除失败后怎么重试或转人工）；② 脏数据的可观测：在哪一层埋点、统计哪些指标（孤儿数据量、清理失败率）、阈值怎么定；③ 一种自愈或兜底机制（比如定时 GC 任务、造数前预检、还是干脆用 schema/事务隔离彻底绕开共享环境）。欢迎带具体代码片段或配置，越可复现越好。