Have you ever posed a tough problem to a super geek? Weren’t you amazed at the way these IT miracle workers were able to solve your dilemma in minutes, when you had been working on the problem for hours? How did they so easily know what to do? Do you want to be that good, too? In this series of articles, I will risk lifetime banishment from the “Super Geek Club” and reveal some of its innermost secrets. With this knowledge in hand, you’ll improve your troubleshooting abilities (and maybe even join the ranks of the super geeks).
The basics of troubleshooting
Technology troubleshooting is a combination of knowledge and logical analysis. Once you understand the prerequisites and methodologies, you will find that they apply to everything from your computer to your kitchen sink. It doesn’t matter if you’re troubleshooting computer hardware, software, network systems, or your garden hose. The same troubleshooting principles apply to them all.
How did you learn to troubleshoot computers? Chances are your education consisted of someone telling you, “Fix it!” and you banging your head against the wall until the system worked. Although this method is effective to a point, wouldn’t it be better to have a less painful method of problem resolution?
Know the system
The first prerequisite to troubleshooting a system is knowledge. You have to understand how to operate the system (inputs), what the system does (outputs), and how it does it (processes). The more detailed your understanding of the system, the easier it is to troubleshoot.
We gain systems knowledge in many ways. Usually, we start with some form of core training. It may be on the job, instructor-led, or even self-study. The purpose of this training is to give you an overview of the system (its inputs and outputs) and to start you down the road to learning the processes.
Was it supposed to do that?
In troubleshooting, understanding the inputs and outputs of a system is the first step. They provide the baseline for normal operation. Without this foundational knowledge, it’s impossible to even begin to troubleshoot a system, no matter how simple it is. How often when troubleshooting a problem have you asked yourself, “Is it supposed to do that?” Chances are, you were not familiar enough with the system you were troubleshooting. You didn’t understand the inputs and outputs of the system.
The best example of knowledge being important to troubleshooting is yours truly. I know that it’s illegal in some states for a guy to admit this, but I can’t fix my car. I can design enterprise-class networks, build complex data solutions, and tune multinode clusters, but pop the hood on my Taurus, and I’m lost. I understand how to operate it (inputs), I know what it does (outputs), but I have no clue how it does it. I’m missing one of the three essential knowledge components necessary to troubleshoot it: understanding the processes.
Why experience counts
Most of us know that experience counts when solving problems, but have you ever stopped and asked yourself why? Primarily, experience provides familiarity with the implementation of specific details of the systems on which we work. Secondarily, we gain insight through experience into the processes that make the systems run. As we gain more experience with a particular system, the depth of our underlying process knowledge also increases.
However, this form of derived knowledge is open to broad interpretation, and this can cause problems. In most cases, this type of knowledge is more opinion than fact. How often have you heard a coworker giving out misinformation? It’s not a deliberate act. They think that what they understand is correct. More often than not, however, it’s based upon either word of mouth or personal experience, not actual facts. Experience is only as good as your ability to derive useful and factual knowledge from it. It’s not about what you’ve done; it’s about what you’ve learned.
This is not to say that experience lacks value. To the contrary: It has tremendous value. However, I don’t believe that it should be the second-level training tool of an entire industry. When you learned algebra in school, you didn’t have to figure out how a quadratic equation worked on your own—you were taught. Then, through repetitive experience, the training was reinforced.
I know what you’re thinking: Super geeks really just have some kind of insider information direct from Microsoft. They call a friend; who looks up the source code and gives them the answer, right? Wrong!
This bonus disclosure of super-geek insider information is sure to guarantee my banishment from the club. If you want to learn more about the registry and how it works, all you have to do is pick up the NT 4.0 Resource Kit or find it online at MSDN Online.
Until next time…
Remember, troubleshooting any system requires an understanding of how it operates (inputs), what it does (outputs), and how it does it (processes). Most of us, for various reasons, don’t spend the time necessary to learn in-depth process knowledge of the systems we support. Therefore, we wind up trying to learn the processes at the last minute and end up with only partial knowledge that has questionable accuracy. Successful super geeks know that they must understand the inputs, outputs, and processes of the systems they support before a problem occurs. Super geeks also realize the importance of tempering their personal experiences with certifiable facts. In the next part of this series, we will move on to the methodology used to effectively analyze and diagnose problems.
Mike Sullivan is a senior systems engineer with Merge Computer Group, Inc., a Richmond, VA, consulting firm. His credentials include MCSE+I, MCDBA, MCT, and 19 years of IT experience. He is a full-time consultant who occasionally takes time off from his clients to teach.Are you the IT guru at your organization? Do you have any troubleshooting tips you consistently rely on? We'd like to hear about them. Post a comment or send us an e-mail.