Where to start with documentation

Where to start with documentation

Everyone knows that to a techie the word “documentation” is a dirty word.  It’s the task on the to-do list that always gets bumped for something more exciting or interesting.  Keeping everything stored in your head isn’t a great idea unfortunately as it not only creates a single point of failure for the IT department, it means that your hit for fixing things when they go wrong and can’t rely on anyone else.
What form? And how much?
Documentation can take many forms, a high level diagram, a detailed document or a spreadsheet with usernames and passwords. Depending on the technology or infrastructure being document each can be relevant.  The key thing to remember is unfortunately documentation cannot absolutely capture everything but it can cover a vast majority of it.
Where to start
I would recommend starting with a high level diagram of how the network and infrastructure is connected. Followed by a lower level diagram on how your network/routing is configured.  If your servers/services are hosted on a cloud platform these kind of diagrams are especially crucial for troubleshooting purposes or for new staff coming into the department.
For any physical kit that is onsite a rack diagram is a helpful thing to have in your document library. I’m a big fan of actual photos of racks and comms rooms, they are always a good memory refresher if you aren’t in the same location as them. These kind of reference points are handy when you need to understand if they are any constraints on adding or removing kit from the rack.
A general overview document of what servers, services, storage platforms, backup software, virtual infrastructure, development environments, etc are located within your infrastructure is a good starting point for your written documentation.   This document doesn’t need to great detail on everything but should detail everything that is within the environment, so it’s a go to reference point for anyone who wants to understand what the environment looks like.
Detailed documents should be produced on things like backup strategies, disaster recovery plans, Active Directory implementation etc.
Nice to haves
Operation guides are also things you should try and add to your document library.  These guides can be used for things like, how to change tapes in your backup server, how to restore files, how to access servers, how to create a new user.  These kind of documents can help to spread some tasks out amongst the department instead of them being solely your responsibility.
Summary
The above is not a complete list of things that you should document but it should hopefully give you a good starting point.