3. 变更管理基础：变更类型、窗口、生命周期与风险分级
在平台工程架构中，变更管理是保障系统稳定性的核心防线。每一次代码部署、配置修改、基础设施扩缩容或数据库迁移，都属于变更。本章将系统梳理变更管理的四大基础要素：变更类型、变更窗口、变更生命周期与变更风险分级，为后续事故响应与数据传输设计奠定规则基础。
3.1 变更类型：标准、正常与紧急
根据变更的预审批状态、执行频率和风险等级，业界通常将变更分为三类。平台工程团队需为每种类型定义不同的审批流与自动化程度。
| 变更类型 | 定义 | 审批方式 | 典型场景 | 自动化程度 |
|---|---|---|---|---|
| 标准变更 | 低风险、预授权、重复执行的变更 | 无需逐次审批，模板化执行 | 例行补丁更新、非核心配置修改、扩缩容 | 高度自动化（CI/CD Pipeline） |
| 正常变更 | 中高风险、需逐次审批、有明确计划 | 变更咨询委员会（CAB）审批 | 新版本发布、数据库模式变更、网络架构调整 | 半自动化（人工审批+自动部署） |
| 紧急变更 | 高风险、需立即执行以修复故障或安全漏洞 | 紧急审批（简化流程，事后补录） | 线上P0故障热修复、安全漏洞紧急封禁 | 低自动化（人工操作+事后审计） |
平台工程实践建议： 标准变更应尽可能通过“变更模板”和“自动化流水线”实现零人工干预；紧急变更需建立“紧急变更通道”，允许SRE在授权范围内跳过常规审批，但必须在变更结束后24小时内完成变更记录与回顾。
3.2 变更窗口概念
变更窗口（Change Window）是指允许执行变更操作的时间段。在平台工程架构下，变更窗口的设计直接影响数据传输的调度策略与事故响应窗口的预留。
- 固定窗口： 每周/每月的固定时间段（如每周二凌晨02:00-06:00），适用于正常变更。
- 滚动窗口： 根据业务低峰期动态计算（如流量低于峰值的10%时），适用于标准变更。
- 零窗口： 无固定窗口，仅允许紧急变更或标准变更中的“无感知变更”（如蓝绿部署、灰度发布）。
- 冻结窗口： 特定时期（如双11、春节、财报季）禁止任何非紧急变更，仅保留紧急变更通道。
关键指标： 变更窗口覆盖率 = （窗口内完成的变更数 / 总变更数）× 100%。平台工程团队应追求标准变更100%在窗口外自动执行，正常变更100%在窗口内执行，紧急变更不受窗口限制但需事后审计。
3.3 变更生命周期
一个完整的变更从提出到关闭，通常经历以下六个阶段。平台工程团队应通过统一的变更管理平台（如ServiceNow、Backstage + 自定义插件）实现全生命周期可追溯。
- 创建与分类： 提交变更请求（RFC），明确变更类型、范围、影响面、回退方案。
- 评估与审批： 技术评审（架构师/SRE）+ 业务评审（产品/运营），根据风险等级决定审批层级。
- 计划与调度： 分配变更窗口，协调依赖项（如数据库迁移顺序、服务依赖拓扑）。
- 构建与测试： 在预发环境执行变更，运行自动化测试套件（单元测试、集成测试、混沌工程）。
- 部署与验证： 按发布策略（灰度/蓝绿/金丝雀）推送到生产环境，执行健康检查与监控告警验证。
- 回顾与关闭： 变更完成后72小时内进行变更回顾，更新知识库，关闭变更记录。
常见陷阱： 变更生命周期中最容易被忽略的是“回退方案”与“验证标准”。平台工程团队必须在变更计划阶段明确回答两个问题：① 变更失败后如何回退？② 如何判断变更是否成功？缺少任一条件，变更应被驳回。
3.4 变更风险分级
变更风险分级是决定审批流程、变更窗口优先级和回退策略的核心依据。平台工程团队应建立统一的风险评估矩阵，避免主观判断导致的误判。
| 风险等级 | 影响范围 | 回退难度 | 审批要求 | 变更窗口要求 | 示例 |
|---|---|---|---|---|---|
| P0（最高） | 全站/核心业务不可用 | 极高（需数据回滚） | CTO + 全体CAB | 仅紧急变更通道 | 数据库主库DDL、核心路由变更 |
| P1（高） | 核心功能受损，影响大量用户 | 高（需代码回退） | VP + CAB | 固定窗口 + 提前48h报备 | 新版本发布、缓存策略调整 |
| P2（中） | 非核心功能受损，影响部分用户 | 中（可灰度回退） | 技术负责人 + SRE | 滚动窗口 | 非核心服务配置修改、日志级别调整 |
| P3（低） | 无用户感知，仅内部影响 | 低（一键回退） | 无需审批（标准变更） | 零窗口 | 监控告警阈值调整、非生产环境变更 |
平台工程自动化策略： 变更风险分级应嵌入变更管理平台的“风险评分引擎”。系统自动根据变更对象（如数据库/配置/代码）、变更范围（全量/灰度）、变更时间（窗口内/窗口外）计算风险分数，并自动路由到对应的审批流。例如：涉及“数据库”且“全量”的变更自动标记为P1以上，强制要求CAB审批。
3.5 变更管理与数据传输的关联
在平台工程架构下，变更管理直接影响数据传输的可靠性设计：
- 变更窗口与数据传输调度： 数据传输任务（如日志采集、指标上报、事件流）应避开变更窗口，或在变更窗口期间启用“降级传输策略”（如批量写入改为单条写入、降低采样率）。
- 变更生命周期与数据一致性： 在变更的“构建与测试”阶段，数据传输管道应切换到“影子模式”，验证变更后的数据格式兼容性；在“部署与验证”阶段，数据传输应启用“双写校验”，确保新旧版本数据一致。
- 风险分级与数据保护： P0/P1变更期间，数据传输应启用“熔断机制”，当数据写入失败率达到阈值时自动切换到备用存储，避免变更故障导致数据丢失。
最佳实践： 建议平台工程团队在变更管理平台中为每个变更记录关联“数据传输影响标签”，自动识别该变更是否涉及数据管道（如Kafka Topic变更、Schema变更、数据源切换），并在变更审批时强制要求数据传输团队确认兼容性。