一、线上操作规范1.测试与使用学习Linux的使用时，从基础到服务再到集群，都是在虚拟机中完成的，虽然老师讲的我们跟真机没什么区别，但是对真实环境的渴望与日俱增，但是虚拟机的各种快照让我们养成了各种廉价的习惯，以至于在拿到服务器操作权限的时候，我们迫不及待地想尝试一下。尝试。记得第一天上班，老板给了我root密码。由于只能用PuTTY，想用XShell，于是悄悄登录服务器，尝试改成XShell+key登录，因为没测试，也没留SSH连接。重新启动SSHD服务器后，我被阻止访问服务器。还好当时备份了sshd_config文件，然后让机房的工作人员cp一下。还好这是一家小公司，不然我早就被直接打死了……还好我当年运气好。第二个例子是关于文件同步的。大家都知道rsync同步的速度非常快，但是删除文件的速度要比rm-rf快很多。rsync中有个命令是根据某个目录同步一个文件（如果第一个目录是空的，那么结果可想而知），源目录（有数据）会被删除。一开始因为误操作，没有测试，把目录写反了。关键是没有备份。。。生产环境数据都被删除了，没有备份。让我们考虑一下后果。它的重要性不言而喻。2.Enter前仔细检查rm-rf/var的错误。相信手快的人，或者网速比较慢的时候，发生的概率是相当高的。当你发现行刑结束的时候，你的心至少凉了一半。你可能会说我按了这么多次都没出错。不要害怕。我只想说，发生一次你就会明白。不要认为那些运维事故是别人造成的。一不留神，下一个就是你。3、不要多人操作我上一家公司，运维管理比较混乱。举个典型的例子，有几位离职的运维都有服务器root密码。通常我们运维接到任务的时候，都会进行简单的巡检。自己解决不了就找别人帮忙，可是一头雾水，客服主管（懂linux的），网管，你老板一起调试一台服务器。当你各种百度，各种对比的时候，发现你的服务器配置文件和上次修改的不一样，然后又改回来，再谷歌，兴冲冲的发现问题解决了，但是别人跟你说他也解决了，修改的参数不一样。。。所以真不知道哪个才是问题的真正原因，当然这样还是不错的，问题解决了，皆大欢喜，但是你遇到过刚刚修改的文件，testInvalid，你去修改发现文件又被修改了怎么办？真烦人，避免多人操作。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.生产环境必须开启防火墙，遵循最小化原则，全部丢弃，并然后释放所需的服务端口。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修复的，所以就这样修复了，但是过了几个小时，又出现了。.重复了三四遍，就去google搜索数据库表莫名损坏的原因：MyISAMBug；MySQL错误；MySQL在写入过程中被杀死。最后发现内存不够，导致OOM杀掉mysqld进程，swap分区也没有了。后台监控内存够用，最后通过升级物理内存解决。4、在测试和生产环境中，重要操作前一定要检查自己所在的机器，尽量避免多开窗口。
