最近的两个发布回滚问题分析：一定要重视细节

1：一次是因为log.error()，后台日志报出大量的ERROR，虽然前台页面功能没有任务影响，但后台的日志文件要爆了，IO量过大。原因是程序员在CATCH一个异常后，直接打log.error(),而且ERROR MESSAGE直接就是把stack抛出。这个CATCH会发生在99%的用户修改产品的场景，逻辑存在问题。新功能，新字段增加时，一定要考虑老的业务。99%的时候会走到老业务场景时，程序就会走到异常，然后打log。异常抛出要考虑一下逻辑，像这种99%的情况走到log的场景，一定是逻辑上要处理掉的，不能用CACHE来处理；
2：预发布环境发现用户产品迁移时速度很慢，一个用户的产品只有一百个，去迁移了半小时。测试环境 时，一切都正常，检查程序也正常。后来发现SQL有性能问题，追问下去才知道，SQL REVIEW过了。但又作了小修改，没有再次提交DBA 进行SQL REVIEW。而这个SQL影响只是加了一个WHERE条件，这个条件加上后影响了ORCAL的索引引化，加上生产库的数据量是测试环境的几百倍，所以性能问题出现。又一教训。
这两个问题都是开发质量的问题，如何提高开发的质量意识，是一个问题。

一种包依赖引发的通宵发布与回滚

引用来自架构组姚明同学的邮件：

Intl-biz/wsproduct里面的代码修改如下：

public void setIndByAll(Integer indByAll) → public void setIndByAll(Integer indByAll, Object… objects)

对应于intl-biz/wholesalesearch里面的代码：

WsProductDO.setIndByAll

由于intl-biz/wholesalesearch是依赖于intl-biz/wsproduct，但是无论Intl-biz/wsproduct里面的代码是否修改，都是能编译通过的。

那么问题出在哪里呢？问题出在方法签名不一样。

这里，我们的编译脚本有一个致命问题：

我们的编译脚本是先编译了intl-biz/wholesearch，这时候对应的方法签名是：WsProductDO.setIndByAll(Ljava/lang/Integer;)

接着才编译了intl-biz/wsproduct，这时候这个方法签名发生了变化，变成了WsProductDO.setIndByAll(Ljava/lang/Integer;[Ljava/lang/Object;)

所以到线上的时候，intl-biz/wholesearch需要的是前者，但是intl-biz/wsproduct提供的却是后者，所以出现了大家看到的异常。

我的看法：

1. 减少不必要的包依赖；可以走远程服务的走远程服务；
   
2. 底层有变动接口签名，一定要通知相关方，当我们改的人不知道相关方有哪些团队时，一定要在发布群里说一下，并找架构组同学REVIEW；架构组同学的信息会比较全面一些；
3. 发布时的编译顺序很关键，这个编译顺序列表要随时维护；