【原】那些年删过的库，跑过的路，你从中找到解决方法了吗？

导读：本文我们盘点了往年发生的一些删库事件，我们该如何做到更好地预防和处理删库实践呢？

本月，多名网友反馈购物推荐网站什么值得买及APP无法访问。晚上10点多官方发表了公告，称服务器遭遇大面积攻击，网站及APP出现异常，目前正在逐步恢复中。针对之前传闻的数据丢失及泄露，什么值得买官方表示否认。但是此次疑似删库事件在网上也是引发了很多热议，下面我们来盘点下往年发生的一些删库事件，思考我们该如何做到更好地预防和处理删库事件。

顺丰事件

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

事件详情：

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

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

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

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

Gitlab删库事件

2017年1月底，Gitlab工作人员由于夜间开车时间很长，错误的将 db1.cluster.gilab.com （生产库）的数据库删除，而不是db2的。丢失了 6 小时的数据库数据。

事件详情：

Gitlab的一位系统管理员在给线上数据库做负载均衡工作时，遭受了DDoS攻击。在阻止了攻击之后，运维人员发现了数据库不同步的问题，便开始修复，在修复过程中，错误地在生产环境上执行了数据库目录删除命令，导致300GB数据被删除，Gitlab被迫下线。在恢复的过程中，他们发现只有db1.staging的数据库可以用于恢复，而其它的5种备份机制都不可用。db1.staging 是6小时前的数据，而且传输速率有限，导致恢复进程缓慢，Gitlab 最终丢掉了差不多6个小时的数据。

起因是Gitlab检测到垃圾邮件发送者通过创建片段来攻击数据库，使其不稳定，于是运维block攻击者的IP,并移除用户发送垃圾邮件。之后运维A发现db2.staging复制滞后生产库4GB的数据（据后期2nd Quadrant的CTO – Simon Riggs 建议，PostgreSQL有4GB的同步滞后是正常的）,运维A开始尝试修复db2,但复制失败，运维A在尝试了多种方案之后依然如此。

运维A决定删除该db2数据库目录，令其重新复制。由于夜间开车时间很长，运维A错误的将 db1.cluster.gitlab.com （生产库）的数据库删除，而不是db2的。大约 300 GB 左右的数据只剩下约4.5 GB。

随后虽然有号称有五重备份机制（常规备份（24小时做一次）、自动同步、LVM快照（24小时做一次）、Azure备份（只对 NFS 启用，对数据库无效）、S3备份),没有一个可靠地运行或设置，最终只能基于LVM的备份（最近6小时以前），还原了6 小时前的备份。恢复期间Gitlab直播了这次恢复过程。

2017/01/31 18:00开始数据异常，截止2017/02/02 02:14,GitLab.com恢复正常。期间丢失了 6 小时的数据库数据（问题，合并请求，用户，评论，片段等）。Git / wiki 存储库和自托管安装不受影响。根据GitLab从日志里得出的结论，有707位用户丢失数据，5,037项目丢失，受事故影响的用户基数不到1%。

verelox.com删库事件

2017年6月，一家荷兰海牙的云主机商 verelox.com，一名前任管理员删光了该公司所有客户的数据，并且擦除了大多数服务器上面的内容。最终导致 Verelox 暂时将网络下线。

 

网络剪报服务商 - Instapaper事件

2017年2月9日至2月10日下午7时30分，Instapaper服务突然中断，事故起因是2014年4月之前创建的RDS实例的2TB文件大小限制，造成了不小的损失。

事件详情：

Instapaper 最初的全文检索使用一台 Sphinx 服务器直接和 MySQL 联合提供搜索，这个搜索使用 AWS EC2 大约70GB 内存，4TB 存储的资源：

Instapaper 的索引数据量（数据库的数据量未知），在2016年5月时数据量2.2TB，每月增长约110GB，后来实在慢的不行，最后选择了 AWS 的 elasticsearch cluster来承载这项服务。而最终，还是败在了存储，数据写入失败直接导致数据库宕机。

携程删库事件

2015年5月28日上午11时，携程网突然陷入瘫痪。携程回应称携程部分服务器遭不明攻击，在此次故障中全部遭受物理删除，且备份数据也无法使用。但在5月29日，携程发布官方情况说明称，此次事件是由于员工错误操作，删除了生产服务器上的执行代码导致。

 

任何程序都会有Bug，任何系统都会有异常，历史发生的删库事件，是提醒我们需要时刻注意风险，积极总结和反思，预防那些可以避免的异常，妥善处理已经发生的异常，让产品更好地服务客户。

说道删库不得不提rm，rm 是 linux 系统下删除文件的命令，-r 代表删除这个下面的一切，一切的一切那种的一切。f 表示不需要用户确认，直接执行。通常这个命令都是指定文件夹用的，比如：

rm -rf /home/test/

就是删除 /home/test/ 这个文件夹下面的所有东西。但是如果后面的文件夹路径没有加对，rm -rf / 在服务器上也就意味着删库了！

所以！严重警告：rm是非常危险的！

面对上面的这些删库事件，我们该如何进行反思？做到更好地预防和处理删库事件呢？

首先，要有完善、有效的备份和容灾机制。诚然很多企业都有了一整套的备份、容灾机制，但是这套备份机制能否真实奏效是需要检验的。我接触过某大型企业，投入巨资兴建的灾备中心，从未正式切换过，这样的灾备在故障来临时也很难有人拍板去进行切换，所以备份的有效、容灾手段的有效是必须确保的。注意，备份的恢复速度必须足够的考虑到，磁带的低效备份关键时刻会害死人。

其次，要有完善的故障处理策略和流程。对于不同系统，在关键时刻要优先确保什么，是要订立规则的，有了规则才能照章办事，不走错方向，不无辜背锅。几年前某国内金融系统出现数据坏块，同样选择了带病修复，最终没能解决问题，同样选择了回档承担了数据损失。

再次，要有端到端融会贯通的应急机制。也就是说不仅仅技术上具备容灾应急的响应方案，从业务端同样要有对应的预案，以便应急时同步处理，区别对待。很多时候，有了业务上的应急、降级服务方案，技术层面的处理就能够从容许多。

最后，要有能够快速协同的团队资源。很多时候严重的故障，需要较大规模的专业团队协作处理，原厂商和第三方在其中都承载着重要的角色，所以关键时刻，要能够获得内外部快速及时的支持，尤其是在绵延数天的高强度工作中。

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