【工作随笔】两个线上问题（不停机发布&大型字符串hashcode出现负数）以及解决方案

      自从去年11月入职新公司后，工作职责突然扩大了，不仅仅是测试开发，连部分QA的活也干了，这其中就包含了线上发布。

      说实话，从11年工作到现在，第一次接触到项目发布，然后就发现了几个比较有纪念性的问题：

      问题一 ：不停机发布 && 没有关闭服务入口导致脏数据。

      系统架构：    我们这个系统是用户通过web调用service，service做用户登录校验和各系统调用，business系统就是其中一个系统。

     系统使用情况: 这个系统是给公司经销商和内部人员用，用户不到1500，使用频率更是一月5~6次。

      以前提发布流程，我都是只提单要求发布对应服务。这次也不例外，直接部署business。没想到碰巧有个经销商在提报活动，根据后来我查数据以及比对代码，代码是已经走到business的事务里，调用了额度系统，准备调用审批流程系统时，服务恰好重启，即如果审批流程系统没有数据，这个事务也没了，活动表也就没有数据。我们business做的事务一致性只能保证其他服务挂了时会回滚数据，自己系统重启就只能毫无办法，我们系统也没有定时任务给重要的数据做数据一致性检查，所以这个问题直到昨晚因为经销商一个普通咨询才发现。 综合考虑，这种问题还是在发布的时候就可以防范，发布时直接先把web停了，发布好business再启动web，左右不过几分钟的事，却能避免一些诸如：经销商钱被吞了一部分这种大问题。

 

       问题二：一个线上才会出现的问题。

      公司重质量重视到严格执行测试流程的地步，不压缩测试时间。所以这个变更我是在release分支测试结束后，代码反合再合并到master分支后回归测试主流程，都没问题。发现线上后，借了业务账号再试，结果发现了一个坑。流程系统在流程拒绝后不发消息了，因为开发为了让不同系统发出的消息有顺序的被业务系统消费，将非数字型code取hashcode再排序，由于线下数据少，不会出现问题。线上数据多，code取hashcode后变负数，就不发消息了。   这个问题通过黑盒测不到，因为这个不是业务需求，只能通过代码走查方式了提前发现。再不然就是等用户发现不对后，前来反馈。

 

     解决方法：

       项目开发过程中，需求文档只能作为方向，具体小细节还是每个开发人员自己定，这就导致了有些问题测试发现不了，上面的问题二就是这种情况。至于停机发布，我所经历的项目都没有停机发布过，最多是选择一个用户使用频率低的时间范围发布，所以问题一的情况也避免不了。 

      既然问题无法从源头解决，那可以换个思路，启用数据检查机制。就像人类无法让自己不生病，但是可以定期体检一样。可以使用脚本或者存储过程对数据库里重要的那部分数据进行定期检查，检查时间则参考各个项目。