4. 变更窗口定义：时间模型、窗口类型与业务日历关联

变更窗口是告警路由自动配置的核心时间约束。它定义了“允许执行变更操作”的时间段，以及“变更期间告警应被抑制或降级”的规则。一个精确的变更窗口模型，能够有效避免变更操作引发大量误告警，同时确保在非变更时段告警的实时性与准确性。

4.1 变更窗口的时间模型

变更窗口的时间模型由三个基本维度构成：起始时间、持续时间和重复模式。这三个维度共同决定了窗口在时间轴上的精确位置与行为。

4.2 窗口类型：固定 / 动态 / 周期性

根据业务场景的不同，变更窗口可分为三种类型。每种类型在时间模型的构建方式上存在显著差异，适用于不同的运维场景。

• 固定窗口：由管理员手动指定具体的起始时间和持续时间，不依赖任何外部条件。适用于计划性较强的重大变更，如版本发布、硬件更换。
• 动态窗口：窗口的起始时间或持续时间根据外部条件自动计算。例如，基于上一变更的结束时间自动推迟下一窗口，或根据系统负载指标动态调整窗口长度。
• 周期性窗口：按照预设的重复模式自动生成一系列窗口。适用于常规运维操作，如每日凌晨的数据库备份、每周三的补丁更新。

4.3 窗口与业务日历的关联

变更窗口不能脱离业务日历独立存在。业务日历定义了“可变更日”与“不可变更日”，例如法定节假日、财务结算日、大促活动日等。变更窗口必须与业务日历进行关联，以确保窗口不会落在禁止变更的日期上。

关联机制通常采用日历过滤器的方式：

• 白名单模式：仅允许在业务日历标记为“可变更”的日期上创建窗口。
• 黑名单模式：自动排除业务日历标记为“禁止变更”的日期，其余日期均可创建窗口。
• 优先级模式：当变更窗口与业务日历冲突时，根据预设的优先级规则决定是否覆盖日历限制。

4.4 窗口冲突处理策略

当多个变更窗口在时间上重叠，或窗口与业务日历冲突时，系统需要具备明确的冲突处理策略。常见的策略包括：

4.5 窗口定义配置示例

以下是一个基于 YAML 的变更窗口定义示例，展示了时间模型、窗口类型与业务日历关联的完整配置：

# 变更窗口定义示例
change_window:
  name: "weekly_patch_window"
  type: "periodic"                    # 窗口类型：fixed / dynamic / periodic
  time_model:
    start_time: "02:00:00"            # 起始时间（本地时区）
    duration: "PT4H"                  # 持续时间（ISO 8601 格式）
    timezone: "Asia/Shanghai"         # 时区
    recurrence:                       # 重复模式（仅 periodic 类型需要）
      frequency: "weekly"
      by_day: ["TU", "TH"]            # 每周二、周四
      until: "2025-12-31T23:59:59Z"   # 可选：重复截止时间
  calendar_association:
    calendar_id: "prod_calendar"      # 关联的业务日历 ID
    filter_mode: "blacklist"          # 过滤器模式：whitelist / blacklist / priority
    conflict_strategy: "skip"         # 冲突策略：reject / skip / force
  alert_behavior:
    suppression: true                 # 窗口期间是否抑制告警
    escalation: "notification"        # 告警升级级别：notification / warning / critical
    exceptions:                       # 例外规则
      - alert_name: "disk_usage"
        action: "keep"                # 磁盘告警在窗口期间保持正常路由