发布后错误率或延迟升高#

验证：未记录

适用版本: 未记录
验证范围: 尚未登记验证记录。

先暂停扩大新版本流量，记录变更时间、镜像 digest（内容摘要）、配置版本和数据库迁移版本。用同一业务路径、相近流量比较新旧版本；发布与故障同时发生只是线索。

1. 确认实际发布了什么#

示例适用于 Kubernetes Deployment。需要 kubectl 只读权限；恢复步骤另需更新权限。

kubectl config current-context
export NS='orders'
export DEPLOYMENT='orders-api'
export APP_SELECTOR='app.kubernetes.io/name=orders-api'
kubectl -n "$NS" rollout history "deployment/$DEPLOYMENT"
kubectl -n "$NS" get deployment "$DEPLOYMENT" -o wide
kubectl -n "$NS" get pods -l "$APP_SELECTOR" -o wide
kubectl -n "$NS" get pods -l "$APP_SELECTOR" -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{range .status.containerStatuses[*]}{.name}{"="}{.imageID}{" "}{end}{"\n"}{end}'
kubectl -n "$NS" get events --sort-by=.metadata.creationTimestamp

标签选择器必须与实际应用匹配。把 Pod 的实际镜像摘要与流水线产物对照；可变标签名相同不代表镜像相同。事件之外还需查询配置、入口路由、权限和依赖变更。

2. 根据证据选择恢复方向#

证据	优先检查	下一步
仅新版本失败、旧版本正常	配置、依赖兼容、异常日志	停止扩大，评估回到已验证版本
新旧都失败	数据库、缓存、网络、公共配置	进入数据库或网站访问；回滚应用未必有效
Pod 正常但入口 502/503	就绪端点、路由权重、终止连接	Pod 排障、HTTP 排障
延迟升高但错误率低	连接池、锁、重试、资源饱和	比较 p95（95 分位延迟）、吞吐和队列增长，不只看平均值
响应成功但数据错误/重复	业务语义、幂等、消息格式、迁移	停止受影响写入或消费者，保护数据，确定修复与对账方案

3. 回滚前的四项条件#

已确定一个真正通过业务验收的版本；不要默认“上一个版本”就是好的。
旧代码兼容当前表结构、配置、Secret 和消息格式；应用回滚不会撤销数据库迁移。
旧版本有足够容量，包含预热、连接预算和下游容量。
明确期望状态的管理者，避免 GitOps 自动协调把临时回滚覆盖。

管理方式	恢复入口
GitOps（以 Git 为期望状态并自动协调）	回退声明中的镜像、配置和流量变更，通过既有审批/同步流程发布；Argo CD
Helm 管理	审查 release 历史，按已验证 revision 回退；同时检查 hooks、外部配置与迁移副作用
原生 Deployment	满足下述条件时执行显式 revision 回滚
金丝雀 / 蓝绿控制器	使用原发布控制器停止推进或切回稳定流量；部署策略、金丝雀

只有未被 Helm/GitOps/渐进式发布控制器管理的 Deployment，才按下面操作。先审查目标历史版本，核对镜像及配置引用：

export GOOD_REVISION='REPLACE_VERIFIED_REVISION'
kubectl -n "$NS" rollout history "deployment/$DEPLOYMENT" --revision="$GOOD_REVISION"

确认历史仍保留、Deployment 未处于 paused 状态，且满足上述条件后（若已暂停，先按既有发布流程协调恢复，不能直接 undo）：

kubectl -n "$NS" rollout undo "deployment/$DEPLOYMENT" --to-revision="$GOOD_REVISION"
kubectl -n "$NS" rollout status "deployment/$DEPLOYMENT" --timeout=10m

回滚恢复 Pod 模板，不能恢复已经原地修改的 ConfigMap/Secret 内容、Service 路由或数据库数据。超时表示未完成，须继续检查事件和可用容量。Kubernetes Deployment 官方说明。

4. 用业务结果关闭事故#

从原入口验证正常业务、原失败路径、关键租户和读写结果；涉及订单/消息时做幂等与对账检查。
连续观察覆盖业务告警窗口：错误率、p95、连接池、队列、重启与目标健康恢复；低流量时补充经批准的合成检查。
把恢复后的镜像、配置和流量状态写回权威配置，记录根因与后续修复，避免下次发布再次引入。

企业演练使用真实业务发布基线与金丝雀实践，保留发布前、新版本、恢复后三份业务和监控证据；不要在生产随意制造错误版本。