2、回滚窗口定义：时间窗口、版本窗口、策略窗口的概念与业务意义

在 GitOps 工作流中，回滚窗口（Rollback Window）并非单一的时间段，而是由时间维度、版本维度和策略维度共同构成的三维决策空间。理解这三个窗口的定义与业务意义，是设计可靠回滚机制的前提。

2.1 时间窗口（Time Window）

定义：从当前时刻向前追溯，允许执行回滚操作的最大时间范围。超过该时间范围的版本，即使存在，也不允许直接回滚。

业务意义：

• 数据一致性：数据库 schema 变更、缓存结构变化等会随时间累积，回滚到过旧版本可能导致数据读写异常。
• 依赖兼容性：下游服务、API 版本、配置中心等外部依赖可能已演进，旧版本无法适配当前环境。
• 审计合规：金融、医疗等行业要求变更记录可追溯，但回滚操作本身也需在合规时间窗内执行。

2.2 版本窗口（Version Window）

定义：允许回滚的目标版本范围，通常以 Git 提交、Helm Chart 版本或容器镜像 Tag 为粒度。版本窗口定义了“可以回滚到哪些版本”，而非“可以回滚到多早”。

业务意义：

• 版本连续性：跳过过多中间版本可能导致配置漂移（Configuration Drift），回滚后实际状态与预期状态不一致。
• 安全隔离：禁止回滚到已知存在安全漏洞的版本（如 CVE 修复前的镜像 Tag）。
• 发布策略对齐：与金丝雀发布、蓝绿部署等策略配合，只允许回滚到已验证通过的稳定版本。

2.3 策略窗口（Policy Window）

定义：由运维策略、业务规则或合规要求定义的附加约束条件，决定“在什么条件下允许回滚”。策略窗口是前两个窗口的“过滤器”，只有同时满足时间窗口和版本窗口的候选版本，再通过策略窗口的校验，才允许执行回滚。

常见策略窗口规则：

• 审批策略：回滚到生产环境需要至少 2 人审批；回滚到预发环境可自动执行。
• 安全策略：禁止回滚到包含已知高危 CVE 的镜像版本（需集成 Trivy / Grype 扫描结果）。
• 合规策略：回滚操作必须在变更窗口内执行（如非业务高峰期），且需记录审计日志。
• 依赖策略：如果目标版本依赖的数据库 schema 已变更，则禁止回滚（需通过 schema 兼容性检查）。

2.4 三个窗口的联合决策流程

在实际 GitOps 工具（如 ArgoCD、Flux）中，回滚窗口的判定通常按以下顺序执行：

1. 时间窗口检查：目标版本的部署时间是否在当前时间窗口内？若否，直接拒绝。
2. 版本窗口检查：目标版本是否在允许的版本范围内？若否，直接拒绝。
3. 策略窗口检查：目标版本是否满足所有附加策略？若否，拒绝并给出具体原因。
4. 执行回滚：三个窗口均通过，执行回滚操作并记录审计日志。

2.5 窗口配置示例（ArgoCD ApplicationSet）

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-app
spec:
  source:
    repoURL: https://git.example.com/my-app.git
    targetRevision: HEAD
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    retry:
      limit: 3
      backoff:
        duration: 30s
        factor: 2
        maxDuration: 5m
  # 自定义回滚窗口策略（通过 PreSync hook 实现）
  hooks:
    - name: rollback-window-check
      type: PreSync
      command: ["/scripts/check-rollback-window.sh"]
      args:
        - --time-window=48h
        - --version-window=5
        - --policy-file=/etc/policies/rollback-policy.yaml