记录一下那天晚上的排查过程。Helm 3.12 升级一个 release 时终端被网络断开，重新执行 helm upgrade 一直报 another operation (install/upgrade/rollback) is in progress，等半小时也没自动恢复。
刚开始盯着「多个流水线同时对同一个 release 执行升级，互相抢占」，折腾了半个多小时，排掉了。
这类报错背后常见的原因有几处，逐个排除就行。上一次 upgrade 的连接断开，release 的 status 停在 pending-upgrade。也可能是Helm 把操作状态写在 Secret 里，没有超时自动清理机制。
还有一种情况，kubeconfig 指向了错误的 namespace，看到的是另一个 release 的状态。
先确认 release 当前状态
helm list -n prod -a && helm status app -n prod随后找到挂起的 Secret 记录
kubectl get secret -n prod -l owner=helm | grep pending再往下把状态回滚到上一个可用版本
helm rollback app 3 -n prod等前面都确认过，再重新执行升级并观察结果
helm upgrade app ./chart -n prod --atomic --timeout 5m怎么算真的好了，看的是同一批现象。helm status 显示 status 为 deployed，helm list 里 revision 正常递增，Pod 全部就绪，后续 upgrade 不再报操作进行中。
容易忽略的是，别直接删 Secret 来解锁，release 的历史会断；升级加 --atomic 能让失败自动回滚，流水线里还要加同一 release 的互斥锁。改动前把原配置备份一份，出问题能马上回滚，这比任何技巧都实用。