Summary
A document repository can be a great time management tool.
A repository for customers can give them the information they need so they can bother you less.
A repository for internal IT information can help you by creating reference material that saves you time in the future. Checklists can be particularly useful—as are short notes describing how a tricky procedure was successfully done—so that others don't have to reinvent the wheel.
A procedure that is sufficiently documented is easier to delegate to someone else. Thus, we can remove a task from our to do list by giving it to someone else.
Wiki technology removes the entry barrier by making access easy and eliminating the need to learn HTML. By letting anyone edit (nearly) any page, the documents are more likely to be up-to-date.
Creating a document repository for your IT operation does not need to be intimidating. You can control the scope of the repository by choosing what to document. The templates included in this chapter can help you get started. Wiki technology lets a document grow and evolve over time.
It can be intimidating to start a new document. Wiki technology makes it easy to create a new document by handling all the linking for you. The initial document can be a simple checklist that will grow over time. You don't need to feel compelled to create the perfect document right from the start. Create something that is useful right now and let it evolve.
A Personal Information Repository
There is some information I want to take everywhere, but it is more than I can fit in a PDA. Certain information doesn't always need instant access, but some kind of access is valuable. Putting it on the Web makes it accessible nearly everywhere, especially with WiFi access being so common. Setting up a password-protected directory is relatively easy.
There is certain information that I keep in a Subversion repository. Subversion, like CVS or Microsoft SourceSafe, lets one access and update a repository of information from anywhere on the network. It's usually used for storing source code and tracking the changes. In theory, wherever I am, I can either download the latest version of the file repository or SSH to a machine that has access already established. I use my repository to store a very large address book and some other notes.
Chapter 13. Automation
Automating our tasks is a special treat. In what other career can we program machines to do our jobs for us? Oh, if only it were that easy. Automating something takes time, but the payback can be enormous.
This chapter doesn't attempt to teach Perl, Python, Ruby, Unix shell, VBasic, or Kix32. Instead, this chapter is about why we automate, what to automate, and how to automate. I'll also include some shortcuts that have helped me through the years.
Automation has the obvious benefit of reducing work for you because the task becomes quicker to do or—through Unix cron or Windows Scheduler—happens automatically without any intervention at all. An unexpected benefit is that an automated task is easier to delegate. Any task you can foist onto someone else is a special victory.
Is It Automated Enough?
Adam Moskowitz, a well-known SA, tells me that his litmus test for whether something is "automated enough" is that he can delegate the task to someone less skilled. For example, once, he automated his company's disk backups to the point that the company secretary was able to take over the daily tape-changing tasks. Each day, the system would send email to her and Adam with the status of the previous night's backup. Usually, the system would simply output instructions about which tapes to change. If there was a failure, she knew not to touch the system until Adam had fixed the problem. Over time, he was able to modify the software to handle more and more failure cases. Soon the system would go months without requiring his intervention.
In this chapter, I will use the terms script and program to mean different things. Script implies a short program, possibly only a few lines. A script is usually a BAT file, a few lines of Perl, or a small Unix shell file. I'll use the term program when I mean a longer program, one that requires more thought and planning. Programs are usually written with a more formal process that includes requirements gathering, development, and testing. Programs tend to be written in compiled languages like C++ and interpreted languages that are suited to large programs such as Perl, but this is not always the case. Perl programmers, for example, often refer to their code as a Perl script if it is small and a Perl Program if it is large.
Figure 13-1.
What to Automate?
It's difficult to find time to automate processes, so we have to be choosy. We can't automate everything. The problems SAs typically deal with fall into four general categories :
Simple things done once. Category 1 includes most of your daily work. If it is simple and you do it only once, there is no sense in automating it. It would take longer to automate than to do the task.
Hard things done once. Category 2 contains the tasks that are a bit difficult to get right the first time, and by recording the final (working) command into a script, you get a free record of how to do the task next time. If you need to do it once, you'll need to do it again eventually. Things in this category also include multicommand sequences that are best tested one command at a time, building up until you have the entire sequence working. Then you can use the sequence with confidence that it will work.
Simple things done often. Category 3 is the obvious case where automation will pay off with the most impact. The time you invest in automating the procedure will be paid off soon, since the task is one that you perform a lot. Always automate the boring, repetitive stuff.
Hard things done often. Category 4 is where a lot of SAs get stuck because they have bitten off more than they can chew. This is the category where one should look into convincing management to allocate greater resources (time and money) into solving this problem. The result may be the purchase of a commercial product, integration of free and/or open source tools to accomplish the task, or development of an in-house solution.
Now, for the visual thinkers, it may help to see these categories as a chart (Figure 13-1).
Figure 13-1. Categories of SA tasks
People are often surprised to see that I automate simple things done often. If they are simple, why automate at all? I automate a wide variety of processes within Categories 2 and 3, from the biggest tasks to the smallest command lines, for the same reason. Automating tasks gets me repeatability, scalability, and typo-free execution:
Repeatability means I can do something consistently many times. For example, when configuring new machines, I want them all to start out with the same software configuration and preferences. Otherwise, supporting them is going to be a nightmare. If I automate the installation process, then it becomes repeatable, and each machine starts out the same. If I figured out something that works, I want to do it exactly that way every time.