提高系统故障排查效率的五法宝

译文
运维 系统运维 新闻
针对出现问题的关键性任务系统进行故障排查是每位运维人员的噩梦,按部就班且有条不紊的处理方式能帮我们节约大量时间。本文分享五条简单规则,可以帮助你提高系统故障排查效率。

【2013年5月16日 51CTO外电头条】但凡在IT行业干过一段时间、哪怕是只工作几天的朋友,应该都会对这样的状况有所了解:关键性任务生产系统突然之间无法正常工作,而我们却完全不知道这一切发生的原因,以及如何着手加以修复。

这些可怕的事情往往猛然出现,粗暴地打断我们的项目会议、应用程序展示以及系统升级等安排——这也正是IT部门存在的意义,并不是每个人都有办法解决突如其来的难题。

对看似无章可循的问题进行故障排查可以说是世界上最紧张且难度、强度最大的工作之一。关键性任务系统的计划外停机事件即使在规模最小的机构当中也是一项不容忽视的大事,需要对同事与管理层进行严格排查;而随着企业规模的不断扩张,停机所导致的后果也将越来越严重,状况自然就变得更糟。

这种无形的压力往往令技术人员身心俱疲,甚至让最出色的工程师不堪忍受而犯下愚蠢的低级失误,这将进一步导致问题复杂化、最终延长停机时间。

要在重重压力下保持冷静绝非易事,即使是无数次面对困境的老手也很难做到这一点。不过这里我们将与大家分享五条简单规则,各位可以尝试将其添加到自己的紧急故障排查流程当中,借以更快整理决议、查明停机原因,最终避免事情变得更糟。

1、避免二次损害

当某个看似难以捉摸的难题出现时,我们的本能反应肯定是快速投身问题分析工作以求速战速决、尽快让系统恢复正常。虽然这样的方式经常能够解决问题而且起效神速,但同时也很可能把情况推向令人难以置信的恶化深渊。故障排查手段包括重新启动不稳定系统、尝试自动记录数据库、文件系统修复等等,这些方式往往确实能搞定难题并让系统重回生产轨道,但同时也没准导致数据恢复努力付之东流,毁掉确定故障根本原因的机会甚至大大延长关键性系统的停机时间。

与本能反应不同,我们建议大家首先采取看似最不自然的处理方式:后退一步,考虑我们要怎样撤销所有针对系统修复所做出的操作与努力。要让自己的修复工作能被顺利撤销,大家可能需要进行配置备份、保存虚拟机或SAN快照、留存也许会丢失或被覆盖的日志文件副本、将可能受到影响的数据复制到正常系统当中等。之所以这种方案与我们的直观感受相悖,是因为面对停机所导致的业务瘫痪压力,似乎没人愿意把时间浪费在这些好像无关紧要的事情上--毕竟它们不能对解决难题起到任何直接作用。然而我们之所以要坚持这种处理思路,是因为它实现了两个非常重要的目标。

第一,如果我们的故障排查工作最终令情况进一步恶化--例如我们决定重启服务器但设备干脆无法运转--良好的撤销准备工作能帮大家在新系统中保留现有数据。

第二,如果大家的紧急处理方案不知何故竟成功解决了难题,上述工作也保留了一切可用于重现故障的数据,这样我们就能在闲暇时慢慢研究问题出现的原因。如果说有什么比面对难题时束手无策更糟糕,那一定是解决了难题但却不知道自己如何或者为什么能取得成功。在这种情况下,我们不仅没法给焦急等待结果的同事与企业领导一个明确的交代,而且也不能保证这类情况不会再次发生。

2、认真记笔记

大家必须做的第二件事是:详细记录自己的观察结果以及尝试过的故障排查操作步骤,如何可以的话最好把时间点也标注在内。与第一条规则类似,记笔记这类建议往往让人感觉是在浪费本身就极度匮乏的处理时间,但从长远角度来看,这样的好习惯能为我们未来的运维工作节约大量时间与精力。

首先,记笔记能防止我们一遍遍尝试已经被证明无效的挽救措施,也就是俗称的“兜圈子”--当面对巨大压力时,这类情况往往时有发生。其次,如果大家需要与供应商方面接洽,笔记也能帮我们建立一套全面的列表,提醒自己哪些厂商已经沟通完成,这样可以避免在慌乱之中理清情况。第三,如果大家打算查阅错误日志,那么可以在笔记中列出自己执行修复操作的时间,并将其与日志中的时间戳相比照。如果不这么做,大家将无法分清日志中哪些条目是系统运行记录、而哪些是自己曾经做过的修复操作,并因而不得不重复故障排查流程--这样无疑会延长问题处理耗时。

3、仔细研究

当被压力逼到绝望的边缘时,大家很可能发现自己开始不顾一切寻找救命稻草--换言之,希望在谷歌上找到答案。而且除非我们碰上了百年一遇的罕见错误,否则网上总会有一堆帖子声称他们也经历过类似的问题,并且最终得到了顺利解决。

需要强调的是,这时候大家务必要对此类看似对症的网上信息进行仔细研究。在很多情况下,我们会发现虽然故障表现完全相同,但实际情况却大相径庭。我曾亲眼目睹很多运维人员浪费大量时间来尝试一种与当前问题毫不相关的解决方案--事实上只要静下心来认真阅读问题描述,大家应该能很容易地回避这类费力不讨好的低级失误。

4、积极进行信息分享

如果大家身为问题处理团队的一员,或者需要面对一大群因工作中断而愤愤不平的用户,肯定会发现沟通在这种情况下拥有极其重要的意义。一方面能帮助用户了解我们正在做什么(当然,前提是确实要做点什么),另一方面则有助于避免团队成员之间各自为战所导致的混乱局面。

在大型团队当中,最理想的开局策略是指派一位沟通伙伴,我们要及时向他汇报自己的工作进展;这位伙伴则负责把得到的消息通知给受影响的用户群体或其他团队成员处,帮助大家了解当前的处理进度。

5、做好准备

虽然我们没办法为那些无法预见的难题做什么准备,但仍然可以从现在开始组织一点应对步骤,帮助自己在面对可能出现的情况时节约时间。

举例来说,如果大家正在进行网络问题的故障排查工作,那么把一台配置了协议分析工具(例如Wireshark)的笔记本接入核心交换机绝对能帮上大忙。在网络问题出现时,我们一般只需要15到20分钟就能让这套分析工具投入运作;但如果事前没有准备,混乱之间我们可能很长时间都搞不定配置工作,并最终导致停机时间大大延长。集中化网络监控与日志记录工具也很重要,它们能简化应用程序与网络事件之间的关联分析,并快速将看似复杂的难题定位至核心原因。

总结陈词

故障排查是一项压力极大的工作,进行过程中毫无乐趣可言,但完成之后则能帮助IT团队积累宝贵的处理经验。相对于那些在房间或数据中心内进行的安全工作来说,故障排查会带来极大的恐慌感并引发肾上腺素飙升。此外,压力的存在还可能诱发我们犯下愚蠢的低级失误--要克服这种白痴般的本能,我们需要克制自己快要爆发的满腔怒火、强迫自己以有条不紊的方式逐一开展尝试。

现在相信大家已经了解如何在肾上腺素的作用下继续保持冷静心态,接下来要做的就是将其付诸实践。

原文链接:

http://www.infoworld.com/d/data-explosion/uh-oh-the-system-went-down-5-rules-better-troubleshooting-203534?1354301229

责任编辑:黄丹 来源: 51CTO.com
相关推荐

2014-05-09 14:33:35

2013-04-10 13:52:23

2020-11-12 11:00:42

运维IT架构

2018-11-26 08:40:43

2011-08-29 18:25:19

Ubuntu

2010-11-02 09:53:57

2010-04-22 18:17:29

Aix系统故障

2013-08-26 09:49:10

系统故障

2011-05-05 17:03:19

硬盘故障

2011-04-26 15:12:58

Windows安全模式

2009-12-25 10:24:14

2012-12-07 10:25:29

Windows 7系统故障

2010-08-17 15:09:45

综合布线系统故障

2011-08-17 10:07:30

windows7故障

2009-02-01 11:44:00

2017-03-08 17:00:20

Windows 7Windows系统故障

2009-04-26 15:56:32

vista驱动程序瘦身

2019-08-19 14:51:56

Linux 系统 数据

2009-08-21 14:07:14

海缆系统故障光缆修复

2009-09-22 13:54:57

VMware驱动VMware后门系统故障
点赞
收藏

51CTO技术栈公众号