CNFM升降级之故障总结

项目上线之后，因为他抱过来的故障，截止到目前为止，已经有两个了。直接后果也是导致偶本季度的故障分已经基本被扣光了。有必要总结一下了。

一、外网搬家用户搬家失败，提示“图片银行空间已满”

现象：很多用户搬家之后发布的产品都失败了，提示图片银行没空间了。可是用户明明有上百M的未使用的空间。

排查过程：

1. grep整个代码，找到系统中抛出这中业务异常的地方（有两处），进入的条件都是图片银行的接口调用之后，判断图片银行没空间了。基本定位，就是该接口处返回值有问题。
2. 进一步跟进看看方法实现，完全没问题啊，查看了SVN记录，最近此处代码根本没有被动过，况且如果真的是这里早就出问题了，怎么会等到现在才出问题呢？开始有点晕了。
3. 因为是线上问题，不能跟踪代码执行流程和结果，感觉有点束手无策了。
4. 汪汪帮我在测试环境跑了一遍搬家过程，发现没问题，于是感觉可能是个别案例，具体原因尚未明确，侥幸心理告诉我这个只是个案，于是第一天就这样结束了，告诉服务台的结果也是代码没问题，不是故障。
5. 晚上是还是觉得有点不放心的，找来了刚哥又跟我一起过了一遍代码，还是没有发现问题，不过刚哥还是给出了建议，如果明天还有这个问题，直接找图片银行的人过来一起排查，毕竟是他们的代码，他们应该更熟悉具体逻辑。至此第一轮排查结束。

周四早晨晨会之后，我就找来了图片银行的工程师跟我一块排查了一遍代码，发现其中还是有两种情况会返回0这样的空间容量的。具体跟踪进去，发现取用户图片银行默认空间大小的地方是来自某文件，忽然之间恍然大悟，因为该文件在项目中被sourcing工程师修改过以适应新的逻辑。于是去SVN对比了一下修改记录，对比代码执行逻辑，确定果然会受到影响。到这里才找到了根本原因。
为什么会发生这个故障：
直接原因就是项目发布当天没有重新发布该定时器。这也解释了为什么QA同学在测试过程中没有发生这个问题以及汪汪在测试环境中没有重现这个问题的原因，因为测试同学每次跑的时候，都相当于重新发布了一次该程序，已经是最新的了，所以压根不会再发生这个情况。当然如果当时汪汪重新跑的那个环境如果没有更新过（公用环境），理论上也会出现这个问题，但是当时没出现，有可能当时测试时候的账户是这种特定类型的，因为只修改了这种类型的配置，这个跟我没有给她提供足够的用户信息有很大关系。
如何避免这类问题：
在测试阶段，QA测试过的定时器理论上都应该重新发布一次，因为当时都是根据当时最新的代码（这里包括数据文件）来做的，如果测试没问题，只能证明在新的修改上没问题，应该重新发布，不然可能会出现在老的环境下会出现问题，这次这个案例就是最好的说明了。当然根本手段还是需要开发同学对对整个系统有足够的了解，能够及时的识别代码修改可能带来的风险，但是鉴于系统的庞大和我目前对系统的了解程度，完全做到这点还很难，况且人的记忆是会消退甚至遗忘的，所以个人觉得还是通过第一种制度上的约束靠谱一点，也更稳妥一点。
排查过程暴露的问题：

1. 初级定位问题大的方向是对的，但是没有深入细节，对别人写的代码的分析不够透彻，这点曾经见过聪妈分析代码的过程，确实值得好好学习和积累。
2. 主观上抱有侥幸心里，不然可以更早更及时的处理这个故障。
3. 在发现问题之后，虽然电话和图片银行的工程师沟通过，但还是不够彻底，当时就应该把他们揪过来一块排查问题，毕竟他们才是最了解自己东西的人。

二、原来已经断约的某类型用户在转换类型重新开通之后，发现之前发布的WS产品都不见了。
服务台刚报过来这个故障时，第一反应就是发布当天也出现过这个问题，于是直接想到这可能是sourcing方面某工程师的问题，于是让服务台直接联系他。但不久就有新的用户报来了新的同样的问题。因为当时在处理外网搬家的故障，也没有引起足够的重视。快到下班时间时，sourcing方面的工程师直接上来找我了，明确了他的涉及该处的功能还没有正式被使用， 所以不可能是他那边的问题。于是在一起分析问题的时候发现，这批重新启用的老用户都是当时直接走的数据订正的流程来完成的，因为他们都是历史数据。想起来当时我给出的数据订正的sql语句少写了一个字段的更新，这个是直接导致问题的原因。哎，又杯具楽。于是又是一通紧急的数据订正，涉及的数据量在75W条以上。
问题原因：

1. 对数据订正这种过程没有给予足够的重视，可能是因为这个没有涉及到代码的改动。但是事实证明，数据订正本身就是一项非常危险的操作过程，如果处理的有问题，会直接导致线上故障（因为直接人为操作数据）。
2. 对被订正的数据没有做充分的分析和排查，这个从根本上说也是属于第一种情况，但是作为开发，既然由自己提供订正的逻辑，就应该也有责任保证这个逻辑是没问题的。

如何避免：

1. 主观上，就是上面分析的问题的原因，自己必须给予足够的重视，并进行充分的分析，找到风险点。
2. 上面的毕竟是主观上的，也是我觉得不是完全靠得住的方法，制度上的预防手段就是认真制定预发布和发布计划，将数据订正的验证列入其中，这样保证在预发布环境就暴露这个问题，不会把问题带到线上。

总结：
任何失败的经历都是成长过程的源泉，希望在自己身上不要再次出现这样的错误，这样他们的曾经出现才是有价值的。
这里还要特别感谢Roby同学替我分担的数据订正故障，所以这个没最终被记录在案。
不过目前Q4的故障分数已经达到了自己的上限了，已经再经不起任何差错了，后面必须更加小心了，希望能够保持这里不要再发展了。