124 lines
4.6 KiB
Markdown
124 lines
4.6 KiB
Markdown
---
|
||
title: "Feature Flag (功能开关)"
|
||
tags: [devops, continuous-delivery, deployment, risk-mitigation, feature-management]
|
||
aliases: [Feature Flagging, Feature Toggle, Feature Switch]
|
||
created: 2026-04-25
|
||
---
|
||
|
||
# Feature Flag (功能开关)
|
||
|
||
**Feature Flag**（功能开关/功能标记）是一种将代码部署（Deploy）与功能发布（Release）解耦的技术机制。通过在代码中嵌入条件判断（开关），团队可以在不重新部署的情况下控制功能的可见性和行为。
|
||
|
||
## Aliases
|
||
- Feature Flagging
|
||
- Feature Toggle
|
||
- Feature Switch
|
||
- Kill Switch（紧急情况下的特殊用法）
|
||
|
||
## Core Mechanism
|
||
|
||
```javascript
|
||
if (featureFlag.enabled('new-checkout-flow')) {
|
||
return newCheckoutProcess();
|
||
} else {
|
||
return oldCheckoutProcess();
|
||
}
|
||
```
|
||
|
||
**关键洞察**：部署代码 ≠ 发布功能。代码可以在任何时间部署到生产环境，但功能发布由开关控制。
|
||
|
||
## Key Capabilities
|
||
|
||
### 1. Decoupled Deployment & Release
|
||
|
||
| 传统方式 | Feature Flag 方式 |
|
||
|----------|-------------------|
|
||
| 部署 = 发布 | 部署 ≠ 发布 |
|
||
| 2AM 部署"以防万一" | 随时部署，择机发布 |
|
||
| 全有或全无 | 灰度发布，渐进放量 |
|
||
|
||
### 2. Kill Switch（应急切断）
|
||
|
||
紧急情况下，无需重新部署即可关闭故障功能：
|
||
|
||
- 支付网关异常？切换到备用提供商（秒级）
|
||
- 搜索结果异常？回退到旧算法（秒级）
|
||
- AI 模型产生幻觉？切换回上一版本（秒级）
|
||
|
||
> "Instead of debugging under pressure while users suffer, you flip a switch and fix the problem properly later."
|
||
|
||
### 3. Progressive Rollout（渐进式放量）
|
||
|
||
分阶段向用户群发布功能，控制影响范围：
|
||
|
||
```
|
||
1% 用户 → 监控错误率、性能指标
|
||
5% 用户 → 监控转化率、用户反馈
|
||
25% 用户 → 检查下游系统负载
|
||
100% 用户 → 完成全量发布
|
||
```
|
||
|
||
如果 5% 阶段出现问题，RTO 以秒计（只需关闭开关），而不是小时级（需要紧急回滚部署）。
|
||
|
||
### 4. Micro-Recovery（Feature 级别微恢复）
|
||
|
||
不再将整个应用视为单一系统，不同功能有不同的风险和业务影响：
|
||
|
||
| 功能 | RTO 目标 | RPO 目标 |
|
||
|------|----------|----------|
|
||
| 核心支付处理 | 秒级 | 零丢失 |
|
||
| 新推荐引擎 | 5 分钟 | 15 分钟 |
|
||
| Beta 仪表盘功能 | 30 分钟 | 1 小时 |
|
||
|
||
### 5. 定向回滚（Targeted Rollback）
|
||
|
||
如果某个功能只影响欧洲移动用户，可以仅针对该用户群禁用该功能，其他用户不受影响。
|
||
|
||
## Feature Flag vs. 传统灾备
|
||
|
||
| 维度 | 传统灾备 | Feature Flag |
|
||
|------|----------|--------------|
|
||
| 目标故障类型 | 硬件故障 | 代码变更 |
|
||
| RTO | 小时级（从备份恢复） | 秒级（配置变更） |
|
||
| RPO | 取决于备份频率 | 近零（不触碰数据层） |
|
||
| 故障频率 | 低（年均几次） | 高（每周可能发生） |
|
||
| 成本 | 高（冗余基础设施） | 低（软件工具） |
|
||
|
||
## 商业案例数据
|
||
|
||
| 公司 | 改进前 | 改进后 |
|
||
|------|--------|--------|
|
||
| HP | 回滚时间：小时级 | 分钟级 |
|
||
| Christian Dior | 回滚时间：15 分钟 | 即时切换 |
|
||
| LaunchDarkly 客户 | — | 86% 在一天内恢复 |
|
||
| LaunchDarkly 客户 | — | 42% 在小时级（甚至分钟级）恢复 |
|
||
|
||
**成本效益**：59% 的 LaunchDarkly 客户表示运维成本降低 11%-50%，8% 表示降低超过 50%。
|
||
|
||
## 核心价值
|
||
|
||
> "Deploy with confidence, recover instantly, and focus on building features instead of fixing outages."
|
||
|
||
Feature Flag 将问题响应从**被动救火**转变为**主动预防**：
|
||
|
||
- **预防优于恢复**：在 1% 用户中发现问题，比全量发布后止损更有价值
|
||
- **减少焦虑**：部署不再可怕，随时可以回退
|
||
- **提高迭代速度**：团队敢于快速实验
|
||
|
||
## Related Concepts
|
||
|
||
- [[Kill Switch]] — Feature Flag 在紧急情况下的用法
|
||
- [[Progressive Rollout]] — Feature Flag 支持的渐进式放量策略
|
||
- [[Micro-Recovery]] — Feature Flag 实现的 feature 级别细粒度恢复
|
||
- [[Deployment-vs-Release]] — Feature Flag 实现的部署与发布解耦
|
||
- [[RTO]] — Feature Flag 将 RTO 从小时降至秒级
|
||
- [[RPO]] — Feature Flag 保护 RPO（不丢失数据）
|
||
- [[LaunchDarkly]] — Feature Flag 管理平台
|
||
- [[CI-CD-Pipeline]] — Feature Flag 是现代 CI/CD 的核心基础设施
|
||
|
||
## Sources
|
||
|
||
- [[sources/rto-vs-rpo-key-differences-for-modern-disaster-recovery.md]]
|
||
- [[sources/devops-culture-and-transformation-fostering-collaboration-agile-practices-and-innovation-linkedin.md]]
|
||
- [[sources/Deployment-Automation.md]]
|