Teaching/developing troubleshooting skills
I'm working on trying to teach others in my group (usually less-experienced, but not always) how to improve their large-network troubleshooting skills (the techniques of isolating a problem, etc). It's been so long since I learned network troubleshooting techniques I can't remember how I learned them or even how I used to do it (so poorly). Does anyone have experience with developing a skills-improvement program on this topic? If you've tried such a thing, what worked/didn't work for you? Outside training? Books? Mentoring? Motivational posters? I'm particularly sensitive to the "I got my CCNA, therefore I know everything there is to know about troubleshooting" perspective, and how to encourage improving troubleshooting skills without making it insultingly basic. Thanks for your help. Pete.
Pete Kruckenberg wrote:
I'm working on trying to teach others in my group (usually less-experienced, but not always) how to improve their large-network troubleshooting skills (the techniques of isolating a problem, etc).
There are several vendors that offer these types of courses, and I am sure that if you search for courseware, you can find some good materials you could use to teach your own sessions in house. Jon -- Jon R. Kibler Chief Technical Officer A.S.E.T., Inc. Charleston, SC USA (843) 849-8214 ================================================== Filtered by: TRUSTEM.COM's Email Filtering Service http://www.trustem.com/ No Spam. No Viruses. Just Good Clean Email.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Pete Kruckenberg wrote: | I'm working on trying to teach others in my group (usually | less-experienced, but not always) how to improve their | large-network troubleshooting skills (the techniques of | isolating a problem, etc). | | It's been so long since I learned network troubleshooting | techniques I can't remember how I learned them or even how I | used to do it (so poorly). | | Does anyone have experience with developing a | skills-improvement program on this topic? If you've tried | such a thing, what worked/didn't work for you? Outside | training? Books? Mentoring? Motivational posters? | | I'm particularly sensitive to the "I got my CCNA, therefore | I know everything there is to know about troubleshooting" | perspective, and how to encourage improving troubleshooting | skills without making it insultingly basic. | If you are looking for some courses on just analytical troubleshooting and/or problem solving techniques, you might want to look at the Kepner Tregoe stuff (www.kepner-tregoe.com). It is not network specific but rather teaches techniques. Some of their courses include: Problem Solving and Decision Making Analytic Trouble Shooting Implementing Corrective and Preventive Actions - -- ========= bep -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (MingW32) iD8DBQFA23J8E1XcgMgrtyYRAun6AKCmtmTkq8Pyq5xYBud478424x67kACeP6w9 uBUJo/El3rVXRC7TBkpb2DA= =q+YH -----END PGP SIGNATURE-----
On 04/6/24 at 5:09 PM -0600, Pete Kruckenberg wrote the following :
I'm working on trying to teach others in my group (usually less-experienced, but not always) how to improve their large-network troubleshooting skills (the techniques of isolating a problem, etc)
I took a 5 day course in another era, fortunately for me at the beginning of my career, on analytic trouble shooting (Kepner Tregoe?). The 5 day course can be boiled down really to one concept that can be taught in 5 minutes... 'half-splitting'. (The other 4.95 days were spent making sure we understood the concept and learning to implement it, the length of time was overkill but the course vendor had to make money somehow :-) (In another discussion* it was pointed out to that that wasn't the correct name in the writers view... it was "binary search". Google may have proved the writer correct, but I still refer to it as half splitting as I spent a week learning to call it that :-) The point of this note is troubleshooting boils down finding the problem in the fewest steps. Half-splitting ensures the number of steps are at a minimum. The troubleshooters knowledge of the system and equipment provides the ability to devise tests at the half-splitting point. Half-splitting is a 5 minute concept. System/equipment knowledge is of course a lifetime endeavor. The reason I am writing this note is as I went through a career of troubleshooting I was surprised at the number of colleagues who had no concept of "half-splitting" and used "linear" or "random" techniques to determine test points/tests with a corresponding dramatic reduction in effectiveness. Cheers, Darrell *p.s., I just remembered where my previous discussion was; http://db.tidbits.com/tbtalk/tlkmsg.lasso?MsgID=15775 http://db.tidbits.com/tbtalk/tlkmsg.lasso?MsgID=15787 http://db.tidbits.com/tbtalk/tlkmsg.lasso?MsgID=15788 Searching with Google for "half-splitting" will produce some useful hits.
DG> Date: Fri, 25 Jun 2004 20:04:38 -0700 DG> From: Darrell Greenwood [ editted for brevity ] DG> The 5 day course can be boiled down really to one concept DG> that can be taught in 5 minutes... "binary search". Every half-decent programmer knows O(log(N)) is one's friend unless the scalar coefficient is large. A good way to demonstrate its efficiency is: * Have someone pick an integer between 1 and n, inclusive * Make guesses, going "higher" or "lower" according to the number-holder's feedback. The uninformed are surprised that one can always guess the number from 1 to 1000 in ten iterations or less. DG> The reason I am writing this note is as I went through a DG> career of troubleshooting I was surprised at the number of DG> colleagues who had no concept of "half-splitting" and used DG> "linear" or "random" techniques to determine test DG> points/tests with a corresponding dramatic reduction in DG> effectiveness. Good point. [ below text in response to nobody in particular ] It's also important that one avoid: * The faulty assumption there is but one problem * Incorrectly-formed causal relationships (NANOG-L has some examples of these) * Making too many changes in one iteration * Attempting to tackle a system with more unknowns than are absolutely necessary. A certain amount of troubleshooting can be taught, but IMHO it requires a self-driven person with intuitive reasoning. Finally: Apprenticeship. Have the novices follow along when experts work actual cases. A certain amount of troubleshooting is developing the intuition to make informed guesses -- e.g., "some idiot broke pmtud" -- and develop good leads without having to search methodically through the entire problem space. Eddy -- EverQuick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita _________________________________________________________________ DO NOT send mail to the following addresses: davidc@brics.com -*- jfconmaapaq@intc.net -*- sam@everquick.net Sending mail to spambait addresses is a great way to get blocked.
participants (5)
-
Bruce Pinsky -
Darrell Greenwood -
Edward B. Dreger -
Jon R. Kibler -
Pete Kruckenberg