MySQL从删库到跑路：顺丰高级工程师跑路被开除之后

9月19 日晚，据微博网友大佬坊间八卦爆料，顺丰的一个高级工程手误把线上系统一个库删除了，导致某项服务无法使用并持续 590 分钟。然后跑路了：

根据邮件内容，事件详情如下：

在接到该变更需求后，按照操作流程要求，登陆生产数据库跳转机，通过navicat-mysql客户端管理工具，连入SHIVA-OMCS的RUSS库进行操作。

但在操作过程中，该运维发现选错了RUSS 数据库，打算删除执行的sql。

在选定删除时，因其操作不严谨，光标回跳到RUSS库的实例上，在未看清所选内容的情况下，便通过delete执行删除，同时，他忽略了弹窗提示，直接回车，导致RUSS库被删除。

因工作运维人员工作不严谨的操作，导致OMCS运营监控系统发生故障，该系统上临时车线上发车功能无法使用并持续约590分钟。同比9月5日的929条临时车需求，此次故障对业务产生了严重的负面影响。

随后，顺丰根据公司相关规定，予以开除，并通报公司批评。并在顺丰内网通报。

此外，据说该员工任职顺丰科技IT数据中心应用交付技术部互联网产品运维组，职务IT运维开发高级工程师。

目前，此事已经在圈内传开了：

网友们在网上也是议论纷纷，有幸灾乐祸调侃型的：不如，rm -f / 刺激

也有人调侃称：删的时候肯定很激动

也有人调侃：付出如此巨大的代价，培养起了一个运维工程师的安全意识，然后竟然把他开除了？

还有就是关于是否备份的讨论：

不过最狠的还是属这一条，反手丢给你一本Mysql从删库到跑路：

看看有没有什么后路好走啊哥们~

0. 国内呆不下了，赶紧出国

首先，不要选动车，要选最近的一班飞机，尽快出国，能走高速走高速，不然选人少的路线。

没错，我们 DBA 都是常备护照的。

切记，注意看高德地图实时路况。

我们有个前辈就是删库之后开车就上二环，下午五点钟。警察到的时候他还堵在路上。

1. 只不过是把数据干掉了

权限问题永远是大问题，做好权限回收，开发数据库和线上数据库分离，线上数据库管理权限（一般指修改表结构权限与删表权限）禁止回收，也不提供给业务直接用。

不然参考 0。

公司管理上，最好有自己的 DB 运维产品，线上数据库只允许查，改的话要有审批流程。

至于查数据要不要脱敏、导入导出流程，就看自己产品的规划和排期了。

至于 DBA 怎么保证不手滑，这个每个人有每个人的习惯。

2. 删库什么的都是小 case

清理数据库之前一定要检查进程，是否存在数据库进程，如果存在则宁愿不搞也不要深夜搞。

公司清理数据库要有下线流程。下线一定要走流程。宁愿多租几天机房也不要丢掉数据。

不然参考 0。

原则是：

rm 文件之前先检查进程是否存在。

绝不手工 drop 库表，如果非要 drop，则应该写成 rename，truncate 也是类似，写成 rename 和 create table like 两条 sql。

删表之前可以根据表文件的最后修改时间进行再次确认，不确认就找人

review，有下线流程则走下线流程。

3. 备份，备份，备在何处？

冷备，热备都要有，一定要每天一备。

冷备便是应对这种情况。

公司应该有自己的 DB 备份方案，并且保证执行到位。

４. 人算不如天算

关于这一点，可以单独拉一个大专题出来了，核心内容是 mysql 高可用。

简单起见，推荐这篇文章：避免硬件故障的核心解决方案是冗余。

硬件层面的 raid，软件层面的主从、热备都是为了保证某一个节点宕机，其他节点仍然能继续工作。

所有库都要有主从备份，一方面做读写分离，一方面也是为了备份、高可用。

即便有半同步复制，有些极端情况下可以认为，mysql binlog 没有同步到从库上，仍然可能存在 binlog 丢失（数据丢失）的风险。

所以应对这点，比较好的开源解决方案有 2：TiDB 和 Mysql GR。

5. 升级也能失败？

说起来很简单，升级无非是：

准备升级

过程原理

手工升级后拓扑

工具（mha）升级后拓扑

6. 操作之前有个流程

一般自己操作的时候，都不会有太多的顾忌。

但是要是拿给别人看，就要考虑一下了。

如果别人不只要看，还要 review，那这样就比较难犯重大的错误了。

如果有些操作需要夜间一个人搞，那么一定要提前列好准备，这个就比较正式了。

包括：

1. 梳理具体的执行步骤、执行命令和每个步骤的预计结果。

2. 如果某些步骤出错，是否要求回滚、预先制定回滚方案。

3. 详细记录执行记录，每一步都要有反馈。

4. 事先梳理好收尾工作。

5. 强关联业务要事先通知，考虑到时间段和别的业务高峰，尽量让对方也安排人留守观察。

6. 一定要严格按照步骤来进行操作。宁愿延期，不要加戏。

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

对此，在企业首先做好权限管理以及多重审核机制的同时，CSDN 也曾教诸多程序员们如何在 Linux 下谨慎使用 rm，避免从删库到跑路的悲剧发生：

一个方案就是重定向 rm 命令以嫁接为 mv 命令，相当于给 Linux 系统定制了一个回收站实现方式如下：

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

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

rl：查看回收站下的文件；

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

rmtrash：清空回收站，不过会友好提示。

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

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

备份！

备份！

备份！

喜欢这篇文章记得收藏，转发哦！更多相关资讯可以关注西安华美校区，免费获得java零基础教程！额外附送excel教程！