构建CI/CD防护栏：实现可靠发布工程

场景

一家快速成长的SaaS公司，每天部署数十次。团队发现，尽管CI流水线总是绿色通过，但生产环境频繁出现故障。部署后几分钟内收到告警，用户访问超时。回滚操作缓慢且手动，导致长时间停机。

症状

• 部署后立即出现P1告警。
• 错误预算快速耗尽。
• 回滚需要30分钟以上。
• 开发者和SRE之间相互指责。

诊断

根本原因在于缺少CI/CD防护栏：没有自动化测试门控、金丝雀分析、部署窗口控制，以及健康检查自动回滚。CI流水线仅通过单元测试，未包含集成测试、负载测试或安全扫描。CD流水线直接全量发布，未做渐进式交付。

命令与配置

以下是一个基于GitHub Actions和ArgoCD的防护栏示例：

# .github/workflows/deploy.yaml
name: Deploy with Guardrails
on:
  push:
    branches: [main]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Run unit tests
        run: make test
      - name: Run integration tests
        run: make integration-test
      - name: Security scan
        run: trivy image --severity HIGH,CRITICAL --exit-code 1 myapp:${{ github.sha }}
  deploy-canary:
    needs: test
    runs-on: ubuntu-latest
    steps:
      - name: Deploy canary to 10%
        run: kubectl set image deployment/myapp-canary myapp=myapp:${{ github.sha }} -n production
      - name: Wait for health check
        run: sleep 60 && kubectl rollout status deployment/myapp-canary -n production --timeout=5m
  promote:
    needs: deploy-canary
    runs-on: ubuntu-latest
    steps:
      - name: Promote to full
        run: kubectl set image deployment/myapp myapp=myapp:${{ github.sha }} -n production
      - name: Verify deployment
        run: kubectl rollout status deployment/myapp -n production --timeout=10m

风险控制

• 功能标志：通过LaunchDarkly或ConfigMap控制新功能暴露。
• 渐进式发布：使用ArgoCD的自动回滚策略，当健康检查失败时触发。
• 部署窗口：在CI中检查当前时间是否在批准窗口内，否则拒绝发布。
• 错误预算门控：如果错误预算消耗超过70%，自动阻止部署。

回滚

# 使用kubectl回滚
kubectl rollout undo deployment/myapp -n production

# 使用Git revert
revert HEAD

# 使用ArgoCD
argocd app rollback myapp --prune

验证

• 监控面板跟踪：部署频率、失败率、错误预算、回滚次数。
• 合成检查：每5分钟执行一次关键交易用户路径。
• 告警规则：部署后10分钟内如果有5xx错误增加>1%，触发回滚。

何时提交OpsGlobal工单

• 需要设计完整的防护栏流水线但缺乏内部专业知识。
• 现有防护栏失效，导致频繁事故。
• 需要跨Kubernetes集群协调复杂渐进式发布策略。