一.线上操作规范
1.测试使用--->学习Linux的使用,从基础到服务到集群都是在虚拟机做的(虚拟机的快照),拿到服务器的操作权限时,领导交给我root密码，由于只能使用putty，我就想使用xshell,于是悄悄登录服务器尝试改为Xshell+密钥登录,因为没有测试，也没有留一个SSH连接,所以重启SSHD服务器之后,自己就被挡在服务器之外了，幸好当时我备份了sshd_config文件,所以让机房人员cp过去即可.
2.第二个例子是关于文件同步的,大家都知道rsync同步很快,可它删除文件的速度大大超过 rm -rf,在rsync中有一个命令是,以某目录为准同步某文件(如果第一个目录是空的，结果可想而知)源目录(有数据的)就会被删除,当初我就是因为误操作,以及缺乏测试,就目录写反了，关键是没有备份数据...生产环境数据被删了-----备份的重要性
3.Enter前再三确认--->关于rm -rf/var这种错误,我相信手快的人,或者网速比较慢的时候,出现的几率相当大,当你发现执行完之后,麻了。 运维事故就是不小心谨慎产生的！
4.切忌多人操作--->运维管理相当混乱,离职好几任的运维都有服务器root密码,通常我们运维接到任务m都会进行简单查看如果无法解决,请求他人帮忙，可当问题被多人操作时,结果就不太理想!例如:调试一个服务器--->修改服务器配置文件。
5.先备份后操作-->养成一个习惯,要修改数据时,先备份,比如.conf的配置文件.另外，修改配置文件时,建议注释原选项,然后再复制,修改。
二.涉及数据
5.慎用rm -rf --->网上的例子很多,各种rm -rf /,各种删除主数据库,各种运维事故.
6备份大于一切---> 数据的定时备份
7.稳定大于一切--->不只是数据,在整个服务器环境中求可用性，不求最快,所以未经测试，不要在服务器使用新的软件 服务器挂了后-->重启下就好了,或者换apache即可！
8.保密大于一切->数据保密性,各种路由器后门
三.涉及安全
9.SSH .
1.更改默认端口(当然如果专业要黑你,扫描下就出来了)
2.禁止root登录
3.使用普通用户+key认证+sudo规则+ip地址+用户限制
4.使用hstdeny类似的防爆里破解软件(超过几次尝试直接拉黑)
筛选 /etc/password中login的用户。
10.防火墙
防火墙生产环境一定要开,并且要遵循最小原则,drop所有,然后放行需要的服务端口。
11.精细权限和控制粒度
能使用普通用户启动的服务绝对不用root,把各种服务权限控制到最低,控制粒度要精细.
12.入侵检测和日志监控
使用第三方软件,时刻监测系统关键文件以及各种服务配置文件的改动,比如: /etc/passwd, /etc/my.cnf, /etc/httpd/con/httpd.con等。
使用集中化的日志监控体系,监控 /var/log/secure, /etc/log/message, ftp上传下载文件等报警错误日志。
另外针对端口扫描,也可以使用一些第三方软件,发现被扫描就直接拉入host.deny.这些信息对于系统被入侵后排错很有帮助。----->提高系统安全性。
四.日常监控
13.系统运行监控---->大公司一般有专业24小时监控运维.系统运行监控一般包括硬件占用率,常见的有,内存,硬盘,CPU，网卡,OS包括登录监控,系统关键文件监控。
定期的监控可以预测出硬件损坏的概率,并且给调优带来很实用的功能.
14.服务运行监控
服务监控一般就是各种应用,web，DB,LVS等，这一般都是监控一些指标。在系统出现性能瓶颈的时候就能很快分析并解决。
15.日志监控
这里的日志监控跟安全的日志监控类似,但这里一般都是硬件,OS应用程序的保存和警报信息。
监控在系统稳定运行的时候确实作用不大,但是一旦出现问题,你又未做监控，无法定位问题,很被动。
五.性能调优
16.深入了解运行机制
对软件进行优化之前,我会更新。在对软件进行优化之前,比如要深入了解一个软件的运行机制,比如nginx和apache,大家都说nginx快,那就必须找到nginx为什么快,利用什么原理，处理请求比apache,必要时要能看懂源代码，否则一切以参数为调优对象的文档都是瞎谈.
17.调优框架以及先后
熟悉了底层运行机制，就要有调试的框架和先后顺序，比如数据库出现瓶颈，好多人直接去更改数据库的配置文件,我的建议是，先根据瓶颈去分析,查看日志,写出来调优方向,然后再入手,最先的应该是硬件和操作系统，现在的数据库服务器都是在各种测试之后才会发布的。
适用于所有操作系统，不应该先从他入手。
18.每次只调一个参数
每次只调一个一个参数,这个大家都了解,调的多了，就迷了。
19. 基准测试
判断调试是否有用,和测试一个新版本软件的稳定性和性能等方面，就必须要基准测试了，测试要涉及很多因素。
测试是否接近业务真实需求，这要看测试人的经验了.我的老师曾言，没有放之四海皆准的参数,任何参数更改任何调优都必须符合业务场景，所以不要再谷歌什么调优了，对你的提升和业务环境的改善没有长久作用。
六 运维心态
20.控制心态
很多rm -rf /data 都在下班前几分钟(在烦躁情绪的时候尽量避免处理关键数据环境,越是有压力越冷静) 大多数人都有rm -rf /data/mysql的经历,发现删除之后可是没有备份?对于MySQL来说,删除了物理文件,一部分表还会存在内存中,所以断开业务,但是不要关闭MySQL数据库，这对恢复很有帮助,并使用dd复制硬盘,然后再进行恢复,当然大多时候只能找数据恢复公司了.
试想一下,数据被删了,你各种操作,关闭数据库，然后修复,不但有可能覆盖文件,还找不到内存中的表了。
21.对数据负责
生产环境不是儿戏,数据库也不是儿戏,一定要对数据负责,不备份后果严重
22.追根溯源
指标也要治本? 数据库表莫名损坏原因:一是Myisam的bug,二是mysql bug,三是mysql在写入过程中被kill,最后发现是内存不够用,导致 OOM kill了mysqlId进程,并且没有swap分区,后台监控内存是够用的,最后升级物理内存解决。
23. 测试和生产环境
在重要操作之前一定要看自己所在的机器,尽量避免多开窗口。
