8.3 DevOps 发布流程

一、适用范围与目标

  • 适用于应用、服务、配置等的发布、更新、回滚等 DevOps 操作。
  • 目标：建立标准化的发布流程，保障发布安全，降低发布风险，提升发布效率。

二、管理目标

  1. 发布流程标准化，支持多种发布策略
  2. 发布过程可追溯、可回滚
  3. 自动化发布与人工审核相结合
  4. 发布后验证与监控完善

三、详细规范

蓝绿发布

  • 原理：新旧环境并行，通过流量切换实现零停机发布
  • 适用场景：需要快速回滚的场景，对停机时间要求高的场景
  • 优势：零停机、快速回滚、风险可控
  • 注意事项：需要双倍资源，数据兼容性要求高

灰度发布（金丝雀发布）

  • 原理：逐步将流量切换到新版本，监控指标，无异常后全量发布
  • 适用场景：需要逐步验证新版本的场景，降低发布风险
  • 优势：风险可控、可逐步验证、支持快速回滚
  • 注意事项：需要流量控制能力，监控指标完善

滚动发布

  • 原理：逐步替换旧版本实例，保持服务可用
  • 适用场景：Kubernetes 等容器平台的标准发布方式
  • 优势：资源利用率高、发布平滑
  • 注意事项：需要健康检查，确保新实例就绪

回滚机制

  • 镜像回退：回退到上一个稳定版本
  • 配置回退：回退配置变更
  • 数据回滚：数据库变更回滚（需谨慎）
  • 自动化回滚：监控异常自动触发回滚

四、操作流程

蓝绿发布流程

  1. 发布前检查 → 检查依赖、配置、回滚方案
  2. 部署新版本 → 部署新版本到”绿”环境
  3. 健康检查 → 检查新版本健康状态
  4. 流量切换 → 逐步或一次性切换流量到新版本
  5. 监控验证 → 监控业务指标，验证功能正常
  6. 保留旧版本 → 保留”蓝”环境一段时间以便回滚
  7. 清理资源 → 确认无问题后清理旧版本资源

灰度发布流程

  1. 发布前检查 → 检查依赖、配置、回滚方案
  2. 部署新版本 → 部署新版本实例
  3. 小流量验证 → 切换 5-10% 流量到新版本
  4. 监控指标 → 监控错误率、响应时间、业务指标
  5. 逐步放量 → 无异常后逐步增加流量（10% → 50% → 100%）
  6. 全量发布 → 所有流量切换到新版本
  7. 清理旧版本 → 确认无问题后清理旧版本

回滚流程

  1. 触发回滚 → 检测到异常或手动触发回滚
  2. 评估影响 → 评估回滚的影响范围
  3. 执行回滚 → 回退到上一个稳定版本
  4. 验证业务 → 验证业务功能恢复正常
  5. 记录归档 → 记录回滚原因和过程
  6. 问题分析 → 分析问题原因，制定改进措施

五、实际案例

案例1：蓝绿发布 Web 服务

  • 场景：生产环境 Web 服务版本更新
  • 步骤：
    1. 部署新版本到”绿”环境
    2. 健康检查通过
    3. 切换 50% 流量到新版本
    4. 监控 10 分钟无异常
    5. 切换 100% 流量到新版本
    6. 保留”蓝”环境 24 小时
  • 结果：零停机发布，业务无影响
  • 亮点：分阶段切换，风险可控

案例2：灰度发布 API 服务

  • 场景：API 服务重大版本更新
  • 步骤：
    1. 部署新版本实例
    2. 切换 5% 流量到新版本
    3. 监控 30 分钟，错误率正常
    4. 切换 20% 流量，继续监控
    5. 逐步增加到 100% 流量
    6. 清理旧版本实例
  • 结果：逐步验证，无异常
  • 亮点：逐步放量，风险可控

案例3：自动回滚

  • 场景：发布后检测到错误率上升
  • 步骤：
    1. 监控系统检测到错误率 > 1%
    2. 自动触发回滚流程
    3. 回退到上一个稳定版本
    4. 验证业务恢复正常
    5. 通知相关人员
    6. 分析问题原因
  • 结果：2 分钟内完成回滚，业务恢复
  • 亮点：自动化回滚，快速恢复

六、操作模板

发布前检查清单

# 发布前检查清单

## 代码与配置
- [ ] 代码已通过测试
- [ ] 配置文件已更新
- [ ] 依赖版本已确认
- [ ] 数据库变更已准备

## 发布方案
- [ ] 发布策略已确定（蓝绿/灰度/滚动）
- [ ] 回滚方案已准备
- [ ] 发布窗口已确定
- [ ] 相关人员已通知

## 监控与告警
- [ ] 监控指标已配置
- [ ] 告警规则已设置
- [ ] 监控面板已准备
- [ ] 值班人员已就位

蓝绿发布脚本示例（Kubernetes）

# 部署新版本（绿环境）
apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-green
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
      version: green
  template:
    metadata:
      labels:
        app: myapp
        version: green
    spec:
      containers:
      - name: app
        image: myapp:v2.0
---
# 服务流量切换
apiVersion: v1
kind: Service
metadata:
  name: myapp-service
spec:
  selector:
    app: myapp
    version: green  # 切换到绿环境
  ports:
  - port: 80
    targetPort: 8080

灰度发布配置示例（Istio）

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: myapp
spec:
  hosts:
  - myapp
  http:
  - match:
    - headers:
        canary:
          exact: "true"
    route:
    - destination:
        host: myapp
        subset: v2
      weight: 100
  - route:
    - destination:
        host: myapp
        subset: v1
      weight: 90
    - destination:
        host: myapp
        subset: v2
      weight: 10

回滚脚本示例

#!/bin/bash
# 回滚脚本

APP_NAME="myapp"
PREVIOUS_VERSION="v1.0"

echo "开始回滚 ${APP_NAME} 到 ${PREVIOUS_VERSION}"

# 回滚 Deployment
kubectl rollout undo deployment/${APP_NAME}

# 等待回滚完成
kubectl rollout status deployment/${APP_NAME}

# 验证服务
kubectl get pods -l app=${APP_NAME}

echo "回滚完成"

七、注意事项

  • 发布过程全程审计：所有发布操作需记录，便于追溯
  • 回滚方案需提前验证：回滚方案需在测试环境验证
  • 灰度/蓝绿需有流量切换与监控：确保有完善的流量控制和监控
  • 发布窗口选择：选择业务低峰期发布，降低影响
  • 数据兼容性：确保新版本与旧版本数据兼容
  • 通知机制：发布前后及时通知相关人员

八、参考资料

  • 《DevOps 发布最佳实践》
  • 《Kubernetes 发布与回滚白皮书》
  • 《Istio 流量管理指南》
  • 团队内部发布流程规范