📚 课程目录第4章蓝绿发布故障场景分类

4. 蓝绿发布故障场景分类：发布失败、流量切换异常、数据不一致、监控告警缺失、回滚失败

蓝绿发布虽然提供了零停机部署的架构能力，但在实际生产环境中，故障往往发生在流程衔接的薄弱环节。根据对数百起生产事故的复盘统计，蓝绿发布故障可归纳为五大核心场景。理解这些场景的根因与表现，是设计MTTR口径与可观测性指标的前提。

  核心观点： 蓝绿发布故障不是单一技术问题，而是“变更-流量-数据-观测-回退”五维风险的连锁反应。任何一维的失效，都会导致发布失败或业务受损。

4.1 故障场景全景图

下图展示了五大故障场景在蓝绿发布流程中的分布位置与相互影响关系。每个场景对应一个关键阶段，且可能触发下游场景的级联故障。

4.2 场景一：发布失败

发布失败是蓝绿发布中最常见的故障类型，通常发生在新版本（Green）环境启动阶段。根据故障发生的位置，可细分为以下子类：

子类	典型根因	影响范围	MTTR 关键环节
镜像/制品拉取失败	镜像仓库鉴权过期、镜像标签不存在、网络限速	单节点 → 全集群	镜像缓存预热、回退至旧版本
配置注入错误	ConfigMap/Secret 版本不匹配、环境变量缺失	全量实例	配置校验、快速回滚
启动探针/就绪探针失败	依赖服务未就绪、健康检查路径变更	部分实例 → 全量	探针超时调整、依赖降级
资源配额不足	CPU/内存 Limit 设置过小、节点资源碎片化	调度失败实例	资源预留、HPA 预扩缩

可观测性建议： 在发布阶段应重点监控 PodStartupDuration、ImagePullErrorCount、ReadinessProbeFailureRate 三个指标。当就绪探针失败率超过 20% 时，应自动暂停发布并触发告警。

4.3 场景二：流量切换异常

流量切换是蓝绿发布的核心操作，也是故障高发区。切换异常通常表现为流量未按预期路由、部分用户无法访问、或新旧版本同时接收流量导致业务混乱。

网关路由未生效： 负载均衡器（如 Nginx、Envoy、ALB）配置未刷新，导致流量仍指向旧版本。典型表现为切换后旧版本 QPS 未下降。
会话粘连（Session Stickiness）： 用户会话被持久化绑定到旧版本实例，切换后新版本无法承接已有会话，导致登录态丢失或请求超时。
权重分配错误： 灰度切换时权重比例配置错误（如 100% 切至新版本但实际只切了 10%），造成流量雪崩或资源闲置。
DNS 缓存滞后： 使用 DNS 做流量切换时，TTL 设置过长导致客户端仍解析到旧 IP，切换生效延迟可达数分钟。

避坑指南： 流量切换异常往往在“切换后 30 秒内”暴露。建议在切换脚本中嵌入自动化验证步骤：切换后立即对比新旧版本的 QPS 变化率，若新版本 QPS 增长低于预期阈值的 80%，则自动触发回滚。

4.4 场景三：数据不一致

数据不一致是蓝绿发布中最隐蔽、恢复成本最高的故障。由于新旧版本可能同时操作同一数据源，或数据库 Schema 变更不兼容，导致数据损坏或丢失。

子类型	根因描述	检测手段	恢复策略
Schema 不兼容	新版本新增字段/修改索引，旧版本无法识别	数据库迁移预检查、Schema 版本比对	前向兼容设计、分阶段迁移
缓存双写冲突	新旧版本同时写入 Redis，导致缓存数据错乱	缓存 key 前缀隔离、版本号标记	切换前清空缓存、使用双写代理
消息队列重复消费	切换过程中消费者组偏移量重置，导致消息重复	消息去重 ID、消费位点监控	幂等消费、手动提交偏移量
异步任务状态丢失	旧版本提交的异步任务在新版本中状态丢失	任务状态表持久化、分布式锁	任务重试机制、状态补偿

4.5 场景四：监控告警缺失

监控告警缺失本身不直接导致业务故障，但它会显著延长故障发现时间（TTD），使其他四类故障的 MTTR 成倍增加。这是可观测性体系中最需要优先解决的“元问题”。

指标未覆盖新版本： 新版本暴露了新的 metric 名称或端口，但监控系统仍按旧版本配置采集，导致新版本指标全为空。
告警阈值未调整： 新版本的性能基线发生变化（如 P99 延迟从 100ms 变为 200ms），旧阈值导致大量误告警或漏告警。
日志采集中断： 新版本日志路径变更或日志格式调整，导致日志采集器无法解析，排障时无日志可查。
链路追踪断裂： 新旧版本使用不同的 trace ID 生成策略，导致跨版本调用链无法串联。

  最佳实践： 在蓝绿发布流程中增加“监控就绪检查”步骤——新版本启动后，自动验证以下三项：

  1. 关键 metric 是否在 Prometheus 中收到数据点

  2. 告警规则是否匹配新版本的 metric 名称

  3. 日志采集器是否成功解析新版本日志

  三项全部通过后，才允许进入流量切换阶段。

4.6 场景五：回滚失败

回滚是蓝绿发布最后的防线。当新版本出现严重故障时，回滚失败意味着故障恢复时间（TTR）将无限延长，甚至导致长时间业务中断。回滚失败通常由以下原因导致：

失败原因	具体表现	预防措施
旧版本资源被回收	发布完成后自动缩容或删除了旧版本 Pod/Deployment	保留旧版本资源至少 30 分钟，设置保留策略
数据迁移不可逆	数据库迁移脚本只支持前向迁移，不支持回退	所有迁移脚本必须包含 `down` 回退操作
配置版本丢失	旧版本的 ConfigMap/Secret 被覆盖或删除	使用版本化配置管理，回滚时自动恢复旧配置
依赖服务已升级	下游服务已升级至新 API，旧版本无法兼容	保持 API 版本兼容、使用适配层
回滚脚本本身有 Bug	回滚流程未经过充分测试，执行时报错	每次发布前演练回滚流程，纳入 CI/CD 流水线

关键指标： 建议将“回滚成功率”作为蓝绿发布的黄金指标之一。目标值应 ≥ 99.5%。每次回滚失败都应触发 P0 级复盘，并补充自动化回滚测试用例。

4.7 故障场景与 MTTR 口径映射

五大故障场景对应不同的 MTTR 阶段和度量口径。下表给出了每个场景的 MTTR 分解口径建议：

故障场景	TTD（发现时间）口径	TTI（定位时间）口径	TTR（恢复时间）口径
发布失败	从开始发布到首次告警触发	从告警触发到确定失败根因（镜像/配置/探针）	从开始回滚到旧版本恢复服务
流量切换异常	从切换操作到 QPS 异常检测	从异常检测定位到网关/路由/会话层	从执行回切到流量恢复正常
数据不一致	从数据写入到一致性校验失败	从校验失败定位到 Schema/缓存/消息层	从数据修复脚本执行到校验通过
监控告警缺失	从发布开始到人工发现指标缺失	从发现缺失到定位采集/阈值/日志问题	从修复配置到指标恢复正常采集
回滚失败	从决定回滚到发现回滚操作失败	从失败到定位资源/数据/脚本问题	从手动干预到服务完全恢复

度量设计要点： 每个场景的 MTTR 口径应独立采集，不能混为一谈。例如“发布失败”的 TTR 通常小于 5 分钟（直接回滚），而“数据不一致”的 TTR 可能长达数小时（需要数据修复）。统一口径会掩盖真实瓶颈。