1. Feature Flag 灰度验证概述
1.1 Feature Flag 定义
Feature Flag（特性开关/功能标记）是一种软件技术，允许在运行时动态启用或禁用特定功能，而无需重新部署代码。在灰度验证场景中，Feature Flag 充当“流量阀门”，控制新功能对特定用户群体的可见性。
核心定义：Feature Flag 是一个存储在配置中心或代码中的布尔值/多值开关，通过运行时决策逻辑决定是否向请求者展示新功能。
| 维度 | 说明 | 典型实现 |
|---|---|---|
| 开关类型 | 布尔开关 / 多变量开关 / 百分比开关 | true/false、A/B/C 变体、0%~100% 流量比例 |
| 生效范围 | 用户 ID、IP 段、地域、设备类型、随机采样 | 一致性哈希、用户白名单、属性匹配 |
| 运行时决策 | SDK 本地缓存 + 远程配置中心实时推送 | LaunchDarkly、Unleash、自研配置中心 |
| 生命周期 | 开发 → 灰度 → 全量 → 清理 | Flag 命名规范 + 自动化清理脚本 |
1.2 灰度发布与 A/B 测试的区别
灰度发布和 A/B 测试虽然都使用 Feature Flag 控制流量，但目标、方法和评估标准有本质差异。混淆两者是导致 MTTR 复盘失真的常见原因。
| 对比维度 | 灰度发布（Canary Release） | A/B 测试（A/B Testing） |
|---|---|---|
| 核心目标 | 降低发布风险，快速回滚 | 验证假设，量化效果差异 |
| 流量分配 | 渐进式扩量：1% → 5% → 20% → 100% | 固定比例：50%/50% 或 90%/10% |
| 决策依据 | 错误率、延迟、资源水位、告警 | 转化率、点击率、留存率等业务指标 |
| 持续时间 | 分钟~小时级，尽快完成全量 | 天~周级，需收集统计显著样本 |
| 回滚策略 | 立即关闭 Flag，秒级生效 | 需保留实验数据，不能粗暴关闭 |
| MTTR 关注点 | 从发现异常到关闭 Flag 的时间 | 从实验启动到得出有效结论的时间 |
SRE 实践建议：灰度发布应使用“错误预算”作为扩量门禁——当灰度组的错误率超过基线组的 1.5 倍时，自动暂停扩量并触发回滚。A/B 测试则不应设置自动回滚，避免破坏实验随机性。
1.3 MTTR 在灰度中的重要性
MTTR（Mean Time to Recover，平均恢复时间）是灰度验证中最关键的 SLO 指标之一。在 Feature Flag 场景下，MTTR 特指从异常事件发生到灰度流量被完全切断（Flag 关闭或回滚）的时间间隔。
常见误区：很多团队将 MTTR 等同于“代码回滚时间”，但在灰度验证中，真正的恢复动作是“关闭 Feature Flag”，而非回滚代码。Flag 关闭通常在秒级完成，而代码回滚需要重新构建和部署，耗时数分钟到数十分钟。
灰度场景 MTTR 的组成阶段
- 检测时间（Detection Time）：从异常发生到监控系统发出告警。依赖可观测性覆盖度和告警灵敏度。
- 确认时间（Confirmation Time）：从收到告警到 SRE 确认异常由灰度功能引起。需要对比灰度组与基线组的指标差异。
- 决策时间（Decision Time）：从确认原因到决定关闭 Flag。涉及值班人员判断和升级流程。
- 执行时间（Execution Time）：从执行关闭操作到 Flag 生效。通常 < 5 秒，但受配置推送延迟影响。
| 阶段 | 典型耗时 | 优化方向 | 可观测性依赖 |
|---|---|---|---|
| 检测时间 | 30s ~ 3min | 缩短采集周期、多维度告警 | Metrics + Logs + Traces |
| 确认时间 | 1min ~ 5min | 灰度/基线自动对比面板 | 指标分组对比、错误率拆分 |
| 决策时间 | 30s ~ 2min | 预设回滚策略、自动化门禁 | Flag 变更审计、值班表 |
| 执行时间 | < 5s | 配置中心推送优化、本地缓存 | Flag 状态实时监控 |
| 总 MTTR | 2min ~ 10min | 目标：< 5min | 全链路可观测 |
MTTR 复盘口径定义：在 Feature Flag 灰度验证中，MTTR = (Flag 关闭时间 − 异常首次可观测时间)。异常首次可观测时间取以下三者中的最早值：① 告警触发时间；② 错误率突破基线阈值时间；③ 用户反馈上报时间。统一口径是跨团队复盘的基础。