2. 灰度试运行目标设定
灰度试运行不是简单的“放量测试”，而是一次有明确度量边界的工程实验。目标设定决定了灰度期间收集什么数据、如何判断成败、以及是否触发回滚。本章从业务目标、技术目标、SLO/SLI 定义三个层次展开，确保灰度试运行可量化、可对比、可复盘。
2.1 业务目标：转化率与错误率
业务目标是灰度试运行的“北极星”，直接反映新版本对用户核心行为的影响。在灰度期间，必须同时观测实验组（新版本）与对照组（旧版本）的业务指标，通过差异判断版本是否正向。
| 业务指标 | 定义 | 灰度目标示例 | 回滚阈值 |
|---|---|---|---|
| 转化率 | 完成核心目标（下单/注册/播放）的用户占比 | 实验组转化率 ≥ 对照组 * 1.01 | 实验组转化率 ≤ 对照组 * 0.95 |
| 业务错误率 | 用户触发业务异常（支付失败/白屏/超时）的比例 | 实验组错误率 ≤ 对照组 * 1.05 | 实验组错误率 ≥ 对照组 * 1.20 |
| 用户留存 | 灰度次日/7日留存率 | 实验组留存率 ≥ 对照组 * 0.98 | 实验组留存率 ≤ 对照组 * 0.90 |
实践建议：业务目标必须与产品/运营对齐，避免“技术达标但业务不买账”。灰度期间建议每日拉取业务漏斗数据，一旦触及回滚阈值立即暂停放量。
2.2 技术目标：延迟与资源消耗
技术目标保障灰度期间系统稳定性与成本可控。延迟反映用户体验，资源消耗反映基础设施压力。技术目标通常以 P99/P95 延迟和 CPU/内存增量作为核心观测点。
- 延迟目标：
- P99 延迟 ≤ 基线版本 * 1.10（允许 10% 退化）
- P50 延迟 ≤ 基线版本 * 1.05（核心路径必须稳定）
- 长尾请求（>5s）占比 ≤ 0.1%
- 资源消耗目标：
- CPU 平均使用率增量 ≤ 基线版本 * 1.15
- 内存 RSS 增量 ≤ 基线版本 * 1.10
- 网络出口带宽增量 ≤ 基线版本 * 1.20
- 可用性目标：
- 灰度集群可用性 ≥ 99.9%（排除计划内运维窗口）
- 无 P0/P1 级故障发生
关键原则：技术目标不是“越低越好”，而是“可接受退化范围内稳定”。过度追求零退化会导致灰度周期拉长、版本迭代变慢。建议设置“黄线（预警）”和“红线（回滚）”两级阈值。
2.3 SLO/SLI 定义与对齐
SLO（Service Level Objective）是灰度试运行的“服务等级承诺”，SLI（Service Level Indicator）是具体度量指标。灰度期间必须将业务目标和技术目标映射为可计算的 SLI，并设定 SLO 窗口。
2.4 SLI 采集与 SLO 计算规则
SLI 采集必须覆盖灰度全链路，避免数据盲区。以下为推荐采集方案与 SLO 计算公式：
| SLI 名称 | 数据源 | 采集粒度 | SLO 计算公式 |
|---|---|---|---|
| 转化率 SLI | 埋点事件 / 订单系统 | 5 min | 成功转化数 ÷ 总请求数 ≥ 0.99 |
| P99 延迟 SLI | APM / 链路追踪 | 1 min | P99 ≤ 2000ms 占比 ≥ 99.5% |
| 错误率 SLI | 网关日志 / 服务端错误码 | 1 min | 5xx 错误数 ÷ 总请求数 ≤ 0.001 |
| CPU 增量 SLI | 容器监控 / 云监控 | 1 min | 灰度实例 CPU 均值 ≤ 基线 * 1.15 |
⚠️ 常见陷阱：
- SLI 与业务脱节：只关注技术延迟，忽略转化率下降，导致灰度通过后业务受损。
- SLO 窗口过短：使用 1 小时窗口，因流量毛刺频繁触发回滚，灰度无法推进。
- 对照组缺失：未保留旧版本基线数据，无法判断退化是版本问题还是环境波动。
2.5 灰度目标设定检查清单
在灰度启动前，使用以下清单逐项确认目标设定完整性：
- 业务目标：是否定义了至少 1 个核心转化指标？是否设置了回滚阈值？
- 技术目标：是否覆盖延迟、资源、可用性三个维度？P99 和 P50 是否分开设定？
- SLO/SLI：每个 SLI 是否有明确的数据源和采集粒度？SLO 窗口是否合理（推荐 7 天滚动）？
- 基线对齐：对照组是否与实验组共享相同的流量入口？基线数据是否已提前采集 24 小时以上？
- 告警联动：SLO 未达标是否自动触发回滚流程？告警通知是否覆盖值班 SRE 和业务负责人？
复盘要点：灰度试运行结束后，需对比实际 SLI 与预设 SLO 的偏差，分析是目标设定过严/过松，还是版本本身存在缺陷。目标设定的合理性直接影响灰度决策的置信度。