项目上线之后,因为他抱过来的故障,截止到目前为止,已经有两个了。直接后果也是导致偶本季度的故障分已经基本被扣光了。有必要总结一下了。 一、外网搬家用户搬家失败,提示“图片银行空间已满” 现象:很多用户搬家之后发布的产品都失败了,提示图片银行没空间了。可是用户明明有上百M的未使用的空间。 排查过程:
为什么会发生这个故障: 直接原因就是项目发布当天没有重新发布该定时器。这也解释了为什么QA同学在测试过程中没有发生这个问题以及汪汪在测试环境中没有重现这个问题的原因,因为测试同学每次跑的时候,都相当于重新发布了一次该程序,已经是最新的了,所以压根不会再发生这个情况。当然如果当时汪汪重新跑的那个环境如果没有更新过(公用环境),理论上也会出现这个问题,但是当时没出现,有可能当时测试时候的账户是这种特定类型的,因为只修改了这种类型的配置,这个跟我没有给她提供足够的用户信息有很大关系。 如何避免这类问题: 在测试阶段,QA测试过的定时器理论上都应该重新发布一次,因为当时都是根据当时最新的代码(这里包括数据文件)来做的,如果测试没问题,只能证明在新的修改上没问题,应该重新发布,不然可能会出现在老的环境下会出现问题,这次这个案例就是最好的说明了。当然根本手段还是需要开发同学对对整个系统有足够的了解,能够及时的识别代码修改可能带来的风险,但是鉴于系统的庞大和我目前对系统的了解程度,完全做到这点还很难,况且人的记忆是会消退甚至遗忘的,所以个人觉得还是通过第一种制度上的约束靠谱一点,也更稳妥一点。 排查过程暴露的问题:
服务台刚报过来这个故障时,第一反应就是发布当天也出现过这个问题,于是直接想到这可能是sourcing方面某工程师的问题,于是让服务台直接联系他。但不久就有新的用户报来了新的同样的问题。因为当时在处理外网搬家的故障,也没有引起足够的重视。快到下班时间时,sourcing方面的工程师直接上来找我了,明确了他的涉及该处的功能还没有正式被使用, 所以不可能是他那边的问题。于是在一起分析问题的时候发现,这批重新启用的老用户都是当时直接走的数据订正的流程来完成的,因为他们都是历史数据。想起来当时我给出的数据订正的sql语句少写了一个字段的更新,这个是直接导致问题的原因。哎,又杯具楽。于是又是一通紧急的数据订正,涉及的数据量在75W条以上。 问题原因:
任何失败的经历都是成长过程的源泉,希望在自己身上不要再次出现这样的错误,这样他们的曾经出现才是有价值的。 这里还要特别感谢Roby同学替我分担的数据订正故障,所以这个没最终被记录在案。 不过目前Q4的故障分数已经达到了自己的上限了,已经再经不起任何差错了,后面必须更加小心了,希望能够保持这里不要再发展了。 |