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

第二篇：服务器运维工作计划

运维部下半年工作计划

为了使运维工作顺利进行，运营部下半年工作计划如下：

1、进一步推进服务器的规划部署、搭建，以及对服务器构架、网络进行优化和调整。

2、利用监控平台nagios实时监控服务器、网络设备及业务系统的运行状态、性能。根据监控和处理结果，及时记录相关信息，定期汇总运营信息。

3、优化公司网络、邮件服务器、语音系统以及解决常见的操作系统、网络和应用故障。

4、负责突发性事件的快速响应和处理，解决服务器和网络故障。

5、与开发人员配合沟通，解决运行过程中的相关问题。

6、对日常运营数据的整理分析，然后对服务器状态监测，游戏出现问题的解决。

7、配合商务及市场部做好相关工作。篇二：运维部2013年终工作总结及2014年工作计划[1] 古交分公司运维部

2013年工作总结及2014年工作计划 2013年运维部在分公司直接领导下及全体部门员工的勤奋努力下，顺利完成网络维护、网络建设、网络安全等任务，有力的保证了古交数字电视及互动业务发展，全年来的工作总结和2014年计划如下：

一、网络维护及建设 1，城农网维护建设 1）、在分公司的正确领导及相关部门的大力支持下，运维部全体人员的勤奋工作。城农网维护截止12月份，运维部共处理用户故障电话报修 次，安装普通用户 户，搬迁用户 户，开通副机用户 户，安装互动用户 户，以旧换新 户，互动副机 户，提高了网络覆盖量，更有力的提升了市场竞争力。2）,完成网络新建工程立项 项，实施 项等几个光节点网络覆盖面积，促进了业务发展和业务收入的增加。2，网络优化建设

在分公司领导亲自带领下，全年对全市所辖网络进行了数字互动电视整体转换前的规划与设计。为2014年全面开展互动业务打下一个坚实的基础。对已开通互动业务的小区，加大了维修力度，并对局部不符合条件的小区进行了小范围的局部改造，使其具备开通互动业务的技术条件。通过走访互动用户，普遍反映收视效果良好。

二、机房维护及消防安全工作

1、在分公司分管领导的指导下制定了《机房值班制度》及《机房维护及消防制度》，根据制度明确了机房值班人员，建立和完善各项维护制度和加强机房资料及文档的管理，机房设备检修清扫，做好“三防”工作，确保设备正常运行，保证信号安全传输。

2、积极配合总公司和机房对纤、跳线等工作。对机房进行不定期检查，遇到安全隐患及时排除并上报，遇到节假日和重要传输时期，都做好了安全上报等工作。

3、不定期对机房的消防工作进行安全检查，就一些存在的问题进行了及时整改，消除了存在的安全隐患。

三、加强技术培训，提高队伍素质

运维部承担分公司运维和工程建设的主要队伍，面对工程建设、网络安全等重要任务，要在短时间内保质保量完成，无论是组织工作，还是技术工作都存在较多的难题。为此运维部把开展技术培训作为一项确保工程质量、进度的重要措施来抓，采取走出去请进来的方式，不但多次派员工参加总公司的培训学习，经常利用部门开会时间组织运维人员进行集中学习培训，还和西山分部的运维人员进行面对面经验和技术的交流，提高了维护人员的技能。

四、安全工作方面

1、城农网网络安全

根据城农网网络安全特性制定，明确片区运维人员为城农网网络安全巡查维护人员。片

区运维人员对辖区内的光、电缆进行巡查并作好日志，对存在隐患的地方及时上报。

3、维护人员人生安全

注重安全生产，全年人员无重大伤亡事故发生。运维部多次开展安全学习来加强员工安全生产意识，提高自我保护的能力。

4、车辆安全

运维部严格按照《车辆安全管理办法》来管理车辆，禁止无证驾车，严禁公车私用，严禁酒后驾车，严禁开英雄车等。对分公司运维车辆进行不同程度的修理维护，杜绝带病车辆上路有效加大车辆安全程度。

五、存在问题及不足

1、目前运维部整体须加强思想认识、提高工作效率、提升服务水平。

2、特别注重安全生产,搞好网络干线巡检工作。

3、运维部目前缺乏新技术、新业务的尖端人才，针对下一步的数字双向网络、数据等新业务，加强能承担新的维护任务技术的培训及业务学习。

4、加强运维文档的管理，提高维护质量。做好每月必须及时认真上报的各类报表。

5、随着城区、农村网络的进一步扩大，运维人员不够的问题制约着运维部的快速反应机制。

6、进一步提高运维部人员的福利待遇，提高工作积极性。六、2014年工作计划

1、继续抓好网络维护质量管理和科技维护水平，提高网络运行质量。

2、继续抓好、抓实干线巡查工作。

3、积极配合做好城农网、城区管道网络建设服务等工作的准备开工建设及其他工作任务。

4、按计划搞好网络新建、小区新建的立项及建设和竣工及验收工作。

5、落实运维部的各项管理制度，明确目标管理，理顺工作流程，提高工作效率、提升服务水平。

6、完善安全生产制度，搞好安全生产工作。

古交分公司运维部

程永亮 2014年1月7日篇三：2009运维服务能力管理计划 2009运维服务能力管理工作计划

根据公司本的工作计划，运维部结合本部门的工作实际，及相关的it运维服务工作的改进需求，特制定本工作计划，内容共分为四部分，包括：

1、运维管理组织结构

2、运维服务流程

3、应急服务响应措施

4、服务管理制度规范。现具体阐述如下：

一、运维管理组织结构

本运维项目的运维管理结构位三层模式，具体如下图所示。由项目负责人与甲方进行业务范围接洽，并将沟通结果向下传递。项目经理负责项目的整体运维工作，包括各种制度的制定和实施。运维工程师则在项目经理的指导下开展维护工作。1．项目负责人

职责：负责项目商务、整体协调事宜。

职位描述： 1）、整体负责建设单位运维项目服务计划的制定，领导项目经理并安排项目工作，指导项目经理完成具体维护工作，每周听取项目经理的工作汇报，负责考核项目经理工作完成情况。2）、协助建设单位完成新增项目的调研、方案设计并指导项目经理进行具体实施。2．项目经理

职责：规划、执行、完善信息化项目的运维工作，指导网络、数据库维护工程师开展工作。

职位描述： 1）根据公司战略目标，指导下属工程师开展客户服务工作，确保运维工作能够满足客户的实际需要； 2）建立和持续完善运维管理体系，优化运维流程流程，解决运维服务中出现的特殊问题； 3）规划并提升运维工程师专业服务能力，在整体上提高客户满意度； 4）制定和持续完善绩效考核体系； 5）制定整理运维项目的应急预案系统，并指导运维工程师实施； 6）提高自身专业技能，在业务方面给予网络管理员和数据库管理员指导。3．技术主管

职责：应用、数据库管理，oracle性能调优，实现应用负载均衡。职位描述： 1）技术主管非项目常驻人员，根据项目需要进行专业方面

指导；

2）负责数据库性能分析与调优，数据库运行状态监控，及

时发现异常并快速处理。

2）熟练掌握oracle10g的rac技术，能够实现部署及调优。3）掌握was、weblogic、tomcat、websphere等中间件的工

作原理，能够实现部署调优及故障解决。4）熟练掌握red-flag、redhat等linux操作系统，部署 证oracle数据库冗灾、数据保护、故障恢复。5）负责应用负载均衡的部署和调试。6）负责指导数据库工程师管理员开展工作。4．服务台

职责：故障电话受理，文档管理。

职位描述

1)负责it业务的救助电话的受理工作； 2)故障处理的发起人，同时进行维护工程师指派，跟踪事件处理状态； 3)进行维护故障统计、用户满意度统计、工作报表输出等工作； 4)协助项目经理，进行文档整理、归类、保存等工作。5．网络管理员

职责：维护建设单位网络系统正常，解决网络相关故障。

职位描述：

1)对现有服务器、局域网络及机房、配线间的日常管理维护； 2)对信息安全建设提出相关建议，确保网络的安全； 3)保证外网光纤线路正常，保证局域网运行正常； 4)对网络系统和网络设备的运行状态进行监控； 5)熟练掌握域策略设置、dhcp、dns、ftp服务器、ntfs权限设置等； 6)编写网络部分的应用处理预案并实施。7)工作认真、细致，积极主动有条理性，具有良好的沟通能力及团队合作精神.6.应用、数据库管理员

职责：维护建设单位业务系统运行正常，解决应用和数据库故障。职位描述： 1)监测业务系统运行状况，应用、数据库性能监视及优化，作必要调整； 2)规划不同数据的生命周期，制订备份、恢复、迁移和灾备策略，根据业务的需要执行数据转换及迁移等操作；

3)保证应用和数据库系统的安全性、完整性和运行效率。4)负责数据库平台的整体架构及解决方案的制定和实施； 5)工作认真、细致，积极主动有条理性，具有良好的沟通能力及团队合作精神.7.终端管理员

职责：维护建设单位桌面系统运行正常，解决终端、外设故障。职位描述: 1)各部门电脑、打印机、传真机的维护； 2)对各部门职员进行电脑相关的技术支持及培训工作； 3)精通windows xp及office的使用，能够熟练使用excel2003、excel2007及以上版本，能够制作相应教程对其他部门员工进行培训

二、运维服务流程 it运维服务管理流程涉及服务台、事件管理、问题管理、配置管理、变更管理、发布管理、服务级别管理、财务管理、能力管理、可用性管理、服务持续性管理、知识管理及供应商管理等，随着运维活动的不断深入和持续改进，其他流程可能会逐步独立并规范。

三、应急服务响应措施

运维项目组制定了详尽的应急处理预案，整个流程严谨而有序。但在服务维护过程中，意外情况将难以完全避免。我们将对项目实施的突发风险进行详细分析，并且针对各类突发事件，设计了相应的预防与解决措施，同时提供了完整的应急处理流程。1.应急预案实施基本流程篇四：运维服务管理计划 2013服务管理计划

版权信息

本文件涉及之信息，属xxxx有限公司所有。

未经xxxx通信技术有限公司允许，文件中的任何部分都不能以任何形式向第三方散发。xxx技术有限公司 模板编号：r.qly.103b xxx有限公司 模板编号：r.mat.103b 1.总体介绍 1.1 计划总则 2013服务管理计划用于指导公司服务团队在本内按照服务级别协议（下简称“sla“）以及服务目录，实施服务管理与服务运营活动。实施服务管理计划的目的是达成公司既定的服务质量目标、规划并合理使用资源、保证业务连续性和it服务连续性、不断改进服务过程。为客户提供稳定、安全、高效运行的业务系统。为建立符合国际/国内服务标准的运维服务体系进行尝试。1.2 适用范围

用于服务管理的全生命周期过程，计划内容在实际执行过程中若有变更，则将适时修改计划内容，并由总经理批准后发布。2.总体概述 2.1 组织架构 xxxx公司运维服务体系组织架构图

具体职能参见《xxxx运维服务体系组织结构图及职责》。2.2 服务目标 xxx有限公司 模板编号：r.mat.103b 3.服务质量管理计划 3.1 服务质量管理活动

为达成服务质量目标，检查运维体系的实施情况，2013计划执行的服务质量管理活动有： 3.1.1 运维服务能力内审

审核运维服务活动及其结果是否符合策划的安排，确保运维服务体系的有效性。

运维服务能力内审由质量部负责组织实施。3.1.2 运维服务能力管理评审

管理评审目的是对公司运维服务管理体系进行系统评审，识别并确定各种改进的机会和需要，确保运维服务管理体系持续的适宜性、充分性和有效性。xxx有限公司 模板编号：r.mat.103b 运维服务能力管理评审由管理者代表负责组织实施，质量部协助。3.1.3 运维服务体系过程改进

日常工作中，通过对运维服务项目过程的监督检查，收集服务提供过程中存在的问题，确定运维服务改进的需求。

定期收集和分析运维服务指标完成情况，发现并确定运维服务改进需求。各相关指标，每季进行收集和分析。

对客户反馈意见进行收集和分析（包括满意度调查结果和客户投诉意见），了解客户意见和需求，为改进提供依据。客户满意度调查每季开展一次。

完成2012未关闭的过程改进事项，详见《运维服务能力管理改进建议与跟踪表》。3.1.4 服务过程质量监督

质量部通过对运维服务项目进行过程监督检查，及时发现问题并督促问题及时解决和改进，以确保运维服务按服务规范实施并按约交付服务。服务质量监督检查由质量专员制定《项目质量保证计划》，按计划实施并报告。3.2 运维服务质量管理计划 xxx有限公司 模板编号：r.mat.103b篇五：2015年运维部工作计划.修改 2015年工作计划

结合公司今年运营发展的思路,我部门今年将重点提升网络服务质量,提高运维人员综合业务素质。

一 运维部基本情况: 运维部主要维护十二师辖区和乌鲁木齐市区两部分,其中十二师辖区内有五大团场片区,共有用户44126(穿线用户)实际使用用户为35525 ,三网用户2237户，现有维护员13人。

市区维护26个小区,共有用户22570, 现有维护员2 人.二 2014年运维部维修故障分析 2013年全年故障发生共10657起,占总用户数的2.5% ,故障率为,主要分为:马赛克，装修改线，公用电停电，用户光纤损坏，拆迁，机顶盒坏等。1小区共用电停电造成的故障占运维故障的50%,主要原因是:不能及时补电，交纳电费受小区物业的控制.2 用户光纤损坏（人为和自然、工程）占10%,加强日常线路维护。3老机顶盒损坏5%,主要原因,大部分用户是2009年左右的用户,使用寿命已到,造成故障.4 用户装修改线15%造成线路不通，和用户光纤的损坏造成二次熔接。5 拆迁用户的维修10%.6 其他原因占10%.三 2014年机房维护情况说明

现有机房10个,计划新增机房1个,存在的问题，分机房停电不能及时供电第一时间到现场解决故障，存在很大的安全隐患。

四2015年的工作计划

1、重点解快因用电造成的故障,与小区物业部协商取得供电支持,计划在今年年初对辖区内的共用电改造工作。

2、抢修组已做到责任制到片区及时处理光纤故障，做好对用户禁止装修改线的宣传工作。

3、为了提高机房安全运行传输质量，加快建设网路机房监控设施，预计建设现有分机房11个。

4、维护人员的综合业务素质 ,加强培训,年初针对运维网络技术和公司考核管理的培训计划一周一次上半年，下半年两周一次和对新进员工的资质培训,月度考试与工资挂钩,提升运维人员的服务统一标准，5、完善安全生产制度，搞好安全生产工作。(1)每月定期对机房进行寻查、巡检工作。(2)对运维人员不定期抽检技术性工作流程。

6、加强运维人员的市场营销意识,新业务推介与提成.7、今年需建设好主干线的环路（列如：师机房至104团，104团至西山等）和网管系统，做好网络运行质量.。

8、今年运维部计划分5个大片区其中城区26个小区，用户22570户其中现有三网用户1509户，3人一辆车维护，西山、104团三网用 户6211户，3个人维护，头屯河农场三网用户7421户2人维护，三平农场三网用户11360户2人维护，五一农场三网用户7090户，2人维护，抢修组4人一辆车负责5个大片区光缆用户光纤、主干光缆的维修维护，9、今年工程部改造老校区的光纤到户的同时改造维修量较大的老有线电视小区。（列如：五一农场诒心园小区一期，楼兰酒厂，光华学校等）。

10、由于公司的网路不只是传输有线电视还传输了数据业务而且用户不断增加，光缆全部是寄挂或借用在别人的管道和木杆抢修查找断点耽误时间，不能及时修复，由其晚上对运行维修带来很大困难，今年计划建设好主干线的环路（列如：师机房至104团，104团至西山等）和网管系统，做好网络运行质量。

11、积极配合工程部做好城郊主干网、本地传输网、及弱点管道和各团场分机房建设，竣工验收工作及维护等其他工作任务。

12、落实运维部的各项管理制度，明确目标管理，理顺工作流程，为了更好地为用户服务，从而提高用户满意度建立良好的天娱传媒口碑。

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

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

故障、于 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运维经验总结

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、应用配置库等模块协同工作，具体介绍后续分析）