Developing Troubleshooting skills? How did you guys do it?
sj4088
Member Posts: 114 ■■■□□□□□□□
I was talking to a find of mine who has been a system engineer for about a decade. Sometimes he has to interview job applicant and he says one of the problems people have is they lack troubleshooting skills.
They may know the basics of how a window server should work and they may know some scripting and database stuff but usually it to solve problems seem to be a challenge for a lot of people.
He was telling me he take a course they was strictly troubleshooting when he first got started in IT that helped him a lot. It wasn't focused on servers, databases, programming, scripting or anything else. You may have touched some of that but the main point was developing troubleshooting skills not learning a specific technology.
That got me thinking. How did you guys develop your troubleshooting skills. A course, books or just through experience. For me I think my troubleshooting skills was developed from experience. Never really take a IT troubleshooting course specifically. I've take technology courses like window server 2003 but that was focused on server 2003. I don't know of any good books. If anyone does, please share them.
They may know the basics of how a window server should work and they may know some scripting and database stuff but usually it to solve problems seem to be a challenge for a lot of people.
He was telling me he take a course they was strictly troubleshooting when he first got started in IT that helped him a lot. It wasn't focused on servers, databases, programming, scripting or anything else. You may have touched some of that but the main point was developing troubleshooting skills not learning a specific technology.
That got me thinking. How did you guys develop your troubleshooting skills. A course, books or just through experience. For me I think my troubleshooting skills was developed from experience. Never really take a IT troubleshooting course specifically. I've take technology courses like window server 2003 but that was focused on server 2003. I don't know of any good books. If anyone does, please share them.
Comments
-
kohr-ah Member Posts: 1,277Experience for 90% of it in my case. The TSHOOT Book for CCNP was great and filled in some cracks but wasn't anything that I would say would beat experience but if I had never done it before I would have to say probably would of helped more.
-
Dieg0M Member Posts: 861If you understanding how the technology works, you just need to use a structured troubleshooting methodology. Read and lab a lot to know all the technologies in and out.
Experience is actually pretty bad when troubleshooting as you will often act on a hunch and be wrong, and that will make you waste crucial time. In my troubleshooting approach I usually leave myself to only 1 "hunch" based on experience, and then go with a strict and structured troubleshooting approach. The troubleshooting approach will vary per technology, for example you will troubleshoot and use different tools for a unicast network than for a multicast network than for a MPLS network etc...Follow my CCDE journey at www.routingnull0.com -
Xyro Member Posts: 623Experience is how I developed my troubleshooting skills. In my humble opinion, you can learn all of the troubleshooting procedures in the world, but nothing can replace the learning that comes with experience. You learn what + what = what. You also learn things that books that cannot teach you. I am not saying "do not read" as I am a big advocate of book-learning; however, to truly develop polished skills in this one area requires time and practice. I would also say, "understand how everything works" so that it decreases the amount of potential possibilities of what has gone wrong. This is extremely crucial to developing good troubleshooting skills.
-
shodown Member Posts: 2,271I got my start in Troubleshooting on electronics. Which pretty much came down to understanding current, voltage and resistance. When one of them were off you knew were your problem was. In IT, I feel that if you know what underlying technology you can troubleshoot. Its just a matter of knowing where the logs are, and how to debug. Of course the OSI model a lot as well.Currently Reading
CUCM SRND 9x/10, UCCX SRND 10x, QOS SRND, SIP Trunking Guide, anything contact center related -
darkerz Member Posts: 431 ■■■■□□□□□□I was given way to much responsibility and access to systems way to early on when I read way to many books and thought I knew everything.
5 years later, same difference - but I KNOW I don't know everything, but enough to figure it our very quickly.
tl;dr Broke things, Fixed them to keep employment:twisted: -
IS3 Member Posts: 71 ■■□□□□□□□□My Advice would be following the OSI model as your TS steps. Some levels of the OSI may not apply but the structure will help you where to start or even where to look. I thought this is strictly for networking but it applies throughout my life situations.:study:
-
MAC_Addy Member Posts: 1,740 ■■■■□□□□□□My Advice would be following the OSI model as your TS steps. Some levels of the OSI may not apply but the structure will help you where to start or even where to look. I thought this is strictly for networking but it applies throughout my life situations.2017 Certification Goals:
CCNP R/S -
--chris-- Member Posts: 1,518 ■■■■■□□□□□Interesting note on the OSI model for trouble shooting...I will be using that
I learn by doing, so for me developing trouble shooting skills really got kick started when I started getting my first incidents through the ticketing system. Swim or die kind of thing. -
Verities Member Posts: 1,162As others have stated, becoming familiar with the technologies you're working with is essential as well as understanding their dependencies. If you don't have a process for troubleshooting yet, I suggest using the CompTIA: A+ steps as a starting point:
CompTIA A+ Cert Guide > PC Technician Essentials > The CompTIA Six-Step Troubleshooting Process - Pg. : Safari Books Online
The OSI model is a useful reference tool for some, but I don't use it. After a while you'll most likely develop your own process.