上线后怎样用日志、指标和健康检查决定继续还是回滚

上线观察窗在部署前就要定义

如果发布后才决定看什么，团队容易只盯 CPU 或首页。先选能反映可用性、性能、错误和核心业务的指标，并写继续、暂停和回滚阈值。

发布基线

记录发布前一段时间的流量、错误、延迟、资源和业务成功率。

通过标准：有可比较旧版本

把涉及的文件、目录、版本、命令和实际输出写进记录；代码变化同时保留 diff 与测试结果。

技术健康

进程、实例、队列、数据库、外部依赖和关键 URL。

通过标准：覆盖实际请求链

确认“技术健康”已经有可回查结果，再进入“用户结果”；依据仍然来自猜测时，把缺口单列并停在当前步骤。

用户结果

登录、提交、支付前确认等核心流程成功率和异常反馈。

通过标准：不只看服务器活着

确认“用户结果”已经有可回查结果，再进入“观察窗口”；依据仍然来自猜测时，把缺口单列并停在当前步骤。

观察窗口

定义开始、最短时长、流量要求和负责人，区分即时和延迟问题。

通过标准：不会在样本太少时过早放行

确认“观察窗口”已经有可回查结果，再进入“回滚条件”；依据仍然来自猜测时，把缺口单列并停在当前步骤。

回滚条件

列硬阈值、趋势、数据风险和无法回滚情形。

通过标准：触发后能立即执行既定动作

需要修改时先限定文件和行为范围，无法说明回滚方式或影响面的动作先不执行。 完成后把证据归入“发布观察窗与回滚决策记录”。

发布决策要记录证据和时间

继续、暂停或回滚都写指标、对照、责任人和后续动作。没有触发阈值但仍有用户异常时，保留人工升级通道。