The virtue of
When is a
repetitive task worth automating? Basically, when it gets time-consuming to the point of being annoying and boring. You know it's time to automate when you can't
remember what a weekend is. If necessity is the mother of invention,
then automation also has a mum: laziness.
more trouble than it's worth?
Of course you can go overboard with automating. I
have heard it said that if you do any task twice, you ought to script
it. I think that's a little obsessive. It doesn't take into account
the overhead in:
- writing the script
- debugging it
- deploying it
- maintaining it when the environment changes
- version control
- cleaning up after it
- retiring it
That last one is important when you
think of the number of “legacy” systems that are out there. They
can't be upgraded or migrated to a virtualised system because nobody quite knows what they do, how they
do it, why they do it or what will happen if they stop doing it. They
are called “legacy” systems, but they're not really legacy until
they can be turned off without any business impact.
Cost of Leaving Everything Running Manually) and BAU (Boring as Usual)
So when do you automate and when do you keep doing those key strokes and mouse clicks you're used to doing? I think you have to balance the time and effort
required to 1) automate a process; with 2) doing it manually. If you prefer to avoid tasks which are BAU (boring, as usual), then it's worth investing some time in letting the system do the work.
Once you start to think of shortcuts for automating your
daily tasks, it can be a huge time-saver. Here are just two examples which I use
in the AIX space:
for common commands
If you regularly do something like
then it's probably worth using an alias called from your .profile:
(More details in Sys
Admin: Get the most out of bash; also see CDPATH variable).
There are plenty of commands
which are run the same each day, and a short script or an alias is
usually a tiny investment to save your fingers millions of
and startup scripts
If you gracefully shut down an LPAR,
command first executes a file called /etc/rc.shutdown,
if it exists. That file is a good place to put in scripts to shut
down your application or database. Then if you have to step the boss
through shutting down a system before the ship goes down all he needs
to know is to run shutdown. It can even be done through the HMC or IVM.
When starting up an LPAR, you can
automate the startup of services, such as database engines, app
servers and many more. This can be called through entries in
/etc/inittab which, among
many other things, calls scripts in /etc/rc.
Remember your dependencies! For example, you may need to stop LPARs in this order:
- app server LPARs
- database LPARs
- VIO servers
When you start the LPARs again, you'll do it in reverse order (VIO servers, databases, app servers).
Always test the process regularly,
especially the order of shutting down and starting up, because
there is the
Downside of Uptime for systems that have not been rebooted for a long time.
– Total Cost of Automation
If you consider the total cost in time
of having to co-ordinate people from several teams to do a task which
could be handled by a single script, you wonder why people prefer to
take the long way. Sometimes it's easier to do things
manually, I suppose. If it takes you two minutes to save someone's number to
your latest i-gadget, use a pen (if you're under 30, click
here). But usually I'm on the lookout for ways to automate,
neatly and simply.
When it comes to running tasks that take a long time to
run or happen frequently enough to be an annoyance, I avoid doing it
manually “just this once.” I follow the warning given to people
battling addictions: "one is too many, a thousand not enough."