4 Types of Feature Flags and When to Use Them

4 种 Feature Flag 与使用时机

@ 技术讨论

前言

先前探讨到：什么是 Feature Flag 以及它解决什么问题？ ，了解 Feature Flag 存在的价值后，今天了解更多关于 4 种类型的 Feature Flag 以及实战上的用途，不同目的的 Flag，在生命周期、动态程度与管理策略上都有不同的特性。

Feature Flag 的 2 个维度

Feature Flag 可以被 2 个维度所分类：「存在时长」与「动态性」。

  • 存在时长：
    • 短期：通常目的是过渡，如功能释出或实验。
    • 长期：往往成为产品设计的一部分。
  • 动态性：
    • 低动态：值通常固定，极少在运行期间改变。
    • 高动态：值会频繁变化，可能依据使用者、请求、环境即时决定。

四个象限分类出不同用途的 Feature Flag：

                    高動態
                      ↑
                      │
      Experiment      │      Permissioning
      Flags           │      Flags
                      │
──────────────────────┼────────────────────→ 存在時長
                      │
      Release         │      Ops
      Flags           │      Flags
                      │
                      ↓
                    低動態

Feature Flag 的 4 个象限

短期 × 低动态 → Release Flags

设定明确移除期限，在功能完全释出后应尽快移除

在 Trunk Based Development🔗 不使用分支而是使用 Feature Flag 来实现「代码部署与功能发布的脱钩」，透过解耦部署与发布保持开发效率。

  • 渐进发布：先部署代码但不启用功能，等准备好再打开开关
  • 金丝雀发布：先对小部分用户开放新功能，观察稳定性
  • 快速回滚：如果新功能出问题，可以立即关闭开关而不需要重新部署
  • 解耦部署与发布：让代码部署和功能上线成为两个独立的动作

短期 × 高动态 → Experiment Flags

为了收集数据做出决策而实验，实验结束一定要根据结论收敛
  • A/B 测试：比较不同版本的 UI、算法或功能，看哪个表现更好
  • 用户分群实验：动态针对不同用户群体测试不同策略

长期 × 高动态 → Permissioning Flags

设计清晰的权限模型，避免与实验混用

用户的权限、订阅状态、特征属性会频繁变化，需要即时反应：

  • 实验权限：早期采用者计划、内部员工测试功能
  • 地理位置限制：某些功能只在特定国家/地区开放、当地法规要求
  • 不同族群：管理员 vs 普通用户、免费 vs 付费功能

长期 × 低动态 → Ops Flags

可靠性与可观测性
  • 防御性回退：流量高峰时关闭非核心功能、降低资源密集型操作的频率、启用快取机制或简化版功能
  • 维护模式：资料库维护时切换为唯读模式、系统升级时显示维护页面、暂时关闭某些服务端点
  • 特殊情境：在特定时段启用额外的监控或日志记录

延伸閱讀