一、A/B 测试是什么
在同一时间窗口里，将用户随机分到两个（或多个）版本中，对比核心指标的差异，以判断新方案是否优于旧方案。
- A：对照组（现有版本）
- B：实验组（改动版本，可能有多个：B1/B2/…）
核心是“随机、并行、可量化”。
二、为什么要做
- 隔离因果：排除季节、活动、流量波动等外因，尽量把指标变化归因于“版本差异”。
- 降低试错成本：小规模验证有效再全面上线。
- 量化优化：以数据为依据迭代产品、算法、运营策略。
三、能测什么
- 转化类：注册率、下单率、付费率、续费率、激活率。
- 留存类：1/7/30 日留存、次日回访。
- 效率类：页面加载时延、客服处理时长。
- 收益类：ARPU、客单价、毛利率。
- 行为路径类：点击率、加购率、完成漏斗比例。
四、正确的实验设计（步骤+要点）
- 明确目标与假设
- 业务目标：例如“提升新客下单率 +5%”。
- 统计假设：H0（无差异） vs H1（有差异）。
- 指标选择：一个核心指标（主指标），若干监控指标（不作为是否上线的唯一依据）。
- 定义受试人群与分流
- 分桶：随机且独立，常用 50/50；多版本时均衡或按最小可检出效应分配。
- 粒度：用户级（最常见）、设备级或会话级，一致性哈希确保同一用户始终进同一组。
- 污染控制：避免跨组曝光（例如同账号多端登录造成串组）。
- 预估样本量与实验时长
- 需要输入：基线转化率 p₀、期望最小可检出差异 MDE、显著性水平 α（常 0.05）、检验功效 1-β（常 0.8）。
- 二项指标近似样本量公式（双侧）：
- 时长：结合日活/曝光量推回持续天数；建议覆盖完整周周期以平滑周内波动。
- 冷启动与清洗规则
- 预热期：前 1–2 天仅采集不判定，等系统缓存/索引/模型稳定。
- 数据过滤：剔除异常流量、内测账号、爬虫、超短会话等。
- 监控与止损
- Guardrail 指标：如崩溃率、时延、退款率。出现恶化触发自动回滚。
- 统一埋点：事件定义、时序、去重、时区一致。
五、如何统计检验（频率学派常见做法）
以“转化率”为例：
- 比例差 Z 检验或卡方检验：比较 pA 与 pB。
- 平均值（如时长/金额）：独立样本 t 检验（不等方差时用 Welch t）。
- 置信区间：给出差值 CI，若不含 0 则显著。
- 多版本/多指标：控制家族错误率（Bonferroni、Holm）或控制 FDR（Benjamini–Hochberg）。
- 赛马式上线：先显著优胜再全量。
六、Bayesian（贝叶斯）方式（简述）
- 直观输出：P(B 优于 A) 及差值的后验分布/置信区间（后验区间）。
- 适合连续监控与“随看随判”，但需事先设定停止规则和阈值（如 P>0.95 上线）。
七、序贯与提早停止
- 频率学派中途多次看数会“膨胀”Ⅰ类错误（假阳性）。
- 解决：Group Sequential（O’Brien–Fleming、Pocock）或 Alpha Spending。
- 简化方案：固定样本量、到点再判；或使用经过校正的序贯设计工具。
八、效应度量与业务解释
- 绝对提升（pp，percentage points）：pB − pA。
- 相对提升（%）：(pB − pA) / pA。
- 实际价值：结合样本量 × 提升 × 利润/成本，评估年化收益。
- 异质性分析：按渠道、地区、端型、新老客分层看一致性。
九、常见坑（踩雷清单）
- 未随机或串桶：同一用户在 A/B 来回跳，导致污染。
- MDE 过小：样本量不足，假阴性多；或过早停止导致假阳性。
- 指标“追涨杀跌”：中途看见抖动就下结论。
- 选择偏差：只在“容易转化”的页面开实验，外推失真。
- 多重比较未校正：试了很多版本，挑一个“显著”的。
- 数据口径不一：埋点延迟、去重不当、跨时区导致错判。
- 季节/活动干扰：大促期跑与常态期上线不一致。
- 漏斗错觉：上游点击率升高但下游下单率下降，被“虚高”迷惑。
- Simpson 悖论：整体提升但分组下降（或反之），需分层验证。
- 与推荐/竞价系统耦合：被动态出价、流量分配策略掩盖真实效应。
十、进阶技巧
- 固定用户实验（Holdout）：保留一小撮用户永远不受新策略影响，用于长期增益评估。
- CUPED：协变量调整（如历史转化/GMV）降低方差、缩短时长。
- 倾向得分/回归调整：缓解轻微不平衡，提升估计精度。
- 多臂老虎机（Bandit）：在线探索-利用，逐步把流量倾向更优版本（适合收益实时最大化场景，但因果解释弱）。
- 互斥实验层（Mutually Exclusive Layers）：避免多个实验在同一用户上互相干扰。
- 功效（Power）回顾：事后计算观测效应下实验的检验力，评估结论稳健性。
- 准实验：无法 A/B 时可用断点回归、差分中的差分（DiD）等方法。
十一、一个极简算例
- 基线转化率 p₀=10%，你希望检测到相对 +5% 的提升（MDE=0.5pp）。
- 取 α=0.05、功效 80%。带入样本量公式，得到每组需要约 n≈150k（数量级示例，实际请用专业计算器/仿真）。
- 实验跑满一周，Z 检验得到差值 0.7pp，95% CI 为 [0.2pp, 1.2pp]，不含 0，显著。
- 业务折算：每百万 UV 多 7,000 单，结合客单价和毛利估算年化收益，再决定全量上线与否。
十二、落地清单（可直接用）
- 定目标与主指标（写清口径与单位）。
- 设分桶与一致性哈希（用户级），避免跨组曝光。
- 选 α、功效、MDE → 计算样本量与时长。
- 定数据清洗、预热期与 Guardrail。
- 实验期间不随意改代码/改分流；如需热修复，记录版本。
- 用一次性检验或有校正的序贯框架判定；输出效应、置信区间、功效。
- 做分层一致性与长期观察（Holdout/留存/利润）。
- 归档：方案、数据、脚本、结论、上线决策与复盘。
一、灰度测试是什么
灰度测试是在小流量、分阶段地把新版本发布给真实用户，在每个阶段观察关键指标与风险信号，达标则扩大比例，不达标立即回滚。核心目标是：把线上变更的风险“切小、切慢、可控”。
二、能解决什么问题
- 降风险：把“全量失败一次”变成“少量失败可回滚多次”
- 快反馈：真实流量、真实依赖链（缓存、网关、下游服务）
- 可观察：阶段性门槛（SLO/SLA）把技术与业务风险量化
三、和 A/B 测试的区别
- 目的不同：A/B 为了验证“哪个版本更好”（因果推断）；灰度为了安全上线（风险控制）
- 分流策略：A/B 强随机、两组长期并行；灰度按时间和比例逐级放量，最终全量
- 判定标准：A/B 用显著性检验/置信区间；灰度以阈值门槛（错误率、时延、崩溃率、业务跌幅）为主
四、典型适用场景
- 后端服务/网关升级、配置切换
- 前端重大重构（先对少量用户/渠道放量）
- 移动端上架“分阶段发布”（先 1% 市场）
- 算法/推荐策略更新但优先保证稳定性
- 数据库变更（expand–migrate–contract）期间的兼容观察
五、灰度分层（几种常用方式）
- 按用户 ID 哈希：稳定分流、避免跨组抖动
- 按渠道/地区/租户：先“内网—员工—友好客户—新客—全量”
- 按实例/节点：先 1 台/1 个 Pod 再扩
- 按请求特征：仅特定路径、特定功能入口
- 影子流量（shadow）：只回放请求到新版本，不返回结果给用户（0% 风险预演）
六、指标与门槛（Guardrails）
技术类（SLO）：
- 错误率（5xx/4xx）、超时率、P95/P99 时延、CPU/内存/GC、队列积压
业务类： - 转化率/下单率/DAU、崩溃率（移动端）、退款率、告警量
门槛例：与基线对比“相对劣化 ≤ 2%”，或“5xx ≤ 0.3%，P95 ≤ 400ms”。任何一项越线 → 自动回滚。
七、标准灰度流程（可直接套用）
- 准备
- 开关：Feature Flag / 配置中心 / 按版本路由（service mesh）
- 监控：埋点统一口径，技术+业务双看板；告警策略写清
- 回滚预案：一键回滚脚本、回滚不触发二次变更（数据库兼容）
- 基线与预演
- 预热：影子流量或 0.1% 内部账号先行
- 基线：近 7 天的指标均值与波动区间
- 放量节奏（示例）
- 1% → 5% → 10% → 20% → 50% → 100%
- 每个阶段观测 ≥ 30–60 分钟（或 ≥ N 次请求 / ≥ N 活跃用户），达标再晋级
- 自动化判定
- 金丝雀分析（Canary Analysis）：把新旧版本指标做对比评分（加权技术/业务项）
- 达标阈值（如 Score ≥ 90）→ 自动升档；否则自动回滚并冻结
- 收尾与复盘
- 留存的兼容开关、兼容代码按计划清理
- 记录：变更单、指标、故障与处置、经验库沉淀
八、数据库/兼容性特别注意
- 双写/双读：先写新旧两套结构，读仍走旧，确认一致性后切读新
- 不可逆变更：先“扩展字段/新索引”上线并稳定，再切流，再“收缩/删除旧结构”
- 幂等与回放：保障重试与回滚不造成重复扣费/重复下单
九、常见坑（避坑清单）
- 粘性会话/缓存未隔离：用户在不同实例看到不同版本
- 指标口径不一致：新旧埋点差异导致“假波动”
- 多实验互相干扰：缺“互斥层”（同一用户叠加多个灰度）
- 放量过快：未覆盖峰值时段即全量，上线后才暴露问题
- 只看技术不看业务：时延 OK，但转化跌了没发现
- 回滚失败：数据库已做不可逆 DDL；或配置/脚本欠缺原子性
- CDN/前端缓存：老资源与新接口不匹配，引发 JS 报错
十、工具与落地选型（思路）
- 开关：Unleash / LaunchDarkly / 自建 Feature Flag
- 服务网格/金丝雀：Istio + Flagger、Argo Rollouts（按权重路由、自动晋级/回滚）
- 可观测：Prometheus + Grafana / DataDog / New Relic；日志聚合 + 分布式追踪
- 移动端分阶段发布：Google Play “staged rollout”、App Store Phased Release
十一、灰度策略模板（示例）
策略名：支付服务 v3 灰度
分流：用户级哈希，初始 1%，目标 100%
晋级门槛（每档至少 45 分钟、≥ 2 万请求）：
- 5xx ≤ 0.3%，相对基线劣化 ≤ 2%
- P95 时延 ≤ 400ms，劣化 ≤ 5%
- 业务下单成功率劣化 ≤ 1%
回滚条件：任一项越线或连续 5 分钟告警触发
节奏：1%/5%/10%/20%/50%/100%，夜高峰前至少完成到 20% 并观察一轮
特别事项：DB 先双写 24 小时；灰度期间禁止合并其他高风险改动
十二、给不同形态的快速建议
- 后端服务：优先用网格/网关按权重路由，配合自动金丝雀分析
- Web 前端：HTML/JS/CSS 版本与接口版本绑定，强制版本校验；静态资源走“版本号+强缓存”
- 移动端：后端灰度+客户端分阶段上架；必要时后端可通过 Feature Flag 针对老版本降级