删库跑路对网站造成的后果是很严重的，甚至是“毁灭性”的。上面那起事件造成的历史数据损失，要一周时间修复，更不用提因线上服务瘫痪、导致业务停滞造成的直接经济损失了！
这件事引发的深思，从法律角度就不细谈了，《网络安全法》第 21 条写的很清晰。
我们从技术角度，详细谈一谈：
1、rm -rf怎么防止以及怎么应对（技术、流程、应急预案）？
2、为什么数据库工程师对企业意义重大？
为什么数据库工程师对企业意义重大？
其实误操作并不少见，最好的结果就是有镜像，花点时间就能恢复。
纵览一些删库跑路事件，可以总结出来就是，一是做好镜像，二是重视数据库权限管控，像删库这种高危操作建立审批机制，留一条“生路”给备份数据。
公司管理上，最好有自己的 DB 运维产品，线上数据库只允许查，改的话要有审批流程。
归根结底，数据库工程师责任重大！其本身的技术专业度、整个数据库团队建设的规范程度、以及数据库管控制度，是职业生涯终身需要关注的问题！
这也是为什么，企业招聘高级数据库工程师，动辄给出30w的年薪！
数据库工程师，加班强度不大，并且随着年龄和工作经验增加、越老越吃香，是IT行业薪酬最高的十大职业之一。
数据库工程师可以去政企国有单位从事数据库运维管理岗（DBA）、数据库开发岗等，也可以去乙方数据库服务厂家做数据库售前咨询、数据库项目经理、数据库研发与测试、数据库管理与维护等等。
从数据库技术角度看，以MySQL为例，一天的binlog（数据变更日志）数据都是非常大的，另外备份选择的通常是全库冷备+binlog热备的形式，甚至还包括多副本保存、异地保存、线上线下保存、文件加密权限隔离等方式，但99%的中小企业都不会做这些看起来相当麻烦的事情
rm -rf怎么防止以及怎么应对？
一、如何正确使用rm -rf
言归正传，其实rm -rf命令本身并不是一个“坏东西”，它是删除文件夹及其内容的最快方法之一。但一个标点错误就可能会导致不可恢复的系统损坏。与rm命令选项是：
rm 命令用于删除文件。
rm -r命令以递归方式删除文件夹，甚至是空文件夹。
rm -f命令在不询问的情况下删除“只读文件”。
rm -rf /：强制删除根目录中的所有内容。
rm -rf ~将删除主文件夹中的所有文件，
rm -rf .*将删除所有配置文件。
rm -rf *：强制删除当前目录/工作目录中的所有内容
rm -rf. ：强制删除当前文件夹和子文件夹。
因此，提醒大家在执行rm -rf要格外小心。为了防止意外删除文件，最佳实践是在“.bashrc”文件中创建’rm’命令别名为’rm -i’，它会要求确认每次删除。
二、如何正确使用rm -rf
值得注意的是，在进行清理数据库之前一定要检查进程，是否存在数据库进程，如果存在则宁愿不搞也不要深夜搞。清理数据库一定要梳理相关具体执行步骤和命令，并详细记录反馈，按照流程进行操作，宁愿多租几天机房也不要丢掉数据。
对于删库这个问题，网络技术大佬认为权限问题永远是大问题，做好权限回收，开发数据库和线上数据库分离，线上数据库管理权限（一般指修改表结构权限与删表权限）禁止回收，也不提供给业务直接用。
最后，在备份方面，也应该冷备、热备双管齐下，一天一备。
三、如何有效避免删库跑路事故？
这里总结了4点（大家做好笔记） ????
好吧，我们谈一谈如何避免陷入这样的困境？以下是我们的一些思路，与大家商榷。
首先，要有完善、有效的备份和容灾机制。诚然很多企业都有了一整套的备份、容灾机制，但是这套备份机制能否真实奏效是需要检验的。我接触过某大型企业，投入巨资兴建的灾备中心，从未正式切换过，这样的灾备在故障来临时也很难有人拍板去进行切换，所以备份的有效、容灾手段的有效是必须确保的。注意，备份的恢复速度必须足够的考虑到，磁带的低效备份关键时刻会害死人。
其次，要有完善的故障处理策略和流程。对于不同系统，在关键时刻要优先确保什么，是要订立规则的，有了规则才能照章办事，不走错方向，不无辜背锅。几年前某国内金融系统出现数据坏块，同样选择了带病修复，最终没能解决问题，同样选择了回档承担了数据损失。
再次，要有端到端融会贯通的应急机制。也就是说不仅仅技术上具备容灾应急的响应方案，从业务端同样要有对应的预案，以便应急时同步处理，区别对待。很多时候，有了业务上的应急、降级服务方案，技术层面的处理就能够从容许多。
最后，要有能够快速协同的团队资源。很多时候严重的故障，需要较大规模的专业团队协作处理，原厂商和第三方在其中都承载着重要的角色，所以关键时刻，要能够获得内外部快速及时的支持，尤其是在绵延数天的高强度工作中。
数据库故障【应急手册】
