3.5 部署与发布：离站发车

3.5 部署与发布：离站发车

试跑放行，列车驶上正式线路。部署与发布是把"能跑"变成"在跑"的最后一段，也是出事最不体面的一段——前面的错都有机会悄悄修，发布出错直接见用户。本节讲环境分级、发布检查单、灰度放量与回滚设计，核心只有一句话：先保证可回退，再追求不出错。

发车站台的分级线路

环境不是"开发机"和"生产机"两截，成熟的站台分四级，各有专职：

• 开发环境：开发者本机或共享沙箱，随便折腾，坏了就重建；
• 测试环境：自动化流水线的跑道，版本进站先在这里过联调与回归；
• 预发布环境：与生产同配置的最后一道站台，数据仿真或脱敏，发布前的彩排与冒烟在这里做；
• 生产环境：正式线路，只接受过预演的变更。

分级的意义在于把意外拦在便宜的站台。环境间最大的坑是漂移：预发布与生产配置不一致，彩排全绿、上线翻车。治理漂移的办法是基础设施即代码——环境配置写成代码入库，任何环境都能从同一段代码重建，漂移自然无处藏身（工具链详见第 6 章）。

发布检查单：离站前最后一道闸

检查单是抵御"想当然"的武器。人的记忆在高压力的上线夜最不可靠，把动作写死在纸上逐项打勾，是航空业用血换来的经验。云梯的发布检查单核心段：

发布检查单 · 版本 v2.7.0 · 申请人：后端甲
  [前置]
   □ 试跑报告结论为"可发"，遗留项已评级
   □ 变更清单与版本号核对一致（防夹带）
   □ 数据库变更脚本在预发布环境预演通过
   □ 回滚脚本就绪，回滚时长实测不超过 5 分钟
  [发布中]
   □ 灰度顺序：内部员工 → 白名单仓库 → 全量
   □ 监控大屏已开启：报错率、计费成功率、队列积压
  [发布后 30 分钟内]
   □ 核对计费抽样：随机 10 笔与人工计算一致
   □ 确认旧版本热备保留 24 小时
   □ 发布记录归档：谁、何时、发了什么、为何而发
​

注意"防夹带"与"回滚实测"两项。夹带是发布事故的高发源头——本想发三个修复，实际带上了上周一个未验的实验分支；回滚时长不实测，纸上写的五分钟现实里可能是一小时，因为没人记得旧配置怎么还原。

灰度：让风险按比例进场

全量发布等于把全部用户押注在新版本上。灰度发布把注拆开下：先放小比例流量，盯监控，无异常再逐级放量。放量的节奏没有万能公式，原则是每级停留时间足够看清该级的信号——计费系统的信号周期是账单生成，几分钟看不出来，就得等到抽样对账出结果。

图 3-4：灰度放量与回滚决策线

回滚设计：退路修在发车前

回滚的纪律只有三条：脚本化（一条命令回到上一版，不靠翻聊天记录找步骤）、演练过（回滚脚本没跑过就等于没有）、数据先行（最难回滚的从来是数据——新代码写出的脏数据要有一套清理或兼容方案）。数据库变更因此单独设卡：加列先行、双写过渡、确认后再删旧列，让代码版本与数据结构在过渡期互相兼容。

云梯上线夜的真实一幕值得记下：v2.6 全量后 12 分钟，队列积压告警触发回滚决策线，值班工程师执行回滚脚本，七分钟后旧版本恢复服务，事后定位是一处缓存键冲突。因为回滚干净利落，这次故障在用户侧几乎无感——发车成功的标志不是从不回退，而是回退时没有人在车里察觉。

发布窗口：什么时候发与怎么发同样重要

发布时机是容易被忽视的变量。云梯的两条窗口纪律：避开业务洪峰——对账服务从不在月末三天内发版，哪怕只是"小改动"；预留观察期——周五下午不发布，因为周末的值班力量撑不起一次故障的完整救援，周五发的版本要在周末独自撑过第一个夜晚。窗口纪律要写进发布检查单而不是口口相传，新成员第一次独立值班前必须读过。另一条配套纪律是变更冻结期：发布前的代码冻结窗口（比如发版前四小时），期间非紧急修复不进主干，让发车时刻的制品内容可预期——夹带事故的很大一部分，就是冻结窗口形同虚设。

数据迁移：发车单里最重的一节

带数据结构变更的发布要单独立项对待。云梯的迁移三步法：第一步兼容先行——加列先加、删列后删，新旧结构并存的过渡期让回滚永远有退路；第二步预演——迁移脚本在生产数据量的脱敏副本上实测，记录耗时与锁表行为，"开发库上秒过的脚本在生产卡死四十分钟"是老生常谈的事故；第三步回滚脚本对数据同样成立——回滚代码容易，回滚已迁移的数据才是难点，脚本必须写到"执行两遍结果一致"的幂等形态。这一节车厢超载，前面所有发布纪律都会被它拖垮。

发布类型的分级：不是每班车都一样重

发布有轻重，检查单与流程也应分级。云梯把发布分成三档：常规发布（普通功能与修复）走标准检查单与灰度；高危发布（动数据结构、动计费内核、动权限模型）加码——压测报告、数据回滚脚本、跨团队知会一样不能少；紧急修复（线上止血）走压缩通道——检查单缩成五条保命项，事后四十八小时内补全档案并复盘。分级的意义是让"该重的地方重、能轻的地方轻"，一刀切的流程要么重到没人遵守、要么轻到拦不住事故。判断发布属于哪一档的问句很朴素：这次变更如果出错，波及的是展示、是账、还是数据？波及账与数据的，自动升高危档。

两个高频疑问

问：出了事先修复还是先回滚？ 默认先回滚。线上故障的第一目标是止血，不是破案——回滚让服务回到已知的好状态，定位与修复从容地在线下做。"坚持在线上修"的每一次成功都在积累侥幸，而侥幸的利息在一次彻底翻车时结清。例外只有一种：回滚本身比故障更具破坏性（如数据已不可逆变更）——这正是前面强调迁移要幂等、要预演的原因。

问：发布检查单会不会越攒越长？ 会的，所以要定期修剪。每季度把检查单过一遍：过去半年从未拦下过任何问题的项、已被自动化覆盖的项，降级或删除；新事故的教训按复盘结论补入。检查单的健康长度以"高压夜真的会被逐项执行"为限——超过一页半，执行率必然崩塌，届时它保护的是签名，不是发车。

本节要点回顾

• 环境分四级，各自专职；预发布与生产的配置漂移用基础设施即代码根治。
• 发布检查单是高压夜的记忆外包，防夹带与回滚实测两项不可省。
• 灰度按比例放量，每级停留时长看该级的业务信号周期，不由工时决定。
• 回滚三纪律：脚本化、演练过、数据先行；数据库变更用兼容过渡降低回退难度。
• 发布成熟度看回退：干净利落的回滚比侥幸的全量成功更专业。

列车离站进入正线运营，最后一站处理返修、大修与延寿。