Hour 6
The SOAP Method: Subjective Data, Objective Data, Analysis, and Plan

I hope you’ve liked all the writing involved in the last hour, because the method of troubleshooting in this hour involves a great deal more of it. Treating a complex problem usually involves a lot of note-taking, because you have to fill in the gaps where your understanding of the problem is incomplete. Up until now, you’ve treated problems the way you treat a multiple-choice test—with change analysis, divisive reasoning, and matching. Now, we’re talking about a fill-in-the-blank test, and it gets a little bit harder; this is the hour where you have to wade through the subjective, match it up with the objective, analyze your data, and plan on what to do next. In other words, this is the hour you want to save for the tough problems.

Doctor Network

First, a little bit about the SOAP method. I first encountered the SOAP method while I was deciding not to be a doctor like my father. Although I had absolutely no interest in sticking needles into people, hanging around my father in his office taught me a lot about troubleshooting. In a sense, medicine is much harder than computing—there are hardly any standards, the designer never released the data sheets (much less the full documentation), and the device you’re trying to troubleshoot can sue you if you make a mistake. The medical profession has come up with all sorts of diagnostic tricks—we as network troubleshooters have a great deal to learn from the medical profession.

One of those diagnostic techniques is the SOAP method of note-taking. On their patients’ charts, some doctors write down on separate lines the letters S, O, A, and P, standing for Subjective, Objective, Analysis, and Plan, respectively. Therefore, if I went to see the doctor about my stomach, he might write:

S: Patient reports stomach pain; ate hot chicken wings last night; extra work lately.

O: Palpation reveals tenderness in upper right quadrant.

A: Suspect acute gastritis.

P: Treat with antacid x 5 days, bland diet, follow up in 5 days to assess condition.

The subjective is what I say to the doctor, the objective is what the doctor sees, the analysis is what he deduces from his additional questions and reasoning, and the plan is what he will do to try to treat the problem, plus the next step. Doctors are used to not being able to get a black-and-white answer; however, if they have a plan, they are going in the right direction.

Going in the right direction is what the SOAP method is all about. Not every problem you run into as a troubleshooter is going to be solvable within that day or week—particularly problems that are not show-stoppers (emergency room visits). In particular, problems that come and go (intermittent problems) are usually long-term and complex troubleshooting jobs. To be able to wrap your arms around a complex problem, you have to segregate the problem into its component parts—that is, the subjective report and the objective facts. It’s particularly important to be able to separate the subjective out—someone may be reporting something that has some bearing on the problem but perhaps is not pointing directly at the problem. Consider someone who’s reporting chest pains—is this person reporting a heart attack or a muscle problem? The report of pain in the chest is a subjective feeling—the active investigation that reveals a heart attack or muscle pain is the objective finding. The subjective is useful but can only be borne out by investigation.

Just the Facts

When considering the facts in an intermittent or complex network issue (also known in the industry lingo as “troubleshooting a weird problem”), you need to categorize a basic list of objective items that can help point towards a solution:

•  Duration of problem (all the time or intermittent?)

•  Start of problem (date and time)

•  Place (on the network, physical location)

•  Number of users involved

•  Configuration of workstation (like or unlike others?)

•  Number and types of applications involved (running simultaneously with?)

•  User name(s) involved, security group(s) belonged to

•  Measurements

•  Behavior of similar applications

Even though you may have a lot of objective data, you might not have the right objective data to analyze in order to come to the right conclusion. Therefore, your “plan” item on your first couple of tries on a tough problem will probably be to gather more data. Don’t give up; the more data you have, the better guess you can make.

SOAP in the Real World

Let’s take a case in which a user says she can’t run a particular Web applet that she needs for her job. Figure 6.1 shows a logical map of the site; her PC lives at point A on the map.

Figure 6.1  Troubleshooting a time-related problem.

You visit the user’s PC and can run the applet just fine. She frowns at you, and says, “Well, it doesn’t work for me.” She tries right after you, and it works, but she reports the problem again the next day. You decide to use SOAP on this one:

S: Web applet does not run.

O: Web applet runs when I try it.

A: Perhaps the time of day has something to do with it?

P: Come back during the time she usually tries the applet.

Your analysis of the problem is a good one, and your plan to gather new information works. You visit her when she usually tries her Web applet, and, sure enough, it won’t work for you. What’s going on? This time through, you’re the one supplying the subjective data; it’s your guess:

S: I bet that the time of day has something to do with the applet not working.

O: Web applet does not run at 8:00 a.m.

A: Could it be related to another network activity on that segment happening at the same time?

P: Try using a different network segment (point B on the map).

An okay plan, but it doesn’t work out, as shown from your notes:

S: Network activity may be different on her segment at 8:00 a.m.

O: Web applet still fails on a different segment.

A: My head hurts. What else could be different at this time of day?

P: Investigate what goes on at 8:00 a.m. on the network as a whole.

She still has problems at 8:00 a.m. on a different network segment. That’s fine. You’ve now ruled out her network segment, and that’s very important to do. You’ve made a deduction, and it’s wrong. Don’t sweat it.