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.
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.
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.
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.