Previous Table of Contents Next
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. 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 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 into
work" or some variation on this. That turns on a light bulb 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:
o Actual measurement (relatively difficult unless you've already
read Hour 21, "Tell Me About Your Network")
o 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:
S: The problem might be network congestion.
O: The problem occurs at the same time on different major
network segments.
A: Login congestion is likely on major segments, but not as
likely on a segment with fewer users.
P: Check maps and try the applet on a "low traffic" network
segment (perhaps nearer to the Internet segment and away from
segments with server login traffic on them).
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 may vary. On one hand, it may 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. A hub with less traffic might be 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
live on a busier 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,
"Internet/Intranet Troubleshooting," 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. Lots of things can happen between here and Paris. You
write down your SOAP again:
S: Applet is not working; other applications are.
O: The applet is the only Internet application in the mix.
A: Internet applications are not local applications.
P: Try a different Internet application during peak hours.
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:
S: The application itself seems to be at fault.
O: Only have tried two other Internet applications.
A: Measurement of congestion and delay might help but would
still lead to vendor.
P: Contact supplier of the applet and relate all notes that led
to this conclusion.
Previous Table of Contents Next
Wyszukiwarka
Podobne podstrony:
077 NEWPHASEv 02 079I F 077nik p 13 079 zegluga079 KUTCHVSS1 Flowchart programming mode English ASM 000 079 0 PZ464 T0131 00v 04 0792010 01 02, str 077 080079 081KLIR biuletyn 077I F 079078 079więcej podobnych podstron