一起离奇数据丢失案件引发的思考
The following article is from BY林子 Author 林冰玉
（给数据分析与开发加星标，提升数据技能）
来源：林冰玉
https://www.bylinzi.com/2019/10/24/how-to-solve-data-lost-issue/
最近生产环境出了一起数据离奇丢失案件，调查过程很曲折，几度进入死胡同…下面跟大家分享整个事件的来龙去脉。
数据丢失案件
8月初，用户批量导入了一批（300+）委托人数据，导入后检查过数据都没有问题。最近（10月中），处理那些委托人的时候，发现所有委托人的某几个列表（list）类型的自定义字段的值都没有了…
这是用户报过来的问题，客户对此特别紧张，涉及到数据丢失，那是优先级非常高的！
团队随即展开调查。
背景信息
委托人的信息存在于两个系统中：从A系统导入，存入A系统的数据库，同时会有同步机制把数据同步到B系统的数据库；在B系统也可以修改这些数据，修改完会同时写入A、B两个系统。
问题排查过程
团队第一反应是怀疑双写和同步之间出了问题，但仔细想想好像没法成立…
怀疑B系统的用户有不当操作，把数据抹去了。但是，通过检查数据变更event，没有发现来自B系统的event…况且，现在是一批数据都没有了，B系统并没有批量操作的入口…
是不是A系统进行过批量操作，导致数据被重写？开发人员看代码，测试人员尝试重试各种相关场景，也是没有成功。同时，从event里也没有找到跟这批委托人相关的任何可疑event…
会不会是第三方的系统写入导致数据没了？随即查看第三方的api和相关event，也是没有找到任何可疑迹象…
能想到的用户相关操作都试过了，也没有任何相关event的记录，难道是直接运行SQL脚本了？客户的相关人员不会无故去运行脚本，怀疑可能我们提供的某次修复生产环境问题的脚本搞得鬼…查看最近这段时间的脚本记录，大家放心了，没有脚本会导致数据丢失！
真的是见鬼了！怎么可能数据就这么莫名其妙的丢了呢？！调查小组几经折腾已经筋疲力尽了，请来了小陈同学。
小陈同学听了前面的排查过程，好像真的天衣无缝，但他还是不甘心，决定再去看看event和log。他重新查了前面提到的那些委托人相关的event，的确没有发现任何可疑。又仔细看了看用户报过来的问题，竟然只是list类型的值丢失了！这一定有什么不对！他赶紧去查看那几个list字段相关event，终于真相大白了！原来是有用户把list里的选项删除又重新以不同顺序添加了一遍，从而导致原来用这些选项的字段值都没有了！（该用户应该是觉得原来顺序不合适...…）
我的思考
找到了罪魁祸首，这个案件也就侦破了，日子又恢复了往日的平静。作为QA的我，除了记录下这个过程，也想分享一下我的思考：
数据丢失通常都会比较严重，一般不可恢复或难以恢复，给企业和用户都会带来损失。团队接到这种问题务必引起重视，投入足够的人力去进行调查，如果一波人查到走投无路的话，要及时求助外部力量，往往旁观者清，可能会事半功倍，带来不一样的效果。
调查过程需要结合业务、开发和测试人员的力量，考虑可能会影响的业务场景，从界面操作和系统代码两方面入手，同时排查各种可能性。前面的调查过程大家看着可能觉得挺轻松的，事实上排查各种可疑场景不是一件轻松的事情，因为对于一个复杂系统来说，不是很容易想到每一个场景的…
对于丢失数据的字段本身也是可由用户添加删除的情况，一定要想到还有可能是字段本身被删除了！同时，这里也暴露一个设计和实现上的问题，对于这种字段选项的调整会导致数据丢失的情况，竟然不给用户任何提示…这是需要注意的，后续再有类似的字段一定不可以由用户自由的删减！
日志记录非常重要，而且要记录足够的、清晰的信息，方便对问题的调查。
数据库脚本用版本控制工具管理非常有必要，出问题的时候，执行过的任何脚本都有利于帮助排查可疑情况。
推荐阅读
（点击标题可跳转阅读）
看完本文有收获？请转发分享给更多人
关注「数据分析与开发」加星标，提升数据技能
好文章，我在看❤️