Thomas Limoncelli - Time Management for System Administrators

But first, let's talk about why we dislike, fear, and generally avoid writing documentation.

We're suspicious of anyone who asks us to document what we do because it sounds like the precursor to being fired. If we document what we do, we can be replaced. Alternatively, the request to have everything documented comes from outside our group, usually from someone who has gotten "ISO 9001 fever" and doesn't realize that documenting processes is a means to an end, not the other way around.

It can be very difficult to start writing a document. "Documentation" summons an intimidating image of a 1,000-page book describing everything we do, how it's done, and how things work. Where the heck would we start if we had to write that?

System administrators are often perfectionists. We could never document everything . Why start a project if it can't be finished? Because of the time it takes to write, documentation often becomes outdated during the writing. Why write something that will be useless the day it is completed?

Besides, there is always a line of people outside our offices requesting that we do urgent things. That's always going to trump documenting. Writing requires long stretches of uninterrupted time. No system administrator has that, right?

Lastly, geeks hate printed documents. Why kill a tree?

This chapter proposes something so different that I hate to call it documentation. Instead, we're going to make an information repository that is accessible, updatable, and useful. Best of all, it will serve our time management needs.

Figure 12-1.

Document What Matters to You

In place of big ol' scary documentation , what do system administrators need? You need repositories to store the information that will help you from a time management perspective. Your boss may have her reasons for wanting you to maintain documentation, but I recommend that your inspiration be something different—selfish. Build documentation repositories that serve you and your time management needs, not the seemingly irrelevant needs of your boss or quality department. Specifically, SAs need two repositories:

Customer-facing repository. Documents that you want users of your network to have access to, such as the policies and procedures they should follow to get service.

Internal IT repository. The info you need internally to help you do your job, such as contact info for vendors, written instructions for tasks, and so on.

The first repository saves you time by making customers more self-sufficient. It deflects them away from bothering you. Why should they call you to ask a question when they could read about it? This way, they will only call you when they need clarification. Many customers prefer the self-help route simply because it saves them from embarrassment when they ask silly questions.

The second repository is useful because you make it useful. In particular, you record all the processes, procedures, and reference materials that you need at your fingertips. It is another opportunity to store something digitally so that it doesn't take up space in your brain. It reduces the work your brain has to do so that you can be more focused. Focus is good.

I suggest two repositories because one needs to be freely accessible by all customers, while the other may contain sensitive information that should be restricted for security reasons.

In these two repositories, you should accumulate:

How customers can request service or get help (possibly a simple decision tree)

A single place to find all your written policies (with links to HR and Legal's equivalent pages)

A list of vendors and their contacts, along with maintenance contact information

A list of procedures of the things you have to do a lot or want someone else to be able to do

A simple network diagram that someone joining your group (or helping out for the day) can use as a reference

You will put this information on a web site with a public area and a private area. To make it easy to start, I'll include a template for each repository. To make it easy to update, I recommend that you use a Wiki. If you're not familiar with Wikis, I describe them in detail in the upcoming section "Wiki Technology." For now, just remember that a Wiki is a web site that is very easy to update.

You can eliminate the fear of the repository never being done by declaring it to be a living document . Rather than something that has to be reprinted every time you make a change, you simply maintain the repository on the intranet. You'll update it any time you need to update it. "Done" doesn't mean it's complete and ready to print, it just means that the initial repository has been birthed and is ready to grow.

The Customer-Facing Repository

The first web site is publicly readable, and it contains IT customer documentation.

When a customer browses to your document repository, the main page should be very simple. Here's a template. Create a home page with the following headings:

How to get help

Include a few ways in a bulleted list. How to request new services

List a few services that someone might need activated and provide a list or link for how she gets started. Some examples might be VPN access and how to request an external web space. Policies

A bulleted list of links to the policies that you do have written, plus links to any equivalent pages for HR or Legal. A single place to find all your written policies

With links to HR and the Legal department's equivalent pages.

This template should be sufficient for any small system administration group that doesn't have a similar web site yet. If you are an IT or CIO organization so large that you laugh at my little template, you probably have a huge home page/web site already and don't need such a template anyway. However, I'm surprised at how many CIO organizations have web sites that are missing at least one of the above items. I also find that large organizations are made up of smaller teams, each of which can benefit from its own repository.

IT policies are the rules by which users of your computers/networks live. These include security policies, service level agreements, acceptable use policies, ethics guidelines, privileged information/access guidelines, and so on. Under IT Policies, link to each written policy that you already have, whether these policies are in HTML, Word, or PDF format. If you don't have any policies, don't include this heading just yet. However, add any of the policies you think you should have to your to do list. If you are looking for inspiration on what policies to add or how to write them, read Chapter 7 (Security) and Chapter 9 (Ethics) of The Practice of System and Network Administration . I recommend starting with an acceptable use policy. If your legal department or HR maintains relevant policies, link to them. If these sections do nothing but highlight what policies you are missing, that's a good thing.

This template is only a start. Over time, you will realize things to add or changes to make.

If you have the time and resources, the next step is to improve this home page so that people will want to set it as their default web page. This will encourage people to go to your web site often and use it when they do need, for example, to refer to an IT policy. Add useful things like a Google search box, stock tickers, or company news. Set it as the default page on any new machine you install.

Internal IT Documentation

The second repository contains internal IT documentation: documents that are useful to you and the people on your team. These documents will contain information that is sensitive, and therefore it should be secured in some manner, possibly just by simple password protection. This repository is often a password-protected area of the other repository.