zhaoxuya520 发布策略（Release Strategy）
参考来源：Weaveworks Progressive Delivery、Argo Rollouts、Flagger、LaunchDarkly Feature Flags、Google SRE Release Engineering。
适用场景
- 生产发布方案设计
- 灰度 / 蓝绿 / 金丝雀选型
- 回滚方案设计
- Feature Flag 管理
- 数据库迁移与代码发布协调
- 多环境发布流程
核心原则
1. 渐进式发布（Progressive Delivery）
不一次性全量，逐步放量
2. 可观测驱动
每个阶段看指标再决定继续 / 回滚
3. 回滚 < 5 分钟
任何发布都必须能快速回滚
4. 代码与配置分离
Feature Flag 控制功能开关
5. 数据库先于代码
Schema 兼容变更先上，代码后上
6. 自动化优先
人工审批可以有，但执行必须自动
发布策略对比
| 策略 | 停机 | 风险 | 复杂度 | 适合 |
|---|---|---|---|---|
| 滚动更新 | 无 | 中 | 低 | K8s 默认 |
| 蓝绿部署 | 无 | 低 | 中 | 快速切换 |
| 金丝雀 | 无 | 极低 | 高 | 核心服务 |
| 灰度（百分比） | 无 | 低 | 中 | 用户级控制 |
| Feature Flag | 无 | 极低 | 中 | 功能级控制 |
| 大爆炸 | 可能 | 高 | 低 | 内部工具 |
滚动更新（Rolling Update）
# K8s 默认策略
spec:
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 25% # 最多多 25% Pod
maxUnavailable: 25% # 最多少 25% Pod
流程：
旧 Pod: [A] [A] [A] [A]
→ 新建 1 个新 Pod: [A] [A] [A] [A] [B]
→ 删 1 个旧 Pod: [A] [A] [A] [B]
→ 新建 1 个新 Pod: [A] [A] [A] [B] [B]
→ ...
→ 全部替换: [B] [B] [B] [B]
优点：零停机、简单
缺点：新旧版本共存期间可能不兼容
蓝绿部署（Blue-Green）
流程：
1. 当前生产（Blue）正常运行
2. 部署新版本到 Green 环境
3. 验证 Green（健康检查 + 冒烟测试）
4. 切换流量：Blue → Green
5. 观察 Green
6. 确认无问题后销毁 Blue
7. 出问题：切回 Blue（秒级）
优点：切换快、回滚快
缺点：需要双倍资源
# K8s 蓝绿（用 Service selector 切换）
apiVersion: v1
kind: Service
metadata:
name: my-app
spec:
selector:
app: my-app
version: green # 切换时改为 blue
金丝雀（Canary）
流程：
1. 部署新版本到 1 个 Pod（5% 流量）
2. 监控 5 分钟（错误率 / P99）
3. 指标正常 → 扩到 50%
4. 监控 10 分钟
5. 指标正常 → 100%
6. 指标异常 → 自动回滚到 0%
工具：
- Argo Rollouts
- Flagger
- Istio + 流量分配
# Argo Rollouts 金丝雀
apiVersion: argoproj.io/v1alpha1
kind: Rollout
spec:
strategy:
canary:
steps:
- setWeight: 5
- pause: { duration: 5m }
- setWeight: 50
- pause: { duration: 10m }
- setWeight: 100
analysis:
templates:
- templateName: success-rate
startingStep: 1
Feature Flag
用途：
- 功能开关（不发版就能开关功能）
- 灰度（按用户 / 租户 / 百分比）
- A/B 测试
- Kill Switch（紧急关闭）
工具：
- LaunchDarkly（SaaS）
- Unleash（开源）
- Flagsmith（开源）
- GrowthBook（开源 + A/B）
- 自建（Redis + 配置）
代码示例：
if (featureFlags.isEnabled('new-checkout', { userId })) {
return <NewCheckout />;
}
return <OldCheckout />;
回滚方案
三层回滚
1. 代码回滚（最快，< 1 min）
- K8s: kubectl rollout undo
- Vercel: 一键回滚
- Docker: 切回旧镜像 tag
2. 配置回滚（< 5 min）
- Feature Flag 关闭
- 环境变量回退
- ConfigMap 回退
3. 数据回滚（最慢，分钟~小时）
- 数据库 PITR
- 备份恢复
- 补偿脚本
回滚触发条件
自动回滚（推荐）：
- 错误率 > 5% 持续 2 分钟
- P99 > 2x 基线持续 5 分钟
- 健康检查失败 > 3 次
手动回滚：
- 业务指标异常（订单数骤降）
- 用户投诉激增
- 安全漏洞发现
K8s 回滚
# 查看历史
kubectl rollout history deployment/my-app
# 回滚到上一版本
kubectl rollout undo deployment/my-app
# 回滚到指定版本
kubectl rollout undo deployment/my-app --to-revision=3
# 查看状态
kubectl rollout status deployment/my-app
发布流程模板
1. 代码合并到 main
↓
2. CI 跑通（lint + test + build + scan）
↓
3. 构建镜像（tag = git sha）
↓
4. 部署到 staging
↓
5. staging 验证（自动 + 手动）
↓
6. 审批（如需）
↓
7. 部署到 production（金丝雀 5%）
↓
8. 监控 5 分钟
↓
9. 扩到 50% → 监控 10 分钟
↓
10. 扩到 100%
↓
11. 观察 1 小时
↓
12. 完成（或回滚）
数据库与代码协调
原则：Schema 变更先于代码变更
发布顺序：
1. 数据库兼容变更（Expand）
2. 部署新代码（读写新字段）
3. 回填数据
4. 数据库清理变更（Contract）
详见 database-engineer/migration-rollout skill
配套模板
templates/release-plan-template.md— 发布计划 + 策略 + 回滚 + 监控
质量自检
□ 发布策略选定（滚动 / 蓝绿 / 金丝雀）
□ 回滚方案可执行（< 5 min）
□ 回滚触发条件明确
□ 监控指标覆盖
□ staging 验证通过
□ 数据库变更先于代码
□ Feature Flag（如需）
□ 审批流程（如需）
□ 发布后观察期
□ 文档化（发布手册）
常见坑
- 没有回滚方案——故障时慌
- 全量发布——一次性影响所有用户
- 不监控就放量——问题扩散
- 代码先于数据库——新代码读不到新字段
- 回滚太慢——> 30 分钟
- Feature Flag 不清理——代码里一堆 if/else
- staging 跳过——生产才发现
- 镜像 tag 用 latest——不知道回滚到哪个版本
- 不自动化——手动部署出错
- 告警不配——发布后出问题不知道
与其他 skill 的协作
上游：
ci-cd-pipeline → 构建产物
containerization → 镜像
kubernetes-orchestration → 部署目标
下游：
monitoring-alerting → 发布后监控
sre-operations 工作流 → 事故响应
database-engineer → 迁移协调