流量渐进切换与金丝雀验证（特性开关、分阶段放量、Go/No-Go 决策、回滚预案）
基于特性开关/服务网格实施流量渐进切换：1%→5%→10%→25%→50%→100%，每阶段全维度验证，支持一键回滚
提示词
你是资深交付工程师/架构师。任务：指导基于特性开关/服务网格实施流量渐进切换，实现零停机、可观测、可回滚的生产发布。
约束：
- 遵循渐进式交付原则：
- 小步快跑：1%→5%→10%→25%→50%→100%
- 每阶段全维度验证（指标、日志、链路、业务指标、用户反馈）
- 明确 Go/No-Go 决策标准、决策人、观察窗口
- 一键回滚能力（特性开关/流量规则/数据回滚）
- 必须产出：
- 分阶段切换计划（流量比例、观察窗口、通过标准、决策人、补救措施）
- 金丝雀验证报告模板（关键指标、错误率、延迟分位、业务指标、用户反馈、告警记录）
- Go/No-Go 决策记录模板（通过/延期/回滚、决策人、理由、补救措施）
- 回滚预案（触发条件、执行步骤、回滚时间目标 RTO、验证步骤）
- 紧急熔断机制（自动/手动熔断条件、执行逻辑、通知机制）
- 支持：特性开关、服务网格流量规则、API 网关路由、DNS 切换
输出格式：
流量渐进切换执行手册:
切换计划:
金丝雀验证报告模板:
Go/No-Go 决策记录:
回滚预案:
紧急熔断机制:
少样本示例
展示完整流量切换手册：分阶段计划、金丝雀验证、Go/No-Go 决策、回滚预案、紧急熔断
输入
新版订单服务 v2.0 已通过 staging 验证，需从 v1.0 切换。SLA：可用性 99.99%、P99<200ms、错误率<0.1%。
输出
流量渐进切换执行手册：订单服务 v1.0 → v2.0:
切换计划:
| 阶段 | 流量比例 | 观察窗口 | 通过标准 | 决策人 | 补救措施 |
|---|---|---|---|---|---|
| 阶段1 | 1% | 30 min | 错误率<0.01%, P99<100ms, 业务指标无异常 | TL | 立即回滚 |
| 阶段2 | 5% | 1 h | 同前，无新增告警 | TL | 降至 1% |
| 阶段3 | 10% | 2 h | 同前，业务指标稳定 | Tech Lead | 降至 5% |
| 阶段4 | 25% | 4 h | 同前，无性能回退 | 架构师 | 降至 10% |
| 阶段5 | 50% | 8 h | 同前，高峰期通过 | 架构师+业务方 | 降至 25% |
| 阶段6 | 100% | 24 h | 全量稳定运行 | 架构师+业务方 | 回滚 v1 |
金丝雀验证报告模板:
关键指标:
| 指标 | 基线 | 目标 | 当前 | 状态 |
|---|---|---|---|---|
| 错误率 | 0.05% | <0.1% | 0.03% | ✅ |
| P99 延迟 | 150ms | <200ms | 180ms | ✅ |
| P99.9 延迟 | 300ms | <500ms | 450ms | ✅ |
| 吞吐量 | 1000 QPS | >1000 QPS | 1200 QPS | ✅ |
| CPU 使用率 | 45% | <70% | 52% | ✅ |
| 内存使用率 | 60% | <80% | 65% | ✅ |
业务指标:
| 指标 | 基线 | 当前 | 状态 |
|---|---|---|---|
| 下单成功率 | 99.95% | 99.96% | ✅ |
| 支付成功率 | 99.9% | 99.91% | ✅ |
| 退款成功率 | 99.5% | 99.5% | ✅ |
告警记录:
- 无新增 P0/P1 告警
- 无新增业务投诉
Go/No-Go 决策记录模板:
| 阶段 | 决策 | 决策人 | 理由 | 补救措施 |
|---|---|---|---|---|
| 1% → 5% | Go | TL | 指标全绿、无告警、业务指标稳定 | 无 |
| 5% → 10% | Go | Tech Lead | 1% 观察期无异常、性能基线达标 | 无 |
| 10% → 25% | 延期 | 架构师 | 发现 P99 偶发抖动，需观察 | 增加观察窗口 2h |
回滚预案:
触发条件:
- 错误率 > 0.5% 持续 5 分钟
- P99 延迟 > 500ms 持续 10 分钟
- 业务指标异常（下单成功率 < 99.5%）
- 关键依赖服务不可用
- 发现数据不一致/丢失
回滚执行步骤:
- 一键回滚：关闭特性开关
order_service_v2_enabled=false - 流量切回：服务网格流量规则 100% 切回 v1
- 数据校验：核对订单数据一致性、无丢单/重单
- 验证恢复：错误率恢复 < 0.01%、P99 < 200ms
- 通知相关方：发布回滚通知、记录原因
回滚时间目标:
- RTO (恢复时间目标): < 5 分钟
- RPO (恢复点目标): 0 数据丢失
紧急熔断机制:
- 自动熔断：错误率 > 1% 持续 1 分钟 → 自动触发回滚
- 手动熔断：On-call 可执行
kubectl rollout undo deployment/order-service - 通知机制：钉钉/飞书/短信/电话四级升级
紧急联系人:
| 角色 | 姓名 | 联系方式 | 升级顺序 |
|---|---|---|---|
| TL | 张三 | 钉钉/电话 | 1 |
| Tech Lead | 李四 | 钉钉/电话 | 2 |
| 架构师 | 王五 | 钉钉/电话 | 3 |
| 运维 | 赵六 | 电话 | 4 |