删库惹的祸，顺丰高级工程师“被跑路”！
那些年，我们删过的库与跑过的路。
图片源自网络
在 IT 从业者中，有着一群比程序员还要低调且掌管着大数据时代企业生死命门的人，他们就是传说中的 DBA。论起 DBA 的工作职能，很多人表示这可比程序员日常复杂得多，不仅上要和应用程序打交道，下还要深入操作系统和硬件之中。所以当继而谈起成为一名优秀的 DBA 是种怎样的体验时？不少过来人调侃道，你能明白那种删得了库跑不了路的酸爽感吗？
近来，一名来自顺丰的技术工程师亲身经历告诉了我们，“对，没错，就是这样的一种感觉。”。
日前，据微博知名互联网资讯博主@大佬坊间八卦爆料，顺丰科技数据中心的一位邓某因误删生产数据库，导致某项服务无法使用并持续 590 分钟。
来自@大佬坊间八卦微博
后来有网友爆料，这位邓某是顺丰科技 IT 数据中心应用交付技术部互联网产品运维组的 IT 运维开发高级工程师。
而事件的起因，据网上流传的邮件截图显示：
在接收到变更需求后，邓某在操作过程中，错选了 RUSS 数据库，打算删除执行的 SQL。在选定删除时，因其操作不严谨，光标回跳到 RUSS 库的实例，在未看清所选内容的情况下，便通过 delete 执行删除，同时邓某忽略了弹窗提醒，直接回车，导致 RUSS 生产数据库被删掉。
因运维工作人员不严谨的操作，导致 OMCS 运营监控管控系统发生故障，该系统上临时车险发车功能无法使用并持续了约 590 分钟。
目前顺丰根据公司相关规定，已将邓某辞退，且在顺丰科技全网通报批评。事件一出，立即引发圈中程序员们的热议。很多人无奈的表示，库都删了，不跑路干什么？记得看好地图，搭载飞机跑路，否则或因堵车，短短几分钟之内你就会被抓回了，譬如下面这位：
事实上，无独有偶，在国内外，删库事件早已不是第一次发生，相比之下，此次顺丰删库带来的后果还不算最为严重，接下来，我们将共同回顾那些年，删的那些库带来了怎样的后果？我们又该如何避免删库跑路事件的频发？
那些年，删过的库
大厂说：
2017 年 2 月，GitLab 的一位系统管理员在给线上数据库做负载均衡工作时，遭受了 DDoS 攻击。在阻止了攻击之后，运维人员发现了数据库不同步的问题，便开始修复，在修复过程中，错误地在生产环境上执行了数据库目录删除命令：
sudo rm -rf导致 300GB 数据被删成 4.5G，GitLab 被迫下线。
2017 年 6 月，一家荷兰海牙的云主机商 verelox.com，一名前任管理员删光了该公司所有客户的数据，并且擦除了大多数服务器上面的内容。
最终导致 Verelox 暂时将网络下线。在发布的官方公告中，Verelox 表示一直努力恢复数据，但遗憾的是，目前已丢失的所有数据可能恢复不了了。
2017 年 9 月，某 IT 大厂技术工程师帮助广西移动进行扩容割接（即增加系统容量）时，不小心将 HSS 设备里面的用户数据格式化删除，导致广西移动近 80 万用户数据丢失。
网友说：
与此同时，来自知乎（https://www.zhihu.com/question/58802374）的不少网友也为曾删过的那些库，大惊失色，直至现在仍心有余悸：
@张家考拉：
公司新来一位应届毕业生，工作能力非常弱，什么都不会，怎么办呢？就先让她帮忙盘点机房设备资产。
就因为有个资产标签看不清楚，直接把刀片服务器拔出来了，旁边带她的人看到，瞬间就石化了。业务系统中断十几分钟，领导也没说什么，就是不让她继续盘点了，而她，根本不知道自己闯祸了。
@土豆爸爸：
多年前（2001 年），那还是 Unix 字符界面，半夜我例行维护，删过一个包含二十万本图书的库。十分钟自己确认出错后，开始冒汗，胃部像是被猛打了一拳得开始痉挛，疼的我都坐不住。
好一会我去过道抽了两根烟，才回忆起前天做了全系统备份，丢的数据不多！
那感觉，一辈子难忘。
@ai0by：
之前自己做的一个站，服务器是在 Vultr 上面，用户有 1000 多，访问量不少。某天在 Vultr 上面另开了一台测试机器，测试完了准备删除时删错了机器，把放网站的那台删掉了……（有必要吐槽一下 Vultr 的服务器界面，我以为新开的机器一定是最下面的那个，然后没看直接就删掉了，没想到最下面的那个不是最新开的那台！）
当时只能说非常慌张，好像在梦里一样，满头大汗，只能眼睁睁看着一条提示删除成功的消息，随即立刻提交了一条 ticket，Vultr 告诉我已经删除掉的机器是不能恢复的，瞬间感觉长时间的经营全部白费了，很难想象经营了那么久一个失误操作全完蛋了。
后来发现那台机器之前有过备份，另开了一台机器把镜像恢复到新机器上面，时间是一周前，好歹算是救回来了，丢失的数据后来自己手工补上了。
删掉的一瞬间，好多用户来找我，我只能淡定的回复说是在维护，实际慌的要死，在问题解决差不多后，自己后背都湿透了，再也不想有第二次了，切记做好备份，切记切记！
那些年，跑路前，我们还可以做些什么？
和上文删库事件相比，不少网友对顺丰的处理结果及制度产生质疑，纷纷表示：开除了涉事工程师，顺丰自身就完全没责任？花了这么大的教训培养了一位运维就这么拱手让人了？
剖开表面，我们不由深思，顺丰以辞退为名，真的能撇开其在流程问题所因担起的责任？此次出事，好在影响尚未造成无法挽回的后果，顺丰应做的不是第一时间去辞退涉事员工，而是通过该教训来看清内部的问题：
删库事件发生一方面源于工程师本人的失误，另一方面是否体现了日常管理流程的松懈，及操作的不规范？
安全责任不分明，除了涉事员工，其直接上司不应担责？
权限控制混乱，仅一名运维工程师可以直接操作数据库？
灾备恢复能力弱，事件的发生到恢复，偌大的顺丰企业花费了 590 分钟？
所以，从以上的种种问题来看，我们该如何再次避免删库“跑路”等事件的再次发生？
对此，在企业首先做好权限管理以及多重审核机制的同时，CSDN 也曾教诸多程序员们如何在 Linux 下谨慎使用 rm，避免从删库到跑路的悲剧发生：
一个方案就是重定向 rm 命令以嫁接为 mv 命令，相当于给 Linux 系统定制了一个回收站。实现方式如下：
最后将上述脚本写入 /etc/bashrc，并立即执行命令 source /etc/bashrc 即刻生效。
以上的脚本定义了几个命令：
rl：查看回收站下的文件；
unrm 文件名或目录：恢复到当前的路径下；
rmtrash：清空回收站，不过会友好提示。
执行 rm 不会真正删除，而是使用 mv 移动到我们指定的回收站。实在真的想删除可以 /bin/rm 来进行删除。另外，需要注意的时，之前 rm 指令的一些参数可能不再使用，因为 rm 现在其实是 mv 了。
还有无论是运维、DBA 还是程序员们都应该在日常 Coding 时严加注意操作规范，铭记“一失手成千古恨”的后果。在审查时也要做好自动容灾、数据同步的步骤，最后，重要的事情说三遍，不要忘记：
备份！
备份！
备份！
“征稿啦”
CSDN 公众号秉持着「与千万技术人共成长」理念，不仅以「极客头条」、「畅言」栏目在第一时间以技术人的独特视角描述技术人关心的行业焦点事件，更有「技术头条」专栏，深度解读行业内的热门技术与场景应用，让所有的开发者紧跟技术潮流，保持警醒的技术嗅觉，对行业趋势、技术有更为全面的认知。
如果你有优质的文章，或是行业热点事件、技术趋势的真知灼见，或是深度的应用实践、场景方案等的新见解，欢迎联系 CSDN 投稿，联系方式：微信（guorui_1118，请备注投稿+姓名+公司职位），邮箱（guorui@csdn.net）。
————— 推荐阅读 —————