Automation is a Process
ACM has a nice article on “soft skills” for Systems Administrators. I’m digging on their advice for automation:
Automation saves time both by getting tasks done more quickly and by ensuring consistency, thus reducing support calls.
Start with a script that outputs the commands that would do the task. The SA can review the commands for correctness, edit them for special cases, and then paste them to the command line. Writing such scripts is usually easier than automating the entire process and can be a stepping stone to further automation of the process.
A simple script that assists with the common case may be more valuable than a large system that automates every possible aspect of a task. Automate the 80 percent that is easy and save the special cases for the next version. Document which cases require manual handling, and what needs to be done.
There have been times in my career when I have felt that people look at automation as a one-off task. “Write a script to automate this task.” Other times I have been asked how I go about automating things, and my answer is that automation isn’t a task so much as an iterative process:
- I try to do the task at least once, maybe a few times.
- Along the way I document what I had to do to get the job done.
- From there, I follow the documentation, and refine edge cases as I go.
- After that I’ll write a script, and get it working. (do)
- I revise the documentation to explain how to use the script. (document)
- And then, I use the script to complete requests, fixing the script when it fails. (refine)
Often enough I have been called upon to help another group automate something. That is a little trickier because I may never get the chance to do the task. Hopefully the other group has written some documentation, otherwise I’ll have to tease it out of them. The whole refinement process is the most obviously collaborative. I’ll document “use the script . . . it should do this . . . if it does something else, send me details.”
There is also the question of what-is-worth-automating. I believe it is the “Practice of System and Network Administration” which breaks tasks in to four buckets: frequent-easy, frequent-difficult, infrequent-easy, infrequent-difficult. You get the most payoff by focusing your automation on the frequent tasks. Easier tasks are generally easier to automate, so go ahead and start there, then turn your focus on the frequent-yet-difficult tasks. If you regard automation as an iterative process, then infrequent tasks are that much harder to automate. This is doubly true when the task is sufficiently infrequent that the systems have a chance to evolve between task execution. Infrequent tasks tend to be adequately served by well-maintained documentation in lieu of an automated process.
A last note for infrequent tasks. Part of the difficulty for these can be a combination of remembering to do them, and finding the correct documentation. One approach to “automating” an infrequent task would be to write a script that files a request to complete the task. This request should of course include a pointer to the documentation. For example, I have a cron job which sends me an e-mail to complete a monthly off-site backup for my personal web site. The e-mail contains the list of commands I need to run. (And yes, the daily local database backups are executed automatically.)
