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

摘要：
不管是供应商还是用户，最棘手的事情莫过于系统故障的发生，这时，所有的压力都在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系统的建设、维护、升级、再建设是一个持续不断的过程，期间，不同的故障也会伴随出现。通过以上的分析，我们知道，故障发生并不可怕，只要我们从心理、工作态度、工作技巧、知识积累等多个方面进行了充分的准备，那么，任何的系统问题都会迎刃而解的。
系统故障的出现、分析、解决的过程，也就是系统不断完善、不断优化的过程，同时，也是工程师解决经验积累的过程。经过一段时间的磨练，面对任何问题，你都会镇定自若、从容不迫。