灰度放量按 uid 尾号分桶：一次 P99 指标在 5% 灰度下虚高 220% 的复盘与分桶避坑清单

结论先行：「按 uid 尾号分桶灰度」本身没错，错的是把灰度桶当成「随机抽样」去读指标。尾号分桶在真实业务里几乎必然是非随机的——老用户、高活用户、特定地区/机型用户的 uid 分布高度集中在某些尾号段，导致 5% 灰度桶里装的根本不是「全量的 5%」，而是「某一类偏科用户」。下面是一次真实复盘，我把它拆成五段，方便你直接抄走清单。

一、现象：灰度组 P99 比全量还高，团队以为是新逻辑坏了

背景规模：

• 服务：推荐 feeds 流接口 /api/reco/feed，双机房合计日 PV 4.2 亿，单机 QPS 峰值约 9000
• 灰度策略：按 user_id % 100 的尾号段切 5%（尾号 00–04）走新召回链路，其余 95% 走旧链路
• 观测指标：接口 P99、feeds 点击率（CTR）、人均停留时长

事故窗口：周三 10:00 放量 5% → 20:00 回滚，共 10 小时。 灰度组读数：

• P99：灰度组 312ms vs 全量基线 99ms，虚高 215%
• CTR：灰度组 2.1% vs 全量 3.0%，掉 30%
• 人均停留：灰度组 41s vs 全量 68s

第一反应是「新召回链路有性能回归」，拉了 3 小时 trace，结果发现新链路单次调用耗时中位数只有 38ms，比旧链路 45ms 还快。指标对不上代码行为——这才是真正的坑。

二、根因：尾号分桶 ≠ 随机抽样

user_id % 100 在理想均匀注册下是随机的，但真实 uid 不是均匀发的：

1. 历史批次注册：我们 2019–2021 有三波大规模拉新，每波 uid 段是连续分配的，尾号分布呈现明显的「段聚集」。5% 桶（尾号 00–04）恰好落在一波「高活老用户 + 某地区运营商」的段里。
2. 高活用户天然 uid 小：早期用户 uid 小，尾号 00–04 段里高活用户占比是全局的 2.7 倍（拉了 user_active_days 分布验证）。高活用户请求频次高、并发高，单机连接池更容易打满，P99 被这批「重用户」拉高。
3. CTR 偏差：高活用户看 feeds 更挑剔，CTR 天然低——灰度组 CTR 掉 30% 其实是用户结构差异，不是新链路差。

一句话：你把「按尾号分桶」当成了「按概率随机」，但 uid 尾号和业务属性强相关，分桶等于按用户画像切了一刀。

三、具体做法：三件事把灰度做成「可比的」

1. 分桶键换掉 uid 尾号，改用哈希

# 旧：尾号分桶（有偏）
bucket = user_id % 100
in_gray = bucket in range(0, 5)   # 00-04

# 新：FNV-1a 哈希分桶（均匀且稳定）
def fnv1a(s: bytes) -> int:
    h = 0xcbf29ce484222325
    for b in s:
        h ^= b
        h = (h * 0x100000001b3) & 0xFFFFFFFFFFFFFFFF
    return h

bucket = fnv1a(f"{tenant}:{user_id}".encode()) % 100
in_gray = bucket < 5

判据：改完后跑一次「灰度桶 vs 全量」的 user_active_days 分布 KS 检验，p 值 > 0.05 才算均匀。我们改造后 p 值从 0.0001 提到 0.41。

2. 灰度指标必须「同用户对照」，不能跨桶比

跨桶比（灰度组 P99 vs 全量 P99）在用户结构不同时是无效比较。正确做法：

• 在灰度桶内部做 A/B：同一用户切 50% 请求走新链路、50% 走旧链路（用请求级灰度，不是用户级），对比同用户的新旧 P99；
• 或者用 DID（双重差分）：Δ灰度组 - Δ对照组，把用户结构差异当固定效应扣掉。

3. 放量节奏：5% → 20% → 50% 每一档都跑满 24h

我们原来 5% 只观察 4 小时就推 20%，结果 20% 档里正好覆盖到另一波「段聚集」用户，指标又跳了一次。每一档至少 24h，覆盖一个完整的高低峰周期，且每档之间要重新做均匀性检验——因为不同分桶键的均匀性不传递。

四、踩过的坑（反直觉）

• 坑 1：以为「% 100 取 5 个桶」就是随机 5%。错。uid 尾号是业务分配产物，不是随机数。任何「按主键尾号分桶」的方案，上线前必须做均匀性检验。
• 坑 2：灰度指标「看起来合理」就放心。P99 虚高 220% 这种数字，第一直觉是「新逻辑慢了 2 倍」，但实际是用户结构差异。指标数字合理 ≠ 结论合理，必须做同用户对照或 DID。
• 坑 3：放量越快越安全。我们 5%→20% 只隔 4 小时，结果 20% 档踩到另一波段聚集用户，指标再次跳变，团队已经对「新链路有问题」形成定势，差点直接全量回滚旧链路。放量节奏慢一档，反而省了一次误判。
• 坑 4：用 user_id % N 做灰度，但 user_id 是字符串。Java/Python 里字符串取模行为不一致，跨语言灰度桶对不上。统一用 fnv1a(字节串) 或 md5 取前 8 位 hex 再 mod，别用语言内置的 hash()（Python 的 hash() 每次启动随机化，直接翻车）。

五、结论与可复用清单

结论：灰度分桶的键决定了「谁进灰度」，而「谁进灰度」决定了「指标代表谁」。尾号分桶在真实业务里几乎必然有偏，把灰度桶当随机抽样去读指标，是这次 P99 虚高 220% 的真正根因——不是新链路慢，是灰度桶里装的人不对。

可复用清单（按优先级排）：

1. 分桶键用哈希，不用主键尾号：fnv1a(tenant + ":" + user_id) % 100，跨语言稳定、启动不随机化。
2. 上线前做均匀性检验：灰度桶 vs 全量的 user_active_days / region / device_os 三个维度跑 KS 检验，p 值 > 0.05 才放行。
3. 灰度指标用同用户对照或 DID，禁止跨桶直接比 P99/CTR。
4. 放量节奏每档 ≥24h，覆盖完整高低峰；每档之间重做均匀性检验（不同分桶键均匀性不传递）。
5. 灰度桶里打 X-Gray-Bucket 头，落审计日志，便于事后按桶切片对比。
6. 禁止用语言内置 hash() 做分桶键，统一 FNV-1a 或 MD5 前 8 位 hex。

一句话收口：灰度不是「切 5% 流量」，是「挑 5% 用户」；挑人的方式决定了你看到的指标是不是真的。