2 灰度发布与 A/B 测试的核心概念与术语

2.1 本章定位与 SOP 框架

本章并非标准执行步骤，而是建立统一术语体系，使后续所有角色（产品、开发、QA、运维、分析师）在灰度发布与 A/B 测试的流程中复用同一套语言。按流程 SOP 课程体例，以下从 适用场景 到 验收标准 逐一组织。

2.2 适用场景

• 新入职团队成员需要对齐灰度与 A/B 测试的基本概念。
• 项目启动前，评审委员会要求确认关键术语定义与度量标准。
• 跨职能协作时，使用同一套术语表避免歧义。
• 设计灰度/实验方案前，必须明确灰度策略、实验组/对照组、流量切割、指标与显著性五个核心要素。

2.3 前置条件

1. 读者已了解软件版本发布的基本流程（开发→测试→上线）。
2. 具备基础的统计学思维（均值、比例、置信区间）。
3. 熟悉至少一种云平台路由规则（如 Nginx / Kubernetes Ingress / API Gateway）。

2.4 核心概念一览

2.5 操作步骤（概念理解与交付流程）

1. 步骤 1：确认灰度策略模式
   • 输入：产品需求文档、版本发布计划。
   • 输出：选定的策略类型（Canary / Ramped / A/B 固定组）及其阶梯参数。
2. 步骤 2：定义实验组与对照组
   • 输入：流量切割规则（哈希键、分区数、排除条件）。
   • 输出：组标签映射表（group 1 = 实验, group 2 = 控制）。
3. 步骤 3：设计流量切割算法
   • 输入：用户标识（UID / 设备 ID）、切割比例（如 10%）。
   • 输出：路由配置（参见下方代码片段）。
4. 步骤 4：选择指标
   • 输入：业务目标（提升转化 / 降低错误率）。
   • 输出：一级指标（核心）、二级指标（辅助）、护栏指标（防止负面）。
5. 步骤 5：设定显著性阈值
   • 输入：样本量预估、期望效应量、显著性水平 α（默认 0.05）。
   • 输出：实验持续时间、最小可检测效应（MDE）。

-- 基于 UID 的哈希切割
local uid = ngx.var.cookie_uid
local hash = ngx.crc32_long(uid or "default")
local group = (hash % 100)
if group < 10 then
    -- 实验组（10%）
    ngx.var.upstream = "new_backend"
else
    -- 对照组（90%）
    ngx.var.upstream = "old_backend"
end

2.6 输入输出物清单

2.7 责任边界

• 产品经理：定义灰度目标、实验假设、选择指标。
• 开发 / 架构师：实现流量切割逻辑、版本隔离、路由配置。
• QA / 测试：验证切割比例准确、组间不泄露、埋点正确。
• 数据分析师：计算显著性、监控样本均衡性、撰写实验报告。
• 运维 / SRE：配置灰度策略的自动回滚触发器、监控异常指标。

2.8 记录材料

1. 《灰度实验注册表》：每次实验记录 ID、策略、组比例、起止时间。
2. 《流量切割审计日志》：记录每次路由变更的负责人、时间戳。
3. 《指标定义与数据血缘》：指标名称、SQL 查询、埋点事件名。
4. 《显著性判定记录》：样本量、所得 p 值、结论、决策理由。

2.9 异常处理

2.10 验收标准

• 所有团队成员能口头准确复述六项核心术语的定义与区别。
• 在实验设计评审中，能正确填写“灰度策略”、“实验组/对照组”、“流量切割比例”、“一级指标”、“显著性水平”字段。
• 路由配置上线后，通过日志抽样验证实际流量比例与配置偏差 < 0.5%。
• 任何一次实验报告都必须包含显著性 p 值及结论，否则视为无效实验。

2.11 核心概念关系图