合并后观察是什么
合并不是评审的终点：高风险改动在发布之后要盯一段时间的关键指标与告警，确认实际行为符合预期；一旦发现问题，优先快速回滚而不是现场修补。事后把线上结果反馈回评审清单，评审判断才会一次比一次准。
基本信息
| 观察窗口 | 发布后对照错误率、延迟与关键业务指标 |
|---|---|
| 前置准备 | 合并前明确回滚方式与回滚会丢失什么 |
| 闭环动作 | 把线上问题反查评审清单，更新检查项 |
| 特别关注 | 评审通过但线上失败的案例 |
典型使用场景
- 涉及数据迁移：发布后核对行数与抽样内容
- 调整缓存与并发参数：盯错误率与延迟曲线
- 修改权限与鉴权：检查拒绝率与异常登录
- 升级依赖或版本：观察资源占用与超时指标
- 事故复盘：把评审为什么没发现作为固定问题
观察期要准备什么
- 回滚脚本与回滚判定条件
- 关键指标看板与告警阈值
- 值班人与问题升级路径
- 变更记录与时间点，便于前后对照
发布后的对照检查
发布后的对照检查
# 变更时间点前后对照错误日志数量
kubectl -n prod logs deploy/order --since=30m | grep -ci error
# 确认线上版本与预期一致
git log --oneline -1
# 异常时先回滚到上一个已知良好版本，再定位根因线上表现与反查方向
| 线上表现 | 反查评审清单 |
|---|---|
| 配置默认值不符合预期 | 检查配置项是否纳入评审范围 |
| 边界输入导致报错 | 检查边界条件与异常路径是否要求测试 |
| 并发下数据不一致 | 检查并发与共享状态是否列入检查项 |
评审判断的校准来自线上结果：把发布结果回看进评审质量闭环，才算完成一次完整的评审。
观察期长度按影响面定：文案与小工具类改动可以短一些，涉及数据与权限的改动需要覆盖至少一个业务周期。
把观察结果写回改动记录：无论是否出问题，后来者都能知道这次改动上线之后的真实表现。
合并即失联：发布后没有人看指标，异常只能靠用户投诉才会发现。