20 | 做持续交付概念重要还是场景重要？看"笨办法"如何找到最佳方案

发布流程示例:

Step 1: Canary (Argo Rollouts)
├── 目的: 验证新版本技术稳定性（无崩溃、无异常）
├── 指标: Error Rate, P99 Latency, CPU/Memory
└── 判定: 通过 → 进入Step 2

Step 2: Feature Flag (Unleash/LaunchDarkly)
├── 目的: 控制业务功能暴露范围
├── 策略: 内部用户(100%) → 白名单用户(10%) → 全量(渐进)
├── 优势: 一键Kill Switch（出问题时秒级关闭）
└── 判定: 观察3-7天 → 确认稳定 → 清理Flag

# 默认的RollingUpdate策略 - 适合大多数场景
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 10
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 25%       # 滚动过程中最多超出25%副本
      maxUnavailable: 25% # 滚动过程中最多不可用25%副本
  template:
    spec:
      containers:
      - name: my-app
        image: ghcr.io/org/myapp@sha256:new-version-digest
        lifecycle:
          preStop:
            exec:
              command: ["/bin/sh", "-c", "sleep 10"]   # 等待连接排空
        readinessProbe:
          httpGet:
            path: /health/ready
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 5
        livenessProbe:
          httpGet:
            path: /health/live
            port: 8080
          initialDelaySeconds: 15
          periodSeconds: 10

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: my-app
spec:
  replicas: 10
  strategy:
    canary:
      steps:
      # 阶段1: 暂停人工审核 (可选)
      - setWeight: 0
        pause: {duration: 0}     # 手动promote才继续

      # 阶段2: 5%流量，自动分析60秒
      - setWeight: 5
        pause: {duration: 60s}

      # 阶段3: 20%流量，自动分析120秒
      - setWeight: 20
        pause: {duration: 120s}

      # 阶段4: 50%流量，自动分析120秒
      - setWeight: 50
        pause: {duration: 120s}

      # 阶段5: 100%
      - setWeight: 100

      # 分析配置 - 自动判断是否健康
      analysis:
        templates:
        - templateName: success-rate
        args:
        - name: service-name
          value: my-app-svc
        startingStep: 1
      trafficRouting:
        istio:
          virtualService:
            name: my-app-vs
            routes:
            - primary

# 方式1: ArgoCD CLI undo (最简单)
argocd app rollback my-app-production

# 方式2: Argo Rollouts rollback
kubectl rollout undo rollouts/my-app -n production

# 方式3: Feature Flag紧急关闭 (最快!)
# 在Unleash/LaunchDarkly控制台一键关闭Flag
# 无需重新部署，立即对所有用户生效

# 方式4: git revert (最安全 - 可追溯)
git revert HEAD
git push origin main
# ArgoCD自动检测变更并执行回滚

❌ 陷阱1:"工具崇拜综合征"
   症状：每个新技术出来都要试试
   根因：FOMO (Fear Of Missing Out)
   后果：工具栈臃肿，没人能完全掌握
   解法："笨办法"——从实际问题出发，够用就好

❌ 陷阱2:"GitOps形式主义"
   症状：Git里有manifest，但还是kubectl apply
   根因：只做了形式上的GitOps，没有真正信任控制器
   解法：优化GitOps速度 + 禁止集群直接写入权限

❌ 陷阱3:"跳过灰度直接全量"
   症状："改动很小不用灰度"
   根因：过度自信 / 节省时间
   后果：小改动引发大事故
   解法：建立强制灰度策略，核心应用必须走

❌ 陷阱4:"回滚方案从未演练"
   症状："应该能回滚吧"（不确定）
   根因：平时不练，出事才慌
   后果：真正需要回滚时手忙脚乱
   解法：每季度至少一次回滚演练

❌ 陷阱5:"忽视DORA指标"
   症状：不知道自己的交付效能水平
   根因：没有建立度量体系
   后果：无法证明持续交付的价值
   解法：先采集4个基础指标，再逐步完善

❌ 陷阱6:"为了自动化而自动化"
   症状：自动化了所有步骤但整体没变快
   根因：没有识别真正的瓶颈
   后果：投入产出比低
   解法：先度量找瓶颈，再针对性优化