IT运维手册(故障及处理)5篇

第一篇：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米以上，且没有麦克风正对着扬声器。

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

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

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

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

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

②音频输出线路异常。

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

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

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

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

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

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

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

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

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

运维人员赶紧敲键盘，写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、应用配置库等模块协同工作，具体介绍后续分析）

第三篇：代维故障处理规范

代维故障处理规范

为保证代维单位及时高效地处理故障，结合公司实际制定本规范。

一、故障分类

按照目前代维公司维护的界面分工，需要代维处理的故障主要分为基站设备故障（主要为动力配套设备）、基站停电故障、光缆线路故障（按线路级别分干线、本地网、接入网）、室内分布系统。

二、故障通知程序

1、基站设备故障

基站设备故障由网管中心值班人员通过监控系统发现通知基站代维管理员，并做好故障派单记录，基站代维管理员接到通知后应立即通知代维公司专业接口人，并做好故障记录督促代维公司在规定时间内修复障碍，代维公司未能在规定时间内修复障碍的，基站代维管理员应立即通知动力代维中心主任和部门分管经理。

2、基站停电故障

基站停电由网管中心值班人员通过动力环境监控系统发现通知基站代维管理员，并做好故障派单记录，基站代维管理员接到通知后应立即通知代维公司专业接口人，并做好故障记录督促代维公司在规定时间内修复障碍，代维公司未能在规定时间内修复障碍的，基站代维管理员应立即通知动力代维中心主任和部门分管经理。

3、光缆线路故障

干线光缆线路故障（含本地网骨干网线路）网管中心值班人员通知线路代维管理人员，同时通知传输中心值班工程师和传输中心主任，线路代维管理人员接到通知后应立即通知代维公司专业接口人，并向部门分管领导汇报，代维公司未能在规定时间内修复障碍的，网管中心值班人员应立即部门经理和公司分管领导。

本地网线路故障（本地网骨干网除外）网管中心值班人员通知线路代维管理人员，同时通知传输中心值班工程师和传输中心主任，线路代维管理人员接到通知后应立即通知代维公司专业接口人，并做好故障记录督促代维公司在规定时间内修复障碍，代维公司未能在规定时间内修复障碍的，线路代维管理员应立即通知动力代维中心主任和部门分管经理。

接入网线路故障由客响中心112故障专业人员和网管中心值班人员谁先发现谁通知客响中心值班工程师或县分装维人员，客响中心值班工程师（或县分装维人员）判断为线路故障应立即通知线路代维管理人员（网管中心值班人员若能直接判断线路故障可直接通知线路代维管理人员，并告知客响中心值班工程师），线路代维管理人员接到通知后应立即通知代维公司专业接口人，并做好故障记录督促代维公司在规定时间内修复障碍，代维公司未能在规定时间内修复障碍的，线路代维管理员应立即通知动力代维中心主任和部门分管经理。

4、室内分布系统

室内分布系统故障由网管中心值班人员通过监控系统发现通知基站代维管理员和无线中心主任，并做好故障派单记录，基站代维管理员接到通知后应立即通知代维公司专业接口人，并做好故障记录督促代维公司在规定时间内修复障碍，代维公司未能在规定时间内修复障碍的，基站代维管理员应立即通知动力代维中心主任和部门分管经理，网管中心值班人员应通知部门无线分管经理。

三、故障处理记录

1、对于基站设备和停电故障，代维单位每周汇总一次提交基站代维管理人员，对涉及到的抢修材料应做好台账登记。

2、对于线路故障，应在处理故障结束后24小时内提交故障处理记录。

四、故障处理支撑

对于已经交由代维单位处理的故障如不能及时抢通修复，运行维护部相应专业需派人到场进行指导和督促。对于影响业务的故障如代维单位不能在规定的抢修时限内完成，基站或线路代维管理人员应与相关专业工程师到场协助抢修。

五、故障归口及上报

所有涉及代维故障需第一时间通知到代维管理中心基站或线路代维管理人员，各专业工程师及县分工维中心工程师不得擅自调动代维人员，紧急情况下可先通知代维抢修人员后向代维管理中心报备。所有代维公司处理的故障由动力代维中心督促代维公司提交故障处理记录后向质量管理中心进行上报。

二○一二年一月十七日

第四篇：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资产的关联进行深入分析。继续努力吧！

第五篇：运维工作指导手册(精)

运维工作指导手册

一、资源和业务规划及申请

1、项目计划书模板

2、背景和业务目标规划

3、组织和人力资源规划

4、硬件资源规划

5、业务规划

6、财务预算

二、组织和人力资源管理

1、管理职责

2、设置组织机构(成立、任命、部门手册、岗位职责

3、人力资源招聘

4、入职培训和转正

5、薪酬待遇

6、绩效考核

7、人才培养和团队建设

三、财务和行政资源管理

1、管理职责

2、硬件资源配置

3、费用和报销管理

4、财务统计和核算

四、其他工作管理

1、作息制度

2、工作计划和汇报制度

3、固定资产低值易耗品管理

4、工具管理

5、备品备件和耗材管理

6、实验室管理

7、数据监控中心管理

8、档案室管理

9、收入管理

五、设备和基站移交

1、排查

2、检测

3、比对验收

4、设备整改和更换

5、交接

六、签订合同和新建、更换设备

1、明确建设要求

2、签定合同

3、新建和更换设备

七、运营

1、确定运营目标和要求,制定工作流程和制度

2、制定巡检计划并执行

3、确定数据监控计划并执行

4、确定维修和故障处理计划并执行

5、确定数据和工作报告计划并执行

6、确定关系维护计划并执行

八、附录 流程和规章制度