如何快速解决IT系统中的疑难故障问题

原创 2005年03月04日 13:23:00
摘要:
不管是供应商还是用户,最棘手的事情莫过于系统故障的发生,这时,所有的压力都在IT人员身上,领导的关注、项目的工期、甚至能否顺利回款,都要看这些故障能否及时快速的解决。
本文根据笔者多年的工作体会,从心理、责任、沟通、求源、知识结构等多方面,将故障分析过程中需要注意的问题,进行总结归纳,与广大IT技术人员分享。

1. 前言
任何计算机系统都有出现故障的时候,可能发生在试运行的阶段,也可能发生在系统正式运行后,还可能发生在已经稳定运行很多年的系统上,又可能发生在系统一个小小的升级后。同时,系统故障带来的负面影响可大可小,大到整个系统瘫痪,所有业务不能办理,所有营业网点全部停业;小到仅仅是某一台终端的某一笔业务不能正常完成。

系统出现故障,就必须分析故障原因,并尽快的采取措施排除故障。一般来说,故障分析的难度与故障带来的负面影响不成直接的比例关系,整个系统瘫痪的原因可能在1分钟内得出:中心机房停电;某一笔业务不能正常完成的原因可能需要分析一天甚至若干周:在长达5万行的程序中有一个底层函数的一个输入参数少了一位的长度。与故障分析的难度成正比的,是系统的复杂度,这里指的复杂不是指设备的数量和软件的长度,而是指系统中设备的种类、软件的种类、涉及的厂商的数量。系统越复杂,涉及的设备、软件、厂家、人员就越多,可能带来的故障分析难度也就越大。

以Callcenter系统为例,它不仅仅包括计算机系统,还包括电话交换系统,其中设备、软件的种类繁多,技术复杂,包括:PBX设备、小型机设备、网络设备、存储设备、7号信令、CTI中间件、IVR中间件、交易中间件、WEB中间件、数据库软件以及C++/DELPHI/JAVA等编程语言,所涉及的供应商、合作伙伴、相关业务系统也比一般系统复杂。因此,类似这样的高复杂度系统,其故障的分析、排除就具有相当的难度。

系统故障的快速排除,需要企业有一套完整有效的协调机制和流程。现在,大多数有着严格质量管理体系的IT企业,都制订了自己的重大故障处理流程,故障分析就是其中的一个环节,也是最关键的环节。但是,由于故障分析本身涉及到更多的是技术细节和相关人员的综合能力,在流程之外,故障分析本身,又确实有其内在规律需要技术人员注意。

本文根据笔者多年的工作体会,将故障分析过程中需要注意的问题进行总结归纳,与广大IT技术人员分享,希望能给读者一定的帮助。

2. 必要的心理准备

2.1. 故障,总是会发生的,就算你全测试过。

软件工程师大多都是心地善良、充满自信的,在系统开发、测试的时候兢兢业业,一丝不苟,完全通过后,就放心的认为自己的系统已经固若金汤了。当系统发生故障以后,就觉得不能接受这样的现实,“怎么可能出错啊?不可能的!”,一旦确认系统出错后,又会很愧疚,“哎,怎么这么仔细还会出错啊?”,在心里产生挫折感。

其实,这两种心态都大可不必。复杂的软件系统,不管你代码质量多高,测试多完善,理论上,出错的可能总是存在的。出现故障了就尽快确认,接受这个现实,然后,不用多想什么,快速分析,排除故障,用户会理解你,甚至会感谢你。让用户感到烦的是出了错死活不承认,面对证据不能抵赖了,又束手无策的那种人。因此,最关键的是你要有这样的心里准备和能力准备,如果盲目的自信而且毫无准备,那到时候就难看了。

2.2. 故障,总是有原因的,就算你不知道。

计算机业务系统是高度逻辑的集合,任何操作都有其前因后果,故障只要发生了,那就有其发生的原因。有时候,遇到故障,我们会苦闷:“没有道理?”,“莫名其妙?”,说这些都不能说明系统错误是无缘无故发生的,而只能说明原因可能暂时还不知道,只要有错误发生,我们就必须进行故障分析。故障发生了,是不能否认的,你肩负责任,也是不可推卸的,说出这样的话,只能表明“没有道理”的,不是计算机系统,而是你自己。

2.3. 故障,总是需要你保持理智的头脑。

解决故障的过程中,充满了各式各样的斗争,不管发生了什么意外的情况,遇到了多么怒火冲天的用户,多么顽固不化、固执己见的工程师,多么傲慢的厂商技术支持,做为解决故障负责人的你,都要时刻保持理智,冷静的控制你的情绪,千万不能情绪失控。

因为,在愤怒的状态下,人的思维总是缺乏逻辑的,一旦失去了理智,你会说一些不该说的话,做一些不该做的事。而你的目标是什么,是解决问题,但吵架只会使问题更复杂,使以后的配合、沟通更不顺畅,这样无疑是加大了解决问题的难度。所以,无论如何,请不要让自己失控,而且,也没有必要发火,无论多么棘手的问题,总会解决的。

2.4. 故障,总是能排除的,只要你努力去做。

“实在是莫名其妙”,“真是搞不懂”,在想到的各种可能都排除了之后,你仍然找不到原因,往往郁闷其中,觉得山穷水尽了,自己无能为力了,想放弃了。这个时候,千万要挺住,要有信心,相信计算机的逻辑性,相信自己的分析,第101种可能或许就是问题的答案。在这个时候,不要急躁,总结一下,再回头对问题仔细分析一遍,多一次思考就多一条思路,就离解决问题前进一步,再多想想,就会“柳暗花明”了。

3. 敢于负责的态度

3.1. 故障,总是掩盖不了的,如果你不作分析,仅仅想掩盖。

故障发生的时候,碰巧知道的人不多,心里害怕,你不敢告诉其他人,也不上报,甚至就作了点简单处理就算完了,祈祷“千万不要再发生了,这事就这么过去吧!”,这是不可能的。故障就是故障,只要具备条件,还是会出现的,想让故障不再发生,最好的办法是分析排除,靠遮遮掩掩,没门儿。

3.2. 故障,总是会再发生的,如果你不排除。

故障既然发生了,就必须尽快排除,即便暂时不知道为什么,也得牢记在心,有件事情还没有做完。千万不能存在半点儿侥幸心理,看几天过去了,没有再发生,就谢天谢地,以为事情过去了,那你就错了,指不定哪天,可能就在业务最繁忙的那天,又给你来一下,那时,就没有人给你好气了。用户可不是好惹的,在一在二不在三四,重复发生了这么多次了,你想干嘛?

3.3. 故障,总有可能由你造成,如果没有确凿证据。

系统复杂了,分工多了,各司其职。出故障的时候,总有牛人在第一时间跳出来,“这个跟我没有关系,我这里不可能出错… 在别的系统中,我们的产品就从来没有…”。可最后的事实呢,大家都查不出来,最后还是他的问题。在出现问题的时候,不能盲目的把自己排除在外,事不关己,仍然要静下心来,好好分析,不管分析的结果如何,即使确实不是你的错误,也算为解决问题消除了一种可能,对整个问题的解决也是有益的。

同样,如果当故障发生后,很快有人告诉你,这是你的错,你也要平静的反问他,证据在哪里?不管对方是否提供出确凿的证据,你都要诚恳的表示你积极配合的态度,立即仔细分析,并保持沟通。这时,还是不能闹情绪,要耐心的听别人的理由,不管对方说的正确与否,对你分析问题都是有帮助的。

3.4. 故障,总是不能排除的,如果没有你的积极参与。

在一个设备、软件种类繁多的系统中,疑难故障的排除不是一个人能够解决的,甚至不是一个公司能够解决的。如果没有你的参与而且是积极参与,解决问题的难度就会增大,时间就会延长。而且,简单的回避或消极的参与,对你没有任何好处,你的不作为,很快就为别人提供攻击你的借口,反而使你成为矛盾的核心,即使这个故障跟你真的没有一点儿关系。明智的做法仍然是积极的参与,只要有相关各方的积极参与,故障排除的时间就会大大加快。

4. 恰当的沟通技巧

4.1. 故障,总得让相关的人知道,如果你不想更多麻烦。

故障发生了,当然不需要扯着嗓子让全世界的人都知道,毕竟不是什么好事,但是,该知道的人,还是要让人知道的。这样,不会给你添麻烦,反而有好处,你告诉他们,总比别人告诉他们,他们再来质问你来的好一些吧。 你告诉他们故障的事情,比如 业务代表、项目经理、部门经理等等,告诉他们你正在努力分析,当其他相关人向他们询问时,他们会有所准备,会替你说话的,至少不会尴尬。至于什么程度该让什么人知道,这个就靠你恰当判断了,不要小题大做,同样,也不能大题小做。

4.2. 故障,总有一些可以帮你的人,如果你放下架子多问问。

故障发生后,先作一下简单分析,感觉一下是否完全在你的技术能力范围之内,如果发现不妙,就别一个人扛着了,赶紧问问别人吧。“三人行,必有我师”,“不耻下问”,这些都是至理名言。解决问题要紧,询问别人是最简洁的途径,不要犹豫,绝大多数人还是乐意回答你的问题的,如果他真的懂的话。
当然,询问也有技巧,不要乱问人,因为你的时间有限。而且,不要乱问问题,别人的时间也珍贵。

挑选联系一下相关的资源,比如:厂商技术支持、技术网站,原项目组成员、同事、同行朋友,专业论坛等等。这些人,都应该是相关方面的专家或者对系统有特殊的了解。注意,售后的问题,别去问厂商的售前技术支持。

在你询问别人之前,首先自己得想明确,要问别人什么问题,不需要跟别人描述系统的整个原始故障,因为别人可能根本就不知道这个系统是做什么的,说的太多,反而把别人弄糊涂了。如果你连问题都没有想明确,就先别着急问,省得问题没问到,反遭了奚落。

4.3. 故障,总是需要你来汇总多方的力量,牵头解决。

复杂业务功能的系统,复杂逻辑架构的系统,复杂系统接口的系统,如果系统出现了故障,其分析解决所需要的知识,很可能是你力不能及的。这时,你要联络用户方的多个相关部门,联络其他相关支撑系统的厂商,将他们组成一个虚拟项目组,进行若干次多方协作的联调测试,而你的角色应该就是这个紧急项目的虚拟项目经理。

所有联合测试,期望达到的效果,你要比任何人都清楚;所有测试的结果,都需要你来汇总、记录;所有重要的沟通,都要通过你进行,因为正确信息的传达,在解决问题的过程中是最重要的。
在这样的多方协调过程中,你面对的是总体,其他参与者面对的是局部;其他参与者工作的感觉可能是间断的,你的工作思路却必须始终是连贯的,目的就是一个――分析故障原因,找到解决办法。

5. 追根问底的作风

5.1. 故障,总有可能连现象都是错的,如果你不去亲自问问。

从系统出现错误,到你知道这件事情,中间可能已经被多人转述,包括当事人,当事人主管,用户联系人,业务代表,项目经理… … 最后到你,而你通常会向用户联系人再次进行询问、确认,然后开始分析查错。其实,不管用户联系人的技术水平如何,你都应该通过他,尽快联系到当事人,并亲自询问故障发生的时间、地点、现象等第一手的资料。

因为,一种故障现象经过转述之后必然会变味的,不同故障现象的细微差别,可能就是两个完全不同的分析思路,所以,再次明确故障现象,是你最最起码也是最最重要的第一个步骤而这些,却往往被忽视,很多人分析了半天,才发现不对,再去询问,却发现根本就不是这么回事情,已经白白的浪费了时间和精力,也拖延了故障排除的时间。

5.2. 故障,总是隐藏真实原因的,如果你少问一个为什么。

在故障明确的前提下,通过一番排除,总可以找到一些直接的原因。比如,故障现象是某笔业务不能提交,经过分析,发现原因是系统中的几个服务宕掉了,是不是直接把这几个服务再重启就可以万事大吉了呢?不一定啊! 应该再接着问:这几个服务为什么会宕呢?会不会是这几个服务都有问题呢?这几个服务是同时宕的吗?他们宕的先后次序是什么?这几个服务之间有互相调用的关系吗?等等。这样多问几个为什么,你就会发现潜在的原因,是其中的一个服务不够健壮,在某种条件下,会出现内存崩溃而引发宕机。但这就是最根本的原因吗?是不是还可以问几个为什么呢? 是什么非正常的情况使其具备内存崩溃的条件呢?再分析排查,就发现是因为系统在查询数据库时,得到的资料不完整,有的字段意外为空值?还是在查询后的合法性检查不够完善呢?还是数据库限制太少呢?… …

每个为什么都是对自己的挑战,在分析排错的过程中,不能有畏惧和懈怠的心理,真正的原因只有一个,只有具备追根问底的精神和勇气,才能探究到事实的真相。否则,不但故障不能有效解决,还可能引发新的故障。

5.3. 故障,总是需要你坚持独立思考的精神,保持清醒的头脑。

遇到难题的时候,寻找各方面专家的帮助是明智的和必需的。这里的专家可能是厂商的资深售后支持,可能是专业技术论坛的资深人士,可能是你熟悉的朋友,可能是你的同事,可能是你的技术总监,也可能是你们公司的一个技术大牛人。总之,这些不同类型的人,总可能会根据他们自己的经验做出一些判断,给你提出建议,甚至直接告诉你,“不要找了,原因就是这样的… …”。
这些建议中,可能有相同的、类似的、不同的,甚至是矛盾的。你该怎么办?到底哪个说的对?该听谁的?

有的人唯厂商是从,“人家厂家的××说了,事情是这样……”;有的人唯上级是从,“××经理说了,原因是这样的……”。
在技术上,没有高低贵贱之分,应该唯真理是从。

分析解决问题的人是你,坚持独立思考,不是说你一个人死扛着,谁也不问,而是说,不能盲从别人;不但要知其然,更要知其所以然,在你咨询专家的时候,你要多问为什么,让他告诉你理由。到这个时候,就别死要面子了,再想当然的、浅显的道理,只要你不理解的,尽管问,就算是你不熟悉的领域,真正的专家是能够用简单的技术语言解释给你的;如果实在是不能理解,你就原样记录下专家的专业术语解释,然后自己再去查资料或者询问别的专家。不管怎样,对于专家给出的建议,你要理解其中的内在道理,否则,不知其所以然的后果往往会误导你的思路。
专家给出的永远都只是建议,只有你,才能给出结论。要博采众长,不要刚愎自用;要相信自己,不要盲目崇拜。

6. 全面的知识结构

6.1. 故障,总有没人靠的时候,如果你总想靠别人。

多问问别人是有好处的,但你自己要有点儿本事。别人给你更多的是提示和思路,虽然偶尔能直接给你结果,但,毕竟是偶尔,绝大部分问题需要你去分解,去综合,去联想,去查证,如果说别人的帮助是一个个点,而你就是去挑选、去连点成线的人,选择不同的点,会连成不同的线,而真正的路线,只有一条。

这种能力,是一种更高层次的能力,对你的要求也就更高。分析问题远不是打打电话这么简单,你得不断的学习,增强知识的广度和深度。只有你才真正了解系统,了解业务,也只有你,才能最终分析出问题的答案。

6.2. 故障,总是发生在那个你认为“透明”的部分。

现在的系统架构多采用分层架构,带来的层次清晰和性能提升无庸讳言。由于上层平台屏蔽下层平台,下层平台对上层开发人员“透明”,上层开发人员可以只了解本层技术,对底层技术不需要了解。对于一般开发人员来说,分层架构能够降低开发人员的要求,他可以认为底层是透明的。但是,真实的数据依然要从高层流经低层,从低层流上高层,任何层次发生故障,数据流就会发生阻断,系统就必然出现故障,而且,故障往往就发生在你认为想当然的、“透明”的地方。

因此,从故障分析的角度,总负责人的知识必须是全面的,对他而言,没有什么是“透明”的,对每个层次的内部结构,都要有简洁而清晰的了解,不需要任何的细节都非常熟悉,但需要一个清晰的轮廓,数据都经过了哪些部件,都经过了哪些逻辑,作了哪些处理?如果在其中的任何一个环节出问题,会出现怎样的故障现象?只有这样,你才能根据现象来定位故障点,尽快发现故障的原因。

6.3. 故障,总是能力决定时间,决定成本,决定客户关系。

故障发生了,谁都想快速的解决,单着急是不管用的,分析问题的能力来自于日常的点滴积累,你知道的越多,你的思路越开阔,你的经验越丰富,分析问题就越快。
出了问题的时候,再临时抱佛脚就来不急了,平时的多学习、多总结,增加知识的广度和深度,关键时刻,你的能力自然会体现出来。

7. 总结

IT系统的建设、维护、升级、再建设是一个持续不断的过程,期间,不同的故障也会伴随出现。通过以上的分析,我们知道,故障发生并不可怕,只要我们从心理、工作态度、工作技巧、知识积累等多个方面进行了充分的准备,那么,任何的系统问题都会迎刃而解的。
系统故障的出现、分析、解决的过程,也就是系统不断完善、不断优化的过程,同时,也是工程师解决经验积累的过程。经过一段时间的磨练,面对任何问题,你都会镇定自若、从容不迫。

相关文章推荐

重大疑难故障分析日志(已经解决)

故障现象:三个不同的应用,每个应用都是N台服务器的集群。从两周前出现一个非常奇怪的现象,每天从11:20开始,到下面的几个点的20分,如12:20,13:20,14:20,15点20.一直到某个点结束...
  • axman
  • axman
  • 2011年09月14日 16:28
  • 1166

系统分析师考试疑难问题解答

  • 2008年07月21日 09:55
  • 8MB
  • 下载

IT系统故障引起的一个事故的思考

IT系统故障

使用U盘安装WIN7系统疑难问题总结

在使用U盘给新硬盘装系统的时候,遇到了坎,为难了我一天,通过坚持不懈,最终还是找到了解决的办法。再次总结和分享一下。 我是用微软提供的USB Download Tools 这个工具来制作U盘安装盘的。...

【Unity3d】疑难杂症解决之系统报错:Supplied NxActorDesc is not valid. createActor returns NULL

最近用Unity3d开发的游戏项目忽然频频报错: Supplied NxActorDesc is not valid. createActor returns NULL. 按照csdn的搜索结果...
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:如何快速解决IT系统中的疑难故障问题
举报原因:
原因补充:

(最多只允许输入30个字)