Linux运维一定要知道的六类好习惯和23个教训，避免入坑！

其实按一年多的运维经验来说，谈调优根本就是纸上谈兵，但是我只是想简单总结下，如果有更深入的了解，我会更新。在对软件进行优化之前，比如要深入了解一个软件的运行机制，比如nginx和apache，大家都说nginx快，那就必须知道nginx为什么快，利用什么原理，处理请求比apache，并且要能跟别人用浅显易懂的话说出来，必要的时候还要能看懂源代码，否则一切以参数为调优对象的文档都是瞎谈。

2.调优框架以及先后

熟悉了底层运行机制，就要有调优的框架和先后顺序，比如数据库出现瓶颈，好多人直接就去更改数据库的配置文件，我的建议是，先根据瓶颈去分析，查看日志，写出来调优方向，然后再入手，并且数据库服务器调优应该是最后一步，最先的应该是硬件和操作系统，现在的数据库服务器都是在各种测试之后才会发布的

适用于所有操作系统，不应该先从他入手。

3.每次只调一个参数

每次只调一个参数，这个相比大家都了解，调的多了，你就自己就迷糊了。

4.基准测试

判断调优是否有用，和测试一个新版本软件的稳定性和性能等方面，就必须要基准测试了，测试要涉及很多因素

测试是否接近业务真实需求这要看测试人的经验了，相关资料大家可以参考《高性能mysql》第三版相当的好

我的老师曾说过，没有放之四海皆准的参数，任何参数更改任何调优都必须符合业务场景

所以不要再谷歌什么什么调优了，对你的提升和业务环境的改善没有长久作用

六、运维心态

1.控制心态

很多rm -rf /data都在下班的前几分钟，都在烦躁的高峰，那么你还不打算控制下你的心态么

有人说了，烦躁也要上班，可是你可以在烦躁的时候尽量避免处理关键数据环境

越是有压力，越要冷静，不然会损失更多。

大多人都有rm -rf /data/mysql的经历，发现删除之后，那种心情你可以想象一下，可是如果没有备份，你急又有什么用，一般这种情况下，你就要冷静想下最坏打算了，对于mysql来说，删除了物理文件，一部分表还会存在内存中，所以断开业务，但是不要关闭mysql数据库，这对恢复很有帮助，并使用dd复制硬盘，然后你再进行恢复

当然了大多时候你就只能找数据恢复公司了。

试想一下，数据被删了，你各种操作，关闭数据库，然后修复，不但有可能覆盖文件，还找不到内存中的表了。

2.对数据负责

生产环境不是儿戏，数据库也不是儿戏，一定要对数据负责。不备份的后果是非常严重的。

3.追根究底

很多运维人员比较忙，遇到问题解决就不会再管了，记得去年一个客户的网站老是打不开，经过php代码报错

发现是session和whos_online损坏，前任运维是通过repair修复的，我就也这样修复了，但是过了几个小时，又出现了

反复三四次之后，我就去谷歌数据库表莫名损坏原因：一是myisam的bug，二是mysqlbug，三是mysql在写入过程中

被kill，最后发现是内存不够用，导致OOM kill了mysqld进程

并且没有swap分区，后台监控内存是够用的，最后升级物理内存解决。

4.测试和生产环境

在重要操作之前一定要看自己所在的机器，尽量避免多开窗口。

【编辑推荐】

1. Linux下PHP网站服务器安全配置加固防护方法
2. Linux服务器Redis漏洞被利用挖矿解决方法
3. Linux服务器安全事件应急的一些随笔 - 备份篇
4. 服务器安全运维规范-安全运维的事前、事中、事后
5. Linux 多网卡的7种bond模式原理

（编辑：PHP编程网 - 黄冈站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!