Last Updated on 12/04/2008 by dboth
The second step in solving the problem is to observe the symptoms of the problem. It is important to take note of all of the problem symptoms. It is also important to observe what is working properly.
This is not the time to try to fix the problem; merely observe.
Another important part of observation is to ask yourself questions about what you see and what you do not see. Aside from the questions you need to ask that are specific to the problem, there are some general questions to ask:
- Is this problem caused by hardware, Linux, application software, or perhaps by lack of user knowledge or training?
- Is this problem similar to others I have seen?
- Is there an error message?
- Are there any log entries pertaining to the problem?
- What was taking place on the computer just before the error occurred?
- What did I expect to happen if the error had not occurred?
- Has anything about the system hardware or software changed recently?
Other questions will reveal themselves as you work to answer these. The important thing to remember here is to gather as much information as possible. This increases the knowledge you have about this specific problem and aids in finding the solution.
As you gather data, never assume that the information obtained from someone else is correct. Observe everything yourself. This can be a major problem if you are working with someone who is at a remote location. Careful questioning is essential and tools that allow remote access to the system in question are extremely helpful when attempting to confirm the information that you are given.
When questioning a person at a remote site, never ask leading questions; They will try to be helpful by answering with what they think you want to hear.
At other times the answers you receive will depend upon how much or how little knowledge the person has of Linux and computers in general. When a person knows — or thinks he knows — about computers, the answers you receive may contain assumptions that can be difficult to disprove. Rather than ask. “Did you check…,” it is better to have the other person actually perform the task required to check the item. And rather than telling the person what he or she should see, simply have the user explain or describe to you what he or she sees. Again, remote access to the machine can allow you to confirm the information you are given.
The best problem solvers are those who never take anything for granted. They never assume that the information they have is 100% accurate or complete. When the information you have seems to contradict itself or the symptoms, start over from the beginning as if you have no information at all.