变更管理

变更管理在 SRE 中的定位 Google SRE 总结的一条铁律：大约 70% 的线上故障由变更直接引发。无论是代码部署、配置修改、基础设施调整还是依赖升级，每一次变更都在向系统注入不确定性。因此，变更管理不是流程上的繁文缛节，而是 SRE 可靠性工程的第一道防线。 变更管理的核心目标可以归纳为三点： 降低爆炸半径——变更出了问题，影响面应尽可能小。 缩短发现问题的时间——变更后若出现异常，必须能在分钟级甚至秒级感知。 具备快速回滚能力——发现问题后，能在最短时间内恢复到上一个已知正常状态。 实现这三个目标的关键技术手段就是灰度发布与快速回滚。下面逐一展开。 金丝雀发布原理与实现 核心思想 “金丝雀"一词源自矿工带金丝雀下井探测有毒气体的做法。在软件发布中，金丝雀发布指的是：先将新版本部署到极小比例的实例上，引入少量真实流量进行验证，确认无异常后再逐步扩大流量比例，直至全量切换。 与全量发布相比，金丝雀发布的本质区别在于引入了流量比例控制和指标门控两个机制，使发布过程变成一个可控的、可观测的渐进过程。 流量比例控制 典型的金丝雀发布流量推进序列： 5% → 10% → 25% → 50% → 100% 每个阶段之间设置观察窗口（如 5-10 分钟），期间持续采集关键指标。只有当指标满足预设的健康标准时，才推进到下一阶段；否则自动暂停甚至回滚。 指标门控 指标门控是金丝雀发布的"大脑”。通常关注以下几类指标： 指标类别 示例 门控逻辑 错误率 HTTP 5xx 比例 金丝雀错误率 > 基线 1.5x → 自动回滚 延迟 P99 / P95 响应时间 金丝雀 P99 > 基线 + 50ms → 暂停推进 业务指标 下单成功率、支付成功率 成功率下降 > 2% → 自动回滚 资源指标 CPU、内存、连接数 资源使用率异常飙升 → 告警暂停 关键原则：门控指标必须从用户视角出发，而非仅看基础设施指标。一个 CPU 正常但 P99 翻倍的系统，仍然应该触发回滚。...