When I first became a DBA, one of the first things I did was create a DBA "run book" that contained detailed information about every SQL Server that I was under my realm of responsibility. I can't tell you the source reference for this idea off hand, but I will admit, that the idea of creating a run book wasn't my own, I read about it online (to be honest, I am pretty sure it was a SQL Server Central article or forums post). For the last three years I have made a point to review this document quarterly and make updates to it to reflect ongoing changes to my environment. My intention in doing this was to make sure that a smooth and rapid transition was possible in the event that I was called to Active Duty by the Army Reserves.
However, until recently I didn't quite realize the importance of such a document until I had to sit down in a meeting to plan the hand off of responsibility from myself to another DBA of my companies production environment as a part of my mobilization with the Army. It turned out that every question that my management staff could ask was covered in my run book already which meant two things. First it meant that there was a quick reference for while I am going to be gone that covers each server, what it is for, how it is backed up, who to contact in case there is a problem with the server, and any special circumstances related to the particular server like SOX Audited databases. Second, it further demonstrated my value and worth to the company as a DBA.
So what exactly should a "run book" cover? Well I basically hit it in the last paragraph. For each server in your environment, the "run book" should have a section that covers, the applications/databases supported by the server, who the interested parties are for each application/database with their contact information, the backup methodology for the server/databases on the server, the servers hardware and software configurations, and any special circumstances related to the server/databases on the server like SOX Auditing . I include some basic information in a few Appendix's that cover environment specific information like how backups are performed, maintained, and the fastest way to recovery in the event a restore from backup is required, and how to create a new SQL Server in the environment following established and approved configuration practices. If you use a third party tool like Netbackup for backups to a common device this kind of thing is important to document. In addition to this standardized information, I also included a section with code examples on how to troubleshoot common problems in SQL Server since my primary backup DBA is not a SQL Server DBA but instead an Oracle DBA (one thing I've learned is that we do the same job fundamentally, we just have different ways on performing the tasks).
So what exactly did it cost me to make this kind of documentation? About 2 days of time for an environment of approximately 30 SQL Severs up front, and the around a 1/2 a day every quarter to review it and make necessary changes to update the documentation to bring it current. This cost in time is minimal compared to the time it would have taken for me to explain my environment to someone new in the event that I was activated by the Army Reserves like recently happened. In addition, my management staff could provide the documentation to almost anyone and they would be able to be up to speed on the environment within a few days time.