从事运维一年半，遇到过各种问题，数据丢失，网站挂，数据库文件误删，黑客攻击等问题。今天想简单梳理一下分享给小伙伴们1.线上操作规范1.测试使用学习Linux的使用，从基础到服务再到集群，都是在虚拟机上完成的。虽然老师跟我们说跟真机没什么区别，但是对于真实环境来说，虚拟机的各种快照让我们养成了各种廉价的习惯，以至于当我们拿到服务器操作权限的时候，我们等不及要试试了。记得第一天上班，老板把root密码给我。由于只能用putty，想用xshell，于是悄悄登录服务器，尝试改成xshell+key登录，因为没有测试，就没有ssh连接了。重启sshd服务器后，我被blocked被服务器屏蔽了。还好当时备份了sshd_config文件，然后让机房人员cp过来。还好这是一家小公司，不然早就被直接干掉了……还好，当年的我运气不错。第二个例子是关于文件同步的。大家都知道rsync同步的速度非常快，但是删除文件的速度要比rm-rf快很多。rsync中有个命令是根据某个目录同步一个文件（如果第一个目录为空，那结果可想而知），源目录（有数据）会被删除。一开始因为误操作，没有测试，把目录写反了。关键是没有备份。。。生产环境的数据被删除了，没有备份。自己想想后果。它的重要性不言而喻。2.回车前仔细检查rm-rf/var的错误。相信手快的人，或者网速比较慢的时候，发生的概率是相当高的。当你发现执行完之后，你的心至少凉了一半。.你可能会说，我按了那么多次，没有出错。不要害怕。我只想说，发生一次你就会明白。不要认为那些运维事故是别人造成的。一不留神，下一个就是你。3、不要多人操作我上一家公司，运维管理比较混乱。让我举一个典型的例子。离职的几名运维员工都有服务器root密码。通常我们运维团队接到一个任务的时候，我们会进行简单的检查，如果不能解决，我们就会找其他人帮忙，各种对比，结果发现你的服务器配置文件和上次修改的不一样，又改回来，然后google了一下，兴奋的找到问题解决了，但是别人告诉你他也解决了它。修改的参数不一样。。。这个，真不知道哪个是问题的真正原因，当然这样还是不错的，问题解决了，皆大欢喜，但是你遇到了刚刚修改的文件，测试无效，然后去修改的时候发现文件又被修改了？真烦人，避免多人操作。4、养成先备份再操作的习惯。当要修改数据时，先备份好，比如.conf的配置文件。另外，修改配置文件时，建议将原来的选项注释掉，然后复制修改。例子中有数据库备份，所以rsync的误操作很快就好了。所以，数据库丢失不会一蹴而就，也不会随便备份一个就这么惨。二、涉及的数据1、慎用rm-rf网上例子很多，各种rm-rf/，各种删除主库，各种运维事故……一个小小的失误，就会造成很大的损失.如果确实需要删除，则必须谨慎。2、备份大于一切。本来上面就有各种备份，但是我想把它分到数据类。同样，备份非常重要。因为我工作的公司有第三方支付网站和网贷平台，第三方支付每两小时备份一次，网贷平台每20分钟备份一次。事实上，稳定性胜过一切数据。在整个服务器环境中，稳定性重于一切。它不求最快，但求最稳定和可用性。因此，它没有经过测试。服务器上不要用新的软件，比如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上传下载文件等告警错误日志；另外，对于端口扫描，也可以使用一些第三方软件，如果发现被扫描了，会直接Pull到host.deny中。此信息对于系统遭到破坏后的故障排除非常有帮助。有人说，企业在安全方面的投资成本，与企业遭受安全攻击的损失成本成正比。安全是一个很大的话题，也是一项很基础的工作。如果基础做得好，系统的安全性可以得到很大的提高。,其他都是安全专家做的4.日常监控1.系统运行监控很多人踏入运维都是从监控开始的。大公司一般都有专业的24小时监控运维。系统运行监控一般包括硬件占用率，内存，硬盘，cpu，网卡，os包括登录监控，系统关键文件监控，定期监控可以预测硬件损坏的概率，给调优带来非常实用的功能2.服务运营monitoring服务监控泛指各种应用，web，db，lvs等，一般监控一些指标，可以快速的发现和解决系统中的性能瓶颈。3、日志监控这里的日志监控与安全日志监控类似，但一般是硬件、os、应用程序错误和告警信息的监控。在系统稳定运行的时候真的没用，但是一旦出现问题，你可以不用监控，就会很被动。五、性能调优1、深入理解运行机制其实根据一年多的运维经验，谈调优基本就是纸上谈兵，只是想简单总结一下，如果有更深入的知识，我会更新。例如，在对软件进行优化之前，需要深入了解一个软件的运行机制，比如nginx、apache。大家都说nginx快，那么你一定要知道nginx为什么快，它使用的是什么原理，它是如何处理请求的，比apache更好，还要能和别人交流。用通俗易懂的话说，必要的时候必须能看懂源码，否则所有以参数为调优对象的文档都是废话。2.调优框架和对底层运行机制的熟悉，你需要有一个调优框架和顺序。比如数据库出现瓶颈，很多人会直接改数据库的配置文件。我的建议是先根据瓶颈来分析，查看日志，写出调优方向，然后启动，而数据库服务器调优应该是最后一步，首先应该是硬件和操作系统，目前的数据库服务器是经过各种测试才发布的。与所有操作系统一样，您不应该从他开始。3.一次只调整一个参数。一次只调整一个参数。跟大家比起来，这一点谁都知道。如果你调整太多，你会感到困惑。4、基准测试判断调优是否有用，测试新版本软件的稳定性和性能，基准测试是必不可少的。测试涉及很多因素。测试是否贴近业务的真实需求，取决于测试人员的经验，大家可以参考一下相关资料《高性能mysql》第三版挺好的。我的老师曾经说过，没有一刀切的参数。任何参数的改变，任何的调优，都必须符合业务场景，所以不要再google调优了。是的，对你改善和改善业务环境没有长期的影响六、运维心态1.控制心态很多rm-rf/data在上班前几分钟处于烦躁的高峰期，所以你还不打算控制你是什么心态？有人说，脾气暴躁就得上班，但是脾气暴躁的时候可以尽量避免去处理关键数据。环境越有压力，越要冷静，否则会失去更多。大多数人都有rm-rf/data/mysql的经历。你可以想象发现删除后的感觉，但如果你没有备份，着急有什么用。一般这种情况，你要冷静的想最坏的打算，对于mysql来说，删除物理文件，内存中还会有一些表存在，所以断开业务，但是不要关闭mysql数据库，很对恢复有帮助，用dd复制硬盘，然后你要恢复，当然大多数时候只能找数据恢复公司了。试想，数据删除了，你做各种操作，关闭数据库，再修复，不仅可能文件被覆盖，内存中的表也找不到了。2.对数据负责。生产环境不是儿戏，数据库也不是。您必须对数据负责。不备份的后果很严重。3、追根究底，很多运维人员比较忙，遇到问题也不会去管。是repair修复的，我也是这样修复的，但是过了几个小时，反复三四次之后，去google了，原因是数据库表莫名损坏：一个是myisam的bug，一个是myisam的bugmysqlbug，第三个是Mysql在写的过程中被kill掉了。最后发现是内存不够，导致OOM杀死mysqld进程，没有swap分区。后台监控内存够用，最后升级物理内存解决。4、在测试和生产环境中，重要操作前一定要检查自己所在的机器，尽量避免多开窗口。以上几点是我自己的工作经验。希望能给一些运维人员带来一些帮助。如有不足欢迎指教
