3.6.2 TROUBLE SHOOTING PART II

Part one of troubleshooting

• Back up the system

• Create an action plan

• Identify the problem

• Identify possible causes and identify a theory of probable cause

Answer explanation

When identifying the problem, resist the urge to start fixing things at this point. To identify the problem:

Ask the user to describe the problem or symptoms, check for error messages, or recreate the problem. Establish what has changed. Most often, problems are caused by new hardware, software, or configuration changes. If necessary, ask users to discover what might have changed that could have caused the problem. Remember to inquire about environmental and infrastructure changes that could be relevant. Review system and application logs. Check knowledge base articles, network topology diagrams, the Internet, and any other documents that may provide helpful information.

Part II of Troubleshooting

• Identify the problem

• Create an action plan

• Back up the system

• Identify possible causes and identify a theory of probable cause

Answer explanation

Before making changes to the system, back up user and system data (or make sure a recent backup exists). While some changes can be made without affecting user data, you should back up data to protect against unintentional data loss caused by making changes.

Part III of Troubleshooting

• Test your theory

• Identify possible causes and identify a theory of probable cause

• Create an action plan

• Back up the system

Answer explanation

Check for simple, obvious, and common problems first. For example, check power cords, connectors, and common user errors.

Part IV of Troubleshooting

• Identify the problem

• Test your theory

• Identify possible causes and identify a theory of probable cause

• . Create an action plan

Answer explanation

Test your theory to verify the cause of the problem.

If your theory is not correct, examine other possible causes (return to the previous step). At this point, if the problem is caused by simple things like an unplugged system, you can safely take actions to resolve the problem. If the cause is not a simple one, identify the necessary steps to correct the problem. If you cannot identify the cause of the problem, or if it is beyond your ability or responsibility to fix, escalate the problem.

Escalation means turning the problem over to someone more capable of handling it. When escalating the problem, be sure to detail the actions you took and the information you have discovered up to this point.

PART V OF TROUBLESHOOTING

• Back up the system

• Test the solution

• Test your theory

• Create an action plan

Answer explanation

To create an action plan, address the most likely problem and account for side effects of the proposed plan. For example,

Will the fix result in significant system downtime? Is the resolution best left for other times of the day? Is there a temporary solution that should be implemented immediately?

When side effects have been weighed against the fix and all concerns have been addressed, fix the problem.

PART VI OF TROUBLESHOOTING

• Test the solution

• Ensure satisfaction

• Document the solution and process

• Create an action plan

Answer explanation

When you are testing your solution, do the following:

Ensure that the problem is fully resolved and that implementation did not cause any new problems. If necessary, take additional actions to prevent the problem from happening again.

PART VII OF TROUBLESHOOTING

• Ensure satisfaction

• Document the solution and process

• Test the solution

• Create an action plan

Answer explanation

After the problem is fixed, ensure the customer's satisfaction and explain what you did to fix the problem. If possible, have the user perform the task to make sure that they understand and accept that the problem has been resolved.

PART VIII

• Ensure satisfaction

• Test the solution

• Document the solution and process

• Back up the system

Answer explanation

Documenting the solution and process provides you with a record of what the problem was and what you did to solve the problem. In the future, you can check your documentation to see what has changed or to help you remember the solution to common problems. It will save you time and money when troubleshooting problems.