Time Management for System Adminstrators??? Impossible!

by Thomas A. Limoncelli

Related link: http://www.EverythingSysadmin.com



We are just a few days away from the first shipment of O'Reilly's newest book, "Time Management for System Administrators".


When I started writing the book someone told me that time management is impossible for system administrators because we can't define what a system administrator does.


Actually, we can.


In general, I find that everything system administrators do fit somewhere in 4 categories:


  1. Easy things, that happen rarely.
  2. Difficult things, that happen rarely.
  3. Easy things, that happen often.
  4. Difficult things, that happen often.


Category 1 (easy/rare) are things we should do manually.



Category 2 (difficult/rare) are things we should document on our internal wiki. For example, when I replace a bad disk on one of my RAID systems there is a complicated series of steps I must take. It happens rarely enough that I'll never memorize the exact sequence. Therefore, I record it. The next time the issue comes up, I can refer to my notes. It goes after the next time.



Category 3 (easy/often) are things that should be automated. Because they happen often, the time spent creating the automation will pay off quickly. I remember once recognizing that there was going to be a growth of requests to move home directories from one server to another. This is a procedure that requires care and takes a long time, but isn't particularly difficult. By automating the process we improved our ability to move homedirs without error, and saved a lot of time.



Category 4 (difficult/often) is where you want to delegate the task. By using off-the-shelf software (commericial or open source) you get the best of both worlds. Since the code is difficult to write, that 'cost' is divided among all the customers. Since the task is done often, it is worthwhile to automate. For example, we use workdprocessors constantly, and they are difficult to create (after the initial features are done). So we use vi, emacs, OpenOffice, or MS-Word. Backups are another situation. There are so many oddball combinations of hardware and since backups must happen accurately, succesfully, and very often, it doesn't make sense to write our own backup software. That's why we're glad there is Backula, Amanda, and other such packages. We still have work to do (installation, integration, testing, etc.) but certainly not as much as if we were to write these systems from scratch.



Now, as Jon Stewart says on The Daily Show, I'm gonna blow you mind.



Documenting something turns a difficult task into an easy task.



The first part of automating something is to document the steps. Documenting the steps is often the most difficult part. When we can accurately document a procedure, it becomes easy to automate. It crosses over to the easy/often category and now becomes worthwhile to automate.



Documenting a process has another big benefit. Once we document it, we can delegate it. Until I had documented the process for replacing a disk in my RAID system, I was the only person that could do the task. Once it was documented I can ask a junior engineer to do it for me. They can come to me with questions, but the task can be taken "off my plate."



The best time management techniques result in giving the task to someone else.



And it reduces my stress-level too.



System administrators often have a difficult time taking vacations. When we do, it's difficult to de-stress because we're still "on call". You can't relax if you are staying mentally prepared to spring into action and fix a problem. You might as well be back at the office.



However, if I've documented all those processes that "only I know how to do", then other people can do a better job of covering for me. I can go on vacation with confidence.



Finally, I can also feel less stressed because I feel less trapped in my job. Nothing creates more stress for me than feeling trapped. I start getting grumpy, irritable, less productive and less fun to be around.



When I document-as-I-work (particularly easy when I use a wiki), I maintain a good record of how things are done, I can delegate tasks to others easier, and I feel less trapped. I am less grumpy, irritable, more productive and much more fun to be around.



What wiki do you use?


5 Comments

NathanR
2005-11-29 17:49:33
What Wiki?
TWiki all the way. Used an older release in a prev job and just setting up a new site using the Dakar Beta now available. Looking good so far, some great improvements.


Tried MediaWIKI for a while but didn't really gel with it for some reason. Just liked the way TWiki did things in comparison, but thats a purely personal opinion.

TomLimoncelli
2005-12-01 13:04:11
What Wiki?
Yes, I'm a TWiki fan too. I would love to spend some time collaborating with the authors to improve some of the rough-edges. (Anyone reading this want to talk? I'll be at LISA next week.)


Tom

NathanR
2005-12-07 18:55:34
What Wiki?
Just wondering if you've got any notes on how you've structured your wiki deployments. In trying to setup a new internal site for our team, I'm still coming to grips with a way that works. Any info you might have on what's worked for you would be really great to know.


TIA

oReally?
2006-01-12 14:17:00
What about RTFM?
Yeah, I know what you're thinking, and that is _not_ what I'm talking about.


I'm referring to Best Practical's (http://www.bestpractical.com) RT FAQ Manager, a tool that integrates with their "flagship product", RT or Request Tracker.


Sure, you need RT for RTFM to be useful, but RT addresses ticketing or helpdesk support incident management, an issue discussed by The Practice of System and Network Administration (a great book for sysadmins) by Thomas Limoncelli and Christine Hogan. No, I'm not Mr. Limoncelli or Ms. Hogan and I don't personally know either of them! This just happens to be a very decent volume that I keep near-at-hand.

oReally?
2006-01-12 14:28:34
What about RTFM?
Yeah, I know what you're thinking, and that is not what I'm talking about.


I'm referring to Best Practical's (http://www.bestpractical.com) RT FAQ Manager, a tool that integrates with their "flagship product", RT or Request Tracker.


Sure, you need RT for RTFM to be useful, but RT addresses ticketing or helpdesk support incident management, an issue discussed by The Practice of System and Network Administration (a great book for sysadmins) by Thomas Limoncelli and Christine Hogan. No, I'm not Mr. Limoncelli or Ms. Hogan and I don't personally know either of them! This just happens to be a decent volume that I keep near-at-hand.