IT troubleshooting 101: “The truth is out there...”
You may have realized by now that computers are not human. In spite of all the movies out there and their incredible complexity, they are not human. They are not subject to mood, personality, or what they had for breakfast that morning. They act in the manner they are programmed to act, every time.
What is this babble, you may ask? But, they often don’t work, and break! They stop functioning and make my life miserable! How can you say they act in the manner they are programmed to act, every time! That is absurd!
There’s always a solution
For example, if a service stops running, because the account used to run that service had an expired password, then even though your program has ceased to function at this level, it is still acting in the manner it was programed to. The program expected to be run with a password that is current. When that perimeter is changed, it cannot adjust to that and it stops working. This behavior will happen, every time, without exception.
Windows will never give a smile and a wink and say, “Ok, your password expired, but this one time… go ahead buddy…I’ll overlook it…”
It is essential you start with this fundamental truth. Because if you do not believe the answer is there, you will not look for it. Remember for every issue there is a solution.
Your quick guide to IT troubleshooting
I define IT troubleshooting as, “discovering the cause of the problem and implementing the solution.”
What is not IT troubleshooting is the “shot gun approach” that includes solutions such as a reinstallation of the software or the entire OS to solve an issue. While that may, at times, solve the problem it is not by definition IT troubleshooting. As soon as the environmental variable that caused the initial problem is re-introduced the problem will come back. Sound familiar? In that case the Admin has skipped the first part of IT troubleshooting “discovering the cause of the problem” and jumped right to a solution of sorts.
Learn it know it, live it. When something doesn’t work, there is always a reason why. This is true: every single time without exception.
And your mission is to find that reason. The more you do this, the better you get at it. So let’s look at the first part of the definition: discovering the cause of the problem.
Collect the data
Collect data, lots of data, then when it comes time to implementing the solution you have narrowed this down to only a few choices.
Breaking down the problem… All IT problems fall into one of two categories:
- This is a new implementation that has not worked before.
- This is a running solution that has stopped working (break fix).
Collecting data for a new implementation.
- “What have you done so far?”
Since you do not know the skill level of your end user, you cannot assume they know anything about the problem. Essential requirements may not even be in place.
- “Is this an upgrade to a previous version?”
Makes a big difference. What an end user calls a new install could be an upgrade or even a move from one server to another.
- What exactly is the issue you are experiencing?
Narrow it down, specifically. You define the issue.
Collecting data for break-fix issues.
- When did it last work correctly?
- When did you first notice the problem?
- What happened in between the time it was working and now?
Questions to be asked for any issue
- Are there any error messages? Ask for a screen shot of the error message. End users don’t always want to read this to you.
- How often does this occur?
- Under what conditions does this occur?
- Can you easily reproduce the issue?
- What is the impact to the business?
- Is there anything relevant in the system or application event logs? (you determine this, not the caller)
Record problems and solutions
A Rutter is a mariner's handbook of written sailing directions. Before the advent of nautical charts, rutters were the primary store of geographic information for maritime navigation.
What does that have to do with IT troubleshooting? Logging problems and solutions can act as your technical Rutter. If you document your IT troubleshooting well, you can refer back to them when the same issue occurs again.
Documenting what has been done is a habit of any good System’s Admin. Developing a clear and precise documentation method is vital.
Also, recording your methodology is a great way to recall and improve upon it for next time.
You have chosen a career in IT as a professional troubleshooter. Make it your goal then to be the very best you can be. Every problem that comes your way can be an opportunity to develop this skill set. A solid IT troubleshooting methodology will follow you your entire career.