Investigation is the first phase in the troubleshooting process. It involves the following steps:

 

1. Write a problem statement.
2. Write a problem description.
3. Identify differences and changes.

---

Write a Problem Statement

The first part of the Investigation phase is to write a problem statement. The problem statement must be broad enough to describe the problem, but narrow enough to focus the investigation. It should not contain value judgements and should be a factual answer to the question "What is wrong?"¹

 

Good Examples 

 

• The server crashed on Wednesday evening.
• The car would not start early this morning.
• The fluorescent light in the garage does not turn on.

Why are these good examples? They do NOT include a value judgement, and they do NOT guess at possible causes. They do not list any observable symptoms beyond the precise statement of the problem.

 

Bad Examples 

 

• The server crashed on Wednesday evening, probably caused by an end user. Blue LED is blinking solid on the front of the bezel.
• The car would not start this morning due to the subzero temperature, a bad starter motor, or a faulty alternator. The lights seem to work fine.
• The fluorescent light in the garage does not work; it's old and probably needs to be replaced. 

Why are these bad examples? These examples include a guess at a possible cause, and they include a list of immediately observable symptom beyond simply stating the problem.

 

---

Write a Problem Description

The next part of the Investigation phase is to write a problem description. This is where you describe the problem in more detail by collecting as many symptoms as possible. Gather as much data as you can, such as any error messages, core dumps, service outages, and contrasting descriptions of what still works. As much as possible, identify the time of the incident and the circumstance.¹ 

 

When documenting the problem description, do not underestimate or overestimate the magnitude of the problem. Be sure to stick to the facts in the data that you gathered.

 

Good Example

 

• A customer attempted to start their 1992 Chevy Cobalt at 8 a.m. and the car would not start. The car makes a clicking sound when it is started. However, headlights and windshield wipers turn on and function properly. No error lights display on the dashboard.

This is a good problem description because it includes information about symptoms, and contrasting information about what still works on the car. It also identifies the time that the problem occurred.

 

Bad Example 

 

• Sometime this morning the customer attempted to start their car and it would not start. They think it's the battery. It's probably something much worse, like the starter.

This is a bad example because it is too vague; it does not contain symptom information or information on what still works. It also contains a statement that overestimates the magnitude of the problem, with nothing to back the hypothesis.

 

---

Identify Differences and Changes

Identify differences between the faulted system and any similar working systems. Has this problem always existed? Has the system ever worked properly?

 

Also, identify any recent changes to the system.¹ For example, was any preventive maintenance performed recently? Was any part of the system upgraded or modified recently? 

 

Examples

 

• Our records show that the server's memory was upgraded 3 months ago.
• The customer said they have had no recent problems with their car. They had a 3,000 mile preventive maintenance/oil change service three weeks ago, and the car was fine.

---

What's Next?

Phase 2: Analysis >

 

---

References

1. Cromar, Scott. "Troubleshooting Methodology," Princeton University Enterprise Servers and Storage, 2007; available from http://www.princeton.edu/~unix/Solaris/troubleshoot/methodology.html; accessed on January 4, 2011.