人在家中坐，删库天上来。

上个月wei盟的删库事件，在运维圈引起不小的轰动，不了解的自行搜索下哈。

我也和大佬聊了下，我问：“能从其中得到怎样的教训？”。

大佬回复是：“个例事件不具有参考价值。”。

我后来仔细一想也对呀。

每个公司掌握核心运维权限的人都可以瞬间把服务器搞瘫痪。

真的不是能从技术层面能解决的。至少从我的技术认知范围内还没想到什么办法通过技术让人不犯罪。

通过以前多次的事件和这次的影响。大家更进一步认识了运维人员的威力。

既然删错数据和文件危害那么大，我们作为一个好人。怎么避免脑子糊涂踩雷呢。

今天和大家分享下我的和同事的一些经历，以及自己拙劣的应对策略希望大家莫见笑。

1、直接清空了测试库

2008年，（暴露自己是老程序员了，^_^） 自己和同事在导表的时候，没注意到最上面有一句的sql

DROP DATABASE  IF EXISTS  <database>

直接在同事的电脑上点击了运行，后来发现其他表的都没有。才注意到刚刚执行的sql最上面是删库语句。吓死了后背都冒冷汗，还好是测试库。给自己敲响了警钟。

应对策略：运行SQL时比如倒库、导表的时候一定注意有没有删库和删除表格的语句。

2、数据库某个字段没加条件被全部更新

• 某个早春的下午， 一张存放图库的表被同事不加where条件的执行了。本来把某一条数据的字段A置空，结果把所有记录的字段A置空了,还好影响数据不多。通过用前一天的备份的数据恢复了表，上午编辑的工作白做了。

应对策略：

1）备份很重要
2）我自己写update 或者delete语句时候，会先写出where语句后面的，然后在去写前面的表名和字段名
3）尽量避免开发有对线上数据库的直接操作权限，能减少一部分误操作

4）一般的更新或者删除要加limit

• 又是某个初夏的下午

一个程序员通过QQ发给运维要修改下自己账号的密码，来了一句。

update user set passwd='xxxxx'

运维也没注意，直接运行了。

结果悲剧了，客服部门反馈有某些账号登录不了。危害不大的原因是。很多用户浏览器都保存了cookie。不需要直接密码直接登录。抓紧恢复。后果导致当天修改过密码的人得再次修改密码。

应对策略：走审核系统杜绝直接私信运维执行语句。

3、图片被误删除

又是某个下午，（看来下午容易糊涂呀）我工位后面的同事大概想执行的命令是（印象中是这样）

rm ./ 

结果变成了。

rm .空格 /

发现执行很长时间，然后有人反馈有的图片打不开了。悲剧了。图片持续被删除了，而且没备份。

一定数量的图片被删除（万张以上），（因为使用了nfs架构，图片目录挂载到了web服务器上）

随后通过cdn恢复了一部分。

应当策略：

1） 杜绝开发人员有服务器的操作权限

2） 资源走云存储

3） 图片资源，只增加不删除

我自己在工作对数据库和服务器操作中也通过一些方法来提醒自己，时刻保持谨慎。

4、数据库操作软件的使用

或者操作数据和查询干脆就使用两个不同的软件。但navicat很好用，不舍得不用

开发和测试一个

线上修改数据一个

Sequel Pro 的提示真是太垃圾了，快也不是，慢也不是。谁用谁知道

5、ssh命令终端的区分

对于我这个小心谨慎的和严重强迫症性格，必须区分开

。

欢迎点赞，评论，转发，收藏！！！