经验谈：Linux运维工程师攻击的6个好习惯23课等，今天简单整理一下，分享给小伙伴们。一、线上操作规范1、测试使用刚开始学习Linux使用的时候，从基础到服务再到集群，都是在虚拟机上完成的。虽然老师告诉我们和真机没什么区别，对真实环境的渴望与日俱增，但是虚拟机的各种快照让我们养成了各种廉价的习惯，以至于当我们得到服务器操作权限，我们已经迫不及待想试试了。记得第一天上班，老板给了我root密码，因为我只能用putty，我想用xshell，于是我悄悄登录服务器，尝试改成Xshell+按键登录，因为没有测试，也没有剩余的SSH连接。重新启动SSHD服务器后，我被阻止访问服务器。另外，还好当时自己备份了sshd_config文件，后来让机房的工作人员cp过来了。还好这是一家小公司，不然早就被直接干掉了……还好，当年的我运气不错。第二个例子是关于文件同步的。大家都知道rsync同步的速度很快，但是它的删除速度却比rm-rf快很多。rsync中有个命令是根据某个目录同步一个文件（如果第一个目录为空，那结果可想而知），源目录（有数据）会被删除。一开始因为误操作，没有测试，把目录写反了。关键是没有备份。。。生产环境数据被删除了。没有后援，后果大家自己想，其重要性不言而喻。2、在回车前反复确认rm-rf/var的错误。相信手快的人，或者网速比较慢的时候，发生的概率是相当高的。当你发现执行完成时，你的心至少会凉。一半。你可能会说，我按了那么多次，没有出错。不要害怕。我只想说，发生一次你就会明白。不要认为那些运维事故是别人造成的。一不留神，下一个就是你。3、不要多人操作我上一家公司，运维管理比较混乱。让我举一个典型的例子。离职的几名运维员工都有服务器root密码。通常我们运维团队接到一个任务的时候，我们会进行简单的检查，如果不能解决，我们就会找其他人帮忙，各种对比，结果发现你的服务器配置文件和上次修改的不一样，又改回来，然后google了一下，兴奋的找到问题解决了，但是别人告诉你他也解决了它。修改的参数不一样。。。这个，真不知道哪个是问题的真正原因，当然这样还是不错的，问题解决了，皆大欢喜，但是你遇到了刚刚修改的文件，测试无效，然后去修改的时候发现文件又被修改了？真烦人，避免多人操作。4、养成操作前备份的习惯。当要修改数据时，先备份好，比如.conf配置文件。另外，修改配置文件时，建议将原来的选项注释掉，然后复制修改。再者，如果第一个例子中有数据库备份，那么rsync的误操作很快就好了。所以，数据库丢失不是一蹴而就的，随便备份一个也没那么惨。2.涉及数据5.慎用rm-rf网上的例子很多，各种rm-rf/，各种删除主库，各种运维事故……一个小失误，就会造成很大的损失。如果确实需要删除，则必须谨慎。6、备份大于一切。本来上面就有各种各样的备份，但是我想把它分到数据类里再次强调一下，备份很重要。我记得我的老师说过一句话，当涉及到数据时，任何一种谨慎都不过分。我所在的公司有第三方支付网站和网贷平台。第三方支付每两小时备份一次，网贷平台每20分钟备份一次。我就不多说了，大家自己判断吧。7、稳定大于一切。事实上，不仅仅是数据。在整个服务器环境中，稳定性重于一切。它不求最快，但求最稳定和可用性。所以，在没有测试的情况下，不要在服务器上使用新的软件，比如Nginx+PHP-FPM，生产环境各种PHP挂掉。只需重新启动它，或更改x.8.保密比一切都重要。现在各种色情门户满天飞，各种路由器后门，所以说到数据，不保密是不可能的。3、涉及安全9、更改SSH的默认端口（当然，如果专业人士要黑你，扫一扫就出来了）。禁止root登录使用普通用户+密钥认证+sudo规则+IP地址+用户限制使用hostdeny之类的防爆破解软件（多次尝试直接屏蔽）屏蔽/etc/passwd中的登录用户.10、防火墙防火墙的生产环境必须开启，必须遵循最小化原则，dropall，然后释放需要的服务端口。11、细权限和控制粒度可以使用普通用户启动的服务，坚决不用root，把各种服务权限控制到最小，控制粒度细。12、入侵检测和日志监控利用第三方软件不断检测系统关键文件和各种服务配置文件的变化，如：/etc/passwd、/etc/my.cnf、/etc/httpd/con/httpd。等等。使用集中日志监控系统监控/var/log/secure、/etc/log/message、ftp上传下载文件等告警和错误日志。另外，对于端口扫描，也可以使用一些第三方软件，如果发现被扫描了，会直接拉入host.deny。此信息对于系统遭到破坏后的故障排除非常有帮助。有人说，企业在安全方面的投资成本，与企业遭受安全攻击的损失成本成正比。安全是一个很大的话题，也是一项很基础的工作。如果基础做得好，系统的安全性可以得到很大的提高。性，剩下的就交给安全专家了。4.日常监控13.系统运行监控很多人一踏入运维，就从监控入手。大公司一般都有专业的24小时监控运维。系统运行监控一般包括硬件占用率，常见的包括内存、硬盘、CPU、网卡，OS包括登录监控、系统关键文件监控。定期监控可以预测硬件损坏的概率，并为调优带来有用的功能。14、服务运行监控服务监控一般是指各种应用，Web，DB，LVS等，一般是监控一些指标。当系统出现性能瓶颈时，可以快速发现并解决。15.日志监控这里的日志监控类似于安全日志监控，但这里一般是硬件、操作系统、应用程序的错误和告警信息。在系统稳定运行的时候监控真的没用，但是一旦出现问题你不监控，你就会很被动。五、性能调优16、深入理解运行机制其实根据一年多的运维经验，谈调优基本是纸上谈兵，只是想简单总结一下。如果我有更深入的了解，我会更新它。例如，在对软件进行优化之前，你需要深入了解一个软件的运行机制，比如Nginx、Apache。大家都说Nginx快，那么你一定要知道Nginx为什么快，它使用的是什么原理，它是如何比Apache更好地处理请求的，并且你必须能够和别人交流。用通俗易懂的话说，必要的时候必须能看懂源码，否则所有以参数为调优对象的文档都是废话。17.调优框架和熟悉底层运行机制，你需要有一个调优框架和顺序。比如数据库出现瓶颈，很多人会直接改数据库的配置文件。我的建议是先根据瓶颈来分析，查看日志，写出调优方向，然后启动，而数据库服务器调优应该是最后一步，首先应该是硬件和操作系统，目前的数据库服务器是经过各种测试才发布的。与所有操作系统一样，您不应该从他开始。18.一次只调整一个参数。一次只调整一个参数。跟大家比起来，这一点谁都知道。如果你调整太多，你会感到困惑。19、基准测试判断调优是否有用，测试新版本软件的稳定性和性能，基准测试是必不可少的，测试涉及的因素很多。测试是否贴近业务的真实需求，取决于测试人员的经验。相关资料可以参考《高性能MySQL》第三版还是不错的。我的老师曾经说过，没有一刀切的参数，任何参数的变化，任何的调优都要符合业务场景，所以不要再谷歌调优了，对长期影响不大您的改善和商业环境的改善。6.运维心态20.控制心态很多rm-rf/data在下班前几分钟都处于烦躁的高峰期，那你不打算控制一下自己的心态吗？有人说，烦躁了就得上班，但是烦躁的时候可以尽量避免和关键数据环境打交道。压力越大，越冷静，否则会失去更多。大多数人都有rm-rf/data/mysql的经历。你可以想象发现删除后的感觉，但如果你没有备份，着急有什么用。一般这种情况，你要冷静的想一想最坏的情况，对于MySQL来说，删除物理文件后，内存中还会存在一些表，所以断开业务，但不要关闭MySQL数据库，这是对恢复很有帮助，用dd复制硬盘，就可以恢复了。当然，大多数时候只能找数据恢复公司。试想，数据删除了，你做各种操作，关闭数据库，再修复，不仅可能文件被覆盖，内存中的表也找不到了。21.对数据负责。生产环境不是儿戏，数据库也不是。您必须对数据负责。不备份的后果很严重。22、追根究底，很多运维人员比较忙，遇到问题也不会去管。记得去年有一个客户的网站打不开。PHP代码报错后，发现是session和whos_online损坏了。之前的运维是通过repair修复的，我也是这样修复的，但是过了几个小时，又出现了。反复三四次后，又去google查找数据库表莫名损坏的原因：一是myisam的bug，二是mysql的bug，三是写入过程中mysql被kill了。最后发现是内存不够，导致mysqld进程OOM杀，而且没有swap分区，后台监控内存够用，最后升级物理内存解决。23、在测试和生产环境中，重要操作前一定要检查自己所在的机器，尽量避免多开窗口。
