reading 04 - OddGarden/Ops201-Reading-Notes GitHub Wiki

Troubleshooting Techniques: CompTIA A+ 220-902 Troubleshooting Methodology

In order to go from "uh oh, it's broken" to "it works! yay!", the following troubleshooting processs comes in handly in any environment:

Identify the problem

Information gathering

  • Get as many details as possible. The more information at hand, the better it will be to piece together the total picture of the issue.
  • Duplicate the issue, if possible. Being able to see what issue is occuring can help narrow down the root cause of the issue.

Identify sysmptoms

  • Determine is there may be more than a single symptom. Multiple symptoms could be indicative of a larger issues. Fixing one sysmptom will not neccessarity fix the primary issue.

Question users

  • Users are the best source of details. Users can identify what time the issue occured, what application/system has the issue, what actions they were performing prior and after the incidents. The more finite detail that can be collected, the more likely less time will be spent tracking down the issue.

Determine if anything has changed

  • Who's in the wiring closet. If the issues were abrupt when it might be a good idea to determine what changed in the environment. Reverting these changes could resolve the issue entirely.

Approach multiple problems individually

  • Break problems into smaller pieces. Not all problems are connected. Looking at each issue individually means exploring all possible angles. It is possible that a single issues is actually as a result of multiple independent issues that led to failure resulting in a single issue.

Establish a theory

Start with the obvious

  • Occam's razor applies. Occam's razor in simple terms states that when faced with competing explanations for the same phenomenon, the simplest is the likely the correct one.

Consider everything

  • Nothing is out of scope. Even the not-so-obivous could be the answer.

Make a lis of all possible causes

  • Start with the easy theories
  • And the least difficult to test
  • Going through each item on the list ensures nothing is left unchecked.

Test the Theory and Evaluate Results: Is it working?

Confirm the theory

  • Determine nest steps to resolve the issue. Test the theory to confirm if it resolves the issues

Theory didn't work?

  • Circle back to previous steps to determine if anything was missed. If so, re-establish a new theory.
  • If needed, escalate or call an expert.

Establish a Plan of Action

Build the plan

  • Correct the issue with minimum of impact. Unless it is critical, find a viable time to make the changes that will be least disruptive.
  • Some issues can't be resolved during production hours.

Identify protential effects

  • Every plan can go bad. Always plan for worst case scenario.
  • Have a plan B and a plan C.
  • Be prepared to rollback any changes should things go wrong.

Implement the Plan

Fix the issue

  • Implement plan dusing the change control window Escalate as necessary
  • You may need help from a 3rd party to fully implement in the plan.

Verify Full System Functionality

It's not fixed until it's really fixed

  • The test should be part of your plan
  • Have the user confirm the fx

Implement preventative measures

  • It is important to have measured in place to ensure this issue is avoided in the future.

Document Findings

It's not over until you build the knowdledge base

  • Don't lose valuable knowledge. This will be helpful if someone else encounters the same issue down the line.

Consider a formal database

  • Capture help desk notes
  • invest in a searchable database for easy access.