Previous | Table of Contents | Next |
Youre not obligated to finish the task; neither are you free to neglect it.R. Tarfon, Pirkey Avot (Chapter 2, Mishna 21)
The answer to where do I start? could be this: Every day, try to improve things just a little bit. This is known as proactive troubleshooting in geek speak, and you got a good glimpse of what its about with documentation in Hour 2, You Cant Have Too Much Documentation, Money, or Love and homogenization in Hour 16, Beauty Is Consistency Deep: Saving Yourself Trouble. (Well look a little more at proactive troubleshooting in Hour 22, Who Watches The Watchmen?: Network Management Tools.)
The best kind of troubleshooting is the kind where you stop problems before they start. However, proactive troubleshooting is a little bit like peace, love, and understanding. (Whats so funny?) This is all great and everything, and its definitely worth shooting for (pardon the phrase); however, no matter how much you make things better, youll still have to engage in reactive troubleshooting when things dont go as planned. Just as youll continuously work on your proactive troubleshooting by documenting, observing your network, and planning, youll also continuously be reactively troubleshooting. Its inevitable.
Even though wed all rather avoid problems before they start by learning what causes problems and enacting policies and procedures to avoid them in the future, even as we do this, new problems have a way of popping up. Proactive and reactive troubleshooting are simply the yin and the yang of the troubleshooting game. Youll never get done with either; all you can do is make each one less painful.
Accordingly, in this hour, well reexamine the basics of how to get started with reactive troubleshooting of networking problems, whether those problems are application related, network protocol related, or physical network related. This will allow you to then further hone in on what the problem might be, based on the theory and composition behind the component.
No book can provide you with a cool head during a network combat situation. However, as this stuff is demystified for you, and you start to form your own set of troubleshooting reaction habits, youll start to see that whatever the spooky problem is, the source will eventually rear its ugly head if you keep plugging away. At the point at which this all becomes more common to you, your stress level during problem determination will definitely start to decrease.
Unless you have a crystal ball or some sort of network-management software, your first inkling that something is wrong with your network will have nothing to do with your network and everything to do with your telephone. Particularly if your organization has multiple sites or multiple network segments, youre not always going to personally suffer during a network outage; therefore, you wont know whats happening unless someone (or something) lets you know.
Ill cover network management software in Hour 22. However, for the moment, lets assume you havent invested in such software and are relying on your telephone to explode at the speed of light when the network gets into trouble.
First, you should ask the person at the other end of the phone whether other users have this same problem. It may take some doing to tickle this answer out of the caller; he or she is understandably upset, may have lost work, may have a deadline, and so on. Youll need to be polite but firmyou cant provide help if you dont know the scope of the problem.
If other users are experiencing the same problem, then the problem is systemicthat is, its a pretty safe bet that everybodys PC hasnt malfunctioned in exactly the same way at exactly the same time. Therefore, the answer can be found in something that all the PCs have in commontheir common network glue. Heres a list of items PCs are commonly connected to (in the order of more local to less local):
If youre lucky, the first 90 seconds of the trouble call should tell you where the problem lies, which is pretty cool. Once you know what type of problem it is, the troubleshooting takes care of itself. If you know the problem is systemic, you can sometimes practice the techniques we discussed in Hour 4, The Napoleon Method: Divide and Conquer. If you know the problem is local (PC related), you can relaxat least you dont have a lot of people down. Whats more, if youve practiced the network consistency techniques we discussed in Hour 16, your likelihood of getting this person back up quickly is quite high.
As optimistic as wed all like to be, you wont always run into clear-cut situations. Sometimes the network isnt down for everybody. When the network infrastructure is not totally misbehaving, some of your calls will come from users who have gotten various illegal operation errors. Perhaps a user will report to you that he printed, but nothing came out.
Some network problems arent directly related to the network protocol or physical network attributes. These problems are generally thought of as application problems, whether theyre client/server programs or file and printoriented programs. Well do a lot of in-depth application troubleshooting in Hour 18, Lots of Different People in Your Neighborhood: In-Depth Application Troubleshooting. Be sure to bring coffee and a hankering to tinker!
Previous | Table of Contents | Next |