新服务上线时 P99 延迟 SLO 基线怎么定：参照老服务、压测推演还是拍经验值？

背景

我是一名技术文档工程师，最近在给团队整理一套「新服务上线 checklist」，其中一项是上线前必须给出延迟 SLO（P99 目标值）。这件事看起来一句话就能写进文档，但真去调研各团队的实际做法，发现完全没共识，卡在这里。

现象

调研了 4 个团队，定 P99 基线的方式各不相同：

1. A 团队：直接抄老服务当前线上 P99 上浮 20%（理由是"技术栈一样"）；
2. B 团队：只做一轮单机压测，取压测 P99 的 1.5 倍，不上生产链路压测；
3. C 团队：上线后先跑 2 周，拿自然流量的 P99 中位数回填 SLO（等于 SLO 滞后于上线）；
4. D 团队：架构师凭经验给一个整数（比如 200ms），没人能复述这个数字怎么来的。

我撞到的具体卡点：一个没有历史数据的 Java 新服务（Spring Boot + MySQL，预估 QPS 300），在没有任何线上分位数可参考的情况下，哪个方法给出的 P99 基线在"可承诺"和"不拍脑袋"之间最平衡？ 压测数据我理解不可直接外推（单机 vs 生产多副本、无真实数据分布），但具体要打几折、叠多少余量，没人说得清。

已尝试的排查

• 翻了 Google SRE Book 的 SLO 章节：讲了"从现有数据出发"，但没讲"没有数据时怎么办"；
• 站内已读了《限流阈值到底怎么定》《性能预算该不该进 CI 门禁》两篇讨论，前者聚焦限流阈值、后者聚焦 CI 门禁，都提到了 P99 但都不是"冷启动定基线"这个问题；
• 自己试了 B 团队的方法：单机压测 P99 = 87ms，×1.5 ≈ 130ms，但同技术栈的老服务线上 P99 是 210ms——两个数字差 60%，不知道信谁。

期望得到的答案形态

希望有实际踩过坑的同学给一个带数字的决策路径，比如：

• 在什么条件下可以用压测值外推、折扣系数怎么定（单机→集群、数据量、连接池等因素各占多少）；
• "上线后 2 周回填 SLO"这种做法的合理窗口期怎么判断，期间出故障怎么兜底；
• 如果让我在 checklist 里只写一条"定 P99 基线"的规则，你会写什么、为什么。

最好能附一个你自己团队真实用过的例子（脱敏即可），数字、推导过程都写出来，这种我可以直接搬进文档。