3. 蓝绿发布流程与操作：发布前检查清单、流量切换步骤、回滚操作流程、常见自动化工具

蓝绿发布的核心在于维护两套完全独立的生产环境——蓝环境（当前稳定版本）与绿环境（新版本）。发布流程的严谨性直接决定故障恢复速度（MTTR）与业务连续性。本节从检查清单、流量切换、回滚操作到自动化工具，构建完整的操作体系。

3.1 发布前检查清单

发布前检查是降低故障概率的第一道防线。以下清单按基础设施、应用配置、数据层、监控告警四个维度组织：

3.2 流量切换步骤

流量切换是蓝绿发布的核心操作，通常分为灰度验证与全量切换两个阶段。以下为标准的5步切换流程：

1. 预热绿环境：启动绿环境后，先发送少量内部探测流量（如健康检查、影子流量），确认应用正常响应。
2. 灰度切流（1%-5%）：通过负载均衡器（如 Nginx/ALB/Envoy）将1%-5%的生产流量导向绿环境，持续观察5-15分钟。
3. 指标验证：对比蓝绿环境的错误率（<1%）、P99延迟（<基线+10%）、业务成功率（>99.9%）。
4. 逐步切流（25% → 50% → 100%）：每步间隔3-5分钟，观察指标无异常后继续。
5. 流量锁定与蓝环境保留：全量切换后，蓝环境保持运行至少30分钟（或一个完整业务周期），用于快速回滚。

3.3 回滚操作流程

回滚是蓝绿发布的核心优势——只需将负载均衡流量切回蓝环境，无需重新部署。但回滚决策必须基于明确的故障判定标准，避免盲目操作。标准回滚流程如下：

3.4 常见自动化工具

蓝绿发布的自动化程度直接影响MTTR。以下对比业界主流工具：

3.5 自动化工具关键配置示例

以下为ArgoCD配合Argo Rollouts实现蓝绿发布的简化配置片段：

# argo-rollouts-bluegreen.yaml
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: myapp-bluegreen
spec:
  replicas: 5
  revisionHistoryLimit: 2
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp
        image: myapp:1.2.3
        ports:
        - containerPort: 8080
  strategy:
    blueGreen:
      # 蓝环境Service（当前稳定版本）
      activeService: myapp-active
      # 绿环境Service（新版本预览）
      previewService: myapp-preview
      # 自动回滚条件：基于Prometheus指标
      autoPromotionEnabled: false
      scaleDownDelaySeconds: 1800  # 蓝环境保留30分钟
      prePromotionAnalysis:
        templates:
        - templateName: success-rate
        args:
        - name: service-name
          value: myapp-preview