Why document your environment?

A recent presentation started me on thinking about why we document our environments. We all hate writing the as built type documentation and seldom update it as things change so why do it? The fundamental reason is so that when things aren’t working we know what “working” was. Then we compare current to documented working and remediate until all is working again. The problem is that the documented working is seldom the actual last working state, just the last documented. The other problem is identifying the current, not working, state to sufficient detail.

Both these issues could be addressed if we could gather the entire state of the environment using an automated tool. We gather the actual working state on a scheduled basis, ensuring we have a frequent picture of real state. Then when something isn’t working we capture current state again and compare to last known working, or last couple of documented states. Provided we have gathered the right data it should be possible to identify the causal change or at least be certain of the causal area.

This train of thought was triggered by a presentation at the Tech Field Day Extra at Cisco Live! last week.
Disclosure: Tech Field Day (TFD) have paid for my flights to attend events in June. TFD have not requested this blog post nor will they see it before it is published. TFD also paid for my lunch before the briefing at Cisco Live! and at least one bagel at the event.

The presentation was by NetBrain, and showed their product dynamically building up a network map as part of a troubleshooting activity. Their application dynamically builds up rich maps of networks by retrieving real time configuration from the devices. A huge amount of information was pulled from the network devices and displayed in a format that looks a lot like a Visio diagram. It was this immediate and focussed diagramming that had me thinking about why we keep documentation. I imagine that if I had to manage a moderately complex network I would love the sort of easy access to current state that NetBrain delivers. The delegate at the presentation who do look after large networks seemed pretty impressed, as they write about NetBrain you will see articles appear on this page which also has links to videos of the NetBrain presentation.



© 2015, Alastair. All rights reserved.

About Alastair

I am a professional geek, working in IT Infrastructure. Mostly I help to communicate and educate around the use of current technology and the direction of future technologies.
This entry was posted in General. Bookmark the permalink.

3 Responses to Why document your environment?

  1. Jeff Preou says:

    At a *very* basic level, I have a PS script for Exchange and a PS script for Lync that runs a whole heap of ‘Get-‘ commands into a dated/timed sub-folder (e.g. Exchange-Doco_2015-06-16_1319). This can (but isn’t yet) be scheduled. Not pretty. Kinda raw. But useful for a ‘snapshot’ of the configuration; at least on some level.
    A tool that does a similar job and hauls that info into a more readable and usable format would sure be useful.
    Cheers for this post, might follow the links and check it out when I have more time.
    I hope you enjoyed the bagel…

  2. Pingback: Why document your environment? - Tech Field Day

  3. Pingback: Newsletter: June 21, 2015 | Notes from MWhite

Comments are closed.