分享到社交媒体:

本文首发于「BY林子」,转载请参考版权声明


01 离奇的数据丢失案件

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

1.1 数据丢失案件

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

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

团队随即展开调查。

1.2 补充说明

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

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

1.3 案件排查过程

案件排查过程

  1. 团队第一反应是怀疑双写和同步之间出了问题,但仔细检查后觉得没法成立。

  2. 怀疑B系统的用户操作不当导致数据被抹去。但是,通过检查数据变更event,没有发现来自B系统的event;况且,现在丢失的是一批数据,B系统并没有批量操作的入口。

  3. 是不是A系统进行过批量操作,导致数据被重写?开发人员看代码,测试人员尝试重试各种相关场景,也是没有成功;同时,从event里也没有找到跟这批委托人相关的任何可疑event。

  4. 会不会是第三方的系统写入导致数据丢失?随即查看第三方的api和相关event,也是没有找到任何可疑迹象。

  5. 能想到的用户相关操作都试过了,也没有任何相关event的记录,难道是直接运行SQL脚本把数据删除了?客户的相关人员不会无故去运行脚本,怀疑可能我们提供的某次修复生产环境问题的脚本搞得鬼……查看最近这段时间的脚本记录,大家放心了,没有脚本会导致数据丢失!

  6. 真的是见鬼了!怎么可能数据就这么莫名其妙的丢了呢?!调查小组几经折腾已经筋疲力尽了,决定求助资深专家小陈。小陈同学听了前面的排查过程,好像真的天衣无缝,但他还是不甘心,决定再去看看event和log。他重新查了前面提到的那些委托人相关的event,的确没有发现任何可疑。又仔细看了看用户报过来的问题,发现竟然只是list类型的值丢失了!这一定有什么不对!他赶紧去查看那几个list字段相关event,终于真相大白了!原来是有用户把list里的选项删除又重新以不同顺序添加了一遍,从而导致原来用这些选项的字段的值都没有了!

02 案件引发的思考

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

数据丢失案件的思考

2.1 问题排查

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

1. 清晰识别问题

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

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

2. 定位问题

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

2.2 修复问题

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

1. 恢复数据:

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

2. 修复代码缺陷

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

3. 审查安全措施

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

2.3 制定预防措施

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

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

03 推荐阅读


本文首发于「BY林子」,转载请参考版权声明

2 个评论

发表回复

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