前篇-反思自己出过的错

第一篇博客

使用 Markdown编辑器 还不够熟练.熟悉一下编辑器.顺便也记录一些自己之前遇到过并一直记着的情况和问题.,也是对自己的一个反思和总结.

1.生产环境数据库

当时发生的事情是:误删了生产的数据库表,
出现这种情况的原因,

• 第一,也是自己操作的时候不够细心;
• 第二,也是因为开发可以直接连接并操作生产的数据库;
  但是这种情况在小公司里基本很普遍,首先是条件不允许,其次,有一些情况,直接操作也确实会方便很多;

自我分析:
当时也是太不小心了,在同时连接着生产数据库和测试数据库的情况下,进行了删除操作,却没有注意,把生产的数据库表,当做测试给删除了;
不过好在当时删除的表是用户的一些偏好设置,比如像背景颜色啊,字体大小啊等等这样的一些喜好设置.也算是不幸中的万幸;

最终也是奋战到凌晨,从缓存中恢复了一部分数据,但还是有相当一部分数据被清除掉了;

丢失掉数据的那部分用户,可能在下次进来,会发现在自己之前的一些设置项怎么全部变成默认设置了;虽然这部分没有实质性的影响系统运行,但是也给用户带来了不好的体验;

这件事情的发生也给自己敲响了一个警钟:
试想一下:
如果当时删除的不是这些偏好设置,而是系统运行的一些必要数据,那后果真的是不敢想象.

总结:

从那之后,时至今日,乃至以后任何时候,
数据库除了查询以外的删除,新增和修改操作,都要再三的确认确认再确认;养成习惯甚至是肌肉记忆;而且最好在备份之后再执行;不管是生产环境还是测试环境,不管自己现在是否能够操作生产环境;不会嫌一点麻烦,因为出了问题的话,麻烦会更多.这种错误,绝对不允许出现第二次;

2.linux操作注意

这次发生的问题时一句linux执行命令;

大家应该都知道的linux里禁区命令"rm -rf /*",甚至可以说只要是rm命令,都要很细心;

但是其实危险的的地方,并不仅仅只有"rm",还有"/*"+r;

显而易见,翻译出来,意思就是,危险操作并不仅仅只有删除操作,只要是设计到所有文件的操作都是危险的;

当时执行了一行命令:

chmod -R 777 /*

当时的情况是,文件的权限不足,所以简单粗暴的方式就是更改文件的权限,但是意外的是,本来要执行的命令:

chmod -R 777 ./*

在自己的手抖的情况下,居然少打了一个小数点,直接就变成了

chmod -R 777 /*

而在发现的时候,命令已经执行了一半了;
造成的直接后果就是:linux系统的一些原生文件的权限被篡改成了;而linux系统依赖的一些文件,权限是固定的,不管是权限开放过大,或者过小,系统都不认;
所以会导致很多linux原生的命令和功能出现报错,最直接的体现就是拒绝ssh远程访问;

要是云服务器的话,在执行完命令之后;他就拒绝ssh远程访问;
换句话说就是,在执行完命令之前打开的ssh连接,不关闭的情况下,你可以继续操作,但是如果你关闭了,那是新建不了连接的;你就失去了和你的服务器连接…
接下来,就要去联系云服务器的工作管理人员…具体怎么搞就不太清楚了;

不过好在;当时公司的服务器不是云服务器,而是自家的物理服务器,所以直接去机房操作的,又是在奋战到凌晨,终于算是把默认的系统文件权限全部恢复了回来,恢复了服务器的正常运行,和功能的正常使用;(机房的机器排布很奇怪,只能站着敲了一夜的指令,第二天直接半死.)

总结:

不仅仅是

rm -rf /*
chmod -r 777 /*

等等这些指令,只要是涉及到/*,-r这一类的指令时,也一定要确认无误再执行;

人非圣贤孰能无过,有时候,出错并不是一件坏事,重要的是,能够从其中自我总结,并吸取经验,避免出现第二次类似的错误
在自己亲身经历了之后,真的是会刻在骨子里警示自己.做类似的事情时一定会仔细仔细再仔细;

看到这篇文章的小伙伴们,还是希望大家引以为戒,不要犯类似的错误;