来呀，玩游戏啊，免费的，不来玩玩吗？
问：你想删库吗？
DBA：我有病啊
问：你想删库吗？
DBA：不想啊
问：你想删库吗？
DBA：要负责任吗？
问：你想删库吗？
DBA：哎呀嘛，咔咔的！这么刺激的事谁不想干！
今年的网络安全风暴似乎比以往来得更猛烈一些，勒索事件使得业界哗然，删库跑路事件也一度使得人人自危，意外的是，一直默默无闻的“删库”顿时成为业界新宠，甚至与删库有着千丝万缕的“跑路”，也开始成为验证大神和屌丝的试金石。
删库为何会发生？
1.初级删——我真的不是故意的
夜凉如水，Gitlab的同志已经分不清是白天还是黑夜，眼镜已经戴不住了，只觉得头很重，像磕了安眠药似的，于是，在下一秒敲在键盘的时候，倒头就睡了过去……
醒来时，做梦般眼睁睁看着自己误删了一个错误的服务器上的目录！！！
这是Gitlab的管理员在极度疲劳时不小心删除了一个包含 300GB 实时产品数据的文件夹，在取消 rm -rf 删除命令后该文件夹只剩下 4.5GB 数据，无可挽回的是最近的数据是在6小时前备份的……
2.中级删——我们能怎么办？我们也很无奈
2017年2月9日至2月10日下午7时30分，Instapaper服务突然中断，事故起因是2014年4月之前创建的RDS实例的2TB文件大小限制，造成了不小的损失。
3.创意删——宁为玉碎不为瓦全
2017年8月20日电 软件工程师徐某离职后因公司未能如期结清工资，便利用其在所设计的网站中安插的后门文件将网站源代码全部删除。
一时冲动不仅毁了自己的前程，还有海量的数据……
4.高级删——未解之谜
2015年5月28日11时，携程网官网出现大面积瘫痪，网页版和手机APP均不能正常使用。携程方面对此回应称服务器遭到不明攻击，在此次故障中全部遭受物理删除，且备份数据也无法使用。
一时间众说纷纭，有人爆料说是因为运营的妹子和携程的高管好了,所以遭报复删除了数据，还有人说是离职员工联手携程的竞争对手干的……但5月29日，携程发布官方情况说明称，此次事件是由于员工错误操作，删除了生产服务器上的执行代码导致。
当然，这些都是人为的车祸事故，更多的是日常正常维护删库，或许是业务繁忙后系统已装载不下，或者是供电出现问题系统崩溃了……..但不得不承认，应对删库本身似乎成为心照不宣的衡量DBA专业素质标杆。
有人说，删库后便达到了万物皆空的高度。一切不可说、不能说、不必说、也不须说。那是背后的专业素质和心理素质的高度达到让人不得不疯狂打call的地步……
不想删库的DBA，不是一个苦逼的运维大神，但不论是哪种删库，如果能跑路，那就跑吧，不能跑的，那就勤练备份和还原吧~
而从企业角度来看，如何避免有意无意类删库事件造成损失呢？

首先，要有完善、有效的备份和容灾机制。诚然很多企业都有了一整套的备份、容灾机制，但是这套备份机制能否真实奏效是需要检验的。一些大型企业，虽然投入巨资兴建灾备中心，却从未正式切换过，这样的灾备在故障来临时也很难有人拍板去进行切换，所以备份的有效、容灾手段的有效是必须确保的。注意，备份的恢复速度必须足够的考虑到，磁带的低效备份关键时刻会害死人。
其次，要有完善的故障处理策略和流程。对于不同系统，在关键时刻要优先确保什么，是要订立规则的，有了规则才能照章办事，不走错方向，不无辜背锅。几年前国内金融系统出现数据坏块，同样选择了带病修复，最终没能解决问题，同样选择了回档承担了数据损失。
再次，要有端到端融会贯通的应急机制。也就是说不仅仅技术上具备容灾应急的响应方案，从业务端同样要有对应的预案，以便应急时同步处理，区别对待。很多时候，有了业务上的应急、降级服务方案，技术层面的处理就能够从容许多。
最后，要有能够快速协同的团队资源。很多时候严重的故障，需要较大规模的专业团队协作处理，原厂商和第三方在其中都承载着重要的角色，所以关键时刻，要能够获得内外部快速及时的支持，尤其是在绵延数天的高强度工作中。
其实，最稳妥的方式，是珍惜每个DBA,创造一个轻松舒适的工作氛围，避免熬夜加班、疲劳驾驶，没有什么解决不了的事，如果有，可能是这个公司不是像宝原科技一样和睦，那些心有戚戚的DBA，也要冷静下，删库只能获得一时快感，清醒之后更多的麻烦会压得你喘不过气儿来……而且天网恢恢疏而不漏，跑路也没用…… 记住，备份重于一切。