In IT, a lack of resources isn't usually the problem when troubleshooting. Instead, the challenge is figuring out an efficient way to comb through a wealth of information--including blogs and social media--to find the one obscure bit that resolves your problem.
Mastering the many sources of information available to you as an engineer will drastically decrease your troubleshooting session times and boost your well-earned network ninja reputation.
My first line of defense when troubleshooting is reading the manual or release notes. It kills me the number of times engineers chose to forgo this simple exercise, and the results are often spectacular, but not in a good way. I still have scars from some of my reckless attempts to just wing it--a painful education, indeed.
Oftentimes, however, IT professionals are handed a giant stack of network gear and a deadline decreed by the Mayor of Crazy Town. Reading all 1,100-plus pages of the latest deployment guide just isnât going to happen. This is where I find that blogs, social media and vendor technical assistance work a special kind of magic.
Technical blogs are manna from heaven for so many of the setup and troubleshooting tasks we come across in the daily grind. Very likely, no matter whatever issue you are facing, some other engineer has faced it, too, and has blogged about. This is one of the primary reasons I blog, and if you are an engineer, you should, too. Knowing which blogs to reference is a balance of strong search engine skills and excellent contacts in my field. Many times these blogs include a blog roll, which lead to more great resources.
[Read about two key steps that can help make the difference between a short, unhappy stint and a long, successful career in networking in "Advice To New Network Engineers."]
Social media plays a huge roll in my troubleshooting process. Being extremely active with other network engineers on Twitter means I have a constant stream of relevant content and resources at my fingertips. I get answers to head-scratching questions in minutes, not hours or days. I often make note of bugs and incidents that other engineers discuss or complain about, which can serve as a fabulous source of forewarning on upcoming projects.
A word of caution if you use social media as a troubleshooting resource: These platforms are not designed for lazy types. While convention doesnât mind if you throw out a couple of easy-to-find-on-Google questions every so often, donât be that guy who clearly hasnât taken the time to do any personal research before crowdsourcing a question. Nobody likes that guy.
One resource underutilized by a number of engineers is vendor technical assistance, commonly referred to as TAC. Iâm not sure if it is pride that keeps engineers away or bad past experiences with certain vendors, but TAC is one resource that has been bought and paid for, so you might as well use it. Many times, a quick call with TAC can get you that bit of configuration info your feature requires but that the documentation glosses over or leaves out. Other times, vendor technicians can quickly spot the typos that you canât see because youâve been staring at the same lines of configuration for days.
Yes, you take a chance that you might draw the short straw and get a crummy engineer, but in my experience you are just as likely to get a solution to your problem from someone who knows the tricks the documentation doesnât reveal. Some advice, though: Never be afraid to use terms like escalate, re-queue and your-manager-please when not getting ideal results with a TAC.
Even as you master the many sources of information available for troubleshooting, never forget to build your foundational knowledge. Knowing what tool to utilize and when depends very much on your discernment and skill as an engineer, which comes from understanding the concepts at work. Thereâs still no shortcut for that, and I highly doubt one is coming anytime soon.
[Find out how to take a structured approach to resolving network problems in "11 Things You Can Do When You Get Back to the Office to Improve Network Performance" at Interop New York Sept. 30-Oct. 4.]