4. 变更门禁概念

4.1 什么是变更门禁（Change Gate）

变更门禁（Change Gate）是部署流水线中用于控制变更是否允许进入下一阶段的安全检查点。它本质上是一个策略执行点，在变更从提交到生产的每个关键环节进行自动化验证与人工审批，确保只有满足质量、安全与合规要求的变更才能继续前进。

在多集群环境中，变更门禁的作用尤为突出：

• 防止有缺陷的 Helm Chart 扩散：避免一个集群中的错误配置传播到其他集群。
• 实现渐进式交付：通过分阶段验证，逐步扩大变更影响范围。
• 提供审计与回滚依据：每个门禁点的决策记录可用于事后追溯与自动回滚触发。

4.2 门禁的四个阶段

标准的多集群变更门禁模型将部署流水线划分为四个阶段，每个阶段对应一个门禁检查点：

四个阶段形成一条渐进式信任链：变更必须依次通过每个门禁，且前一阶段的验证结果作为后一阶段的输入条件。

4.3 门禁策略模型

门禁策略模型定义了在每个门禁点检查什么、如何检查、失败后怎么办。一个完整的策略模型包含三个核心要素：

1. 检查项（Check Items）：具体的验证规则，如 Pod 就绪率、API 响应延迟、安全漏洞等级。
2. 判定逻辑（Decision Logic）：如何组合多个检查项的结果，例如“所有检查项通过”或“允许 N-1 个检查项失败”。
3. 失败动作（Failure Action）：门禁未通过时的处理方式，包括阻断、自动回滚、告警通知、人工审批升级。

4.3.1 策略模型示例

4.3.2 策略模型的可编程性

在实际多集群场景中，门禁策略通常以声明式配置的形式存储在 Git 仓库中，与 Helm Chart 一起版本化管理。以下是一个简化的策略配置示例：

# gate-policy.yaml
apiVersion: changegate.io/v1
kind: GatePolicy
metadata:
  name: canary-gate
spec:
  phase: canary
  checks:
    - name: error-rate
      type: metric
      query: 'rate(http_requests_total{status=~"5.."}[5m])'
      threshold: 0.001
      duration: 5m
    - name: pod-health
      type: kubernetes
      resource: pods
      condition: "status.phase == Running"
      minReady: 0.95
  failureAction:
    primary: rollback
    rollbackRevision: "previous"
    notify:
      - slack: "#ops-alerts"
      - email: "sre@company.com"

4.4 门禁与 Helm Chart 回滚的关联

在多集群变更门禁模型中，Helm Chart 回滚不是独立操作，而是门禁策略的内置失败动作。当某个门禁点检测到异常时，策略引擎自动触发 helm rollback 命令，将目标集群的 Chart 版本恢复到上一个稳定版本。

这种关联关系带来三个关键优势：

• 自动化：无需人工介入，门禁失败后秒级触发回滚，缩短 MTTR（平均修复时间）。
• 一致性：回滚操作由策略引擎统一执行，避免不同团队执行回滚时的操作差异。
• 可审计：每次回滚都记录在门禁事件日志中，包含触发原因、回滚版本、执行时间。