Feature Flags（特性开关）的 DevOps 工程化：从暗发布到渐进式交付

问题一：代码合并 = 功能上线
  想偷偷灰度？不行——代码一发就全量可见

问题二：回滚要重新发布
  出问题要 redeploy，慢且影响面大

问题三：无法做渐进式验证
  要么全量，要么全关，看不到"小流量下表现如何"

特性开关的解法：
  功能由"代码"与"开关状态"共同决定
  → 代码可按时合并；开关可随时控制可见性
  → 发布决定"代码在不在"，开关决定"功能开不开"

- 暗发布：代码已上线但功能默认关闭，先验证
- 灰度放量：按用户/流量逐步打开
- 即时回滚：关开关即可秒级回退，不用 redeploy
- 团队并行：各团队合代码互不干扰，统一在开关层收敛

按生命周期/用途，特性开关大致分两类：

1. 发布开关（Toggle）
   控制新功能的发布进度（默认关→逐步开）
   例：resV2 / 新结算流程 / 推荐算法 v2

2. 运维开关（Kill Switch / 应急）
   线上应急：出问题一键关闭某能力
   例：drain-queue / stop-training / 临时降级

（另一大类是"实验开关"——A/B 实验用，往往跟实验平台耦合）

按可见性粒度：
  - 全量（100%）
  - 比例（1%、5%、10%…）
  - 白名单/灰名单（指定用户/租户/QPS）
  - 灰度组（canary 集群）

维度可叠加：
  先"比例 5%"，再按用户白名单放大，再全量

一个特性的完整生命周期：

  开发阶段
    │  写代码时用开关包裹新功能
    │  默认关闭（off）
    ▼
  CI/CD 阶段
    │  代码合并，功能"暗发布"（代码在、开关关）
    ▼
  发布放量
    │  逐步打开：5%→50%→100%（灰度）
    ▼
  稳定运行
    │  全量打开，持续观察指标
    ▼
  特性完成
    │  清理开关：代码删掉分支，移除开关定义
    ▼
  归档/删除
    │  完成一个：删代码分支 + 删开关 → 避免技术债

关键：开关从"创建 → 打开 → 全量 → 清理"是生命周期，
     不是"建了就不管"。清理（删除死开关）是降债关键一环。

不推荐：散落各处突发 if

  if (user in FLAGS["v2-cart"]) { ...新逻辑... }
  else { ...旧逻辑... }
  // 散落多处 → 难管理、难清理

推荐：集中在一个"开关服务/配置"里判断，返回真/假
  flags.get("v2-cart", user/租户/地理) -> true/false
  // 一处判断，多处消费

开关状态存哪里：
  - 配置文件（静态，重启生效）——简单但难动态
  - 配置中心（如 Nacos/etcd/apollo）——动态、集中
  - 专门 Feature Flag 平台（商业化/开源）——管理+规则+审计

线上环境选：动态生效 + 集中管理 + 无重启

代码先上线，功能默认关闭（开关 off）
  → 真实流量先"暗"着接受（验证不崩、不影响）
  → 不真正让用户看到新功能

用途：
  - 让数据层/后端逻辑先跑起来热身
  - 用真实流量验证新服务/新存储的稳定性
  - 为后面的灰度做"已上线验证"的准备

金丝雀（Canary）：
  只对"一小撮服务实例/节点"开放新版本
  → 缩减爆炸半径，数据只打在金丝雀节点上

灰度（按流量/用户渐开）：
   - 5% 用户 → 观察
   - 30% 用户 → 验证
   - 100% → 全量

两者可组合：
  复杂发布 = 金丝雀版本 + 灰度放量 + 开关兜底
  全部由开关控制 → 出问题关开关即回归

回滚的三种层面（耗时间少到多）：
  1. 关开关（秒级）——推荐：先关到"旧逻辑"
  2. 版本回滚（分钟级）
  3. 整服务重建（更大）

最佳实践：
  用"开关"做第一道回滚防线
  关键功能绝不把"全量重建"当作唯一的回滚手段

评估时机：
  - 请求进入时实时查开关（动态、开销略高）
  - 定时拉取本地缓存（性能好、略有延迟）
  - 变异（Webhook/Stream）即时更新

规则引擎（进阶）：
  - 支持条件和算子：user.id ∈ {…}、geo == zh、div%100 < 5
  - 支持多条件组合、覆盖与优先级
  - 让"放量规则"通过配置表达，而非改代码

{
  "flag": "cart-v2",
  "default": false,
  "rules": [
    { "if": { "user.geo": "CN" }, "then": false },
    { "if": { "rolloutPercent": 5 }, "then": true },
    { "then": false }
  ],
  "audit": { "lastChangedBy": "team-a", "time": "2026-09-27T10:00:00Z" }
}

部署策略：先更新配置→再打开开关（渐进式）

开关泛滥的风险：
  - 判断分支太多 → 代码可读性崩
  - 已上线功能的开关不清理 → 技术债累积
  - 新旧逻辑并存期拉长 → 逻辑膨胀、阅读困难

治理基本法：
  1. 开关必须登记（名字、负责人、创建时间、范围）
  2. 设有"默认值"，避免未定义时行为是猜的
  3. 定期清理：功能全量稳定后删代码 + 删开关
  4. 开关有唯一负责人，可被审计

清理开关（特性退役）：
  1. 确认功能全量且旧逻辑无依赖
  2. 代码里删掉所有该开关的 if/分支（只留新逻辑）
  3. 从开关平台移除该 flag + 相关规则
  4. 更新文档/登记表

不清理的代价：
  死代码 + 死配置 → 每次发布都在给后来者挖坑

- 通过开关控制实验流量 → 更清楚地对照指标差异
- 出问题时用开关快速隔离 → 让监控少报警
- 开关自身的变更要打审计日志（谁、何时、变成什么）

建议：
  - 每次切换开关都记录审计事件（变更人/时间/前后值）
  - 关键功能开关与监控联动：关闭告警里带上开关状态

发布流程里连上观测：
  - 打开前：记录基线指标
  - 开 5%：看错误率/延迟/核心转化
  - 逐步打开：每档停留观察，指标异常则停止放量
  - 全程可追：开关变更与指标快照都可回溯

□ 特性默认关：新功能对用户默认隐藏
□ 开关进登记：单一负责人 + 审计
□ 生命周期完整：创建→放量→全量→清理
□ 发布/上线解耦：代码≠上线，开关控制
□ 回滚先关开关：秒级回退不 redeploy
□ 比例/灰名单渐进放量：5%→30%→100%
□ 全量后清理：删分支 + 删 flag，控制债务
□ 空判默认：做好"开关失效/未知 flag"的兜底

特性开关 = "把发布 / 上线"解耦，
让代码可进、功能可控、故障可回退、演进可持续。