回滚了却比不回滚还惨：CI/CD 自动回滚体系的 5 层架构与 4 个生产级踩坑

# Argo Rollouts AnalysisTemplate - 多指标投票制
apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
  name: rollback-vote
spec:
  args:
  - name: service-name
  - name: baseline-tag
  metrics:
  # 指标1: 错误率
  - name: error-rate
    interval: 30s
    count: 5
    successCondition: result[0] < 0.01
    failureLimit: 3
    provider:
      prometheus:
        address: http://prometheus:9090
        query: |
          sum(rate(http_requests_total{service="{{args.service-name}}",code=~"5.."}[2m]))
          /
          sum(rate(http_requests_total{service="{{args.service-name}}"}[2m]))          

  # 指标2: P99 延迟
  - name: p99-latency
    interval: 30s
    count: 5
    successCondition: result[0] < 200
    failureLimit: 3
    provider:
      prometheus:
        address: http://prometheus:9090
        query: |
          histogram_quantile(0.99,
            sum(rate(http_request_duration_seconds_bucket{service="{{args.service-name}}"}[2m]))
            by (le)
          ) * 1000          

  # 指标3: 业务指标（下单成功率）
  - name: business-success-rate
    interval: 60s
    count: 3
    successCondition: result[0] > 0.95
    failureLimit: 2
    provider:
      prometheus:
        address: http://prometheus:9090
        query: |
          sum(rate(order_created_total{status="success"}[3m]))
          /
          sum(rate(order_created_total[3m]))          

# 看似合理的探针配置，实际上有三个坑
apiVersion: apps/v1
kind: Deployment
metadata:
  name: payment-service
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  template:
    spec:
      containers:
      - name: app
        image: payment-service:v2.1.0
        readinessProbe:
          httpGet:
            path: /health
            port: 8080
          initialDelaySeconds: 10    # 坑1: 10秒太短
          periodSeconds: 5
          failureThreshold: 3        # 坑2: 3次失败=15秒，太慢
        livenessProbe:
          httpGet:
            path: /health
            port: 8080
          initialDelaySeconds: 30
          periodSeconds: 10
          failureThreshold: 3        # 坑3: 活性和就绪用同一个端点

# 分离式探针配置 - 生产级
readinessProbe:
  httpGet:
    path: /ready        # 就绪检查：连上数据库、缓存可用、线程池有余量
    port: 8080
  initialDelaySeconds: 30
  periodSeconds: 3
  failureThreshold: 1   # 一次失败立即摘流量
  timeoutSeconds: 2      # 超时也算失败

livenessProbe:
  httpGet:
    path: /live          # 存活检查：进程没死锁、GC 没卡死
    port: 8080
  initialDelaySeconds: 60
  periodSeconds: 10
  failureThreshold: 3
  timeoutSeconds: 5

# Argo Rollouts 金丝雀发布 + 自动回滚
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: payment-service
spec:
  replicas: 4
  strategy:
    canary:
      steps:
      - setWeight: 10          # 10% 流量到新版本
      - pause: { duration: 2m }  # 观察 2 分钟
      - analysis:              # 分析指标
          templates:
          - templateName: rollback-vote
          args:
          - name: service-name
            value: payment-service
      - setWeight: 30          # 通过后放至 30%
      - pause: { duration: 3m }
      - analysis:
          templates:
          - templateName: rollback-vote
          args:
          - name: service-name
            value: payment-service
      - setWeight: 60
      - pause: { duration: 3m }
      - analysis:
          templates:
          - templateName: rollback-vote
          args:
          - name: service-name
            value: payment-service
      - setWeight: 100

ALTER TABLE orders MODIFY COLUMN status TINYINT;

第 1 次发布（扩展）：
  - 新增字段 status_new TINYINT
  - 双写：同时写 status(varchar) 和 status_new(tinyint)
  - 读仍用 status

第 2 次发布（迁移+读切换）：
  - 后台任务把存量数据从 status 迁移到 status_new
  - 读切换到 status_new
  - 仍双写

第 3 次发布（收缩）：
  - 停止写 status，只写 status_new
  - 删除 status 字段

#!/bin/bash
# check_migration_safety.sh - 数据库迁移安全检查
# 在 CI/CD 流水线的 pre-deploy 阶段执行

MIGRATION_FILE=$1
VIOLATIONS=0

# 规则1: 检测 DROP TABLE / DROP COLUMN
if grep -iE 'DROP\s+(TABLE|COLUMN)' "$MIGRATION_FILE"; then
    echo "BLOCKED: 检测到 DROP 操作，必须使用扩展-收缩模式"
    VIOLATIONS=$((VIOLATIONS + 1))
fi

# 规则2: 检测 MODIFY COLUMN（类型变更）
if grep -iE 'MODIFY\s+COLUMN|ALTER\s+COLUMN.*TYPE' "$MIGRATION_FILE"; then
    echo "BLOCKED: 检测到列类型变更，必须使用扩展-收缩模式"
    VIOLATIONS=$((VIOLATIONS + 1))
fi

# 规则3: 检测 NOT NULL 约束添加（可能阻塞写入）
if grep -iE 'NOT\s+NULL' "$MIGRATION_FILE" | grep -iE 'ADD|MODIFY'; then
    echo "WARN: 检测到 NOT NULL 约束，确保已有默认值或数据已清洗"
    VIOLATIONS=$((VIOLATIONS + 1))
fi

# 规则4: 检测是否有对应的 down/rollback 迁移
MIGRATION_DIR=$(dirname "$MIGRATION_FILE")
MIGRATION_BASE=$(basename "$MIGRATION_FILE" | sed 's/^\d*_//;s/\.sql$//')
DOWN_FILE="${MIGRATION_DIR}/down_${MIGRATION_BASE}.sql"
if [ ! -f "$DOWN_FILE" ]; then
    echo "WARN: 未找到对应的回滚迁移文件: $DOWN_FILE"
    echo "       破坏性变更必须提供回滚脚本"
    VIOLATIONS=$((VIOLATIONS + 1))
fi

if [ $VIOLATIONS -gt 0 ]; then
    echo "迁移安全检查未通过，共 $VIOLATIONS 个违规"
    exit 1
fi

echo "迁移安全检查通过"
exit 0

# GitLab CI / GitHub Actions 配置片段
pre-deploy-check:
  stage: pre-deploy
  script:
    - ./scripts/check_migration_safety.sh migrations/20261003_add_status_field.sql
    - ./scripts/check_migration_safety.sh migrations/20261003_update_index.sql
  only:
    refs:
      - main
    changes:
      - migrations/*.sql

回滚前: 4 个 Pod 全是 v2（新版本）
回滚中: 1 个 v1 + 3 个 v2
回滚中: 2 个 v1 + 2 个 v2
回滚中: 3 个 v1 + 1 个 v2
回滚后: 4 个 Pod 全是 v1（旧版本）

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: payment-service
spec:
  replicas: 4
  strategy:
    blueGreen:
      activeService: payment-service-active       # 当前接流量的 Service
      previewService: payment-service-preview     # 预览用的 Service
      autoPromotionEnabled: false                  # 不自动切换，人工确认
      autoPromotionSeconds: 300                    # 或 5 分钟后自动切换
      scaleDownDelaySeconds: 60                    # 切换后 60 秒再缩容旧版本
      prePromotionAnalysis:
        templates:
        - templateName: rollback-vote              # 切换前先分析指标
        args:
        - name: service-name
          value: payment-service-preview

// 缓存版本号方案 - 每个缓存值带版本前缀
func CacheKey(key string, version int) string {
    return fmt.Sprintf("v%d:%s", version, key)
}

// 写缓存时带版本号
func SetCache(ctx context.Context, key string, value []byte, version int) error {
    cacheKey := CacheKey(key, version)
    return redis.Set(ctx, cacheKey, value, 5*time.Minute)
}

// 读缓存时先试当前版本，miss 后不碰其他版本
func GetCache(ctx context.Context, key string, version int) ([]byte, error) {
    cacheKey := CacheKey(key, version)
    data, err := redis.Get(ctx, cacheKey)
    if err == redis.Nil {
        return nil, nil // Cache miss，走回源
    }
    return data, err
}

#!/bin/bash
# verify_rollback.sh - 回滚后验证脚本
# 在回滚操作完成后执行

SERVICE=$1
NAMESPACE=${2:-default}
HEALTH_CHECK_URL="http://${SERVICE}.${NAMESPACE}.svc:8080/ready"

# 等待回滚完成
echo "等待 rollout 完成..."
kubectl rollout status deployment/${SERVICE} -n ${NAMESPACE} --timeout=120s
if [ $? -ne 0 ]; then
    echo "ROLLBACK_FAILED: rollout 未在 120 秒内完成"
    exit 1
fi

# 等待 Pod 就绪
echo "等待 Pod 就绪..."
sleep 10

# 健康检查
echo "执行健康检查..."
for i in $(seq 1 10); do
    HTTP_CODE=$(curl -s -o /dev/null -w "%{http_code}" "$HEALTH_CHECK_URL")
    if [ "$HTTP_CODE" = "200" ]; then
        echo "健康检查通过 (attempt $i)"
        break
    fi
    echo "健康检查失败 (attempt $i/10), HTTP $HTTP_CODE"
    sleep 5
done

# 关键业务指标检查
echo "检查业务指标..."
ERROR_RATE=$(curl -s "http://prometheus:9090/api/v1/query?query=sum(rate(http_requests_total{service=\"${SERVICE}\",code=~\"5..\"}[1m]))/sum(rate(http_requests_total{service=\"${SERVICE}\"}[1m]))" | jq -r '.data.result[0].value[1]')
if [ "$(echo "$ERROR_RATE > 0.01" | bc)" = "1" ]; then
    echo "ROLLBACK_VERIFICATION_FAILED: 错误率 $ERROR_RATE 仍高于 1%"
    echo "触发 P1 告警，人工介入"
    # 发送告警
    exit 1
fi

echo "回滚验证通过，服务已恢复"

# 不安全：maxUnavailable=0 在资源不足时卡死
rollingUpdate:
  maxSurge: 1
  maxUnavailable: 0

# 推荐：允许少量不可用，给调度器腾挪空间
rollingUpdate:
  maxSurge: 1
  maxUnavailable: 1  # 4 副本中允许 1 个不可用，25% 冗余

# 不推荐：历史版本太少
revisionHistoryLimit: 2

# 推荐：保留足够的历史版本
revisionHistoryLimit: 10  # 默认值，不要随意改小

#!/bin/bash
# rollback_with_config.sh - 带配置的完整回滚
DEPLOYMENT=$1
NAMESPACE=$2
REVISION=$3  # 回滚到哪个 revision

# 获取目标 revision 的镜像
TARGET_IMAGE=$(kubectl rollout history deployment/${DEPLOYMENT} -n ${NAMESPACE} --revision=${REVISION} -o jsonpath='{.spec.template.spec.containers[0].image}')
# 从镜像 tag 中提取配置版本（假设配置版本和镜像 tag 绑定）
CONFIG_VERSION=$(echo "$TARGET_IMAGE" | sed 's/.*-v\([0-9.]*\)$/\1/')

# 回滚 ConfigMap 和 Secret 到对应版本
kubectl apply -f configs/configmap-v${CONFIG_VERSION}.yaml
kubectl apply -f secrets/secret-v${CONFIG_VERSION}.yaml --dry-run=server

# 等待配置生效
sleep 5

# 回滚镜像
kubectl rollout undo deployment/${DEPLOYMENT} -n ${NAMESPACE} --to-revision=${REVISION}

# 验证回滚
kubectl rollout status deployment/${DEPLOYMENT} -n ${NAMESPACE} --timeout=120s

正常状态: 4 个旧版本 Pod (HPA min=3, 当前=4)
发布开始: 1 个新版本 + 4 个旧版本，10% 流量到新版本
HPA 触发: 负载降低 → 旧版本缩到 2 个 (1 新 + 2 旧)
回滚触发: 流量全部切回旧版本 → 2 个旧版本 Pod 承受全量流量 → 雪崩

# 发布前暂停 HPA
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: payment-service
spec:
  replicas: 4
  strategy:
    canary:
      steps:
      - setWeight: 10
      - pause: { duration: 2m }
      # ... 后续步骤
  # 关键：发布期间固定副本数，不触发 HPA
  # 通过 Argo Rollouts 的 HPA 集成自动处理

# 发布前
kubectl patch hpa payment-service --type=json -p='[{"op":"replace","path":"/spec/minReplicas","value":6}]'

# 发布后恢复
kubectl patch hpa payment-service --type=json -p='[{"op":"replace","path":"/spec/minReplicas","value":3}]'

# 回滚执行耗时（从触发到完成）
- record: rollback_duration_seconds
  expr: |
    max(timestamp(kube_deployment_status_replicas_available{deployment="payment-service"}))
    - max(timestamp(kube_deployment_status_replicas_updated{deployment="payment-service"}))

# 回滚后服务恢复速度（错误率回到正常水平的时间）
- record: rollback_recovery_seconds
  expr: |
    timestamp(sum(rate(http_requests_total{service="payment-service",code=~"5.."}[1m])) < 0.001)
    - timestamp(rollback_trigger_time)

# 回滚期间受影响请求总量
- record: rollback_affected_requests_total
  expr: |
    sum(increase(http_requests_total{service="payment-service",code=~"5.."}[15m]))

回滚演练 checklist:
□ 自动回滚触发耗时 < 30s
□ 回滚执行耗时 < 60s  
□ 回滚后健康检查通过
□ 回滚后错误率恢复 < 1%
□ 回滚通知已发送到告警群
□ 数据库连接正常
□ 缓存命中率回稳
□ 业务指标恢复
□ 人工介入次数 = 0