首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

备份,备份,记得备份!

和优秀的人一起成长,才能让自己更优秀

从删库到跑路

在 IT 从业者中,有着一群比程序员还要低调且掌管着大数据时代企业生死命门的人,他们就是传说中的 DBA。论起 DBA 的工作职能,很多人表示这可比程序员日常复杂得多,不仅上要和应用程序打交道,下还要深入操作系统和硬件之中。所以当继而谈起成为一名优秀的 DBA 是种怎样的体验时?不少过来人调侃道,你能明白那种删得了库跑不了路的酸爽感吗?

近来,一名来自顺丰的技术工程师亲身经历告诉了我们,“对,没错,就是这样的一种感觉。”。

日前,据微博知名互联网资讯博主@大佬坊间八卦爆料,顺丰科技数据中心的一位邓某因误删生产数据库,导致某项服务无法使用并持续 590 分钟。

来自@大佬坊间八卦微博

后来有网友爆料,这位邓某是顺丰科技 IT 数据中心应用交付技术部互联网产品运维组的 IT 运维开发高级工程师

而事件的起因,据网上流传的邮件截图显示:

在接收到变更需求后,邓某在操作过程中,错选了 RUSS 数据库,打算删除执行的 SQL。在选定删除时,因其操作不严谨,光标回跳到 RUSS 库的实例,在未看清所选内容的情况下,便通过 delete 执行删除,同时邓某忽略了弹窗提醒,直接回车,导致 RUSS 生产数据库被删掉。

因运维工作人员不严谨的操作,导致 OMCS 运营监控管控系统发生故障,该系统上临时车险发车功能无法使用并持续了约 590 分钟。

目前顺丰根据公司相关规定,已将邓某辞退,且在顺丰科技全网通报批评。事件一出,立即引发圈中程序员们的热议。很多人无奈的表示,库都删了,不跑路干什么?记得看好地图,搭载飞机跑路,否则或因堵车,短短几分钟之内你就会被抓回了,譬如下面这位:

事实上,无独有偶,在国内外,删库事件早已不是第一次发生,相比之下,此次顺丰删库带来的后果还不算最为严重,接下来,我们将共同回顾那些年,删的那些库带来了怎样的后果?我们又该如何避免删库跑路事件的频发?

那些年删过的库

来看看

大厂说:

2017 年 2 月,GitLab 的一位系统管理员在给线上数据库做负载均衡工作时,遭受了 DDoS 攻击。在阻止了攻击之后,运维人员发现了数据库不同步的问题,便开始修复,在修复过程中,错误地在生产环境上执行了数据库目录删除命令:

导致 300GB 数据被删成 4.5G,GitLab 被迫下线。

2017 年 6 月,一家荷兰海牙的云主机商 verelox.com,一名前任管理员删光了该公司所有客户的数据,并且擦除了大多数服务器上面的内容。

最终导致 Verelox 暂时将网络下线。在发布的官方公告中,Verelox 表示一直努力恢复数据,但遗憾的是,目前已丢失的所有数据可能恢复不了了。

2017 年 9 月,某 IT 大厂技术工程师帮助广西移动进行扩容割接(即增加系统容量)时,不小心将 HSS 设备里面的用户数据格式化删除,导致广西移动近 80 万用户数据丢失。

网友说:

与此同时,来自知乎的不少网友也为曾删过的那些库,大惊失色,直至现在仍心有余悸:

@张家考拉:

公司新来一位应届毕业生,工作能力非常弱,什么都不会,怎么办呢?就先让她帮忙盘点机房设备资产。

就因为有个资产标签看不清楚,直接把刀片服务器拔出来了,旁边带她的人看到,瞬间就石化了。业务系统中断十几分钟,领导也没说什么,就是不让她继续盘点了,而她,根本不知道自己闯祸了。

@土豆爸爸:

多年前(2001 年),那还是 Unix 字符界面,半夜我例行维护,删过一个包含二十万本图书的库。十分钟自己确认出错后,开始冒汗,胃部像是被猛打了一拳得开始痉挛,疼的我都坐不住。

好一会我去过道抽了两根烟,才回忆起前天做了全系统备份,丢的数据不多!

那感觉,一辈子难忘。

@ai0by:

之前自己做的一个站,服务器是在 Vultr 上面,用户有 1000 多,访问量不少。某天在 Vultr 上面另开了一台测试机器,测试完了准备删除时删错了机器,把放网站的那台删掉了……(有必要吐槽一下 Vultr 的服务器界面,我以为新开的机器一定是最下面的那个,然后没看直接就删掉了,没想到最下面的那个不是最新开的那台!)

当时只能说非常慌张,好像在梦里一样,满头大汗,只能眼睁睁看着一条提示删除成功的消息,随即立刻提交了一条 ticket,Vultr 告诉我已经删除掉的机器是不能恢复的,瞬间感觉长时间的经营全部白费了,很难想象经营了那么久一个失误操作全完蛋了。

后来发现那台机器之前有过备份,另开了一台机器把镜像恢复到新机器上面,时间是一周前,好歹算是救回来了,丢失的数据后来自己手工补上了。

删掉的一瞬间,好多用户来找我,我只能淡定的回复说是在维护,实际慌的要死,在问题解决差不多后,自己后背都湿透了,再也不想有第二次了,切记做好备份,切记切记!

那些年,跑路前

我们还可以做什么

和上文删库事件相比,不少网友对顺丰的处理结果及制度产生质疑,纷纷表示:开除了涉事工程师,顺丰自身就完全没责任?花了这么大的教训培养了一位运维就这么拱手让人了?

剖开表面,我们不由深思,顺丰以辞退为名,真的能撇开其在流程问题所因担起的责任?此次出事,好在影响尚未造成无法挽回的后果,顺丰应做的不是第一时间去辞退涉事员工,而是通过该教训来看清内部的问题:

删库事件发生一方面源于工程师本人的失误,另一方面是否体现了日常管理流程的松懈,及操作的不规范?

安全责任不分明,除了涉事员工,其直接上司不应担责?

权限控制混乱,仅一名运维工程师可以直接操作数据库?

灾备恢复能力弱,事件的发生到恢复,偌大的顺丰企业花费了 590 分钟?

所以,从以上的种种问题来看,我们该如何再次避免删库“跑路”等事件的再次发生?

一个方案就是重定向 rm 命令以嫁接为 mv 命令,相当于给 Linux 系统定制了一个回收站。

实现方式如下:

最后将上述脚本写入 /etc/bashrc,并立即执行命令 source /etc/bashrc 即刻生效。

以上的脚本定义了几个命令:

rl:查看回收站下的文件;

unrm 文件名或目录:恢复到当前的路径下;

rmtrash:清空回收站,不过会友好提示。

执行 rm 不会真正删除,而是使用 mv 移动到我们指定的回收站。实在真的想删除可以 /bin/rm 来进行删除。另外,需要注意的时,之前 rm 指令的一些参数可能不再使用,因为 rm 现在其实是 mv 了。

还有无论是运维、DBA 还是程序员们都应该在日常 Coding 时严加注意操作规范,铭记“一失手成千古恨”的后果。在审查时也要做好自动容灾、数据同步的步骤,最后,重要的事情说三遍,

不要忘记:备份!备份!备份!

看了上面的文章,是不是觉得好像和自己没什么关系,真的没关系么,希望大家工作的时候多点责任心,规范性。

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20180926A0AUQZ00?refer=cp_1026
  • 腾讯「腾讯云开发者社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 cloudcommunity@tencent.com 删除。

扫码

添加站长 进交流群

领取专属 10元无门槛券

私享最新 技术干货

扫码加入开发者社群
领券