运维中遇到的问题如何解决的书(一)
运维常见问题详细解决方案
运维工作及常见解决方案
1. 概述
1.1 编写目的
编写本解决方案的目的是对运维人员在遇到问题的时候提供一个可参考的依据。运维人员以此解决方案作为今后在运维工作中遇到相同问题的一个指南和依据，指导运维人员如何去解决类似问题。也为新来运维人员熟悉运维工作。本解决方案主要从问题类型、问题描述和解决方案等方面进行说明。
1.2 适用范围
适用于运维人员、新来运维人员及相关人员。
2. 运维工作流程
客户打找运维服务，接到电话，先判断是由运维做还是的人做；
运维分机号为1，，先记录房间号，报修时间，服务开始时间，故障现象及记录接线人。
负责人先想解决方法，告知运维人员大体方向，运维人员根据了解的情况想解决方案，在去见客户的时候知道如何操作；
负责人给运维人员派工单，运维人员去执行；
执行完之后跟负责人交待此次工作结果；
回复，双方接收
每周的运维工作数据及运维工作报告的电子档须在下周一十点前发送到负责人邮箱中。
3. 运维工作内容
1) 终端软件维护
2) 网络调整
3) 电话调整
4) 机房巡检
5) 服务器操作：应用系统包括安全系统、移动执法系统、备份系统、机房监控系统；网络设备包括交换机、路由器、防火墙、流量控制系统。
6) 机房清洁
7) 空调维护
8) 其他
4. 常见问题解决方案
4.1 电脑装应用软件的步骤
新台式机和笔记本：
装OFFRICE，正版序列号为
杀毒软件
360安全卫士，修复系统漏洞，点击修复，在安装路径中产生一个hotfix文件夹，然后把工具中的hotfix文件夹里面所有文件拷贝到安装路径下的hotfix文件夹；
装常用的工具：Wara,暴风影音，Adobe,QQ,MSN,以及用户要求的免费软件
旧电脑：
IP设置，每次都要记录IP，在用完之后把IP设置为原来的IP 旧机器在装系统之前，我的文档及桌面上的文件要备份，用U盘拷贝出来再装系统（要特别注意财物室的机器重装系统，在装系统之前还需要把C盘里面的某些文件给拷贝出来） 注意事项：
1. 不装克隆XP
2. 不安装盗版软件
4.2 常见问题类型
4.2.1 打印机
运维中遇到的问题如何解决的书(二)
运维注意事项
运维过程中遇到过各式各样的问题，数据丢失，网站挂马，误删数据库文件，黑客攻击等各类问题，主要有以下几点：
1.线上操作规范【运维中遇到的问题如何解决的书】
测试使用
Enter前再三确认
忌多人同时操作
先看再备份后改
2.涉及数据
慎用rm -rf
备份大于一切
稳定大于一切
保密大于一切
3.涉及安全
ssh
防火墙
精细权限控制粒度
入侵检测和日志监控
4.日常监控
系统运行状况
服务运行状况
日志监控（安全）
5.性能调优
深入了解运行机制
调优框架以及先后
每次只调一个参数
基准测试
6.运维心态
控制心态
对数据负责
追根究底
测试和生产环境
一，线上操作规范
1.测试使用
当初学习linux的使用，从基础到服务到集群，都是在虚拟机做的，虽然老师告诉我们跟真机没有什么差别，可是对真实环境的渴望日渐上升，不过虚拟机的各种快照却让我们养成了各种手贱的习惯，以致于拿到服务器操作权限时候，就迫不及待的想去试试，记得上班第一天，老大把root密码交给我，由于只能使用putty，我就想使用xshell，于是悄悄登录服
务器尝试改为xshell+密钥登录，因为没有测试，也没有留一个ssh连接，所有重启sshd服务器之后，自己就被挡在服务器之外了，幸好当时我备份了sshd_config文件，后来让机房人员cp过去就可以了，幸亏这是一家小公司，不然直接就被干了。。。庆幸当年运气比较好。
第二个例子是关于文件同步的，大家都知道rsync同步很快，可是他删除文件的速度大大超过了rm -rf,在rsync中有一个命令是，以某目录为准同步某文件（如果第一个目录是空的，那么结果可想而知），源目录（有数据的）就会被删除，当初我就是因为误操作，以及缺乏测试，就目录写反了，关键是没有备份。。生产环境数据被删了，没备份，大家自己想后果吧，我不想再回忆了。
测试的重要性我就不再多说了，大家自己体会吧。
2.Enter前再三确认
关于rm -rf / var 这种错误，我相信手快的人，或者网速比较慢的时候，出现的几率相当大，当你发现执行完之后，你的心至少是凉了半截。
大家可能会说，我按了这么多次都没出过错，不用怕，我只想说，呵呵，出现一次就够了。。。你就明白了，不要以为那些运维事故都是在别人身上，如果你不注意，下一个就是你。 （就是强制删除/var/spool/postfix/deferred 目录下所有文件和文件夹。）
3.切忌多人操作
我在的上一家公司，运维管理相当混乱，举一个最典型的例子吧，离职好几任的运维都有服务器root密码，呵呵。
通常我们运维接到任务，都会进行简单查看如果无法解决，就请求他人帮忙，可是当问题焦头烂额的时候，客服主管（懂点linux），网管，你上司一起调试一个服务器，当你各种百度,各种对照，完了发现，你的服务器配置文件，跟上次你修改不一样了，然后再改回来，然后再谷歌，兴冲冲发现问题，解决了，别人却告诉你，他也解决了，修改的是不同的参数。。。这个，我就真不知道哪个是问题真正的原因了，当然这还是好的，问题解决了，皆大欢喜，可是你遇到过你刚修改的文件，测试无效，再去修改发现文件又被修改的时候呢，多人同时修改很蛋疼哇。
4.先备份后操作
养成一个习惯，要修改数据时，先备份，比如.conf的配置文件，另外，修改配置文件时，建议注释原选项，然后再复制，修改。
再者说，如果第一个例子中，有数据库备份，那rsync的误操作不久没事了吧。所以说丢数据库非一朝一夕哇。。。随便备份一个就不用那么惨哇。。。
二，涉及数据
1.慎用rm -rf
网上的例子很多，各种rm -rf / 哇，各种删除主数据库哇，各种运维事故，，，你这1s的疏忽，造成的损失可是相当重大的，呵呵，如果真需要删除就看看在看看再看看再说吧
2.备份大于一切
本来上面都有各种关于备份，但是我想把它划分在数据类再次强调，备份非常之重要哇，我记得我的老师说过一句话，涉及到数据何种的谨慎都不为过。我就职的公司有做第三方支付网站和网贷平台的，第三方支付是每两个小时完全备份一次，网贷平台是每20分钟备份一次。我不多说了，大家自己斟酌吧。
3.稳定大于一切
其实不止是数据，在整个服务器环境，都是稳定大于一切，不求最快，但求最稳定，求可用性，所以未经测试，不要再服务器使用新的软件，比如nginx+php-fpm，生产环境中php各种挂啊，重启下就好了，或者换apache就好了。说多了都是泪啊。
4.保密大于一切
现在各种艳照门漫天飞，各种路由器后门，所以说，涉及到数据，不保密能行么，除非你想成为下一个陈冠希，，，哇咔咔。。。
三，涉及安全
1，ssh
更改默认端口（当然如果专业要黑你，扫描下就出来了）
禁止root登录
使用普通用户+key认证+sudo规则+ip地址+用户限制
使用hostdeny类似的防爆里破解软件（超过几次尝试直接拉黑）
筛选/etc/passwd中login的用户，
2. 防火墙
防火墙生产环境一定要开，并且要遵循最小原则，drop所有，然后放行需要的服务端口。
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.日志监控
这里的日志监控跟安全的日志监控类似，但这里一般都是硬件，os，应用程序的报错和警报信息，
监控在系统稳定运行的时候确实没啥用，但是一旦出现问题，你又没做监控，你就只能呵呵
了。。。【运维中遇到的问题如何解决的书】
五，性能调优
1.深入了解运行机制
其实按一年多的运维经验来说，谈调优根本就是纸上谈兵，但是我只是想简单总结下，如果有更深入的了解，我会更新，
在对软件进行优化之前，比如要深入了解一个软件的运行机制，比如nginx和apache，大家都说nginx快，那就必须知道nginx为什么快，利用什么原理，处理请求比apache，并且要能跟别人用浅显易懂的话说出来，必要的时候还要能看懂源代码，否则一切以参数为调优对象的文档都是瞎谈
2.调优框架以及先后
熟悉了底层运行机制，就要有调优的框架和先后顺序，比如数据库出现瓶颈，好多人直接就去更改数据库的配置文件，我的建议是，先根据瓶颈去分析，查看日志，写出来调优方向，然后再入手，并且数据库服务器调优应该是最后一步，最先的应该是硬件和操作系统，现在的数据库服务器都是在各种测试之后才会发布的，适用于所有操作系统，不应该先从他入手。
3.每次只调一个参数
每次只调一个参数，这个相比大家都了解，调的多了，你就自己就迷糊了。
4.基准测试
判断调优是否有用，和测试一个新版本软件的稳定性和性能等方面，就必须要基准测试了，测试要涉及很多因素，测试是否接近业务真实需求这要看测试人的经验了，相关资料大家可以参考《高性能mysql》第三版，相当的好。
我记得我的老师曾说过，没有放之四海皆准的参数，任何参数更改任何调优都必须符合业务场景，所以不要再谷歌什么什么调优了，对你的提升和业务环境的改善没有长久作用。
六，运维心态
1，控制心态
很多rm -rf /data都在下班的前几分钟，都在烦躁的高峰，那么你还不打算控制下你的心态么，有人说了，烦躁也要上班，可是你可以在烦躁的时候尽量避免处理关键数据环境哇。。。越是有压力，越要冷静，不然会损失更多。。。
大多人都有rm -rf /data/mysql的经历，发现删除之后，那种心情你可以想象一下，可是
运维中遇到的问题如何解决的书(三)
Linux运维的一些常见问题及解决方法
今晚有空把最近运维中遇到的一些问题及解决方法总结下，写的比较匆忙，可能有些问题和错误，请各位看官指正。
——————————————————————————————————————————
1.shell脚本死活不执行
问题：某天研发某同事找我说帮他看看他写的shell脚本，死活不执行，报错。我看了下，脚本很简单，也没有常规性的错误，报“: bad interpreter: No such file or directory”错。一 看这错，我就问他是不是在windows下编写的脚本，然后在上传到linux服务器的……果然。 原因：在DOS/Windows里，文本文件的换行符为rn，而在*nix系统里则为n，所以DOS/Windows里编辑过的文本文件到了*nix里，每一行都多了个^M。
解决：1）重新在linux下编写脚本；2）vi :% s/r//g :% s/^M//g （^M输入用Ctrl+v, Ctrl+m） ——————————————————————————————————————————
2.crontab输出
问题：/var/spool/clientmqueue目录占用空间超过100G
原因：cron中执行的程序有输出内容，输出内容会以邮件形式发给cron的用户，而sendmail没有启动所以就产生了/var/spool/clientmqueue目录下的那些文件，日积月累可能撑破磁盘。 解决：1）直接手动删除：ls |xargs rm -f ； 2）彻底解决：在cron的自动执行语句后加上 >/dev/null 2>&1
——————————————————————————————————————————
3.telnet很慢
问题：某天研发某同事说10.50访问10.52memcached服务异常，让我们检查下看网络/服务/系统是否有异常。检查发现系统正常，服务正常，10.50ping10.52也正常，但10.50telnet10.52很慢。同时发现该机器的namesever是不起作用的。
原因：because your PC
http://m.zhuodaoren.com/fanwen357856/
推荐访问:it运维所遇到的问题 运维工作中遇见的问题
