浏览 AI 知识库
上线后怎样用日志、指标和健康检查决定继续还是回滚
页面返回 200 不是发布结束。上线前先写观察窗口、关键指标和回滚阈值，发布后才知道应该继续观察、暂停还是立即撤回。
先比较关键条件，再作选择
把自己的条件代入判断项；没有证据的维度保留未知，不用印象替代结论。
刚上线一切正常，十分钟后的错误率谁来判断
发布页面返回 200 后团队立即离开。十分钟后错误率从 0.2% 升到 3%，但没有人提前写何时继续、暂停或回滚。
- 基线、窗口和阈值预先定义
- 回滚可在兼容窗口内执行
- 决定和实际指标有时间记录
发布后同时看技术健康和核心业务成功率
| 指标 | 基线 | 阈值/窗口 | 决定 |
|---|---|---|---|
| 5xx | 过去 30 分钟 0.4% | >1% 持续 5 分钟 | 暂停并调查 |
| P95 延迟 | 420 ms | >800 ms 持续 10 分钟 | 按预案回滚 |
| 登录成功率 | 99.2% | <98% 或异常集中 | 人工升级 |
| 核心提交 | 1,200/min | 下降且无流量解释 | 检查发布路径与依赖 |
阈值和基线为示例；真实观察窗需由业务/运维负责人批准。
先把本例的条件、限制和目标摆出来
| 需要确认 | 本例内容 |
|---|---|
| 现有材料 | 本次改动影响登录；基线错误率 0.2%、p95 450ms；有旧镜像和数据库兼容窗口。 |
| 不能越过的边界 | 部署成功不是观察结束；预先定义指标、窗口和阈值；回滚依据业务影响而非个人感觉。 |
| 要交付的结果 | 发布观察窗与回滚决策记录 |
部署后怎么验证，哪些条件会改变最后选择
| 判断条件 | 本例怎么核对 | 本例归类 |
|---|---|---|
| 发布基线 | 记录发布前一段时间的流量、错误、延迟、资源和业务成功率。 | 有可比较旧版本 |
| 技术健康 | 进程、实例、队列、数据库、外部依赖和关键 URL。 | 覆盖实际请求链 |
| 用户结果 | 登录、提交、支付前确认等核心流程成功率和异常反馈。 | 不只看服务器活着 |
| 观察窗口 | 定义开始、最短时长、流量要求和负责人，区分即时和延迟问题。 | 不会在样本太少时过早放行 |
| 回滚条件 | 列硬阈值、趋势、数据风险和无法回滚情形。 | 触发后能立即执行既定动作 |
部署后怎么验证：按本例条件得到的结论
发布观察窗与回滚决策记录
观察窗为 30 分钟，每 5 分钟记录登录成功率、5xx、p95 和关键日志。第 10 分钟 5xx 连续两次超过 2%，触发回滚；旧镜像恢复后指标回到基线。决策记录保留时间和证据。
边界变化后需要重新判断
低流量时固定百分比不稳定，需要同时看事件数和真实关键流程。
为什么“指标未越线，用户仍报告严重问题”还不能交付
指标未越线，用户仍报告严重问题
- 原因
- 监控没有覆盖特定地区或关键细分
- 怎么改
- 把用户报告接入观察窗，按影响范围增设分组指标和手工探测