谈谈运维人员谨慎操作系统环境和管理

Posted 2021-01-07 youcong

很多时候，特别是初学者在搭建环境的时候，由于事先尝试了，导致软件残留，以至于部分软件安装失败。当然了，通常可以百度直接找到解决方案。

不过呢？有一点需要注意的，运维同志们再安装软件时，哪怕是尝试，尽可能本地虚拟机环境尝试，千万不要在生产服务器上。

卸载同删除一样，是一个极其危险的。有的时候一不小心咔擦，删错了东西，可能会导致系统没了，例如，记得刚刚做运维的时候，在公司电脑上，自己弄了几台虚拟机，其中有一台就是因为我不小心把boot给删了，导致很多东西都没了，不过幸好是本地虚拟机，如果是公司服务器，那就更糟糕了。

因此，从那以后，我极其谨慎。不管是现在的公司兼任DBA也好或是运维。我一般情况下都使用的是非root权限，因为“人非圣贤”，有的时候工作太忙了，如果使用root权限较为频繁的话，那么可能会出现一些意外。在这里，有一点我要强调，每天备份很重要，使用shell脚本完成自动化备份。

这样一来，确保数据尽可能的少损失。因为谁也不知道，明天会有哪些意外。既然意外具有突发性，那么时刻应对是最好的手段。

当然了，服务器也不能确保一定是没问题的，尽管使用的是阿里云。但是前段时间阿里云被攻击，导致部分公司因为采用的是阿里云服务器，影响项目的正常运行。不过好在没有大的损失。

下面首先说下卸载软件:

1.卸载软件

sudo apt-get remove 软件名

例如:

sudo apt -get remove apache

这条命令不能彻底的删除，彻底的删除是这条命令:

sudo apt-get --purge remove apache2
sudo apt-get --purge remove apache2.2-common
sudo apt-get autoremove

purge 翻译过来的意思是“肃清”，意为清除所有。

 

其实卸载软件除了数据库外，其他也没多大关系，这是非运维的理解。

从专业运维户的理解上看，生产环境，每个软件，每个文件及其系统的稳定性都与你密切相关，你必须要知道整个系统的点点滴滴(这里不是说你一定要非常理解Linux系统乃至内核，因为那样功底没有个五六年或者七八年的积累是不行的，这里指的比如系统上运行的软件,例如几台tomcat、mysql、redis、mongodb、zookeeper或hadoop、docker等等，同时对其软件优化到那种程度，知道比如MySQL当达到那个I/O值会导致出问题等等)。

通常说，一个运维相当于半个DBA。

2.删除

rm命令

-d：直接把欲删除的目录的硬连接数据删除成0，删除该目录；
-f：强制删除文件或目录；
-i：删除已有文件或目录之前先询问用户；
-r或-R：递归处理，将指定目录下的所有文件与子目录一并处理；
--preserve-root：不对根目录进行递归操作；
-v：显示指令的详细执行过程。

特别这一条命令,rm -rf 相当于递归强制删除，这个命令是最可怕的。

 

最好做个小总结，

比如最近出了好几个新闻，要么是数据库密码上传到github上，被某些人获知从而盗取数据；要么是，不小心删库。

如何避免出现这些问题？

从运维的角度来说,

　　 (1)制定严格完善的制度，比如对mysql而言，可以使用phpmyadmin对库表进行权限控制；

 　　(2)密码不可过于简单，比如123456这样的，该复杂还是要复杂,最好有个定期修改密码，比如三个月或者半年这样的周期，不过最有效保险的就是配置文件方式，这种配置文件方式只对运维人员开放，隐藏内部细节，开发者只能以键值对的形式获得，键值对中的值以某种编码方式加密，看起来复杂点，其实这样是最保险的，这样一来，倒是让我想起的Java三大特性之一的封装;

 

总而言之，运维人员一定要非常谨慎，必须要掌控全局(生产环境的点点滴滴),当然了，还是得对开发和测试有所了解，不然有的时候，很容易沦为专业背锅户的。

记得我一个同学，他们公司，有的时候因为开发人员的代码质量差，功能bug多的，导致系统稳定性差，出现了突发宕机，运维人员通常这个时候就处于风口浪尖的位置。

不管是运维也好，测试也罢，或者是开发，都要对彼此的工作了解和熟悉，因为这样一来，出了问题，会最大程度避免你推我，我推你，互相推卸责任的这种情况。彼此熟悉和了解，利于沟通，从而利于项目的良性开发，最大程度上，提高项目的成功率。