[lug] Basic Troubleshooting Skills

John Dollison johndollison at hotmail.com
Mon Sep 13 22:35:47 MDT 2010

I was a Navy Electronic Technician for nine years, and you're not the first to ask this kind of question.  I'd like some time to think about an answer (and review several Navy manuals in my basement), but I'll give you some quick thoughts now.  
You've already mentioned several of the basics (in-depth system knowledge, a broad background in other systems, and the ability to think logically and sequentially).  Here are a few other ideas...
1) Just about everything is a system, whether it's electronic, mechanical, plumbing, business processes, or how water gets from your roof & gutters all the way down to the ocean.  Having a keen sense of observation (five senses) and intellectual curiosity (books, Google, asking experts) will give you at least a basic understanding of just about anything.   
2)  It helps if you're able to look for and recognize patterns.  If you know the sound of your car or refrigerator and now something's changed, follow the changes back to the source (like a vibrating bearing that's about to fail).  It even works with software... I don't know how XYZ works, but lately I've seen some new messages in the log file, and that's unusual, so I'll go to the great oracle (Google) and seek advice...
3) Every system has inputs and outputs.  If you can at least take a stab at understanding what those should normally be, and are actually now at this moment, you'll often see the problem right away.  This one seems deceptively simple, and is often overlooked.
4) The Navy is big on highly structured documentation, which usually starts out with some sort of overview, then "functional diagrams," which are like flowcharts for electronics, then detailed circuit-level schematics.  Most Navy manuals also have chapters on parts layout; disassembly and maintenance procedures; common failures; test points and logical troubleshooting steps; and indexes and cross-references.  That might not help directly, but if you start thinking about those areas as they apply to any system, you'll start to see the value.   It's also good advice to know and use all available resources (tech manuals, people, etc.), because you just can't store it all in your head (well, I can't).
5) If you can visualize the flowchart for your system, then you can do what the Navy calls "half-splitting."  Pick some definitive test point in the middle of the system, where you know you should have product X (a voltage, a sound, water pressure, whatever) and check it there.  If you don't have the right output there, then you've already eliminated the last half of your system, and the fault must be further back toward your original inputs.  Now take the half that's left, and split it in half again.  This method will often save you hours of troubleshooting step-by-step from one end to the other.  This is a BIG, IMPORTANT step; it's the synthesis of all the steps (skills) before.  And I'm amazed how many people just don't get this.  
5) If something's stuck, figuratively or literally, don't force it.  Look for something subtle that's holding it (or you) back.  I might gently play with the iris on a camera for 10 minutes before finally spying the grain of sand caught near the edge.   If I had just pushed harder, I would have destroyed it.  It took 4 hours of disassembling and reassembling my turbocharger housing before I got it right, but 4 hours of patience in the face of frustration saved me thousands of $$$.  Just keep observing and prodding and looking from other angles until the solution becomes apparent.
6) Sometimes you just have to guess!  Turn it all off, wiggle all the wires and connectors, check the fuses, and try again.  Worst case, try "shotgunning."  That's where you just start replacing whole subassemblies (like a transmission) or uninstalling & reinstalling whole software suites, because nothing else seems to work.
In conclusion...
Too many people just hunt-and-peck their way to a solution, because they can't do the steps above or can't see how all the steps work together.  My friends say I can fix almost anything, because I understand the steps above.  (And sometimes I just have to admit that I don't have the foundational knowledge or years of experience, so I call an expert... but I watch him work, so I don't have to call him again!)
John Dollison
Westminster, CO 80021
(720) 935-1970 (Cell)

> Date: Mon, 13 Sep 2010 20:11:46 -0600
> From: anselmi at anselmi.us
> To: lug at lug.boulder.co.us
> Subject: Re: [lug] Linux Troubleshooting Guide
> Jose Luis Salas wrote:
> > Hi folks,
> >
> > Does somebody knows about a good Liunx Troubleshooting Guide
> > so I can use it to be prepared for a Linux support interview?
> I'll ask a broader question: does anyone know a good way to teach troubleshooting skills? I know 
> the Navy does some of that but I never went to any of those schools.
> I seem to be able to troubleshoot fairly well, but that's usually due to in depth system knowledge, 
> a broad background in other systems, and the ability to think logically and sequentially. I have no 
> idea how to teach any of that.
> A textbook would be a good start.
> Thanks!
> Dave
> _______________________________________________
> Web Page: http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> Join us on IRC: irc.hackingsociety.org port=6667 channel=#hackingsociety
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lug.boulder.co.us/pipermail/lug/attachments/20100913/59dfbcd3/attachment.html>

More information about the LUG mailing list