Servers

Take stock of your data center: Documenting servers

James Wright discusses the importance of documenting your server setup and suggests some general guidelines about what to include, how to store it, and who gets access to the information.

Today we are going to talk about the importance of documenting your servers. This is something that we all know must get done, yet there always seems to be something with a higher priority taking our time. Perhaps the holiday season provides you with a little "downtime" at work when you can catch up on these kinds of tasks.

The ways in which good documentation can assist an IT department are many and varied. Good documentation can help you in the areas of accountability, governance and compliance, disaster recovery, performance and base-lining, and troubleshooting just to name a few. It is therefore of the utmost importance that you consistently maintain a good documentation structure for your systems.

What do I mean when I say a "good" documentation structure? There are many books and articles, not to mention personal opinions, on this subject and so long as your system meets a few critical items the details of your documentation approach can be flexible.

Items to consider when mapping out your documentation strategy:

Know the purpose of documenting a system

The purpose of documentation is so that you will know what the system is and what you will need in the event you have to completely rebuild it from the ground up. What server OS is installed and what is the hardware configuration for each component? What is the network configuration? What applications are installed and why are they installed on this server, etc. Just grabbing a bunch of data, while better than nothing, is still not sufficient. Do not just document what is on a system but, wherever possible, explain why it's set up the way it is.

Document from the general to the specific

You should have a base document that applies to all of your servers. You should also include an area to document the specifics of a server; for example, if it is an application server include the specifics of the application's configuration and who the primary audience for that application is. Include any contact for support of the application and any "Guru" your company has that might help when things have gone terribly wrong. This doesn't just apply to application servers but should also include your email system, virtual hosting systems, etc.

You should also maintain a Service Log for each server documenting routine maintenance, as well as hot fixes and gotcha's. This part could prove especially useful when troubleshooting persistent and intermittent issues.

Also, be sure to include the DR plan for the server in conjunction with the company's overall DR plan.

Update documentation

It is just as important to keep your documentation up to date as it is to develop it in the first place. An old, out-of-date document might well be better than nothing, but a current document will definitely be more beneficial and save time when time is of the essence.

Know your intended audience

Is your primary audience technical or managerial? If both, you should create two sets of documents -- one including all the fuzzy technical details we geeks have grown to love and one providing a high level overview that is accessible to your management.

Security and accessibility

Your documentation should be secured from those without the need to know, yet accessible to those who do. This is another place where having both a highly technical and a general overview is handy. Only a few people in the IT department need the technical details. Just remember to always err on the side of security. Better to have to grant access then explain why your systems are documented all over the Internet.

Documentation software

I have never used a designated documentation system personal, though I do know that you could if you have the budget to purchase one. I may, in the near future, select several and research them for a future article.

Personally, I prefer just using an old-fashioned Windows folder structure and then building an HTML front-end to access the documents. You can also keep this type of information in a SQL database and build a front-end to view and sort the data for an even more powerful, and potentially helpful, solution.

Summary

Documentation of your systems is more critical than some people realize. It can help drastically reduce recovery time when the inevitable happens. It can also assist you in tracking down the root cause, or at least a workaround, for various system issues. If IT Auditors happen to visit, then this documentation, and the security thereof, can really be a job saver.

You can even use scripts to document your systems for you. Just write a script and set the output to whatever type of file you want and run it on your systems. This will enable you to set a Scheduled Task on the server to automatically get a fresh view of your systems.

Identify what needs to be documented

  • Develop a plan to store the documentation - including who will have access.
  • Develop a format in which to store the data, i.e., Word Templates, Database, etc.
  • Develop a strategy for documenting each system, both in existence currently and new systems brought online.
  • Implement these and rigidly update the data once it is in place.

Do you have a documentation strategy in place or use a software solution to help you keep track of it? Tell us about it in the discussion area.

Also see:

About

James Wright is a veteran IT professional who has spent the majority of his career as a Systems Administrator. James has also served as a Systems Analyst, Helpdesk Senior Technician and as a Programmer Analyst. This range of experience has allowed hi...

6 comments
rjalan2
rjalan2

Check out device42 as well which is being created to serve as a single comprehensive solution for data center documentation and IP address management. With recent release of our auto-discovery tool, it is now possible to update the documentation with minimal efforts.

mark1408
mark1408

...is the combination we use. Spiceworks is useful for running a report of key hardware configs. I have separate documents for each server providing extra info and then separate docs again for key applications. One thing that intrigues me in this virtualisation age: We only dabble in it so far, but where an organisation is creating servers rapidly & frequently what's the philosophy for keeping up with documentation? (Especially if a VM may be temporary.) Obviously a network scanner like Spiceworks will tell you when devices appear but beyond that it must get harder and harder to keep documentation current.

rpollard
rpollard

I have been using MediaWiki for a while and like the fact that although it's structured, has a formatting markup language and is free flowing, it has a great search mechanism for finding things. Also, it tracks changes and whom they were made by.

bowlingbrad
bowlingbrad

Evernote is great. We came up with a standard format and we place all related info there.

rmaccara
rmaccara

I've found SpiceWorks to be a great help in not only documenting the servers, but documenting the entire network - including AD integration. This is a totally free way to not only document your servers, but monitor software changes on all networked computers, UPS monitoring, keep track of quotes and purchases, built-in help desk, and a great community to boot!

tommy
tommy

I had the luxury of starting from a bare-brick building and building the infrastructure and services from scratch for my current post. One of the mandates I had to fulfil was full DR documentation for the business. Building a nuts and bolts IT Services Manual as part of the process was quite a task, but it's been incredibly useful over the years. Having completed it, maintaining it is not difficult or particularly time consuming, so I would agree it's well worth the initial effort. We've been using Virtual Machines for a number of tasks, but one of the areas where I find this technology very useful is testing out the protocols I've documented. I'm a great believer in testing the DR plan. I think testing a plan it's the only way to really know if it's going to work if things do go bang.

Editor's Picks