| Previous | Table of Contents | Next |
LOONIE has two connections in the back (one to your local area network and one to the satellite transmitter); you should label each connection with the device name and its endpoint. For example, the cable going to the satellite transmitter could be labeled this:
LOONIE -> Satellite Transmitter
Then, the other label might be this:
LOONIE -> Data Closet #1, Hub #3
Why label the cable that’s directly connected to LOONIE as “LOONIE”? Well, suppose you have to disconnect the cable. It would be nice to know where to put it back.
I like to label each end of a cable with both devices that will be connected with the cable. This is so that I don’t have to think about which end to put in the cable. I’ve been at sites where some poor, confused soul has labeled each end with the source rather than the destination, so that all you know is that the LOONIE router has a cable that goes to, uh, LOONIE. Oops! It’s best to look at cable labeling from both sides (after all, you bought a $50 label maker, and making labels is easy). It really does save aggravation.
The difference between a well-documented site and a professionally documented site is in the details. Detail documentation—although the least practiced documentation type—can augment the other types of documentation very nicely.
Detail documentation in the form of a formal write-up of how a system was configured, along with site-specific standards or frequently used troubleshooting practices, can make it easier for others to retrace your footsteps. This type of documentation, which includes how-to’s and cheat sheets, contributes greatly to your ability to actually take a vacation.
You’re the captain, so keep a log. It’s hard to find a block of time to sit down and write up a formal description of previous troubleshooting techniques, but if you keep a log book near each crucial device, you can document as you go. Make it part of your SOP to write down anything that’s done to a server, switch, or router (and at what date and time this operation was performed)—you’ll save yourself a bunch of time when it comes to retracing your steps. Log books are also great for providing back-up documentation with a vendor. For example, an entry such as “The new server has crashed each week at 10:00 on Monday night” might lead a vendor to realize that the hard drive cleanup program scheduled to run on the server at 9:50 on Monday nights might be causing a problem.
Is it possible to reverse-engineer an undocumented network? Sure, but this requires a good bit of knowledge. What’s more, it’s really a waste of time if the network is being installed or changed while the documentation is taking place. See Hour 24, “Reverse-Engineering Somebody Else’s Network,” if you have a nightmare network that you need to document.
Is this a hint that you should insist on good documentation when you contract out for someone to build a network for you? Yes! Any professional worth his or her salt will probably be labeling like crazy anyway, but just in case you run into someone who thinks that an undocumented network equals job security, you need to get tough. Insist on labels on all cables, and ask for maps. If you have to pay more, either pay up a reasonable amount, which should be nominal (plus you’ll save time and money in the long run), or find a different vendor. A lot of vendors are out there, and, ultimately, you’re the person who either suffers or benefits from the documentation of the network and cable plan.
You can be the best network troubleshooter in the world, but without documentation, you’re out to sea in a leaking boat. Documentation can mean the difference between ten minutes of downtime compared to two hours or so; therefore, a little work up front can really pay off in the long run.
Each type of documentation is important in its own way—for example, labels on cables, maps of the network cable runs, and functional diagrams of server placement. Also, keeping a logbook can keep history from repeating itself. In other words, it gives you a point of reference when the network goes down.
Q I label cables by number because each cable function can change and it’s time consuming to replace the cable labels. Is this adequate?
A Not in my experience. Folks don’t always keep track of what numbers are being used, and a number doesn’t describe what’s at the other end, thus requiring a separate table to translate the numeric cable number to the physical device (which you’ll have to update when you change devices, anyway). Do yourself a favor and just put the description on the cable.
Q What should I document on my maps? What shouldn’t I document on my maps?
A Completeness is the key here. Once you get some experience doing this and practice the techniques in future hours, you’ll probably look at your initial maps and say, “I didn’t need to write that down.” However, you’ll only know this after you get some experience under your belt. For now, write it all down; you can edit later.
Q This all seems overwhelming. Where do I start?
A Start simple and you’ll be fine. You can start by writing down everything that you know about your network—your server name, where it’s plugged in, what hub your computer is plugged into, and so on. Then, you can write down the categories of documentation, along with to-do’s for each category.
| Previous | Table of Contents | Next |