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

2.2 修复问题

数据丢失问题的修复需要处理以下几种情况：恢复数据、修复代码缺陷、审查安全措施。

1. 恢复数据

数据丢失问题，最紧急的是恢复数据。如果有备份数据，则可以尝试使用备份数据进行恢复。如果没有备份，则可能需要使用数据恢复工具或其他手段尝试恢复丢失的数据。

2. 修复代码缺陷

如果数据丢失是因代码缺陷导致，在恢复数据之后需要修复相应的代码问题。本案件中的自定义字段被使用，但是还允许用户删除该字段，且没有收到任何提示，这也是一种代码缺陷，是需要结合真实业务使用情况进行完善和修复的。

3. 审查安全措施

数据丢失也可能是代码以外的其他原因所致，需要评估现有的安全措施。例如数据备份策略、数据恢复策略、访问控制和身份验证措施、加密和防火墙等。以确定是否存在缺陷或漏洞，并进行相应的修复和改进。

2.3 制定预防措施

任何问题如果能做到防患于未然当然是最好的！分析数据丢失事件的原因和影响，制定预防措施以避免类似事件再次发生至关重要。例如，加强数据备份和恢复策略、加强安全防范和监控、加强员工培训和管理等。

《都是脏数据惹的祸》一文对于脏数据的预防有详细的介绍，而数据丢失也是脏数据的一种形式，适用同样的预防措施。

文/Thoughtworks 林冰玉

更多精彩洞见，请关注公众号Thoughtworks洞见！