发布后的 24 小时：观察窗口、回滚判据与冻结期

上线那一刻最危险，因为你什么都不知道。

一、发布当晚没人看

司南在周五晚上八点发布了新版本，改动包括一次数据库字段重命名。他本地测过，预览环境也测过，然后关掉电脑去看电影。

周六上午，错误率 4.2%，是一百多个导出请求全部失败。回滚只用了十二分钟，但那批用户已经在群里讨论了一晚上。

以下情境为教学假设，人物、引语和数字不代表经核实的真实案例。

发布后的第一个小时，信息量最大。 新代码在真实流量下的表现，任何测试环境都给不了。

观察要有时间盒。 没有边界的观察会变成焦虑，也会挤掉当天其他工作；四个窗口就是四个盒子。

回滚不是失败。 它是发布流程里的一个正常分支；把回滚当耻辱，就会拖到故障扩大才做。

二、四个观察窗口

不同窗口看不同的东西。

0–15 分钟只看三个数。 看太多会错过窗口；错误率、延迟、探针，三分钟刷新一次就够。

三个数要能在一屏里看完。 分散在三个系统里，你会花十分钟找数，只剩五分钟判断。

1 小时看业务结果。 技术指标正常但付款成功率掉了，仍然要回滚；技术指标只是代理。

24 小时看新错误组。 发布引入的错误往往在低频路径上，第二天才浮出来。

7 天看业务指标。 有些问题不报错，只是转化变差；一周的同日对比能看出来。

三、回滚判据与冻结期

判据要提前写，不能临场讨论。

错误率基线 = 0.4%，回滚阈值 = 1.0% = 基线的 2.5 倍
P95 基线 = 800 ms，回滚阈值 = 1600 ms = 基线的 2 倍
回滚耗时 ≈ 12 分钟；热修耗时 ≈ 40 分钟
因此：超过阈值先回滚，再决定要不要重新发
4 次/月 × 45 分钟观察 = 180 分钟 = 3 小时
占 4 小时预算的 75% → 改为双周发布：2 × 45 = 90 分钟（37.5%）

先回滚再分析，是算术结论。 12 分钟与 40 分钟的差距，意味着多犹豫半小时就多亏半小时。

回滚后不要立刻重发。 先复现、修好、在同一条路径上验证，再发；当天重发通常会把同一个问题带回来。

阈值要用基线倍数，不用绝对值。 换一个产品，1.0% 可能太松也可能太紧；2 到 2.5 倍是通用起点。

冻结期要写进日历。 周五 15:00 之后、节假日前一天、自己出差的日期，一律不发；紧急修复除外，且必须有人盯满 24 小时。

冻结期也要覆盖数据变更。 不发版但改配置、改字段同样有风险；这类操作也进冻结清单。

回滚要演练。 半年没回滚过，真要用时可能发现脚本已经坏了。

回滚也要看数据。 新版本写过新字段，回滚后旧代码可能读不了；涉及数据变更的发布要单独评估。

四、发布成本与节奏

发布是有成本的，成本要记进运维预算。

每次发布 45 分钟。 包括发布前检查 10 分钟、0–15 分钟观察、1 小时窗口的回看，以及发布后的记录。

每月 4 次就是 3 小时。 已经占掉 4 小时预算的 75%，剩下的 1 小时要留给告警与巡检。

改成双周发布，观察成本减半。 2 次 × 45 分钟 = 90 分钟，代价是每次发布的改动更大，回滚风险上升。

折中是「小步 + 双周」。 每次改动小，但节奏放慢；比每周大改更安全。

紧急修复不计入节奏。 它属于事故处理，应该单独记账；把紧急修复算进常规发布，会掩盖真实成本。

发布记录要留。 版本号、改动、观察结果、是否回滚，四行就够；下次出问题能对照。

记录里要写「下次注意」。 一句话就够，但必须是具体动作，比如「涉及字段重命名的发布放到周二」。

五、行动清单与复算验收

把判据写在发布清单里，而不是记在脑子里。

• 写下错误率与延迟的基线值。
• 为五个信号各定阈值、持续时间与动作。
• 在发布脚本里加一条回滚命令，并测试一次。
• 规定 0–15 分钟只看三个指标。
• 设置周五 15:00 后的发布冻结期。
• 每次发布记录版本、改动与观察结果。
• 每月统计发布次数与观察总耗时。
• 涉及数据变更的发布单独评估回滚可行性。

验收标准：发布后十分钟内，你能根据预先写好的阈值判断该回滚还是继续观察；做不到，说明你的发布还靠感觉。

使用边界与实操验收

本文处理的是发布后的观察与回滚，不涉及构建、签名与商店审核。

构建与签名不归本文。 CI、安装包与商店审核在交付专题里；本文从「新版本已经对用户生效」开始。

灰度发布不归本文。 有灰度能力时，先放 1% 再全量，观察窗口可以更短；一人产品常常没有这层能力。

回滚不等于恢复。 数据写坏、消息已发、邮件已出，回滚代码也收不回来；这类发布要额外准备。

别用「再等等看」代替判据。 犹豫的每一分钟都在扩大影响面。

观察时间要保护。 发布后立刻去开会，等于没有观察；把 15 分钟写进日历。

冻结期要有例外流程。 安全修复必须能发；例外要记录原因与盯守人。

发布节奏要匹配用户。 B 端客户在工作日使用，周五发布等于把风险留给最冷清的时间。

关键参考与核验范围

核验日期：2026-10-25。以下链接用于核对发布与回滚的一般做法，本文未逐条引用其内容。

• Google SRE：发布工程 ：用于核对发布流程与回滚的基本结构。
• Google SRE Workbook：金丝雀发布 ：用于核对分阶段放量与观察窗口的做法。

引用口径。 本文只借用「分窗口观察 + 阈值触发回滚」这一一般结构；0.4%、1.0%、800 ms、45 分钟与 12 分钟全部是教学假设，与上述材料无关。

核验范围。 核验的是「五个信号能否支撑一次回滚决策」，不是比对某家发布平台的功能。

如何自行复核。 取上一次发布，回看当时有没有在 15 分钟内看三个指标；没有的话，把观察写进发布清单第一行。

系列导航

• 上一篇：第三方依赖运维：供应商挂了，你怎么办
• 下一篇：事故响应与复盘：五分钟止损、一天说明、七天复盘
• 回到目录：一个人的运维：可用性、告警、事故与值班
• 相关阅读：版本节奏与回滚：发布列车、兼容窗口与一次撤回