1、什么场景可以灰度
| 场景 | 原因 |
|---|---|
| 新功能上线 | 用户无感知，失败可快速回滚 |
| 性能优化/重构 | 验证实际负载下的稳定性 |
| 配置变更 | 影响范围可控，便于观察 |
| 依赖服务升级 | 隔离验证第三方兼容性 |
| UI/交互改版 | 收集用户反馈，降低舆情风险 |
| 数据库迁移/分库分表 | 双写阶段验证数据一致性 |
2、什么场景 绝对不能灰度
| 场景 | 风险 |
|---|---|
| 金融交易核心链路 | 资金损失不可逆，必须全量验证 |
| 安全补丁/漏洞修复 | 部分用户暴露漏洞 = 全体暴露 |
| 数据格式不兼容的变更 | 新旧版本数据互读会产生脏数 * 新版本对数据库做不可逆变更（删列、改字段类型、改数据含义） → 回滚极难 * 新老版本同时读写同一张表 → 格式不一致导致崩溃 |
| 涉及合规/审计的强制规则 | 法规要求100%生效，不能部分适用 |
| 基础设施层变更（如网络拓扑、K8s版本） | 底层故障会级联影响全量 |
| 单点架构无冗余的服务 | 灰度机器故障 = 该流量全损 |
3、灰度发布的硬性前提条件
-
可观测性：必须有完整的监控、日志、链路追踪，能实时发现异常
-
快速回滚能力：能在分钟级切回旧版本（建议 < 5分钟）
-
流量控制能力：能按用户ID、地域、设备、随机比例等维度精准切流
-
数据兼容性：新旧版本必须能同时读写共享数据（或已做好双写/影子库）
-
自动化测试覆盖：核心流程的自动化用例必须通过，灰度不是替代测试
4、关键操作要点
-
渐进节奏：1% → 5% → 20% → 50% → 100%，每步观察至少一个完整业务周期
-
影子验证：核心接口先跑影子流量（只记录不返回），确认无损后再切真实流量
-
熔断兜底：灰度实例异常比例超过阈值时，自动将流量降级到旧版本集群
-
用户隔离：避免同一用户的多次请求在新旧版本间来回跳转（导致状态不一致）
-
回滚优于修复：灰度阶段发现问题，第一时间回滚，而不是在线修复
5、灰度标准流程
需求自测 → 测试全量测 → 预发验证 → 线上小流量灰度 → 观测指标 → 逐步放量 → 平稳无异常 → 全量发布
6、原则
- 能灰度的：失败成本可控、数据无损、可秒级回滚、不影响合规底线的变更。
- 不能灰度的：涉及资金安全、安全漏洞、强制合规、数据不兼容、单点故障会扩散的变更。