Troubleshooting Methodology

August 2, 2020

There are 7 steps in the troubleshooting methodology.

• Consider corporate policies, procedures, and impacts before implementing changes
• Identify the problem
• Establish a theory of probable cause (question the obvious)
• Test the theory to determine the cause
• Establish a plan of action to resolve the problem and implement the solution
• Verify full system functionality and, if applicable, implement preventive measures
• Document findings, actions, and outcomes

Always, always remember corporate policies. They differ from one company to the next so knowing your specific company’s policy is important. Sometimes the company’s procedures dictate that you go through the rest of these steps and how to do them. Sometimes companies have ticket systems that will walk you through these steps.

When identifying the problem you will be asking questions from the user, such as, “Have there been any changes made recently to the system?” or “Has anything changed in regards to the environment, for example, has the computer been moved?”. Always try to use open-ended questions so the user has the opportunity to give you as much information as possible. This is the point in which you need to find out the symptoms so you can find that root cause. You can also review logs in the system and/or application. Remember to ask about a backup also.

You need to make an educated guess at what the root cause is. Just like in science class when you had to come up with a hypothesis. This is the same thing as that. Use the resources that you have to get to that hypothesis. Use your company’s internal database if they have one. Use Google (but make sure you using trusted information). Look at the manufactures’ websites. Use the information to make this guess. That is why it is an educated guess. Remember the acronym KISS. Keep it simple stupid. Monitor won’t turn on? Is the monitor plugged in? It’s usually the obvious that we don’t think about that is the problem. Think about making a back up of the system now.

Test this hypothesis. Remember to back up the system before you do because this could be the last chance to before the whole system is messed up. Maybe you need to use a controlled lab to test this and eventually you’ll roll it out to every machine in the company. Maybe its only one machine and you test it and it doesn’t solve the issue. Remember to take pictures of the original settings or write them down so that you can go back and reverse the changes that you made.

Now you need to test if those changes have fixed the problem. Is the problem isn’t fixed? Hopefully you took notes of the settings changed because now you need to undo those changes if it didn’t work. Maybe you crashed the whole system and need that backup. Hopefully you have it. If I haven’t said it enough. MAKE BACKUPS. If your problem isn’t fixed then you have to go back to the drawing board and create a new hypothesis.

Once you have confirmed the theory, you need to establish a plan to resolve the problem and implement the plan . Maybe you need to schedule downtime on the server. Keep in mind what the impact of the plan has on users.

Now after the fix is implemented, you need to make use the fix didn’t break anything else. You have to make sure the whole system is working. If you don’t do this then you’ll be getting a call back soon saying something isn’t working. This is also the time where you implement preventative measures. If someone tripped over a cord and the computer came unplugged maybe you would reroute the power cord where no one could trip on it.

Make sure you document everything that you found out, everything that you did, and what the outcomes were when you did it. This will save time in the future. When you have that same problem arise again in three months and you don’t remember what you did then you have something to look back on. Maybe it took 4 hours to find the cause before and because you documented everything it only takes 15 minutes next time.

This procedure is the one that the CompTIA exams use and expect you to know. Some companies have their own and expect you to follow that. This one is a good generic model to follow and most companies base theirs off of this one.