Feature Flag + 金丝雀：用数据驱动上线与回滚

九月上线会员中心重构，我们把“功能开关 + 金丝雀发布”组合成一套稳定的上线流程。过程里踩过的坑、指标、SLO、回滚策略这里统一记录。

1. 体系搭建

Flag 平台：LaunchDarkly（SaaS）+ 内网代理；
金丝雀策略：按用户分群（10%→30%→70%→100%）；
SLO：
- API 错误率 < 0.5%
- 核心转化率（下单）下降不超过 3%
- 页面加载 P75 < 2.8s

2. Flag 设计原则

可枚举：Flag 名称 feature.membership.checkout_v2，语义清晰；
可配置：规则体支持属性、地理位置、版本号；
可回滚：默认值始终指向旧逻辑，发布失败只需 Toggle；
可审计：所有变更通过 PR + 平台审计日志记录。

代码层：

import { ldClient } from '../lib/ld'

export async function renderCheckout(user: User){
	const flag = await ldClient.variation('feature.membership.checkout_v2', user, false)
	if(flag){
		return renderNewCheckout(user)
	}
	return renderLegacyCheckout(user)
}

3. 金丝雀步骤

阶段	覆盖比例	时长	验证要点
Stage0	内部账号	0.5 天	验证基础功能、日志、监控
Stage1	10%	1 天	指标波动，客服反馈
Stage2	30%	1 天	核心转化率稳定，错误率无明显上升
Stage3	70%	1 天	压测/稳定性，观察边缘平台
Stage4	100%	-	观察 24h，最后清理旧逻辑

每一阶段都要求：

监控 Dashboard（Grafana）上指标正常；
Sentry 无新增严重告警；
数据团队验证业务指标；
产研共识后进入下一阶段。

4. 监控与告警

技术指标：请求量、错误率、响应时间。Prometheus + Alertmanager，规则示例：

expr: increase(http_requests_total{status=~"5..",feature="checkout_v2"}[5m])
			/
			increase(http_requests_total{feature="checkout_v2"}[5m]) > 0.005
for: 10m
labels:
	severity: critical

业务指标：数据团队用 dbt + Airflow 构建“日订购率”看板；
用户体验：埋点 SDK 上报 feature_id，配合体验团队做 NPS 调查；
灰度审计：保留 Feature Flag 变更记录，出现问题时可追责。

5. 回滚演练

上线前我们做了三次演练：

Flag Toggle 回滚：脚本一键关闭新功能，同时广播 Slack；
全量回滚：git revert + kubectl rollout undo；
数据回滚：针对订单表新增的字段，准备好清理脚本，并在预发布环境执行过一次。

上线当天真正遇到过一次“支付失败率升高”问题：Stage2 时支付接口超时，我们在 4 分钟内执行了 Flag Toggle，错误率回落，随后排查是第三方支付服务的限流。事件复盘后把支付接口也纳入金丝雀联动。

6. 成熟度模型

为了让新人快速上手，我们整理了一个成熟度表：

Level 1：已有 Feature Flag，但无监控/审计 → 不允许直接上生产；
Level 2：有监控 + Toggle 回滚 → 可以做小流量练手；
Level 3：有完整的金丝雀计划 + 演练记录 → 才允许大版本上线；
Level 4：自动化金丝雀（如 Kayenta）+ 自动暂停机制。

工程的价值是“可控”。Feature Flag 不是开关本身，而是把上线、监控、回滚、审计串成闭环。做完这套流程后，我们的迭代从“月级交付”变成了“周级交付”，心态也从焦虑转向自信。

琅琊苑