One fact of life with the sysadmin lifestyle is that most issues are task and event driven rather than project driven. For me, over the last 6 months, the split has been about 80% issue driven and 20% project driven. And most tasks tend to be short, event or incident driven. Short in this case might be 10 minute tasks or even 3 day long tasks, but not the sort of things one would handle in project scenarios : 3 to 4 month long tasks, split into multiple sprints.

With such a high rate of churn in the ToDo lists, one tends to often overlook the automate angle in return for short term win. On the other hand, its also easy to slip into a state where over aggressive automation leads to a case of seriously low on-the-day productivity. The way I've tried to get pragmatic about this is to adopt a policy of automating at the second instance, monitoring at the first.

So short tasks are fine to execute manually the first time they come up - but ensure there is monitoring around it. The second time a task is repeated, automate if possible. And if the same or similar issue comes up a third time, and its still not automated - reconsider the task. Either break it up into smaller chunks so it can be automated or reconsider what and how you are doing. Its only in exceptional corner cases that you will find automation fail, even for repeated tasks.

In highly repetitive environments, using a config and change management system should never be optional. Not only does one get a large portion of the admin-task automation win, but you also get an audit trail, state reproducibility and speed in deployment.

- KB