[SAGE] Unix sys admin "run book" documentation standards and templates

[Bruce Hamilton <bhami@pobox.com>]

My department, which has nearly 20 Unix sys admins running about as many 
distinct administrative domains*, needs to put together some sort of "run 
book" documentation so that any admin can come quickly up to speed in any 
other admin's domain.

We already have a pretty good database with detailed records per server 
giving stuff like OS version, serial#, and lots of detailed hardware 
configuration information. We need to go far beyond that to document how 
various hosts interact, where accounts get added, where and how various 
system databases are maintained, etc.

A cursory search of Google (Web and USENET) doesn't seem to come up with 
much. Surely every major consulting company and large in-house IT shop has 
encountered this problem.

We need standards and templates that are comprehensive but that at the same 
time can be broken into manageable chunks so that a sys admin with an hour 
here or there can produce something useful toward the goal.

Any pointers or discussion would be most welcome. Might this be a good 
topic for a SAGE "Short Topics in System Administration" booklet?

I can get some inspiration from the SAGE Job Descriptions, the Evi Nemeth 
Handbook, or the BOK efforts, but I'm looking for something a lot less 
encyclopedic and more focused, starting with the most important day-to-day 
questions, e.g.:

- Who are the key customers? What are their requirements? Who controls 
their funding?
- How are requests tracked?
- How are new accounts created?
- How are new hosts added? (procuring network drop, creating host table 
and/or DNS entries, ...)
- How are backups performed? Describe offsite procedures, retention, and 
media rotation.
- How are outages scheduled?
- ...

--Bruce (Bruce Hamilton, Redondo Beach, CA)
bhami@pobox.com
http://bhami.com/

*  What would be a better term than "administrative domain" for "the stuff 
one person admins"? It typically would include multiple subnets and may or 
may not correspond to a DNS domain.