从事运维三年半，遇到各种问题，例如数据丢失、网站崩溃、数据库文件意外删除、黑客攻击等。本文简单整理，分享给小伙伴们。一、线上操作规范1、测试使用刚开始学习Linux使用的时候，从基础到服务再到集群，都是在虚拟机上完成的。虽然老师告诉我们和真机没什么区别，对真实环境的渴望与日俱增，但是虚拟机的各种快照让我们养成了各种廉价的习惯，以至于当我们拿到服务器的时候操作权限，我们迫不及待地想尝试一下。记得第一天上班，老板给了我root密码。由于只能用putty，想用xshell，于是悄悄登录服务器，尝试改成xshell+key登录，因为没有测试，也没留下ssh连接。重新启动sshd服务器后，我被服务器阻止了。还好当时备份了sshd_config文件，然后让机房的工作人员cp一下。还好这是一家小公司，不然我早就被直接打死了……还好，当年的运气比较好。第二个例子是关于文件同步的。大家都知道rsync同步很快，但是它的删除速度比rm-rf要快很多。rsync中有个命令是根据某个目录同步一个文件（如果第一个目录为空，那结果可想而知），源目录（有数据）会被删除。一开始因为误操作，没有测试，把目录写反了。关键是没有备份。。。生产环境数据被删除了。没有后援，后果大家自己想，其重要性不言而喻。2、回车前，再次确认rm-rf/var的错误。相信手快的人或者网速比较慢的时候，发生的概率还是挺高的。当你发现行刑结束的时候，你的心至少凉了一半。你可能会说我按了这么多次都没出错。不要害怕。我只想说，发生一次你就会明白。一个是你。3、不要多人操作我上一家公司，运维管理比较混乱。让我举一个典型的例子。离职的几名运维员工都有服务器root密码。通常我们运维接到任务的时候，都会进行简单的巡检。自己解决不了就找别人帮忙，但遇到问题不堪重负时，客服主管（懂一点linux）、网管、你老板一起调试一台服务器。,和上次修改不一样了，又改回来，然后Google了一下，兴冲冲的找到问题解决了，结果有人告诉你他也解决了，而且修改的参数不一样了。。。这个，我我真的不知道哪个是问题的真正原因。当然，这样还是不错的。问题解决了，皆大欢喜，但是你有没有遇到过刚刚修改的文件，测试无效，然后你修改，发现文件又被修改了？真烦人，避免多人操作。4、养成操作前备份的习惯。当要修改数据时，先备份，比如.conf配置文件；另外，修改配置文件时，建议将原来的选项注释掉，然后复制修改；举个例子，有一个数据库备份，那么rsync的误操作很快就好了；所以，数据库丢失不会一蹴而就，随便备份一个也不会那么惨。二、涉及的数据1、慎用rm-rf网上例子很多，各种rm-rf/，各种删除主库，各种运维事故……一个小失误，就会造成很大的损失。如果确实需要删除，则必须谨慎。2、备份大于一切。本来上面就有各种各样的备份，但是我想把它分到数据的范畴里，再次强调一下，备份很重要。不要太多。我所在的公司有第三方支付网站和网贷平台。第三方支付每两小时备份一次，网贷平台每20分钟备份一次。我就不多说了，大家自己决定吧！3、稳定大于一切其实，不仅仅是数据。在整个服务器环境中，稳定性重于一切。我们不求最快，只求最稳定好用。所以，在没有测试的情况下，不要在服务器上使用新的软件，比如nginx+php-fpm，生产环境各种php挂掉~重启一下，或者换个apache。4.保密重于一切。现在各种色情网站满天飞，各种路由器后门，所以说到数据，不保密是不可能的。三、涉及的安全1、ssh更改默认端口（当然，如果专业的要黑你，扫描后就会出来）禁止root登录使用普通用户+密钥认证+sudo规则+ip地址+用户限制使用hostdeny类似防爆破解软件（多试几次直接屏蔽）屏蔽/etc/passwd中登录的用户2.生产环境必须开启防火墙，遵循最小化原则，dropall，然后释放所需的服务端口。3、细权限和控制粒度可以使用普通用户启动的服务，坚决不用root，把各种服务权限控制到最小，粒度控制到细。4、入侵检测和日志监控利用第三方软件时刻检测关键系统文件和各种服务配置文件的变化。例如/etc/passwd、/etc/my.cnf、/etc/httpd/con/httpd.con等。使用集中式日志监控系统监控/var/log/secure、/etc/log/message、ftp上传下载文件等告警和错误日志。另外，对于端口扫描，也可以使用一些第三方软件，如果发现被扫描了，会直接拉入host.deny。此信息对于系统遭到破坏后的故障排除非常有帮助。有人说，企业在安全方面的投资成本，与企业遭受安全攻击的损失成本成正比。安全是一个大话题。这也是一项非常基础的工作。如果基础做好了，系统的安全性就可以得到相当大的提升，剩下的就交给安全专家了。四、日常监控1、系统运行监控很多人一踏入运维，就从监控入手。大公司一般都有专业的24小时监控运维。系统运行监控一般包括硬件占用率，常见的有内存、硬盘、cpu、网卡，os包括登录监控、系统关键文件监控。定期监控可以预测硬件损坏的概率，并为调优带来有用的功能。2、服务运行监控服务监控一般是指各种应用，web，db，lvs等，一般是监控一些指标，可以快速的发现和解决系统中的性能瓶颈。3、日志监控这里的日志监控类似于安全日志监控，但这里一般是硬件、操作系统、应用程序的错误和告警信息。在系统稳定运行的时候监控真的没用，但是一旦出现问题你不监控，你就会很被动。五、性能调优1、深入理解运行机制其实根据一年多的运维经验，谈调优基本是纸上谈兵，只是想简单总结一下。如果我有更深入的了解，我会更新它。例如，在对软件进行优化之前，需要深入了解一个软件的运行机制，比如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，二是mysql的bug，三是mysql在写入过程中被kill了。最后发现内存不够，导致mysqld进程OOMkill，而且没有swap分区，后台监控内存够用，最后升级物理内存解决。4、在测试和生产环境中，重要操作前一定要检查自己所在的机器，尽量避免多开窗口。
