你是指发版中有人使用系统出现异常吗？有做滚动更新的发布策略吗？

避免不了，可容忍；

谁 XX 的来告诉我，什么 XX 的叫 XX 的发版 Bug

线上缺陷避免不了，只能在前期尽量把危害程度高的都规避下，真的发生了也只能按严重程度响应。
比如线上出了资金问题，那就只能紧急回滚 + 范围评估 + 损失评估 + 复盘 + 跑路

发布上线后 出现的 BUG

我们也头疼这种发版 bug
原因 1：代码分支错了 2.运维部署问题 可是这 2 种都跟测试没有关系

一般发版之前重新拉一个代码分支然后进行回归测试，测试如果有问题再修改，一般是一周左右的时间，这个时候其实就是过一下 bug，验证正确就好了，自动化将常用功能跑一下，然后定版。因为我们是做平台，发版之后项目组升级，有问题开发会在版本和快照上修改，验证好之后，大概一到两周之内发补丁包

先归因看先都有哪些类型吧？然后专项治理

所以，这个意思是指所有线上 bug ，还是发版这个动作引起的线上 bug ？

这两个差异挺大的。

虽然没有直接关系，但只要是会频繁造成线上 bug，不管是推动其他部门解决还是自己部门内解决，测试还是有责任想办法规避的吧。

针对原因 1，可以在上线部署环节，加一个测试审核，测试确认代码分支有没有错，有没有夹带一些测试不知道的变更上去。

针对原因 2，看是运维手工操作导致的问题，还是本身上线计划有遗漏导致。
如果是前者，可以推动运维前期做线上操作双人制（1 人操作，1 人 review，降低犯错概率），甚至建设自动发布的平台，减少人工操作，避免出错；
如果是后者，那上线计划测试多加一个审核，以及在上预发布这种类生产环境时就用这个计划演练一遍，确认下有没有遗漏。