Ok, I know I don’t normally post about “non-technical” stuff, but this is one that EVERYONE should read. At least, everyone that is required to help solve problems of any sort, especially Network admins, IT Managers and Staff, and Support folks at a minimum, if not all engineers and just about everyone else. This post is about Troubleshooting. Yes, I know, a boring topic, but one that far too many of us have forgotten the basics of. We all solve problems in our daily lives, and as a result we tend to think that we are good at it. Well, the truth is, we aren’t good at troubleshooting, especially when it comes to solving complex problems (e.g. networking problems, IT issues where someone brings the machine in and says “it doesn’t work”, etc.). But by practicing and some basic fundamentals, we CAN be good at troubleshooting.
The Nerd Guru has an excellent Introduction/Refresher on Troubleshooting and it happens to be an entertaining read as well (with a site named “Nerd Guru” would you expect anything less than at least one summarization of the plot of Start Trek II to make his point?).
One of the most important things to do BEFORE you actually start any real troubleshooting is to define the problem. The most common mistake I see when people are trying to resolve some issue is that they don’t take the time to articulate exactly what the issue is in the first place. Here is an example:
User: “My computer doesn’t work.”
Admin: “What did you do to it?”
Admin: “Liar, you must’ve done something.”
User: “Really, I didn’t. I came in to the office, sat down, and tried to use it, and it isn’t working.”
Admin: “Ok, I’ll come to your cube and take a look.”
Notice anything wrong there? The first question the Admin asked should have been “what exactly do you mean by that?”. If he had, the User would have told him that he couldn’t log into email because it didn’t recognize his password. By narrowing down the problem the Admin could have resolved it remotely, without having to actually visit the User’s computer. By not asking any questions about the exact problem, the Admin not only wasted a bunch of time, but will also be pretty angry when he gets to the User’s computer and realizes that the computer is fine and the User’s password just needs to be reset. The Admin will leave thinking the User is an idiot and the User will be thinking that the Admin is a condescending jerk.
The point is that before doing anything else, you need to take the time to identify what the problem REALLY is. A good reference that makes this point pretty well and gives you some example questions to ask is Cisco’s System Troubleshooting Methodology. This is a very useful guide even if you don’t have any Cisco gear.
If you aren’t convinced about why you should spend some time taking a quick refresher on troubleshooting, I highly recommend you take a look at The Universal Troubleshooting Process. This site makes an excellent case for why you should define a troubleshooting process and practice it regularly, and it gives you lots of tips on troubleshooting and troubleshooting methodology. Brushing up on troubleshooting will save you time, money, and effort, and will make you look smarter and harder working in the eyes of your colleagues.