- Doctor Network
- Just the Facts
- SOAP in the Real World
- Summary
- Q&A
- Workshop
This chapter is from the book
This chapter is from the book
This chapter is from the book
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. In particular, we'll take a case in which the problem seems to be intermittent—again, those tend to be among the toughest problems. Figure 7.1 shows a logical map of the site; her PC lives at point A on the map.
){kind=link}
Figure 7.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:
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:
An okay plan, but it doesn't work out, as shown from your notes:
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.
Is It a Virus, Doc?
After getting a cup of coffee, you briefly think about the possibility of one of those viruses that "go off" at 8:00 a.m. on a certain day, but you dismiss it—you have pretty good virus protection. What's more, you used a different workstation that you're sure is virus free when you tested the different segment. That's a good guess because things like this have happened—even viruses that don't do anything until a certain day at a certain time in the morning can interfere with system operations every day while it checks to see if it's the right day to ruin you.
So, it's back to the drawing board.
Getting a Consultation
This is the crucial part because you're frustrated, and you think you can't possibly solve this problem. It's tempting to give up. Guess what? Pros feel that way, too. The difference, however, is that the successful troubleshooter takes a break and looks at the facts again. Then, much like a doctor, the troubleshooter might "get a consultation" and go right back at it.
Do you have to get a consultation from a pro? Not necessarily. You get a consultation because you're too close to the problem, and you already have preconceptions as to what's going on. Let's say that you ask somebody—anybody—what goes on at 8:00 a.m. every day. The answer is going to be "everybody turns their PCs on" or "everybody gets in to work" or some variation on this. That turns on a lightbulb for you—because everybody is turning their PCs on and logging in at 8:00, might this be the computer equivalent of rush hour on the network?
The answer, of course, is yes, there is a network rush hour. How do you verify this? Well, it's sort of tough. There are two ways:
Actual measurement (relatively difficult unless you've already read Hour 23, "Network Management Tools")
Changing the situation (moving the workstation to a place where traffic will be quieter)
Even though you've already moved the workstation to a different segment, you hadn't considered that the segment you were moving to might also be problematic. You can think of this as the equivalent of moving from the Long Island Expressway to the Grand Central Parkway—it doesn't do you a lot of good at rush hour. (You've been treating the situation as though there was construction or an accident on one but not the other.) Now, your SOAP looks like this:
You deploy your plan: You temporarily set up a workstation at point C on the map. When you try the applet at 8:00, it works. You have now pointed the finger squarely at network congestion. The next question is, whose problem is this? In other words, is this something that the applet vendor is responsible for, or is this your problem for having a network that's too busy?
Your response to this problem might vary. On one hand, it might be practical to move this person to a less busy segment. However, this might not work because you can see from your physical maps that the network segments near PCs tend to have a lot of PCs on them and are smack in the middle of the servers. In other words, physical constraints might prevent you from putting this person on a segment without other PCs because the only hubs near her probably are being used for other users. Note here that if you were using switches that supported VLANs instead of hubs, you could switch her effective segment (the virtual data link domain) without physically moving her workstation—that's what VLANs are for. But in this case, we're dealing with hubs, so no such luck. Worse, we discover that all low-population segments are either in your data center or in another building, outside of her physical reach. (The smart aleck might ask, "Why not ask this person to stop doing her work process at 8:00 in the morning?" Not a great solution—the network is supposed to work, darn it!)
At this point, if you really needed to have this person's workstation stay where it was on the busy segment, you have to start application troubleshooting. Why is it that this person doesn't have any other problems, say, with local applications? As you'll see in Hour 19, "Intranet and Internet Troubleshooting: TCP/IP at Work," comparing a local application to an Internet application isn't a good idea; using Internet applications is like taking an international flight versus hopping in your car to go to the store. A lot of things can happen between here and Paris. You write down your SOAP again:
You've now done five SOAP lists. Long and tedious, isn't it? Yet, as you can see, SOAP is a powerful process for refining what you know, as well as a way to take guesses and turn them into fact and a way to keep you moving forward.
You try a different Internet application at 8:00 the next morning, and it works like a champ. Even though it doesn't do exactly the same thing, at least you're now comparing apples to apples—that is, a firewall-dependent, wide-area application to another firewall-dependent, wide-area application. You try yet another Internet application, just to make sure, and it, too, works just dandy. Here's your latest SOAP:
Fortunately, this is not a free applet, and the supplier is eager to make it work for you. The supplier talks you through taking a network trace, and you email it off to him. He responds that you have quite a lot of traffic, but not an unreasonable amount. Because you've gathered a lot of notes and have sent them to him, he has a good idea of what's going on and understands that it's probably his problem. Because he wants you as a customer, before too long, you've got a patched program emailed to your desk, which you install to your user's PC—problem solved.
TIP
In a situation such as this, you want to make sure that you document the problem—either informally (via email to your colleagues) or formally (say, as an addendum to the product documentation in your library). You might write something like this:
10/20/98, JF: Applet has problems running on a busy network, use Patch 1.2, located on the 'Barbarian' server's 'FIXES' share.
Sound crazy? A software supplier fixing something you reported? Not really. Our shop has reported many bugs to suppliers over the years using this procedure with great success. When you follow careful SOAP note-taking procedures, you're likely to convince your technical support people that you have a bona fide problem that needs to be addressed. However, it's even more likely that you'll come up with the answer yourself—which is really the objective.