发布后监控

发布后前 24-72 小时 — 看什么、建什么仪表盘、如何区分发布峰值噪声与真实回退。

为什么

发布峰值扭曲每个指标：错误率因新流量跳升、注册数好看但可能是好奇驱动的一次性访客、首批 bug 报告是真实问题和用户误用的嘈杂混合。无结构化监控计划，团队要么对噪声过度反应（热修一个其实是功能的"bug"），要么对真实回退反应不足（只影响 2% 用户但占 100% 收入的支付失败）。发布后监控定义哪些指标是信号 vs 噪声、设定考虑流量峰值的阈值、建让你在峰值平息后看到产品真实健康的仪表盘。目标是 T+72 小时达成"稳态"判定：产品比发布前更健康，还是不？

何时使用

从 T+1 小时（发布日执行稳定后）到 T+72 小时。持续增强监控直到指标回到发布前基线或稳定在新的（可接受）稳态。

如何做

1. 建发布仪表盘 4 块：(a) 实时错误率 + 5xx，(b) 注册/转化率 vs 目标，(c) 核心动作完成率，(d) 支持工单率 + 情感
2. 定义峰值调整阈值：错误率阈值 = 基线 × (当前流量 / 基线流量) × 1.5，10 倍流量峰值暂时允许 15 倍错误预算
3. T+1 小时到 T+4 小时：每 30 分钟看仪表盘；在发布日志记录任何异常（时间戳、指标、假设）
4. T+4 小时到 T+24 小时：每 2 小时看；区分发布峰值 bug（仅影响首小时新用户）和稳态 bug（T+12 小时仍影响用户）
5. T+24 小时：写 24 小时报告 — 总注册、转化率、前 5 bug、前 5 支持问题、错误率趋势；对比发布目标
6. T+48 小时：查发布日注册的留存 — 回来了吗？好奇注册 D1 留存 < 10%，真实注册 > 30%
7. T+72 小时：稳态判定 — 错误率和核心动作率在发布前基线 ±10% 内则宣布稳定；否则排发布后热修冲刺

示例

# 发布后仪表盘 — ez4code v2.0（前 72 小时）

## A 块：错误率
T+1 小时：0.3%（峰值，阈值 1.5%）  → 正常
T+12 小时：0.08%（趋稳）           → 正常
T+24 小时：0.05%（基线 0.04%）     → 正常
T+72 小时：0.04%（达基线）         → 稳定

## B 块：注册
目标：200  实际：1,247（6.2 倍）
D1 留存：38%（健康，> 30% 阈值）

## C 块：核心动作（项目部署）
完成率：71%（目标 60%）
首次部署中位时间：4.2 分钟

## D 块：支持
工单：72 小时 23 条（最多："如何连接 GitHub"）
情感：89% 正面

## 24 小时报告
注册 1,247 | 转化 12.4% | 头号 bug OG-404（T+3 小时修）
=> T+72 小时发布稳定

常见问题

⚠峰值期用发布前错误阈值 — 基线流量下对的 0.1% 阈值在 10 倍流量下持续误报；为峰值调阈值否则喊狼来了而忽略真实告警。
⚠把发布日注册当"成功"而不查 D1/D7 留存 — 5000 好奇注册 2% 留存比 500 注册 40% 留存更差；要的指标是留存用户非注册数。
⚠把每个支持工单当 bug — 发布用户问"怎么做 X？"是文档缺口非代码 bug；热修前把工单分 bug vs 文档缺口。
⚠T+24 小时停监控因为"看起来好"— 只影响回访用户的回退在 T+48 小时首批用户回来时才出现；72 小时是最小稳定窗口。

最佳实践

✓发布日前建好发布仪表盘而非期间 — 仪表盘在 T-1 天就绪并显示 staging 数据，T+0 是"切到生产数据"而非"压力下建面板"。
✓前 72 小时给每个注册打"发布队列"标，后续周可比发布队列留存 vs 基线队列留存 — 这是发布质量的真正度量。
✓开专用发布日志频道（Slack/Linear），每个异常、决策、修复带时间戳；它成为发布后复盘的原料，防止"我们为什么做 X？"失忆。
✓发布时就把 T+72 小时稳态评审排进日历而非之后 — 不排评审监控就退回"有人注意时"而稳态判定永远不做。