4. 变更管理基础：变更类型、CAB 与变更窗口

变更管理是 ITIL 框架中的核心流程，也是平台工程中保障服务连续性与安全性的第一道防线。在事故响应与变更窗口通信机制中，变更管理决定了“谁、在什么时候、以什么方式、修改了什么”。本章聚焦三个基础概念：变更类型、变更咨询委员会（CAB）和变更窗口（Change Window）。

4.1 变更类型：标准、正常与紧急

根据风险等级、审批流程和紧急程度，变更通常分为三类。下表从定义、审批路径、典型场景和平台工程中的常见示例四个维度进行对比：

4.2 变更咨询委员会（CAB）

CAB 是一个跨职能的决策团体，负责对正常变更进行风险评估、资源协调和最终批准。在平台工程语境下，CAB 的组成和运作方式需要适应 DevOps 的快速迭代节奏。

4.2.1 CAB 的典型角色

• 变更经理： 流程负责人，主持 CAB 会议，确保变更记录完整。
• 应用负责人： 了解变更对业务功能的影响。
• 基础设施工程师： 评估底层资源（网络、存储、计算）的变更风险。
• 安全代表： 检查变更是否引入安全漏洞或合规问题。
• 发布经理： 协调变更与发布窗口的冲突。
• 平台团队代表： 评估变更对平台自身（如控制面、API 网关）的影响。

4.2.2 平台工程中的 CAB 优化

传统 CAB 每周一次会议的模式在高速 DevOps 中容易成为瓶颈。平台工程推荐以下优化策略：

• 异步 CAB： 使用协作工具（如 Jira、ServiceNow）进行异步评审，减少同步会议。
• 分层 CAB： 低风险正常变更由平台团队内部评审；高风险变更才升级到全量 CAB。
• 自动化 CAB 门禁： 集成 CI/CD 管道，自动检查变更是否符合预定义策略（如安全扫描、成本预算）。

4.3 变更窗口（Change Window）

变更窗口是预先定义的时间段，在此期间允许执行正常变更。变更窗口的核心目的是降低变更对用户的影响，并为回滚预留缓冲时间。

4.3.1 变更窗口的类型

4.3.2 变更窗口与事故响应的关联

变更窗口与事故响应之间存在双向通信机制：

• 变更前通知： 在变更窗口开始前，通过 PagerDuty/Opsgenie 向值班工程师发送“即将变更”通知。
• 变更中监控： 变更执行期间，SLO/SLI 仪表盘自动关联变更 ID，一旦指标异常立即触发事故。
• 变更后回滚： 如果变更导致事故，自动回滚机制应在窗口关闭前完成。

4.4 变更类型、CAB 与变更窗口的关系

下面的 SVG 图展示了三类变更如何与 CAB 决策、变更窗口以及事故响应流程交互：

4.5 平台工程中的变更管理自动化

在平台工程实践中，变更管理不应是手工流程，而应嵌入工具链。以下是一个典型的自动化变更管理流水线示例：

# 变更管理自动化流水线（伪代码）
pipeline:
  name: "变更管理流水线"
  stages:
    - stage: "变更类型识别"
      steps:
        - 解析 RFC 元数据（标签、风险等级）
        - 自动分类：标准 / 正常 / 紧急
    - stage: "CAB 门禁"
      steps:
        - if 标准变更: 自动批准
        - if 正常变更: 触发异步 CAB 评审（Jira + Slack）
        - if 紧急变更: 触发 eCAB 快速通道（PagerDuty + Zoom）
    - stage: "变更窗口调度"
      steps:
        - 查询可用变更窗口（Calendly API）
        - 自动锁定窗口时段
        - 通知相关方（变更前 30 分钟）
    - stage: "执行与监控"
      steps:
        - 执行变更（Ansible / Terraform / ArgoCD）
        - 关联监控仪表盘（Grafana + Prometheus）
        - 如果 SLO 违规 → 自动回滚 + 触发事故