web

第72章｜案例 2：从零搭建一条“安全 CD”交付链（审批、回滚、审计）

CI 回答“制品是否合格”；CD 回答“合格品如何以可接受风险抵达生产”。 安全 CD把发布策略、配置治理、人工审批与机器执行缝在一起：谁有权推生产？变更如何渐进？出事如何分钟级回滚？事后如何审计追责？ 本章用蓝图方式串联 GitOps、门禁与审批、渐进交付与回滚/应急，并指向与供应链章一致的签名与准入策略。

GitOps

Desired state wins

  • Git as SSOT
  • controller reconcile
  • drift detection
Govern

Gates & approvals

  • env protection
  • four-eyes rule
  • break-glass audit
Recover

Rollback & proof

  • git revert / rollout undo
  • migration playbook
  • immutable audit log

1. CD 的“安全”指什么：不是慢，而是可证明、可撤销

把发布变慢并不等于更安全；真正需要的是每一步都有证据（谁、何时、改了什么 digest）、 每一步都可撤销（或至少可缓解），以及异常可观测（SLO 与错误预算联动）。 GitOps 的优势正在于此：集群状态由声明式期望驱动，回滚常常是把 Git 指针移回去，而不是 ssh 上去改文件。

隐喻：安全 CD 像机场登机——安检（CI）、登机口核验（审批）、滑行与起飞（渐进放量）、紧急复飞程序（回滚），缺一不可。

2. GitOps 主干：单一真相源与对账循环

选定 Argo CD 或 Flux 之一（或云厂商托管 GitOps），原则不变：Git 仓库描述期望版本； 控制器持续对账（reconcile）；人工 kubectl 修改会变成漂移（drift），应被告警或自动修复。 多环境通常用目录/分支/overlay（Kustomize）或 Helm values 分层，避免复制粘贴整份 YAML。

Secure CD — GitOps reconcile loop Git repo manifests · Helm · Kustomize GitOps controller diff · apply · health Cluster live desired state continuous reconcile — change Git, not kubectl (exceptions audited) Audit plane sync events · deployer identity · image digest per release — export to SIEM / immutable store
图 1：GitOps 把“想变成什么样”与“谁改的”绑在 Git 历史上——天然利于审计与回滚叙事。
# Argo CD Application (illustrative — English identifiers only)
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: payments-prod
  namespace: argocd
spec:
  project: production
  source:
    repoURL: https://git.example.com/org/gitops.git
    targetRevision: main
    path: overlays/prod/payments
  destination:
    server: https://kubernetes.default.svc
    namespace: payments
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

3. 审批与环境门禁：机器跑得快，人要在正确的门签字

环境保护规则（谁可以部署到 prod）、手动审批步骤（流水线中的 approval）、 变更窗口与双人复核（four-eyes）是常见组合。 与 CI 的“自动绿”不同，CD 要显式回答：业务是否接受此刻的风险（错误预算、冻结窗口、大促）。 紧急通道（break-glass）必须留痕、限时、复盘，否则会变成永久后门。

Mechanism What it prevents Typical implementation
Branch / tag policy unreviewed config to prod PR + CODEOWNERS on gitops repo
Pipeline approval ops fatigue “fat finger” manual gate with role binding
Admission policy unsigned / wrong digest OPA / Kyverno + cosign verify
Freeze window change during incident calendar + automated block

4. 渐进交付：把“全量切换”拆成可观测的小步

蓝绿 / 金丝雀 / 按流量权重降低一次性爆炸半径；配合特性开关把代码发布与功能曝光解耦。 观测要先行：金丝雀阶段必须看黄金信号与业务 KPI，自动晋升或自动回退（需要事先定义阈值，避免“看着仪表盘发呆”）。

Progressive delivery — widen traffic as health proves out v1 stable v2 canary slice Metrics gate latency · errors · SLO auto promote / rollback Full rollout or abort 100% v2 OR revert weights Feature flags decouple deploy from expose — CD moves bits; flags move risk.
图 2：渐进交付把发布变成带仪表的试飞——不是赌一把全量。

5. 回滚与应急：先救命，再讲故事

Kubernetes：Deployment 回滚、Argo Rollouts undo、Istio/网关流量切回。 GitOps：revert commit 或指针回到上一 tag，控制器拉回期望状态。 数据库迁移是经典难点：只向前迁移 + expand/contract 模式，或配套反向数据修复脚本——回滚策略必须在设计迁移时写好，而不是上线当晚现编。 应急通信：明确指挥链、状态页、客户沟通模板，与第 65 章 incident 响应衔接。

Rollback menu (choose one consciously) Git revert / re-point best for GitOps truth kubectl rollout undo fast for Deployment RS Hotfix forward when schema already moved Audit record who triggered rollback · ticket id · postmortem link — same bar as production deploy
图 3：回滚不是单一按钮——是策略菜单；选错菜单会和事故一样贵。

6. 审计与合规：让“事后能讲清楚”成为默认输出

审计三要素：身份（谁）、对象（哪个 digest / manifest）、时间线（何时同步成功）。 将 GitOps 同步事件、流水线审批、准入决策与镜像签名验证结果关联到同一变更单，比散落日志更可辩护。 保留策略要满足法规与事故调查需要——不可变存储或 WORM 类桶可降低抵赖风险。

7. 本章清单与预告

  1. 能描述 GitOps 对账环与漂移处理策略。
  2. 能组合审批、环境保护、准入策略形成安全 CD。
  3. 理解渐进交付与特性开关在风险上的分工。
  4. 能区分常见回滚路径及数据库变更的特殊性。
  5. 能列出审计最小字段并与供应链证明链衔接。
  6. 下一章：面试与晋升——DevOps 专家能力模型与答题框架。
← 上一章：案例 可信 CI 下一章：面试与能力模型 →