一起离奇数据丢失案件引发的思考

最近生产环境出了一起数据离奇丢失案件,调查过程很曲折,几度进入死胡同…下面跟大家分享整个事件的来龙去脉。

数据丢失案件

8月初,用户批量导入了一批(300+)委托人数据,导入后检查过数据都没有问题。最近(10月中),处理那些委托人的时候,发现所有委托人的某几个列表(list)类型的自定义字段的值都没有了…

这是用户报过来的问题,客户对此特别紧张,涉及到数据丢失,那是优先级非常高的!

团队随即展开调查。

背景信息

委托人的信息存在于两个系统中:从A系统导入,存入A系统的数据库,同时会有同步机制把数据同步到B系统的数据库;在B系统也可以修改这些数据,修改完会同时写入A、B两个系统。

问题排查过程

  1. 团队第一反应是怀疑双写和同步之间出了问题,但仔细想想好像没法成立…
  2. 怀疑B系统的用户有不当操作,把数据抹去了。但是,通过检查数据变更event,没有发现来自B系统的event…况且,现在是一批数据都没有了,B系统并没有批量操作的入口…
  3. 是不是A系统进行过批量操作,导致数据被重写?开发人员看代码,测试人员尝试重试各种相关场景,也是没有成功。同时,从event里也没有找到跟这批委托人相关的任何可疑event…
  4. 会不会是第三方的系统写入导致数据没了?随即查看第三方的api和相关event,也是没有找到任何可疑迹象…
  5. 能想到的用户相关操作都试过了,也没有任何相关event的记录,难道是直接运行SQL脚本了?客户的相关人员不会无故去运行脚本,怀疑可能我们提供的某次修复生产环境问题的脚本搞得鬼…查看最近这段时间的脚本记录,大家放心了,没有脚本会导致数据丢失!
  6. 真的是见鬼了!怎么可能数据就这么莫名其妙的丢了呢?!调查小组几经折腾已经筋疲力尽了,请来了小陈同学。
  7. 小陈同学听了前面的排查过程,好像真的天衣无缝,但他还是不甘心,决定再去看看event和log。他重新查了前面提到的那些委托人相关的event,的确没有发现任何可疑。又仔细看了看用户报过来的问题,竟然只是list类型的值丢失了!这一定有什么不对!他赶紧去查看那几个list字段相关event,终于真相大白了!原来是有用户把list里的选项删除又重新以不同顺序添加了一遍,从而导致原来用这些选项的字段值都没有了!(该用户应该是觉得原来顺序不合适……)

我的思考

找到了罪魁祸首,这个案件也就侦破了,日子又恢复了往日的平静。作为QA的我,除了记录下这个过程,也想分享一下我的思考:

  1. 数据丢失通常都会比较严重,一般不可恢复或难以恢复,给企业和用户都会带来损失。团队接到这种问题务必引起重视,投入足够的人力去进行调查,如果一波人查到走投无路的话,要及时求助外部力量,往往旁观者清,可能会事半功倍,带来不一样的效果。
  2. 调查过程需要结合业务、开发和测试人员的力量,考虑可能会影响的业务场景,从界面操作和系统代码两方面入手,同时排查各种可能性。前面的调查过程大家看着可能觉得挺轻松的,事实上排查各种可疑场景不是一件轻松的事情,因为对于一个复杂系统来说,不是很容易想到每一个场景的…
  3. 对于丢失数据的字段本身也是可由用户添加删除的情况,一定要想到还有可能是字段本身被删除了!同时,这里也暴露一个设计和实现上的问题,对于这种字段选项的调整会导致数据丢失的情况,竟然不给用户任何提示…这是需要注意的,后续再有类似的字段一定不可以由用户自由的删减!
  4. 日志记录非常重要,而且要记录足够的、清晰的信息,方便对问题的调查。
  5. 数据库脚本用版本控制工具管理非常有必要,出问题的时候,执行过的任何脚本都有利于帮助排查可疑情况。

一起离奇数据丢失案件引发的思考》有2个想法

  1. 浩鲸

    那么问题来了,为什么删除的时候有event,新增的时候没有event呢?

    回复
    1. 林冰玉 文章作者

      对于字段本身的添加和删除都有event哈,只是之前的调查都在关注字段的值,没有关注到字段本身…

      回复

发表评论

电子邮件地址不会被公开。 必填项已用*标注