发布观察期是什么
发布完成不等于发布结束：观察期是发布后的一段集中盯盘窗口，指定观察人与值班共同看关键 SLI 与业务指标，确认新版本在真实流量下稳定后，才把这次变更判定为完成。窗口内的处置路径要事先明确：继续观察、修复转发还是直接回滚，各有触发条件。把退出条件写清楚，能避免「发完就走、问题第二天才爆」。
基本信息
| 观察对象 | 错误率、延迟、饱和度、核心业务转化 |
|---|---|
| 时长 | 按业务风险设定，常见 30 到 120 分钟 |
| 角色 | 发布人与值班共同观察，明确升级与回滚决策人 |
| 退出条件 | 窗口内指标正常且无新增告警 |
| 记录 | 观察结论与决策写进发布记录 |
| 失败出口 | 关键指标越线即触发修复或回滚预案 |
观察检查项
观察检查项
5xx 速率与发布前基线对比 # 先看有没有整体抬升
P95 / P99 延迟对比 # 分位数比均值更能暴露问题
业务指标：下单、支付成功率 # 技术指标正常也别漏业务口径
日志错误关键词与新增异常类型 # 新出现的异常栈优先看
资源饱和度：CPU、连接池、缓存命中 # 慢启动组件看这份
观察结论：正常 / 异常及处置 # 写进发布记录再收工典型使用场景
- 高风险发布：支付、登录等核心链路上线后强制进入观察窗
- 夜间或周末发布：人力薄，用明确检查项代替口头盯守
- 灰度放量暂停点：每提升一档流量前先观察一档
- 事故归因：观察记录成为「发布是否与故障相关」的证据
- 新人发布陪跑：老手带新人按清单逐项过，降低漏项
- 大促封网前：封网前最后一次发布的稳定性确认
观察维度与越线动作
| 维度 | 看什么 | 越线处理 |
|---|---|---|
| 错误率 | 5xx 与异常比例对齐基线 | 明显抬升即停止放量，评估回滚 |
| 延迟 | P95 / P99 与慢查询 | 持续劣化先查依赖与资源，再决定去留 |
| 资源 | CPU、内存、连接池、缓存命中 | 饱和且不断上升时提前干预 |
| 业务 | 下单、支付、核心转化 | 技术指标正常也要按业务口径核对 |
| 日志告警 | 新增异常类型与告警 | 新出现的错误默认相关问题，逐条归因 |
观察期内不做无关变更：保持环境稳定，减少互相干扰的变量。
观察人要在有权限且能联系到的状态下值班，否则发现问题只能干等。
慢启动系统（缓存预热、连接池爬坡）把观察期拉长：这些问题常在标准窗口结束后才显现。