lxue
作者lxue2017-06-15 11:03
数据库管理员, 某互联网公司

离职员工从删库到跑路,咋办?

字数 2057阅读 31073评论 23赞 38

6月11日,Verelox的所有客户数据被一个离职工程师删除,事故非常严重。Verelox是荷兰海牙的一家云主机商。它成立于2014,以VPS、服务器出租和托管为主。它的VPS基于KVM架构,分HDD和SSD,有加拿大、荷兰、法国三处数据中心,也支持Windows系统,支持按小时和月付。事故发生后,Verelox在官网上公布了该事件,并全力为客户恢复数据,但是,已经不可能恢复全部数据。

删除云主机上的客户数据相当于暴力破坏公司核心资产,是一种犯罪行为,该工程师一定会受到法律的制裁,但是巨大的损失已经造成,无法挽回。
u=2496386706,575791735&fm=26&gp=0.jpg

u=2496386706,575791735&fm=26&gp=0.jpg

比离职员工删库跑路更频繁发生的是各种意外删除数据的事件。

2017年1月31日23:00 左右,Gitlab一名系统管理员在极度疲劳的情况下,尝试删除一个空的目录,结果指令发往了另外一台服务器的命令窗口,等他回过神来的时候,27分钟过去, 终止删除操作为时已晚,大约 300 GB 左右的数据只剩下约4.5 GB。 GitLab.com丢失了 6 小时的数据库数据(问题,合并请求,用户,评论,片段等)。

4 月 5 日,知名的 VPS 服务商 DigitalOcean 出现了一次删除生产数据库的事故。删库导致 DigitalOcean 的控制面板和 API 无法正常使用,时间长达 4 小时 56 分。DigitalOcean 官博撰文致歉,并说明了事故前后过程:“ 在 2017 年 4 月 5 日 10:24 AM EDT,我们开始收到公共服务功能失效的警报。在警报最初的 3 分钟,我们发现主数据库已经被删除了。4 分钟后,我们开始从一台有延迟的数据库副本着手恢复。在接下来的 4 个小时中,我们复制并把数据恢复到主备副本。服务中断这么长时间,主要是因为从副本把数据恢复到在线服务器这个过程非常耗时。” 此次事故的根本原因是工程师驱动的配置错误。有个用于自动化测试的程序,错误使用了生产证书。

无论是主观还是无意,数据库被删除,都是互联网公司难以承受之重,Fintech公司尤其无法接受跟钱相关的数据丢失,技术团队必须要防患于未然。

首先要防止的是,数据库被开发人员误删。

开发人员是否需要连接生产数据?有人说需要,有人说不需要。不同的情况下有不同的道理。这里我们分开来讨论。如果开发人员不需要直接连接数据库,是最好不过的了,就杜绝了数据被开发人员删除的危险,也没有数据被泄露的风险,也不会因为敲出了一个select * from xxx造成负载异常升高。

如果开发人员需要连接呢?通常需要做到以下两点:

  • 如果开发人员需要能连接生产数据库,需要给到只读账号,且需要一个人一个账号
  • 如果生产库有从库/备库,最好能让开发人员连接从库/备库。

其次,需要防止数据被管理员删除。事实上,Verelox的数据就是被不开心的系统管理员恶意删除的。管理员不能使用root账号直接在操作系统层面操作数据文件,尽量使用客户端从远端连接到数据库进行维护。由于意外失误,像Gitlab管理员一样,在昏昏欲睡的时候,rm -rf清掉整个硬盘的事故也太多了,需要使用堡垒机等工具配合屏蔽这类高危命令。最后,尽量减少使用图形工具,因为太多的图形工具,会隐含的具有某些功能,如autocommit,设置字符集等。

第三,如何防止数据被程序删除呢?通常,架构设计上需要注意,重要数据永远不要直接删除,标记为“删除”状态。不能给程序的用户all privileges。Insert、delete、update各类命令的权限单独赋予。

第四,我们也要防黑客。应用的网络进行分层设计。接入层,应用层,数据层。数据层只对固定的应用服务器开放。数据库永远只放在内网,监听在内网IP上。

第五,必须有周密的备份,即使管理员跑路也不怕。数据的物理备份和逻辑备份相互补充,文件不小心被删除的,用物理备份恢复;表被drop掉的,用逻辑备份恢复。备份也经常需要演练。因为一方面要保证我们的备份可用;另外一个方面我们也需要对多久可以恢复负责。对CTO及运维负责人而言,备份情况也需要每天检查。

最后,请各位读者牢记强哥的独家私藏小秘籍:

  • 数据文件被删除了,复制可以救命;数据表被drop掉了,延时复制可以救命;
  • 数据文件被rm掉了,不要急,在不关闭进程的情况通过linux的方法恢复文件;
  • oracle的flaskback query,flashback database等;
  • 在mysql,sql server维护数据的时候关闭autocommit,待确认数据正确之后再提交;
  • 各种数据库的基于时间点的数据恢复,有些时候真的非常有用,所以一定要进行周期性的演练。

当然,最好的办法还是好好照顾自家运维人员,开心工作开心生活,减少人肉运维,不要疲劳驾驶,也不要闹到通过删库报复公司报复社会的程度。

运维不易,请多多关爱。

如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!

38

添加新评论23 条评论

#星陨无痕技术经理, 北京世纪东方国际旅行社
2019-08-08 15:35
我这8.2日刚刚经历了数据库服务器硬盘损坏..有备份的情况下,因为一直没出现过这种情况,导致公司系统瘫痪三天..到现在过去一个星期了数据还没完全恢复..有备份真的要做做演练,否则有备份恢复都很难.
#else_xie系统运维工程师, NZX
2019-04-30 17:20
恢复的成本,不仅包括数据,恢复消耗的时间也是不可估量的机会成本。所以,防止事故的发生应该是投入产出最高效的,多方审核操作,严格授权管理,关爱运维人员!
#秋风追绿叶系统运维工程师, 广州运维
2019-03-14 14:50
周围没遇到这种事 不过数据被误删除真的很惨 相像一下 你的珍藏在硬盘里 而硬盘坏了无法修复 你自己都会心疼一阵子 何况涉及到真真切切利益的数据 天下熙熙皆为利来天下攘攘皆为利往 敲命令时 特别是删除的 小心 小心 再小心
#MengBiao技术经理, 南天信息
2019-02-01 16:07
运维不易,请多多关爱。
#行成it技术咨询顾问, 厂商
2019-01-17 11:23
开心工作开心生活,减少人肉运维,不要疲劳驾驶,也不要闹到通过删库报复公司报复社会的程度。严重同意
#匹马戍梁州其它, **********
2018-11-23 14:23
权限控制着手吧,人品也很重要
#夜惊云网络工程师, 软亲
2018-09-05 17:03
写出了许多人的内心啊
#夜惊云网络工程师, 软亲
2018-09-05 17:03
写出了许多人的内心啊
#dylan.lee信息技术经理, 某财险公司
2018-08-02 16:51
不管有意还是疲劳驾驶,都反映了管理上的漏洞和缺失。
#tuomi2013系统运维工程师, 广州某医药公司
2018-08-02 14:45
运维人员也是不容易啊,不到迫不得已谁会去做这种高风险的操作呢
#Jeanson软件开发工程师, 中科信息
2018-06-25 15:34
祸起萧墙、防不胜防! 多多关照、两不相伤!
#xing854800529系统架构师, 北京亿通科技发展有限公司
2018-06-20 17:13
请照顾好自家的运维人员,不然后果很可怕。
#墨轩研发工程师, 科瑞明
2018-06-07 14:31
曾经我以删除过生产环境数据库,不过现在操作起来还是很后怕。
#蒋啸技术经理, jsdc
2018-05-02 14:17
运维人员不易,干的事情风险大,压力大。工资低。。
#Matthew224项目经理, 中天国富证券
2018-04-18 08:55
运维不易,且用且珍惜
#狂我kg软件开发工程师, 南昌协达科技发展有限公司
2018-04-12 19:03
删库跑路现在成了行业内谈论的一个笑点,但是实际上反映出来的是运维对于数据的安全管理,权限分配,和数据备份容灾的缺失。
#wuwenpin软件开发工程师, 南京
2018-03-12 17:21
学习了
#wlx_87项目经理, DataThink
2018-02-13 17:10
还是要从数据库安全管理上下功夫,做好权限管控、审计、备份容灾。
#一只果子狸数据库管理员, QAQ
2017-11-29 12:56
运维不易,请多多关爱。
#岳彩波产品经理, 无
2017-09-11 10:52
你说的这种情况在整个行业里是极少的个例,这么做,有什么好处,完全违反了职业道德,甚至违法,做一次这种事,一辈子估计都出不来,而且不是特别熟悉的人删了运行的,还有备份,有灾备,等等,没什么用不说,数据重要的话,直接就抓进去牢底坐穿了。
#penguin23系统运维工程师, 广州佳杰科技有限公司
2017-09-11 10:04
运维不易,请多多关爱。
#aixkevin存储工程师, ..............
2017-09-11 09:46
运维不易,请多多关爱。
#yueliusha技术经理, 北京太极信息系统技术有限公司
2017-06-15 12:20
最后这句话,道出了真谛。运维不易,且用且珍惜啊。
Ctrl+Enter 发表

关于TWT  使用指南  社区专家合作  厂商入驻社区  企业招聘  投诉建议  版权与免责声明  联系我们
© 2019  talkwithtrend — talk with trend,talk with technologist 京ICP备09031017号-30