员工“删库跑路“？竟发生在我身上，研发总监慌了...

一. 前言

思科前员工离职后删库&＃xff0c;直接损失达 240 万美元。今天这个事情竟然发生到我们公司身上&＃xff0c;吓了一身冷汗。同胞们一定要注意数据库安全问题。安全无小事&＃xff0c;不出问题没人重视&＃xff0c;一出问题就是致命的。
我目前在一家科技公司担任研发总监工作。今天上午10点左右&＃xff0c;我随机点击了一个线上APP的一个功能&＃xff0c;发现数据没有了。以为是个常规的bug&＃xff0c;把这个问题直接反馈给了测试主管。
下面试我们的聊天&＃xff1a;

震惊&＃xff1a; 生产环境表被覆盖了&＃xff1f;&＃xff1f;&＃xff1f;而且不能还原&＃xff01;&＃xff01;&＃xff01;
我立马停下手头的工作&＃xff0c;赶快找研发落实问题。这个时候研发、运维都聚在一起排查原因了。
最终发现一个库的重要核心表被清空了。我问了下运维&＃xff0c;可以恢复到之前数据不&＃xff0c;运维说由于binlog日志没开启&＃xff0c;而且没有备份&＃xff0c;还是单机的。没法还原&＃xff01;如果真没法还原&＃xff0c;线上数据库有20多万的用户&＃xff0c;还有充值的金额&＃xff0c;这个影响是致命的。

二. 尝试寻找解决问题

听完运维说的无法还原&＃xff0c;我的心一下子提到了嗓子眼&＃xff0c;顿时压力倍增。但是表面故作镇定&＃xff0c;因为我是他们的精神依靠&＃xff0c;我一旦慌了&＃xff0c;他们估计就更慌了。
这个时候还有人在讨论是可能是黑客攻击、误操作、代码问题等原因&＃xff0c;我阻断了他们的讨论&＃xff0c;先解决问题&＃xff01;稍作镇定&＃xff0c;我开始梳理思路。人和任务分成以下3条线同步解决&＃xff1a;

1. 备份现有数据&＃xff1a; 先把当前库的所有表备份一遍&＃xff0c;以防当前是由于黑客或者恶意破坏者继续破坏。
2. 运维继续寻找还原策略&＃xff1a; 运维负责继续寻找还原策略&＃xff0c;再次确认是否有binlog方案还原、事务回滚还原、是否有定时备份文件。
3. 研发通过其他表还原&＃xff1a; 由于表被清空的只有一张&＃xff0c;是否可以通过其他表的关联关系&＃xff0c;进行拼接组装还原该表。经过和研发讨论&＃xff0c;可以通过其他表把数据还原90%。心想&＃xff0c;90%如果能还原也不错了。马上安排研发通过查找其他表的方式进行sql拼装的工作。

三. 结果&＃xff1a;

就这样三个方案同步进行了20分钟&＃xff0c;这个时候第二个方案&＃xff0c;也就是运维这边传来了喜讯&＃xff1a;他发现他之前做了一个定时任务备份数据库策略。大家顿时兴奋了起来&＃xff0c;赶快找到了出问题的时间节点&＃xff0c;然后顺利找到了最近一次备份文件。立马进行了数据库表的还原。还原过程很快&＃xff0c;还原后验证下线上的问题&＃xff0c;一切正常&＃xff0c;这下才把心放了下来。

四. 问题分析&＃xff1a;

由于mysql数据库&＃xff0c;我们没有开启日志的记录。无法统计的造成这次事故的具体原因是什么&＃xff0c;只有通过以下方式进行分析原因&＃xff1a;
1. 黑客攻击&＃xff1a;如果黑客攻击的话&＃xff0c;不应该只删除一张表吧。而且程序上面排查没有类似的不安全脚本执行操作。所以黑客攻击的可能性不大。
2. 离职员工恶意报复&＃xff1a;这个也有可能&＃xff0c;离职员工目前手里面有数据库的账号和密码。也是有操作的可能的。
3. 员工升级误操作导致&＃xff1a; 这个理论上是最有可能的&＃xff0c;但是今天没有升级程序。都说没动过数据库。&＃xff08;其实我觉得应该是有人动了&＃xff0c;不承认&＃xff09;

五. 防止删库跑路策略

1. 服务器异地定时备份&＃xff1a; 一定要做个定时任务脚本&＃xff0c;每天至少要异地&＃xff08;至少是异服务器&＃xff09;备份2次。防止磁盘挂了、黑客攻击、误操作等导致数据库异常。
2. 开启Binlog日志&＃xff1a; 一定要开启binlog日志&＃xff0c;一旦出现问题&＃xff0c;既能通过日志的方式恢复&＃xff1b;又能查出操作记录&＃xff0c;从而追责到人。
3. 数据库集群策略&＃xff1a; 数据库最好有3台机器&＃xff0c;一主两从&＃xff0c;互相同步。读写分离。
4. 数据库账户、操作权限回收&＃xff1a; 这个一定要有&＃xff0c;要把数据库的用户和密码以及操作权限&＃xff0c;从研发人员手中会受到运维手中。防止研发误操作、离职报复等损坏数据库。
5. 业务库分离&＃xff1a; 不要把所有鸡蛋都放到一个篮子中。每个业务对应一个库&＃xff0c;多个业务库和库之间是物理隔离的&＃xff0c;就算是一个数据库挂了&＃xff0c;其他库和业务正常运行&＃xff0c;把影响范围降到最小。