线上误删数据引发的反思

今天线上环境出现一个数据的误操作问题，说说抽象出来的场景吧：

某个数据清理shell脚本里面包含了形如mysql的连接串：

mysql -uxxx -pxxx -hxxx -Pxxx -D xxx -e "drop table xxxx";

本身这个脚本内容是清理某个特定的实例A的过期数据表的，但是运维同学想要用它清理某个离线的从库实例B的数据，修改连接串信息的时候，修改了账号、密码、端口、数据库以及表信息，漏掉了host信息，恰好有这么一个线上实例，于是就被清理掉了。

其实这个关键就在于要清理的实例，是个离线从库，除了IP地址不一样，其他登录信息和线上实例一模一样，所以极容易发生错误。

在数据恢复的同时，我在设想这个场景应该如何避免，我个人认为更多的还是脚本风格上的问题，设想这么2个脚本：

脚本1：

#!/bin/bash

# login_mysql

mysql -uxxx -pxxx -hxxx -Pxxx -D xxx -e "drop table xxxx";

-----------分割线------------------

脚本2：

#!/bin/bash

# conn_info

user=xxx

passwd=xxx

host=xxx

port=xxx

db=xxx

tbl=xxx

# login_mysql

mysql -uuser -ppasswd -hhost -Pport -D db -e "drop table

脚本一可能写着比较快，脚本二相对比较复杂

但是从安全角度来讲，如果你要修改连接信息，脚本一要更容易漏掉其中的某一项（从而导致这个连接信息应用在下一个连接中），而脚本二连接信息在一起写着，不容易漏掉相关的连接信息。

另外，如果在脚本一当中，要更换连接信息，我的习惯做法是先注释掉之前的连接信息，再重新写一个连接串，而不是在原来的连接串上直接修改。这样，也就不容易漏掉其中的某一项了：

#!/bin/bash

# login_mysql

# mysql -uxxx -pxxx -hxxx -Pxxx -D xxx -e "drop table xxxx"; 注释

mysql -uxxx -pxxx -hxxx -Pxxx -D xxx -e "drop table xxxx";

有了这些操作习惯，我觉得可以一定程度上避免误操作。

当时看到这个操作，让我想起了自己当年犯过的一些低级错误：

1、update某个密码，忘了写where 条件，导致全部账号的密码被修改，线上无法访问

反思：这个问题，其实可以在update之前，先select一下，然后修改select关键字为update，再拼写完整语句。

2、脚本中的rm -rf $para/，其中，para参数没有值，导致删除了预发布环境的/目录

反思：这种的低级错误，其实完全可以在执行这个操作的时候，先判断para参数是否为空，为空就不执行这个命令，当时确实年少无知....

其实还有一种办法，就是我们删除文件的时候，最好前面跟上cd xxx && rm -rf xx，这样，就可以把影响范围固定在某个目录里面，再有就是，能mv的目录，先不要rm -rf

3、rm -rf 习惯

反思：其实我不喜欢这个习惯，当你确定你要删除的是一个文件的时候，还是应该使用rm -f xxx，而不是rm -rf xxx

设想这样一个场景：你要删除一个文件aaa.txt,而这个目录中，确实存在aa这个目录，如果你使用了tab补齐，那么出来的先是aa这个目录，你需要双击tab才能出来aaa.txt,那如果第一次补齐的时候，就手快点了回车，那你就只能哭泣了。有的时候，一个小小的习惯，可能会拯救你

诸如此类的经验还有很多，今天没时间写了，改天我总结一篇操作习惯分享分享。

那么，你有哪些好习惯呢？不妨跟我分享一下吧。