Mar 17 2013   1:02PM GMT

Writing a Settings or Configuration document…

Posted by: James Murray
Network Architecture

In other articles I’ve talked about how IT Experts can leap frog their careers by being able to document.  As a Seattle IT consultant, I find that the stereotype is true.  IT Experts don’t document.  They are under a great deal of stress to move

forward to the next project.  Additionally most of us aren’t trained to write technical documentation.  When there are problems on the network and nobody else is writing documentation.  It’s easy to rationalize that there’s no time for documentation.  I think the real reason is that most IT experts were trained to fix computers, not to write about what they are doing.  One of the ways to be successful is to do things that nobody else is willing to do.  What I’ve found, and I’ve written multiple times about this, is that I was allowed onto a number of projects just because I was willing to document.  I learned early that office politics is about making others look good.  If the operations manager is being pressured to provide documentation, then when a new project comes up, someone needs to be able to document it.  Because I had a reputation for documentation, operations managers could depend on me to write documentation for projects and keep their managers off their backs.  Since I was on the project, I was being mentored on the newest technologies that were being implemented on the network.  Because I had documented it, I was also being asked to troubleshoot when it failed.  Because I could troubleshoot, I became the expert.  Because I was an expert, I was asked to lead projects.  So a small thing like writing clean documentation gave me an edge when I competed against experts with much higher levels of technical understanding for the best projects.

When I began teaching, part time, at the local community colleges I passed on this and other pieces of wisdom.  I forced my students to document.  As a result, my students found they had an edge as well.  In this article I’d like to talk about configuration documentation.

So imagine you have a server or a router that suddenly stops working.  The hardware is working fine.  So what’s wrong?  Well if you have been doing this as long as I have you know that something changed.  If you’ve never seen the system, tracking down that change can take forever.  Unless you have a configuration document.  Now you review the configuration on each device in your system and find that some setting did change.  When you set the change back to the original configuration.  Things start working again.  That’s one of the basic assists of a configuration document.  Without the document, unless you know the system or were the person that made the change, it can require hours even days of troubleshooting to figure out what went wrong.

So one type of configuration document is a list of all the non-fault settings on a system.

Another type of Configuration document is a “Base Line” document.  So you build a server and get it up and running on the network.  A year later you come back and the system is failing.  What’s wrong?  If you had created a baseline of the server when the system was running on the network it would be simple.  You create a new baseline today and compare it with the original baseline.  Now you can compare RAM and CPU usage.  You can compare disk space and as many other settings as you originally measured in your first baseline.

As you look at your network, you will see that it is made up of hardware and software.  What makes your system on the network unique is the custom settings and configuration you’ve made across the network.  Without a baseline your network is only as good as the team members memories.  I’m working on developing layouts for the different types of documentation you might need on your network.  You can look here or here for additional help creating configuration documentation.