How much Documentation?

bhcs2014

Admins, Engineers, etc., What do you consider absolutely necessary as far as documentation for an IT environment? What do you use to document things? Is there such a thing as too much documentation?

The reason I ask is because I just started my first job as an IT admin. We as a 5 man team support a 24/7 operation. I think we are pretty severely lacking in the documentation area. All we have is a static IP spreadsheet and some logical network diagrams. We have around 20 physical servers around 10 virtualized. There is no server change log. Changes are not documented. I feel this could bite us in the butt in future. Like when I go to troubleshoot a server I have no idea if the problem could have been caused by some recent change. There are no Physical network diagrams either. Obviously these things should be present, right?

The only problem is getting my teammates on board. At times we can be very busy which is why I think they overlook documentation but I think organization will help us be more efficient.

There were other things I thought should be documented but can't think of them now, so I ask what do you other IT admins usually document? Do you go as far to document ANY solution to any problem that has not been documented?

Find more posts tagged with

Comments

Node Man

Even in my home lab I would feel blind without at least syslog running.

ally_uk

In my own time I use Evernote and document everything I learn as I do alot of Linux stuff I create **** sheets which I can refer to quickly i.e Vim commands.

In the work environment whether it's help desk or Admin same thing applies I document solutions, changes, and problems which I am working on
I hate being in situations where you fix something and the same problem occurs and the knowledge and resolution you had magically has disappeared from your brain

Evernote is pretty good for this

Node Man

Evernote +1 Puts your notes on your computer, your tablet, and your phone.

kohr-ah

bhcs2014 wrote: »

There are no Physical network diagrams either. Obviously these things should be present, right?

>> OH SWEET THOR OF VALHALLA YES!!!!

Every job I have gone to lacks documentation of some sort. Most the time I don't document things I work on unless it is going to become a standard. AKA if remote locations all sites have a specific IP scheme I'll document it. If I am updating SVIs on the Nexus 7k pairs, I wont document that.

Otherwise here is what I do a lot of documentation on:
Procedures - Do it this way to make sure it does what it should
Change Control - Who did what when. This way we know where to look if something is being wonky.
Network Diagrams - Logical Diagram of who connects to what. Same reason. So I can track it down.
IP Schemes - All locations have the same scheme just a different Subnet (Like 10.0.3.0-127 next site may be 10.0.4.0-127)
Oddity equipment - Make this a wireless bridge so Tommy can video conference. Here is what I did after fighting with it for 11 hours to make it work.

lsud00d

Adequate documentation equates to people understanding what/why/how you did things when you're no longer there.

JeanM

Sounds like you are in a fairly small shop/org , the bigger the company/org the more important it becomes for documentation and change management/release management/patch management etc etc

Yeah, docs are important especially as the network/server footprint grows and as time goes by and nobody remembers what goes where or why or how something is configured.

--chris--

kohr-ah wrote: »

>> OH SWEET THOR OF VALHALLA YES!!!!

Every job I have gone to lacks documentation of some sort. Most the time I don't document things I work on unless it is going to become a standard. AKA if remote locations all sites have a specific IP scheme I'll document it. If I am updating SVIs on the Nexus 7k pairs, I wont document that.

Otherwise here is what I do a lot of documentation on:
Procedures - Do it this way to make sure it does what it should
Change Control - Who did what when. This way we know where to look if something is being wonky.
Network Diagrams - Logical Diagram of who connects to what. Same reason. So I can track it down.
IP Schemes - All locations have the same scheme just a different Subnet (Like 10.0.3.0-127 next site may be 10.0.4.0-127)
Oddity equipment - Make this a wireless bridge so Tommy can video conference. Here is what I did after fighting with it for 11 hours to make it work.

+1 this is a solid reccomendation.

In a IT service provider environment, documenting is everything.

In a enterprise support position, standardizing the deployment of hardware (Procedures), Change Controls, Network Diagrams, and things that are not standard should be documented or automated when possible.

It doesn't need to get done all at once, but start pecking away at it.

bhcs2014

node/ally - I am talking more about team oriented documentation. Not personal notes. I do keep personal notes. Haven't used Evernote though, I'll have to look into it.
kohr/chris - Thanks for the ideas. Now that I think more about it I guess our documentation isn't too bad. We do have procedural documentation/deployment guides. Changes aren't really documented. What exactly does change control documentation look like? Is it like an excel sheet with changes made to systems/the network and anything that is implemented. How detailed does it get?
I definitely want to get more network diagrams going though. I know that more diagrams would have been immensely helpful when I first started.
jean- yea we are one of the larger branch sites. I think because of our smallish size people just keep info in their head
lsu- Yup I think I read something like this on TE: If everyone on the IT team got hit by a bus new people should be able to come in and pick everything up right away using documentation

Priston

It doesn't matter, any port. It doesn't matter, any vlan. It doesn't matter, any IP address.

https://www.youtube.com/watch?v=vKqJjTIZgO8

You know what... Maybe documentation and planning is a better idea.

kohr-ah

bhcs2014 wrote: »

kohr/chris - What exactly does change control documentation look like? Is it like an excel sheet with changes made to systems/the network and anything that is implemented. How detailed does it get?

If it is a minor change we just track it via Excel sheet that is distributed weekly. Who is doing what at what time so we know.
If it is complex (like the removal of something like OSPF) then I attach a scope of work to it. That tells the following:
Who is part of this
What exactly is being done
When is it being performed
What changes are being done (the commands)
What is the back out plan if it fails