逃离故障的十条运维工作经验总结

第一篇：逃离故障的十条运维工作经验总结

逃离故障的十条运维工作经验总结

故障、于 DBA、于 运维人员 都是 心中永远的痛、而避免故障的原则却是殊途同归

现列如下、与君共勉

㈠

佛说：每次创伤、都是一次成熟、这便是运维人员的真实写照从某种意义上讲、运维是一门经验的学科、是一门试错的学科

没有做过的东西、总是会给你不期而遇的痛击

请保护现场、让 变更 有回头的机会

㈡ 对破坏性的操作谨慎小心

什么是破坏性的操作哩？

比如：

对 Oracle 而言：truncate table_name、delete table_name、drop table_name

这些语句执行起来轻松简单也惬意极了、但记住！即便数据可被回滚、代价也是非常大！

对 Linux 而言：rm-r 所有当前及其子目录的所有数据都将被变更要能回滚、先在同样的环境测试过

删除

经历过这种故障的人、大多会给 rm 上个别名

alias rm='rm-i'

同理、cp 和 mv 也可以有同样的选项：

alias cp='cp-i'

alias mv='mv-i'

㈢

在操作之前、先理清你所在的是主库、备库？当前目录？哪个 schema？session？时间？

比如：

对 Oracle 来讲：

[plain] view plaincopyprint?

1.idle> set sqlprompt 'RAC-node1-primary@10g>>'

2.RAC-node1-primary@10g>>

设置好命令提示

当然、你也可以在 glogin.sql 里面设置

对于 Linux 而言、bash 环境的提醒可设置 PS1 来知道当前目录、登陆用户名和主机信息等

对 PS1 更多理解、请见：man PS

1㈣ 备份并验证备份的有效性

人非圣贤、岂能无过？是机器总有计划内或计划外崩溃的一天怎么办？备份！！

备份的学问很大、按照不同的维度可以分：冷备和热备；实时和非实时；物理和逻辑

OLTP 7*24 在线业务、DB 就需要有实时热备

这样就可以了吗？

如果开发人员的一个不带任何条件的 delete 误删所有数据所以、此时你除了实时、还需要有非实时的备份、把 DB 从逻辑错误中恢复出来

备份有了、可以高忱无忧了吗？

不行！尚须验证备份的有效性

一个总有那么几次、备份无法保证 100% 恢复

简单的验证就是找个空库、恢复出来

㈤ 对生产环境永保敬畏之心

会计人员在从业之前、都有个职业操守的训练

同理、这也应该是运维人员进入行业首先需要具备的素养比如：

于 Oracle 而言、你可以跑一个 RDA 巡检 DB 的健康状况于 Linux 而言、是否有 password aging、隔离外网等

㈥ 交接和休假最容易出故障、变更请谨慎

接手别人的工作要一而再，再而三的确认变更方案。请教人并不见得就是能力不行的表现

休假前最好各种可以做好的事情，最好能够准备一份文档，指明在什么情况下怎么做和联系哪些人

在别人放假的时候接手工作，“能拖则拖”，实在需要执行：必须不厌其烦的跟原运维者确认各个操作细节

㈦ 搭建报警、及时获取出错信息；搭建性能监控、预测趋势

运维人员赖于生存的工具就是 报警和监控

报警可以让你及时知道系统出现了什么异常、以便及时跟进、把故障扼杀于摇篮

监控可以让你了解系统的历史性能信息、以历为鉴、可以知兴替嘛、早做优化

报警和优化是衣宽带水的好兄弟、相铺相成、互相促进

㈧ 自动却换需谨慎

比如、Oracle 存储级的HA方案：Data Guard

主库提交了一笔订单、结果发生了 switchover、这笔订单没有同步到备库

那么、卖家损失了一个销售单、对客户、对公司都是损失

㈨ 仔细一点，偏执一点，检查，检查，再检查

有这么一个人：

① 他在做一个变更的时候，会先提前一两周发送邮件并电话手机通知相关人

② 在测试机上写好脚本，召集大家 review 操作步骤和脚本③ 测试完成以后拷贝到生产环境

④ 登录对应机器，“打开，关闭，打开，关闭”该脚本

⑤ 跟相关人员再次确认执行的操作，顺序，时间点，可能的影响和回滚是否都准备好了

⑥ 执行前还要退出这个机器，然后再登录进去，“打开，关闭”脚本

⑦ 最后才在后台运行脚本，同时在另外一个窗口登录着，随时ps和查看结果输出

期间姿势端正，呼吸急促而均匀，眼神凝重。操作的人不觉得累，倒是一边学习的人很累

㈩ 简单即是美

这有点禅的意境、和 GNU/Linux 的思想不谋而合我们总是面临各种诱惑：

新的系统架构，新的更智能的命令和工具，最新的硬件平台，功能更全的HA软件...等

你可以在线下安装，测试，怎么搞都行。但是如果想要在生产环境下使用起来、请三思！

能够使用系统内置命令的话，就不用考虑其他要专门下载安装的软件了

脚本本身就能完成的功能，就没有必要专门找一个功能丰富的软件来做

linux本身自带的字符界面比那些复杂的图形界面要简洁方便............

第二篇：linux服务器故障之运维经验总结

服务器故障之运维经验总结

作为一个运维人员，遇到服务器故障是在所难免的，要是再赶上修复时间紧、奇葩的技术平台、缺少信息和文档，基本上这过程都会惨痛到让我们留下深刻的记忆。当出现此类问题时，应该如何处理？本文给大家详尽的分析了一下，一起来看看。

我们团队为上一家公司承担运维、优化和扩展工作的时候，我们碰到了各种不同规模的性能很差的系统和基础设备（大型系统居多，比如CNN或者世界银行的系 统）。要是再赶上修复时间紧、奇葩的技术平台、缺少信息和文档，基本上这过程都会惨痛到让我们留下深刻的记忆。

遇到服务器故障，问题出现的原因很少可以一下就想到。我们基本上都会从以下步骤入手：

一、尽可能搞清楚问题的前因后果

不要一下子就扎到服务器前面，你需要先搞明白对这台服务器有多少已知的情况，还有故障的具体情况。不然你很可能就是在无的放矢。

必须搞清楚的问题有：

         故障的表现是什么？无响应？报错？ 故障是什么时候发现的？ 故障是否可重现？

有没有出现的规律（比如每小时出现一次）

最后一次对整个平台进行更新的内容是什么（代码、服务器等）？

故障影响的特定用户群是什么样的(已登录的, 退出的, 某个地域的…)? 基础架构（物理的、逻辑的）的文档是否能找到?

是否有监控平台可用?（比如Munin、Zabbix、Nagios、New Relic… 什么都可以）

是否有日志可以查看?.（比如Loggly、Airbrake、Graylog…）

最后两个是最方便的信息来源，不过别抱太大希望，基本上它们都不会有。只能再继续摸索了。

二、有谁在? $ w$ last 用这两个命令看看都有谁在线，有哪些用户访问过。这不是什么关键步骤，不过最好别在其他用户正干活的时候来调试系统。有道是一山不容二虎嘛。（ne cook in the kitchen is enough.）

三、之前发生了什么? $ history

查看一下之前服务器上执行过的命令。看一下总是没错的，加上前面看的谁登录过的信息，应该有点用。另外作为admin要注意，不要利用自己的权限去侵犯别人的隐私哦。到这里先提醒一下，等会你可能会需要更新 HISTTIMEFORMAT 环境变量来显示这些命令被执行的时间。对要不然光看到一堆不知道啥时候执行的命令，同样会令人抓狂的。

四、现在在运行的进程是啥? $ pstree-a$ ps aux

这都是查看现有进程的。ps aux 的结果比较杂乱，pstree-a 的结果比较简单明了，可以看到正在运行的进程及相关用户。

五、监听的网络服务

$ netstat-ntlp$ netstat-nulp$ netstat-nxlp

我一般都分开运行这三个命令，不想一下子看到列出一大堆所有的服务。netstat-nalp倒也可以。不过我绝不会用 numeric 选项（鄙人一点浅薄的看法：IP 地址看起来更方便）。找到所有正在运行的服务，检查它们是否应该运行。查看各个监听端口。在netstat显示的服务列表中的PID 和 ps aux 进程列表中的是一样的。

如果服务器上有好几个Java或者Erlang什么的进程在同时运行，能够按PID分别找到每个进程就很重要了。

通常我们建议每台服务器上运行的服务少一点，必要时可以增加服务器。如果你看到一台服务器上有三四十个监听端口开着，那还是做个记录，回头有空的时候清理一下，重新组织一下服务器。

六、CPU 和内存

$ free-m$ uptime$ top$ htop 注意以下问题:

  还有空余的内存吗? 服务器是否正在内存和硬盘之间进行swap?

还有剩余的CPU吗? 服务器是几核的? 是否有某些CPU核负载过多了?  服务器最大的负载来自什么地方?平均负载是多少?

七、硬件

$ lspci$ dmidecode$ ethtool

有很多服务器还是裸机状态，可以看一下：

  找到RAID 卡(是否带BBU备用电池?)、CPU、空余的内存插槽。根据这些情况可以大致了解硬件问题的来源和性能改进的办法。

网卡是否设置好? 是否正运行在半双工状态? 速度是10MBps? 有没有 TX/RX 报错?

八、IO 性能

$ iostat-kx 2$ vmstat 2 10$ mpstat 2 10$ dstat--top-io--top-bio 这些命令对于调试后端性能非常有用。

    检查磁盘使用量：服务器硬盘是否已满? 是否开启了swap交换模式(si/so)?

CPU被谁占用：系统进程? 用户进程? 虚拟机?

dstat 是我的最爱。用它可以看到谁在进行 IO： 是不是MySQL吃掉了所有的系统资源? 还是你的PHP进程?

九、挂载点 和 文件系统

$ mount$ cat /etc/fstab$ vgs$ pvs$ lvs$ df-h$ lsof +D / /* beware not to kill your box */

      一共挂载了多少文件系统?

有没有某个服务专用的文件系统?(比如MySQL?)

文件系统的挂载选项是什么： noatime? default? 有没有文件系统被重新挂载为只读模式了？

磁盘空间是否还有剩余?

是否有大文件被删除但没有清空?

如果磁盘空间有问题，你是否还有空间来扩展一个分区？

十、内核、中断和网络

$ sysctl-a | grep...$ cat /proc/interrupts$ cat /proc/net/ip_conntrack /* may take some time on busy servers */$ netstat$ ss-s

 你的中断请求是否是均衡地分配给CPU处理，还是会有某个CPU的核因为大量的网络中断请求或者RAID请求而过载了？ 

   SWAP交换的设置是什么？对于工作站来说swappinness 设为 60 就很好, 不过对于服务器就太糟了：你最好永远不要让服务器做SWAP交换，不然对磁盘的读写会锁死SWAP进程。

conntrack_max 是否设的足够大，能应付你服务器的流量? 在不同状态下(TIME_WAIT, …)TCP连接时间的设置是怎样的？ 如果要显示所有存在的连接，netstat 会比较慢，你可以先用 ss 看一下总体情况。

你还可以看一下 Linux TCP tuning 了解网络性能调优的一些要点。

十一、系统日志和内核消息

$ dmesg$ less /var/log/messages$ less /var/log/secure$ less /var/log/auth

   查看错误和警告消息，比如看看是不是很多关于连接数过多导致？ 看看是否有硬件错误或文件系统错误?

分析是否能将这些错误事件和前面发现的疑点进行时间上的比对。

十二、定时任务

$ ls /etc/cron* + cat$ for user in $(cat /etc/passwd | cut-f1-d:);do crontab-l-u $user;done

   是否有某个定时任务运行过于频繁? 是否有些用户提交了隐藏的定时任务?

在出现故障的时候，是否正好有某个备份任务在执行？

十三、应用系统日志

这里边可分析的东西就多了, 不过恐怕你作为运维人员是没功夫去仔细研究它的。关注那些明显的问题，比如在一个典型的LAMP（Linux+Apache+Mysql+Perl）应用环境里:

     Apache & Nginx;查找访问和错误日志, 直接找 5xx 错误, 再看看是否有 limit_zone 错误。

MySQL;在mysql.log找错误消息，看看有没有结构损坏的表，是否有innodb修复进程在运行，是否有disk/index/query 问题.PHP-FPM;如果设定了 php-slow 日志, 直接找错误信息(php, mysql, memcache, …)，如果没设定，赶紧设定。

Varnish;在varnishlog 和 varnishstat 里, 检查 hit/miss比.看看配置信息里是否遗漏了什么规则，使最终用户可以直接攻击你的后端？

HA-Proxy;后端的状况如何？健康状况检查是否成功？是前端还是后端的队列大小达到最大值了？ 

结论

经过这5分钟之后，你应该对如下情况比较清楚了：

   在服务器上运行的都是些啥？

这个故障看起来是和 IO/硬件/网络 或者 系统配置(有问题的代码、系统内核调优, …)相关。

这个故障是否有你熟悉的一些特征？比如对数据库索引使用不当，或者太多的apache后台进程。

你甚至有可能找到真正的故障源头。就算还没有找到，搞清楚了上面这些情况之后，你现在也具备了深挖下去的条件。当然还可以借助ITIL工具对CMDB资产的关联进行深入分析。继续努力吧！

第三篇：Linux运维经验总结

Linux运维经验总结

一、线上操作规范

1、测试使用

当初学习Linux的使用，从基础到服务到集群，都是在虚拟机做的，虽然老师告诉我们跟真机没有什么差别，可是对真实环境的渴望日渐上升，不过虚拟机的各种快照却让我们养成了各种手贱的习惯，以致于拿到服务器操作权限时候，就迫不及待的想去试试，记得上班第一天，老大把root密码交给我，由于只能使用putty，我就想使用xshell，于是悄悄登录服务器尝试改为xshell+密钥登录，因为没有测试，也没有留一个ssh连接，所有重启sshd服务器之后，自己就被挡在服务器之外了，幸好当时我备份sshd_config文件，后来让机房人员cp过去就可以了，幸亏这是一家小公司，不然直接就被干了……庆幸当年运气比较好。

第二个例子是关于文件同步的，大家都知道rsync同步很快，可是他删除文件的速度大大超过了rm-rf,在rsync中有一个命令是，以某目录为准同步某文件（如果第一个目录是空的，那么结果可想而知），源目录（有数据的）就会被删除，当初我就是因为误操作，以及缺乏测试，就目录写反了，关键是没有备份……生产环境数据被删了没备份，大家自己想后果吧，其重要性不言而喻。/ 8

2、Enter前再三确认

关于rm-rf / var 这种错误，我相信手快的人，或者网速比较慢的时候，出现的几率相当大，当你发现执行完之后，你的心至少是凉了半截。

大家可能会说，我按了这么多次都没出过错，不用怕，我只想说当出现一次你就明白了，不要以为那些运维事故都是在别人身上，如果你不注意，下一个就是你。

3、切忌多人操作

我在的上一家公司，运维管理相当混乱，举一个最典型的例子吧，离职好几任的运维都有服务器root密码。

通常我们运维接到任务，都会进行简单查看如果无法解决，就请求他人帮忙，可是当问题焦头烂额的时候，客服主管（懂点linux），网管，你上司一起调试一个服务器，当你各种百度,各种对照，完了发现，你的服务器配置文件，跟上次你修改不一样了，然后再改回来，然后再谷歌，兴冲冲发现问题，解决了，别人却告诉你，他也解决了，修改的是不同的参数……这个，我就真不知道哪个是问题真正的原因了，当然这还是好的，问题解决了，皆大欢喜，可是你遇到过你刚修改的文件，测试无效，再去修改发现文件又被修改的时候呢？真的很恼火，切忌多人操作。

4、先备份后操作

养成一个习惯，要修改数据时，先备份，比如.conf的配置文件。另外，修改配置文件时，建议注释原选项，然后再复制，修改 / 8

再者说，如果第一个例子中，有数据库备份，那rsync的误操作不久没事了吧，所以说丢数据库非一朝一夕，随便备份一个就不用那么惨。

二、涉及数据

1、慎用rm-rf 网上的例子很多，各种rm-rf /，各种删除主数据库，各种运维事故……一点小失误就会造成很大的损失。如果真需要删除，一定要谨慎。

2、备份大于一切

本来上面都有各种关于备份，但是我想把它划分在数据类再次强调，备份非常之重要哇，我记得我的老师说过一句话，涉及到数据何种的谨慎都不为过，我就职的公司有做第三方支付网站和网贷平台的，第三方支付是每两个小时完全备份一次，网贷平台是每20分钟备份一次，我不多说了，大家自己斟酌吧

3、稳定大于一切

其实不止是数据，在整个服务器环境，都是稳定大于一切，不求最快，但求最稳定，求可用性，所以未经测试，不要再服务器使用新的软件，比如nginx+php-fpm，生产环境中php各种挂啊，重启下就好了，或者换apache就好了。

4、保密大于一切

现在各种艳照门漫天飞，各种路由器后门，所以说，涉及到数据，不保密是不行的。/ 8

三、涉及安全

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。这些信息对于系统被入侵后排错很有帮助。有人说过，一个公司在安全投入的成本跟他被安全攻击损失的成本成正比，安全是一个很大的话题，也是一个很基础的工作，把基础做好了，就能相当的提高系统安全性，其他的就是安全高手做的了 / 8

四、日常监控

1、系统运行监控

好多人踏入运维都是从监控做起，大的公司一般都有专业24小时监控运维。系统运行监控一般包括硬件占用率常见的有，内存，硬盘，cpu，网卡，os包括登录监控，系统关键文件监控定期的监控可以预测出硬件损坏的概率，并且给调优带来很实用的功能

2、服务运行监控

服务监控一般就是各种应用，web，db，lvs等，这一般都是监控一些指标在系统出现性能瓶颈的时候就能很快发现并解决。

3、日志监控

这里的日志监控跟安全的日志监控类似，但这里一般都是硬件，os，应用程序的报错和警报信息监控在系统稳定运行的时候确实没啥用，但是一旦出现问题，你又没做监控，就会很被动了

五、性能调优

1、深入了解运行机制

其实按一年多的运维经验来说，谈调优根本就是纸上谈兵，但是我只是想简单总结下，如果有更深入的了解，我会更新。在对软件进行优化之前，比如要深入了解一个软件的运行机制，比如nginx和apache，大家都说nginx快，那就必须知道nginx为什么快，利用什么原理，处理请求比apache，并且要能跟别人用浅显易懂的话说出/ 8

来，必要的时候还要能看懂源代码，否则一切以参数为调优对象的文档都是瞎谈。

2、调优框架以及先后

熟悉了底层运行机制，就要有调优的框架和先后顺序，比如数据库出现瓶颈，好多人直接就去更改数据库的配置文件，我的建议是，先根据瓶颈去分析，查看日志，写出来调优方向，然后再入手，并且数据库服务器调优应该是最后一步，最先的应该是硬件和操作系统，现在的数据库服务器都是在各种测试之后才会发布的 适用于所有操作系统，不应该先从他入手。

3、每次只调一个参数

每次只调一个参数，这个相比大家都了解，调的多了，你就自己就迷糊了。

4、基准测试

判断调优是否有用，和测试一个新版本软件的稳定性和性能等方面，就必须要基准测试了，测试要涉及很多因素，测试是否接近业务真实需求这要看测试人的经验了，相关资料大家可以参考《高性能mysql》第三版相当的好，我的老师曾说过，没有放之四海皆准的参数，任何参数更改任何调优都必须符合业务场景，所以不要再谷歌什么什么调优了，对你的提升和业务环境的改善没有长久作用。/ 8

六、运维心态

1、控制心态

很多rm-rf /data都在下班的前几分钟，都在烦躁的高峰，那么你还不打算控制下你的心态么，有人说了，烦躁也要上班，可是你可以在烦躁的时候尽量避免处理关键数据环境越是有压力，越要冷静，不然会损失更多。

大多人都有rm-rf /data/mysql的经历，发现删除之后，那种心情你可以想象一下，可是如果没有备份，你急又有什么用，一般这种情况下，你就要冷静想下最坏打算了，对于mysql来说，删除了物理文件，一部分表还会存在内存中，所以断开业务，但是不要关闭mysql数据库，这对恢复很有帮助，并使用dd复制硬盘，然后你再进行恢复，当然了大多时候你就只能找数据恢复公司了。

试想一下，数据被删了，你各种操作，关闭数据库，然后修复，不但有可能覆盖文件，还找不到内存中的表了。

2、对数据负责

生产环境不是儿戏，数据库也不是儿戏，一定要对数据负责。不备份的后果是非常严重的。

3、追根究底

很多运维人员比较忙，遇到问题解决就不会再管了，记得去年一个客户的网站老是打不开，经过php代码报错发现是session和whos_online损坏，前任运维是通过repair修复的，我就也这样修复了，但是过了几个小时，又出现了反复三四次之后，我就去谷歌数/ 8

据库表莫名损坏原因：一是myisam的bug，二是mysqlbug，三是mysql在写入过程中被kill，最后发现是内存不够用，导致OOM kill了mysqld进程并且没有swap分区，后台监控内存是够用的，最后升级物理内存解决。

4、测试和生产环境

在重要操作之前一定要看自己所在的机器，尽量避免多开窗口。/ 8

第四篇：运维故障处理思路

事件/故障处理应该要有什么思路 导读：

在讲解事件、故障处理思路前，我先讲一个故障场景（以呼叫中心系统作为一例子）：

业务人员反映呼叫中心系统运行缓慢，部份电话在自助语言环节系统处理超时，话务转人工座席，人工座席出现爆线情况。

运维人员开始忙活了，查资源使用情况、查服务是否正常、查日志是否报错、查交易量还有没有„„时间不知不觉的在敲键盘、敲键盘、敲键盘中过去，但是原因还未定位。

经理过来了解情况：“系统恢复了吗？”、“故障影响是什么？”、“交易中断了吗？”„„

运维人员赶紧敲键盘，写sql，看交易量；敲键盘，写命令，看系统资源、情况„„

最终，定位到问题原因是其中一个功能没有控制返回数量，导致内存泄露。针对这个故障，业务希望运维能否更快的解决故障的恢复，经理希望制定优化呼叫中心故障处理流程，做了以下几件事：

1.优先故障处理过程的时间——”能通过鼠标完成的工作，不要用键盘“ 2.提前发现故障，加强监控——“技术早于业务发现问题，监控不仅是报警，还要协助故障定位”

3.完善故障应急方案——“应急方案是最新的、准确的、简单明了的” 4.长远目标：故障自愈——”能固化的操作自动化，能机器做的让机器做“ 下面将从故障常见的处理方法开始介绍，再从故障前的准备工作（完善监控、制定应急方案等方式）来解决经理提出的问题，并提出未来解决故障的想法。

1、常见的方法：

1）确定故障现象并初判问题影响

在处理故障前，运维人员首先要知道故障现象，故障现象直接决定故障应急方案的制定，这依赖于运维人员需要对应用系统的整体功能有一定的熟悉程度。确认了故障现象后，才能指导运维人员初判断故障影响。2）应急恢复

运维最基本的指标就是系统可用性，应急恢复的时效性是系统可用性的关键指标。

有了上述故障现象与影响的判断后，就可以制定故障应急操作，故障应急有很多，比如：

       服务整体性能下降或异常，可以考虑重启服务； 应用做过变更，可以考虑是否需要回切变更； 资源不足，可以考虑应急扩容；

应用性能问题，可以考虑调整应用参数、日志参数； 数据库繁忙，可以考虑通过数据库快照分析，优化SQL； 应用功能设计有误，可以考虑紧急关闭功能菜单； 还有很多„„

另外，需要补充的是，在故障应急前，在有条件的情况需要保存当前系统场景，比如在杀进程前，可以先抓个CORE文件或数据库快照文件。

3）快速定位故障原因

 是否为偶发性、是否可重现

故障现象是否可以重现，对于快速解决问题很重要，能重现说明总会有办法或工具帮助我们定位到问题原因，而且能重现的故障往往可能是服务异常、变更等工作导致的问题。

但，如果故障是偶发性的，是有极小概率出现的，则比较难排查，这依赖于系统是否有足够的故障期间的现场信息来决定是否可以定位到总是原因。

 是否进行过相关变更

大部份故障是由于变更导致，确定故障现象后，如果有应的变更，有助于从变更角度出现分析是否是变更引起，进而快速定位故障并准备好回切等应急方案。

 是否可缩小范围

一方面应用系统提倡解耦，一支交易会流经不同的应用系统及模块；另一方面，故障可能由于应用、系统软件、硬件、网络等环节的问题。在排查故障原因时应该避免全面性的排查，建议先把问题范围缩小到一定程序后再开始协调关联团队排查。

 关联方配合分析问题 与第（3）点避免同时各关联团队同时无头绪的排查的同时，对于牵头方在缩小范围后需要开放的态度去请求关联方配合定位，而对于关联方则需要有积极配合的工作态度。

 是否有足够的日志

定位故障原因，最常用的方法就是分析应用日志，对运维人员不仅需要知道业务功能对应哪个服务进程，还要知道这个服务进程对应的哪些应用日志，并具备一些简单的应用日志异常错误的判断能力。

 是否有core或dump等文件

故障期间的系统现场很重要，这个在故障应急前建议在有条件的情况下留下系统现场的文件，比如COREDUMP，或TRACE采集信息等，备份好一些可能被覆盖的日志等。

上述是一般性的故障常见的方法，在重大故障或多方处理的故障出现时，往往小范围的排查不利于快速解决，需要启动紧急处理的流程，建议可以考虑以下沟通：

      召集相关人员 描述故障现状

说明正常应用逻辑流程 陈述变更

排查进展，展示信息 领导决策

2、完善监控

1）从监控可视化上完善

完善的监控策略需要有统一的可视化操作界面，在制定完善的监控策略后，故障处理人员需要能够快速的看到相应的运行数据，比如：能够看到一段时间的趋势、故障期间的数据表现、性能分析的情况等等数据，且这些数据可以提前制定好策略直接推出分析结果给故障处理人员，这样就大大提高了故障的处理效率，以呼叫中心系统为例，需要提前配置好以下实时交易数据，以便故障定位：

-交易性能数据：平均交易耗时、系统内部模块交易耗时（IVR交易耗时、接口总线交易耗时）、关联系统交易耗时（核心交易耗时、工单系统交易耗时等）-重要交易指标数据：交易量、IVR交易量、话务量、座席通话率、核心交易笔数、工单等系统交易量

-交易异常情况数据：交易成功率、失败率、错误码最多交易-按服务器分析交易数据：按server统计各服务交易处理笔数，交易总耗时 有了以上交易数据，并通过监控按一定频率统计，运维人员在出现故障时，通过鼠标即点击即可看到故障什么时候开始，是系统内部有问题还是关联系统有问题，最突出的交易是哪一支，各服务器交易量是否均衡等情况。

2）从监控面上完善

监控最基本的工作就是实现对负载均衡设备、网络设备、服务器、存储设备、安全设备、数据库、中间件及应用软件等IT资源的全面监控管理。在应用软件类的监控工作中，不仅需要有服务进程、端口等监控，还需要有业务、交易层的监控。

全面性的应用监控可以让故障提前预警，并保存了影响应用运行环境的数据，以缩短故障处理时间。

3）从监控告警上完善

完善的监控策略需要有清晰的监控告警提示，值班人员要以根据监控告警即可作出简单的问题定位与应急处理方案。比如类似以下的监控短信：

22时，【理财应用系统】中【应用服务器LC_APPsvrA 10.2.111.111】的【前置应用模块】出现【应用端口：9080】不存在，该端口作用【提供理财应用处理（负载均衡部署）】，原因可能为【SERVER1服务异常停止】，监控系统己进行以下应急处理【自动执行端口进程启动】，该事件紧急程度【高】。管理员可以通过短信内容看到哪个系统、哪个应用、哪个模块出了什么问题，可能是什么原因，对业务有什么影响，是否需要马上处理（比如凌晨出现此预警是否可以延迟到次日处理）等信息。

4)从监控分析上完善

完善的监控策略不仅需要有实时的数据告警，也要有汇总数据的分析告警,实时数据分析的告警的重要性不用多说，对于汇总分析的数据则能发现潜在风险，同时也为分析疑难杂症提供帮忙。

5)从监控主动性上完善

监控不仅仅是报警，它还可以做得更多，只要我们想办法赋予它主动解决事件的规则，它便有为管理员处理故障的能力。

3、应急方案

提前制定好故障应急方案是很有必要的，但在日常工作过程中我们的应急方案遇到一些问题： 1）应急方案缺乏持续维护，缺乏演练，信息不及时、不准确； 2）应急方案过于追求大而全，导致不利于阅读与使用； 3）应急方案形式大于实际使用效果，方案针对性不强； 4）只关注应急方案的内容，但没有关注运维人员对方案的理解； 针对上述常见问题，我认为应急方案需要做到以下几点：

1）内容精&简

很多人可能会认为故障出现的形式各种各样，所以应急方案需要涉及到方方面面。但实际的故障处理过程中，我们可以发现其实我们的应急措施往往重复使用几个常用的步骤，所以我认为应急方案要有重点，如果一个应急方案可以应对平时故障处理80%的场景，那这个应急手册应该是合格的。过于追求影响应用系统方方面面的内容，会导致这个方案可读性变差，最终变更一个应付检查的文档。以下是我觉得应用系统应急方案应该有的内容：（1）系统级：

能知道当前应用系统在整个交易中的角色，当前系统出现问题或上下游出现问题时，可以知道如何配合上下游分析问题，比如：上下游系统如何通讯，通讯是否有唯一的关键字等。

另外，系统级里还涉及一些基本应急操作，比如扩容、系统及网络参数调整等。（2）服务级：

能知道这个服务影响什么业务，服务涉及的日志、程序、配置文件在哪里，如何检查服务是否正常，如何重启服务，如何调整应用级参数等。（3）交易级：

能知道如何查到某支或某类交易出现了问题，是大面积、局部，还是偶发性问题，能用数据说明交易影响的情况，能定位到交易报错的信息。这里最常用的方法就是数据库查询或工具的使用。

知道最重要的交易如何检查是否正常，重要的定时任务的应急处理方案，比如开业、换日、对账的时间要求及应急措施。（4）辅助工具的使用：

有时候，需要借助一些工具或自动化工具辅助分析并应急，这时需要有辅助工具如何使用的方法。（5）沟通方案：

沟通方案涉及通讯录，包括上下游系统、第三方单位、业务部门等渠道。（6）其它：

上述5点内容如何都完备，相信这个应急手册己可以解决80%的故障恢复工作。

2）应急方案是一项持续的工作

有了应急方案，如何让运维人员持续去更新是难点。我认为要解决这个难点，需要先让运维人员经常使用这个手册。如果一个手册没有场景可以用，那就需要管理者为运维人员创造机会去使用这个手册，比如应急演练。

3）关注运维人员对应用关键信息的认识

前两点关注了手册，最后一点我觉得有必要关注使用这个手册的人。有些运维人员认为应用运维人员没有能力去把应用系统本身的内容了解得很透彻，所以应用运维人员在故障处理过程中的地位很尴尬，运维人员掌握操作权，但却不知道应该操作什么。

对此，我认同应用运维人员不需要掌握应用系统的业务功能，但我觉得就对应用系统本身来讲应用运维人员需要具备以下最基本的能力：（1）知道应用系统这个是干什么的，基本的业务是什么；（2）知道应用架构部署、上下游系统逻辑关系；

（3）知道应用下的服务的作用、端口、服务级的应急处理，日志等数据信息如何找到并简单定位。

（4）知道应用系统重要的时间点及任务，比如开业、停业、换日、定时任务的时间点以及如何判断这些任务是否正确（5）知道最重要的几支交易的流程；（6）知道常见数据库表结构，并能使用。

4、智能化事件处理

处理方法如下图（详细的智能化涉及监控、规则引擎、配置工具、CMDB、应用配置库等模块协同工作，具体介绍后续分析）

第五篇：IT运维手册(故障及处理)

IT运维手册

第二篇 硬件篇 一计算机章 ㈤常见问题 1主机

⑴无法正常开机 ①硬盘灯亮

多为显示器或LCD排线问题，可插入系统引导盘看有无反应，若无反应，则为硬件问题，建议售后处理；若有反应，则为软件问题，可重装系统。②硬盘灯不亮

I电源问题

需更换电源和电池，多为电源适配器或电池损坏造成的提供电压不稳。可更换同型号电源线，排查故障。

II内存问题

拔插内存条或更换插槽。可能是内存条松动或自配内存条不兼容造成，若因不兼容，可通过更改BIOS设置解决。

III灰尘问题

笔记本长期不清洗，积压过多灰尘会造成静电或短路，可拆开外壳用吹风机清理灰尘。

IV主板问题 主板问题是造成不能开机最大可能因素，主板为集成电路，任何地方损坏都会造成硬盘无法通电，从而不能开机，建议去售后处理。⑵无法正常上网 ①网络设置问题

此原因较多出现于需手动指定IP、网关、DNS服务器联网方式下，及使用代理服务器上网的，应仔细检查计算机的网络设置。

②DNS服务器的问题

I当IE无法浏览网页时，可先尝试用IP地址来访问，如果可以访问，则为DNS的问题，造成DNS的问题可能是联网时获取DNS出错或DNS服务器本身问题，可手动指定DNS服务（地址可以是当地TSP提供的DNS服务器地址，也可用其它地方可正常使用DNS服务器地址。在网络的属性里进行（控制面板-网络和拨号连接-本地属性-TCP/IP协议-属性-使用下面的DNS服务器地址）。不用的ISP有不同的DNS地址。有时候则是路由器或网卡的问题，无法与ISP的DNS服务连接，这种情况可重启路由器或重新设置路由器。

II本地DNS缓存出现问题，为提高网站访问速度，系统会自动将已经访问过并获取IP地址的网站存入本地DNS缓存里，一旦继续访问此网站，则不再通过DNS服务器而直接从本地DNS缓存取出该网站的IP地址进行访问。所以，如果本地DNS缓存出现问题，会导致网站无法访问。可以在“运行”中执行ipconfig /flushdns来重建本地DNS缓存。③IE浏览器本身的问题

IE浏览器本身出现故障或IE被恶意修改破坏都会导致无法浏览网页，可尝试用上网助手“IE修复专家”来修复或者重装IE浏览器。④网络防火墙问题

如果网络防火墙设置不当，如安全等级过高、不小心把IE放进了阻止访问列表、错误的防火墙策略等，可尝试检查策略、降低防火墙安全等级或直接关掉试试是否恢复正常。2显示器 ⑴无图像显示 ①开机无反应

I检查电脑的外部接线是否接好，把各个连线重新插一遍，看故障是否排除。

II如果故障依旧，接着打开主机箱查看机箱内有无多余金属物，或主板变形造成的短路，闻一下机箱内有无烧焦的糊味，主板上有无烧毁的芯片，CPU周围的电容有无损坏等。

III如果没有，接着清理主板上的灰尘，检查显卡等硬件是否有松动，然后检查电脑是否正常。IV如果故障依旧，则故障可能由内存、显卡、CPU、主板等设备引起。接着使用插拔法、交换法等方法分别检查内存、显卡、CPU等设备是否正常，如果有损坏的设备，更换损坏的设备。

②未检测到信号

台式机开机时键盘灯不亮、主机风扇正常运转，则多数属于链接线的问题,将电脑与主机间的链接线拔下后清理插头/孔的灰尘进行重试。⑵蓝屏

①首先了解发生蓝屏前电脑的情况及所做的操作。如果电脑在CPU或内存等超频后，出现蓝屏，则蓝屏故障与超频有关，只要将频率恢复正常即可。

②如果电脑在光驱读盘时被非正常打开导致蓝屏，则蓝屏故障是由于被误操作引起的，此故障一般将光盘重新放入光驱，再关上光驱托盘即可。

③如果电脑在带电插拔某设备时发生蓝屏，则蓝屏与带电插拔设备有关，一般重新启动电脑即可恢复。

④如果电脑在使用某一个应用程序软件时发生蓝屏，则蓝屏故障可能是由此程序软件引起的，一般将程序软件卸载，再重新安装即可排除故障；如果不行，则可能是程序软件本身有错误，不能使用。⑤如果电脑在进入系统后就出现蓝屏，引起蓝屏故障的原因可能较多，需要逐步进行排除。先用杀毒软件查杀病毒，排除病毒造成的蓝屏故障，如果故障排除，则是病毒造成的蓝屏故障。

⑥如果故障依旧，重新启动电脑，然后再用安全模式启动电脑，启动后退出系统再重新启动到正常模式，如果排除则是系统错误造成的蓝屏故障。二网络章 ㈡实际操作 2网络运维常用工具 ①驱动精灵

驱动精灵是一款集驱动管理和硬件检测于一体的、专业级的驱动管理和维护工具。驱动精灵为用户提供驱动备份、恢复、安装、删除、在线更新等实用功能。另外除了驱动备份恢复功能外，还提供了Outlook地址簿、邮件和 IE 收藏夹的备份与恢复。并且有多国语言界面供用户选择。

利用驱动精灵的驱动程序备份功能，在电脑重装前，将电脑中的最新版本驱动程序通通备份下载，待重装完成时，再试用它的驱动程序还原功能安装，便可节省驱动程序安装的时间。驱动精灵对于手头上没有驱动盘的用户十分实用，用户可以通过本软件将系统中的驱动程序提取并备份出来。②360硬件大师

360硬件大师是一款专业易用的硬件工具，准确的硬件检测可协助辨别硬件的真伪，并能准备提供中文的硬件名称，使电脑配置一目了然，防止在购买电脑的时候被奸商蒙骗。此外还具有温度监测、性能测试、一键电脑优化等功能。㈢常见网络问题及解决方案 1电脑安装网卡后启动速度降低

①TCP/IP设置中设置了“自动获取IP地址”，启动计算机时，计算机都会主动搜索当前网络中的DHCP服务器，所以计算机启动的速度会降低，这种情况可选择“指定IP地址”。

②安装太多网络通讯协议或服务，计算机启动时寻找和加载程序时间加长。可在本地连接的属性中删除不必要的协议和服务，对局域网的一般应用而言，有TCP/IP协议，MICROSOFT网络用户，MICROSOFT网络的文件和打印机三个网络组建即可。2网络中的某台计算机挪动后，线路连接出现中断，将水晶头用手按住时，网络连通情况为时断时续。计算机Ping本机地址成功，Ping外部地址不通，使用测线仪对网络线路进行测量，发现部分用于传输数据的主要芯线不通。

①拔下水晶头，检查水晶头与网卡接口，若网卡RJ-45接口中的部分弹簧片松动，导致网卡接口与RJ-45头没有连接好，用镊子将弹簧片复位，再行接入后故障即可排除。②采用网络测线仪对双绞线两端接头进行测试，必要时可让两端双绞线脱离配线架、模块或水晶头直接进行测量确诊，以防因连接问题造成误诊，确诊后即可沿网络路由对故障点进行人工查找。如果有专用网络测试仪就可直接查到断点处与测量点间的距离，从而更准确地定位故障点。对线路断开的处理，通常可将双绞线、铜芯一一对应缠绕连接后，加以焊接并进行外皮的密封处理，也可将断点的所有芯线断开，分别压制进入水晶头后用对接模块进行直接连接。如果无法查找断点或无法焊接，在保证断开芯线不多于4根的情况下也可在两端将完好芯线线序优先调整为1、2、3、6，以确保信号有效传输。在条件许可的情况下，也可用新双绞线重新进行布设。五视频会议系统 ㈠宝利通视频会议系统 3常见问题

⑴系统不响应遥控器

①遥控器中没有电池、电池电量不足或电池耗尽； ②遥控器中电池安装不正确；

③红外传感器接收不到遥控器信号或遥控器信号受到干扰； ⑵拿起遥控器，监视器屏幕保持黑屏 ①监视器电源线未插入； ②监视器为正确连接到系统。㈡科达视频会议系统 3常见问题

⑴本会场在会议中本端讲话有较大回声 ①麦克风位置摆放不适合。

检查使所有的麦克风距离扬声器都在3米以上，且没有麦克风正对着扬声器。

②远端会场扬声器输出音量过大。

与远端会场联络，请其检查并降低音量。

③当召开多级级联的会议、主会场发言时，分会场没有闭音。

当召开多级级联的会议、主会场发言时，最好要求分会场将本地麦克风闭音或主会场将各分会场远端闭音。⑵终端开启后没有声音输出。①音频输入线路异常。

用一个已确认正常工作的音频输入设备连接到终端之后再听声音。

②音频输出线路异常。

用一个已确认正常工作的音频输入设备连接到输出设备，确认输出线路和音箱等音频输出设备正常。③终端的音量是否太低或为静音状态。

通过遥控器改变声音大小或静音状态。第五篇 制度篇 三各单位

㈠信息化管理工作制度 ㈡信息化管理岗位职责