SRE 实战手册十延申篇变更与发布工程——让上线本身变安全延申篇。本篇承接容量规划九与错误预算四变更是稳定性最大的敌人也是发布闸门最好的用武之地。配套脚本../deploy/rollout.sh、../deploy/fault.sh。一、一个扎心的事实故障大多来自变更行业统计反复印证线上故障的 70% 源于变更发版、配置、扩缩容、数据迁移而不是硬件坏掉。故障来源占比示意 ┌──────────────────────────────────────────────┐ │ 变更(发版/配置/扩缩容) ████████████████ 70% │ │ 容量/过载 ████ 15% │ │ 依赖故障(下游/中间件) ███ 10% │ │ 硬件/未知 █ 5% │ └──────────────────────────────────────────────┘既然改东西最容易出事SRE 的重点就不是阻止变更业务要往前走而是让变更可灰度、可观测、可回滚、可拦截。二、变更管理三道闸门审批/评审关键变更走评审明确回滚预案才算就绪——没有回滚方案的变更不准上。冻结窗口大促、节假日等高危时段进入变更冻结非紧急不变更。回滚预案回滚必须比定位快。能回滚就先回滚呼应博客六恢复业务优先。三、渐进式交付别一次性梭哈全量发布危险 渐进式交付安全 ┌──────────┐ ┌──────────┐ │ 100% 新版本 │ │ 1% canary│ ─观测 SLO─► 10% ─► 50% ─► 100% └──────────┘ └──────────┘ 一旦有 bug100% 用户遭殃 有 bug只伤 1%且被闸门拦下三种主流渐进式策略策略做法适用金丝雀Canary先放 1%→10%→… 小流量按 SLO 决定是否继续绝大多数无状态服务蓝绿Blue-Green两套环境流量整体切换出问题切回需整体验证、切换快滚动Rolling逐批替换实例量大、可接受逐批风险核心共同点用小流量 实时监控SLI/SLO替代一把梭。四、错误预算即发布闸门把博客四的错误预算用在这里最自然错误预算充足 (剩余 阈值) │ ├─► 允许发布甚至激进发布 ▼ 错误预算紧张 / 已耗尽 │ └─► 冻结非必要发布只放行修复预算的变更即预算是发的许可证不是秋后算账的账本。预算烧穿时还往全量推新版本等于明知会违约还要违约。五、实验台演示金丝雀 SLO 闸门拦下一个坏版本我们用rollout.sh模拟一次带闸门的金丝雀发布。为演示坏版本被拦下脚本在 canary 节点注入 5% 结账失败模拟新版本带的缺陷# 在能 ssh 到各节点的操作机执行bash/opt/sre-lab/rollout.sh ecs-584a-0002600.01# └canary┘ └窗口┘ └错误率闸门 1%┘脚本逻辑已落地在rollout.sh1) 在 canary 节点部署新版本写 /tmp/version 2) 模拟新版本缺陷fault.sh inject 0.055% 结账失败 3) 观测窗口内轮询 canary 结账错误率 4) 若错误率 闸门(1%) ──► 【闸门拦截】清除故障 移除新版本回滚不推广 否则 ──► 向其余节点推广预期输出演示闸门生效[rollout] 金丝雀节点ecs-584a-0002 观测窗口60s 错误率闸门0.01 [rollout] 1) 在 ecs-584a-0002 部署新版本写版本标记 [rollout] 2) 模拟新版本引入的缺陷注入 5% 结账失败仅 canary [rollout] 3) 观测窗口监测 ecs-584a-0002 结账错误率... t5s canary 错误率0.0488 t20s canary 错误率0.0501 [rollout] 4) 【闸门拦截】错误率 0.0501 闸门 0.01停止推广 [rollout] 触发回滚清除故障 移除新版本标记 [rollout] 结论错误预算/燃烧速率 作为发布闸门拦下了一个会烧穿预算的版本。这就是把错误预算从概念变成流水线里的一道真实卡点。真实生产里把第 4 步的判定接到 CI/CDcanary 期间燃烧速率越 6× 即自动回滚。六、再加两件套特性开关与 ChatOps特性开关Feature Flag代码上线但功能默认关开关独立控制放量。让部署和释放解耦——部署可以天天做释放按需、可秒级关。ChatOps发布动作与告警进群如企业微信/钉钉谁发的、发的什么、当前 SLO 如何单一信息源可追溯呼应博客六沟通。七、小结与思考题变更是故障主因SRE 不阻止变更而是让变更可灰度、可观测、可回滚、可拦截。渐进式交付金丝雀/蓝绿/滚动用小流量 SLO 监控替代一把梭。错误预算是发布闸门预算充足才放行烧穿即冻结。rollout.sh把坏版本被闸门拦下在实验台跑通了。思考题你们的上线流程里有发布闸门吗如果没有 SLO 监控金丝雀观测的是日志里有没有报错还是错误预算还剩多少后者才是 SRE 的做法。下一篇既然要验证系统抗造我们主动制造故障——聊聊混沌工程与 Game Day。