2、变更管理基础
2.1 变更管理的定义
在平台工程与站点可靠性工程（SRE）语境下，变更管理是一套用于控制 IT 环境修改过程的标准化流程与策略集合。其核心目标是在推动业务功能迭代的同时，最小化因变更引入的服务中断、性能退化或安全漏洞风险。
变更管理不仅仅是“审批流程”，它涵盖了从变更请求的提出、评估、审批、实施、验证到最终关闭的全生命周期管控。对于平台工程团队而言，变更管理是连接开发速度与系统稳定性的关键桥梁。
核心原则： 任何对生产环境或类生产环境的修改（包括配置、代码、基础设施、策略）都应被视为一次变更，并遵循既定的管理流程。
2.2 变更类型
根据变更的风险等级、紧急程度和实施流程，通常将变更划分为以下三种类型。理解这些类型的差异是进行差异化风险评估和自动化编排的基础。
| 变更类型 | 定义 | 典型场景 | 审批流程 | 风险等级 |
|---|---|---|---|---|
| 标准变更 | 低风险、预授权、流程化、频繁执行的变更。变更方案和风险已被充分理解和验证。 | 例行补丁更新、扩缩容、非功能性配置修改、使用自动化工具进行的常规发布。 | 无需额外审批，通常由自动化工具直接执行或仅需记录。 | 低 |
| 常规变更 | 有一定风险，需要经过完整的变更评估、审批、计划和测试流程的变更。 | 新功能上线、数据库模式变更、中间件版本升级、网络架构调整。 | 需要变更咨询委员会（CAB）或指定负责人审批。 | 中 |
| 紧急变更 | 为应对重大生产事故或安全漏洞，必须立即实施的变更。可跳过常规审批流程，但事后需补录。 | 修复 P0 级故障、紧急安全补丁、回滚有问题的发布。 | 快速通道审批（如值班经理或架构师），事后补全流程。 | 高 |
实践建议： 在平台工程中，应尽可能将更多变更“标准化”。通过自动化工具和预定义的“变更模板”，将常规变更转化为标准变更，是提升交付效率、降低人为失误的关键策略。
2.3 变更生命周期
一个完整的变更生命周期通常包含以下六个阶段。每个阶段都对应着特定的活动、角色和评审点，是后续进行任务编排与可靠性评审自动化的核心模型。
- 请求与创建： 变更发起人提交变更请求（RFC），描述变更内容、目的、影响范围、回退计划等。
- 评估与分类： 变更经理或自动化系统对变更进行初步评估，确定变更类型（标准/常规/紧急），并分配风险等级。
- 审批与计划： 根据变更类型，进入相应的审批流程。审批通过后，制定详细的实施计划、测试方案和排期。
- 构建与测试： 在沙箱或预发布环境中实施变更，并进行功能、性能、安全等测试，验证变更的正确性。
- 实施与部署： 在计划窗口内，按照既定方案将变更部署到目标环境。此阶段通常包含灰度发布、监控告警等自动化步骤。
- 评审与关闭： 变更实施后，进行事后评审（Post-Mortem），确认变更是否达到预期目标，记录经验教训，最后关闭变更记录。
2.4 变更失败的影响
变更失败是导致生产环境事故的首要原因之一。根据行业统计，超过 70% 的 P0/P1 级故障直接或间接由变更引发。理解变更失败的多维度影响，有助于我们量化风险并设计更有效的自动化防护措施。
- 服务可用性下降： 直接导致服务中断、响应超时或功能不可用，影响用户体验和业务收入。
- 数据一致性与完整性受损： 错误的数据库变更或数据迁移脚本可能导致数据丢失、损坏或逻辑错误，修复成本极高。
- 安全风险暴露： 配置错误或引入有漏洞的组件可能为攻击者打开后门，导致数据泄露或合规风险。
- 运维成本激增： 故障排查、紧急回滚、事后复盘以及修复问题需要投入大量的人力与时间资源。
- 团队信任与士气受挫： 频繁的变更失败会降低业务方对平台团队的信任，增加流程摩擦，影响团队创新动力。
关键指标： 平台工程团队应持续追踪 变更失败率（Change Failure Rate, CFR）。CFR 是 DORA（DevOps Research and Assessment）四大核心指标之一，定义为导致服务受损的变更次数占总变更次数的比例。目标是将 CFR 控制在 5% 以下，理想状态低于 1%。