数据离奇丢失案件的侦破与思考

news2024/11/17 5:33:01

01 离奇的数据丢失案件

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

1.1 数据丢失案件

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

用户报过来以上问题，涉及到数据丢失，是高优先级问题，客户为此特别紧张。

团队随即展开调查。

1.2 补充说明

为了更好地解释这个问题，补充如下信息：

委托人的信息存在于两个系统中：从A系统导入，存入A系统的数据库，同时会有同步机制把数据同步到B系统的数据库；在B系统也可以修改这些数据，修改完会同时写入A、B两个系统。
丢失数据的“字段”（不是字段的“值”）本身是通过list类型来自定义的，也就是说不同类型的委托人可能看到的字段是不一样的；而丢失的是自定义字段对应的“值”。

1.3 案件排查过程

案件排查过程

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

02 案件引发的思考

找到了罪魁祸首，案件也就侦破了。不过，经历这次惊心动魄的数据丢失案件，我们该有哪些启发和思考呢？下面，我从问题排查、修复问题和制定预防措施几个维度进行反思和总结。

数据丢失案件的思考

2.1 问题排查

数据出现问题相对比较严重，团队都会着急去排查原因，不过，在开始排查之前，有更重要的事情要做。我认为问题排查也分两个步骤：清晰识别问题、定位问题。

1. 清晰识别问题

对于数据丢失的情况，首先要搞清楚丢失的数据类型，以及丢失数据的时间段和对应的系统/功能模块等。案件中小陈就是进一步识别了问题，发现了问题的根本点在于只有list类型自定义字段对应的数值有丢失，因此找到了问题的突破口。

因此，清晰识别问题，才可能朝着更加正确的方向去排查问题，这一点至关重要！

2. 定位问题

收集日志、Event等信息：查看系统日志、数据库日志和其他相关的系统记录，收集可能有关丢失数据的信息，例如异常情况、错误信息、登录记录等。
对收集到的信息进行分析，以确定可能导致数据丢失的原因。例如，检查数据库或其他系统的异常操作、网络连接或系统故障等。
排查过程需要结合业务、开发、测试和运维人员的力量，考虑可能会影响的业务场景，从界面操作和系统代码两方面入手，同时排查各种可能性。案件中的定位问题过程还是做的比较周全的，对于复杂的系统，就得集团队之力一步一步细心地去排查；甚至有的时候需要借助外部专家的力量，外部力量作为旁观者加入，可能会事半功倍，起到关键作用。