The virtue of laziness
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:
Use aliases for common commands
If you regularly do something like this:
alias cdwb="cd /apps/IBM/WebSphere/AppServer/bin"
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 keystrokes.
shut down and startup scripts
If you gracefully shut down an LPAR, the shutdown 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.
TCA – 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."