Editor's note: Channel partners spend a lot of time learning about their customers' data center environments and...
network infrastructure. It stands to reason: You'll have a difficult time getting to the optimized "to be" promised-land if you don't have a grasp of the "as is" IT estate. A comprehensive network diagram and collection of network documents will help you get there. This network documentation checklist summarizes best practices for detailing network devices and other key aspects of customer networks.
Although network documentation is always a good idea, it's especially important for service providers and value-added resellers. Documenting your customers' networks can make the troubleshooting process much more efficient when problems arise. These same network documents can help you spot areas of your customers' networks that may need to be upgraded, possibly providing you with extra revenue. Finally, good network documentation proves that you adhere to industry best practices, and it could be your best defense should a customer ever file litigation against you for something network-related.
Here's a 10-step network documentation checklist to help you get started.
Step 1: Create a network documentation policy
A network documentation policy should detail what aspects of a network need to be documented, especially each server. A documentation policy also communicates to each administrator exactly what is expected of them regarding the documentation process.
Step 2: Create a network topology diagram
Ideally, you want this map of the network's topology to include each network segment, the routers connecting the various segments, and the servers, gateways and other major pieces of networking hardware that are connected to each segment. For larger networks, you may have to create a general segment map and make more specific maps of each individual segment.
Step 3: Document server names, roles and IP addresses
While the information included in a network topology diagram is not necessarily specific, there is certain information that you should include for each server, even if that information has to be placed in an appendix. For each server, list the server's name, its IP address and the role the server performs (domain name system, Dynamic Host Configuration Protocol, mail server, etc.). Keep in mind that a server may be assigned multiple IP addresses or have multiple network interface cards, so you should document that information too.
Step 4: Create a change log for each server
When a server fails, the failure can often be traced to a recent change. As a part of the network documentation, consider making a log book for each server for documenting changes such as patch and application installations and modified security settings. Not only will the log help you troubleshoot future problems, but it can also help you rebuild the server in the event of a catastrophic failure.
Step 5: Document software versions and proof of licenses
Document the applications and their versions running on each server. You might also include a copy of the software license or a receipt within this documentation just in case your customer becomes involved in a software audit.
Step 6: Document hardware components
I have talked about documenting individual servers, but it's equally important to document switches, routers, gateways and other networking hardware. The documentation should include information such as the following:
- How is the device connected to the network?
- How is the device configured?
- Does a backup of the configuration exist?
- What firmware revision is the device running?
- Is the device configured to use a password? Don't include the actual password, but you can include a password hint or a reference to the password being written in a notebook that is stored in the safe.
Step 7: Document the Active Directory
I could probably write a book on Active Directory documentation, but here are a few things that you should consider documenting:
- The names of the domains in the forest.
- The Active Directory site structure.
- Where the various servers exist within the Active Directory hierarchy.
- The location and contents of each group policy.
- Any external trusts that may exist.
Step 8: Document your backup procedures
Backup is your customer's best defense against a catastrophe, but it will do little good if nobody can figure out how to use it. Be sure to document the backup software used and its version (very important). You will also want to document the tape rotation scheme, a general description of what's included in each backup job and where the backup tapes are stored.
Step 9: Label everything
I once had a client ask me to do a consulting project for them. They gave me a thorough and well-written copy of their network documentation to review ahead of time. But when I got on site, I realized that none of the hardware was labeled. All of the servers looked identical, and there was no way to differentiate between them.
Get a label maker and label all servers, critical hardware components (gateways, routers, etc.) and the most important cables. This will make it easy to identify the various pieces of hardware listed in your network document.
Step 10: Evaluate your documentation
The last step in this network documentation checklist is to evaluate your documentation to make sure it's sufficient for you and your customer's needs. Think of your network documentation as a critical part of your disaster recovery strategy. When the first draft of your documentation is complete, you must ask yourself if it's good enough to help someone with no prior knowledge of the setup to rebuild the network from scratch in the event of a catastrophe. If the answer is yes, then you've done a good job on the documentation.
Readers looking to supplement their knowledge beyond this network documentation checklist can find an additional resource on automating network documents and topology mapping, as well as information on process documentation.