本篇要回答的问题：在"变更是故障之源"的前提下，如何建立一个既快又稳的发布流程？答案由三件套构成：发布检查列表 + 灰度发布 + 专职的发布协调团队（LCE）。
本讲是一篇加餐，承接"49 | 发布、升级与版本管理"，谈发布的工程实践。它不是新的架构推演，而是把"如何在高频发布下兼顾效率与质量"落到可操作的清单与机制上。互联网公司之所以能高频发布，是因为只需在服务端发布、无需推送到每台用户电脑——但高频也意味着发布流程本身必须被精简、固化、自动化。
为什么要有发布流程？
凡是由业务需要而主动发起的软硬件升级与配置变更，统称为发布：换/升级交换机、换/升级基础软件（OS、负载均衡、数据库）、升级业务软件、调整配置项。其中"版本发布"（升级业务软件）最常发生、最受关注。
关键判断：发布流程的价值与发布频率成正比。每三年发一次的公司不需要详细发布流程（优化收益太小）；而每天发布很多次的公司，必须维护一个效率与质量兼顾的精简发布流程。
一个特例：若集群对扩缩容有良好自动化支持（尤其硬件已池化），增减服务器是标准化低成本操作，可不视为变更、不走发布流程。
精简发布流程需要两根支柱：
| 支柱 | 角色 | 说明 |
|---|---|---|
| 发布平台（系统） | 把反复遇到的问题及其解决方案固化进系统 | 但系统不能解决所有问题——变更总有未知的新东西，需人工判断 |
| 发布协调小组（人） | SRE 下的专职团队，成员为 LCE（Launch Coordination Engineering，发布协调工程师） | 为每个业务维护"发布检查列表"，检查点全部确认才放行 |
建立在系统之上的灰度发布
无论检查多全面，都只能减少而非消除风险（测试环境≠生产环境，且覆盖率不可假设）。因此任何发布都应灰度进行，并穿插校验步骤。
| 阶段/机制 | 含义 | 要点 |
|---|---|---|
| 金丝雀（Canary） | 发布第一阶段，先在一台/几台机器上线并严密监控 | 类比矿工带金丝雀下井探毒气；适用于软件版本与配置变更，校验期出问题则自动回退 |
| 逐步放量 | 无异常则扩大机器规模，再监控，直至全量 | —— |
| 功能开关 / AB 测试 | 灰度思想的自然延伸 | 用于无法在测试环境模拟、或真实环境仍有不可预知情况的场景 |
关键洞见：灰度的理念不局限于软件——高成本的商业运营活动也常先在一两个地区做实验，再复制到全国。
AB 测试框架通常需满足：
- 可同时发布多个变更，每个变更只对部分服务器/用户起作用；
- 可灰度到指定比例（如 1%）；
- 出现严重 Bug 时可迅速单独屏蔽某个变更；
- 能用数据度量每个变更对用户体验的提升。
LCE 的职责
LCE 团队管理发布流程，确保又快又好。
| 职责 | 说明 |
|---|---|
| 审核新产品/内部服务 | 确保可靠性达标，不达标则给出具体改进建议 |
| 团队联络纽带 | 在发布过程中连接多个团队 |
| 跟进技术问题 | 负责发布系统相关的所有技术问题 |
| 守门人 | 决定某次发布是否"安全"、是否放行 |
关键判断：LCE 的技术要求与普通 SRE 相同，但要打交道的外部团队很多，因此沟通与领导能力是其更突出的硬要求——要聚合分散团队达成共同目标、处理冲突、为研发提供指导。
发布检查列表：七个维度
发布检查列表是可靠发布的核心工具，一个完备清单通常覆盖七个方面：
| # | 维度 | 关注点 / 典型问题 |
|---|---|---|
| 1 | 架构与依赖 | 是否正确使用基础设施、依赖方容量是否足够；请求流顺序如何？是否隔离了非用户请求？单页可能触发后端多少请求？ |
| 2 | 集成与公司最佳实践 | 服务是否遵循内部生态（建机、配服务、监控、负载均衡、DNS）的统一指导 |
| 3 | 容量规划 | 新功能初期常有尖峰用量（可能需预留 15 倍以上容量），灰度可建立信心；是否与发布会/广告/博客等推广相关？预计流量与增速？资源是否到位？ |
| 4 | 故障模式 | 逐组件分析故障影响范围；能否承受单机/单数据中心/网络故障？能否抗 DoS 与恶意输入？是否有过载保护？依赖故障时能否降级运行、自动恢复？ |
| 5 | 客户端行为 | 同步间隔（60s vs 600s 差 10 倍负载）；重试需指数退避 + 抖动，4xx 一般不重试；自动请求要加随机性以避免惊群（如凌晨 2 点集中下载） |
| 6 | 流程与自动化 | 发布不能完全自动化（那是灾难性的）；减少单点故障源（含人）；手动流程要文档化，使任何成员都能在紧急事故中处理 |
| 7 | 外部依赖 | 识别不受公司控制的第三方代码/数据/服务；提前为其故障、Bug、安全问题做准备；是否有合作伙伴依赖你、需提前通知？ |
关键洞见：客户端的"重试风暴"与"惊群效应"是高频发布下最隐蔽的杀手——抖动（随机延迟）与指数退避是把同步性打散的标准解药。
总结
保障发布"又快又好"的正确做法，不是为快而省流程，而是在不断的发布实践中把每个环节做得更快更有效率。机制上由三件套支撑：把已知问题固化进发布平台、用灰度（金丝雀/AB）控制未知风险、由 LCE 团队用发布检查列表做最后守门。
先把"是什么"回答清楚
| 概念 | 一句话说明 |
|---|---|
| 发布 | 由业务需要主动发起的软硬件升级与配置变更（变更即故障之源） |
| 发布检查列表 | LCE 为每个业务维护的检查点清单，全部确认才放行 |
| 灰度发布 / 金丝雀 | 先小范围上线并监控，无异常再逐步放量，异常自动回退 |
| AB 测试 | 灰度思想的延伸，用数据度量变更对体验的影响 |
| LCE | 发布协调工程师，发布流程的守门人，强沟通能力 |
| 抖动 / 指数退避 | 给重试与周期任务加随机延迟，避免惊群与重试风暴 |
一句话速记
把已知问题固化进发布平台、用金丝雀灰度控住未知风险、让 LCE 拿着检查列表做守门人——这就是高频发布下"又快又稳"的标准答案。
几条值得记住的判断
- 发布流程的价值与发布频率成正比：高频才值得为流程优化投入。
- 任何危险都只能最小化、不能消除，所以一切发布都应灰度。
- 发布不能完全自动化：变更总含未知新东西，需保留人工判断的守门环节。
思考题
回到你自己的服务：当一次发布在生产环境暴露问题时，你能在几分钟内单独回退这一个变更吗？你的客户端重试逻辑里，有没有指数退避与随机抖动，足以避免在故障时把服务彻底压垮？
