Common operational misconceptions

Fri Feb 17 14:51:23 UTC 2012

Actually I taught in a three year tech program for a while and although
trouble shooting was not in the curriculum, and as far as I know it
isn't anywhere, several of us adjunct faculty did teach it and got
reprimanded for it as part of our classes.  So much for the education
industry understanding the needs of business.  I taught basic PC
hardware and NT networking at the time.  We would actually have the
students assemble a PC and then in a subsequent class bring up a
network.  I got pretty good at nailing then with bugs while they were on
breaks. Heck, they had to go out to smoke. They would come back with a
network or PC that was no longer working.  I would then have them
explain what they saw, what they thought was wrong, justify it BEFORE
they could take any corrective action.  I also used some classroom
scenarios - they could ask me anything that they could physically learn
if they could tell me how they would check that.  I let them run bad
rabbit trails if it looked like it would cement the right way.  It
taught some step by step processes. 

BTW, the best trouble shooting course I have ever taken was the Kepner
Trego Problem Analysis/Decision Analysis class.  Caterpillar used it but
I have not seen it run anywhere in years.  It is hard-nosed and may not
be glitzy enough for today.  If you have a junior tech who isn't getting
there, I suggest - get their book and see if it helps.  NO, I do not
sell them or have stock in the company and NO, it will not do any good
unless he reads it.  I still use methodologies I learned in the class.

Ralph Brandt
Communications Engineer
HP Enterprise Services
Telephone +1 717.506.0802
FAX +1 717.506.4358
Email Ralph.Brandt at pateam.com
5095 Ritter Rd
Mechanicsburg PA 17055

-----Original Message-----
From: Leo Bicknell [mailto:bicknell at ufp.org] 
Sent: Friday, February 17, 2012 9:29 AM
To: nanog at nanog.org
Subject: Re: Common operational misconceptions

In a message written on Thu, Feb 16, 2012 at 08:50:11PM -1000, Paul
Graydon wrote:
> At the same time, it's shocking how many network people I come across 
> with no real grasp of even what OSI means by each layer, even if it's 
> only in theory.  Just having a grasp of that makes all the world of 
> difference when it comes to troubleshooting.  Start at layer 1 and
work 
> upwards (unless you're able to make appropriate intuitive leaps.) Is
it 
> physically connected? Are the link lights flashing? Can traffic route
to 
> it, etc. etc.

I wouldn't call it a "misconception", but I want to echo Paul's
comment.  I would venture over 90% of the engineers I work with
have no idea how to troubleshoot properly.  Thinking back to my own
education, I don't recall anyone in highschool or college attempting
to teach troubleshooting skills.  Most classes teach you how to
build things, not deal with them when they are broken.

The basic skills are probably obvious to someone who might design
course material if they sat down and thought about how to teach
troubleshooting.  However, there is one area that may not be obvious.
There's also a group management problem.  Many times troubleshooting
is done with multiple folks on the phone (say, customer, ISP and
vendor).  Not only do you have to know how to troubleshoot, but how
to get everyone on the same page so every possible cause isn't
tested 3 times.

I think all college level courses should include a "break/fix"
exercise/module after learning how to build something, and much of that
should be done in a group enviornment.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/