Skynet is coming…


“Why process automation isn’t always a good thing.”

I’m *GOOD* at scripting and automation.  This is not to say I’m the best there is, I think I worked with him about 10 years ago in California…  I learned most of what I know about BASH from him.

There are some WONDERFUL uses for shell scripting.  Automating mind-searingly simple and repetitive processes.  Providing a little extra functionality and error-checking into a process or to augment the output of a program that probably could have been written better.

And yes, automating a complex task can save you HOURS in the long run.  (Though more often than not, you’re going to spend more time writing and debugging the script than you would have simply executing the commands manually.)

The best reason to do it is, for me at least, it’s fun.

Three Laws

  • A robot may not injure a human being or, through inaction, allow a human being to come to harm.
  • A robot must obey orders given it by human beings except where such orders would conflict with the First Law.
  • A robot must protect its own existence as long as such protection does not conflict with the First or Second Law.

Ok, maybe fun isn’t the right word.  But when you can do with one simple command and a few arguments what would take you 14 different commands and a legal pad to do, it’s…an elegant solution to a convoluted problem.

The downside to process automation is that a script is only as good as the guy who wrote it, and in the absence of the guy who wrote it, it’s only as good as the guy running it.

When you write a script to do an advanced function, you can only plan ahead so far before something comes back to bite you.  Maybe you grep out the number 2140 and then a month later run into a situation where the output is going to include the number 52140.  (Hint always include surrounding spaces in an awk statement, or for beginning of line use “^” to ensure nothing precedes the value you’re looking for)

This is where it gets tricky, and where scripting isn’t always a good idea.

A script is never, EVER a replacement for actually knowing how to do the job.


“DARPA is apparently investing $20-million in a project to come up with bi-pedal combat robots that can be operated remotely or automatically.–Apparently the finest minds in the US Military have yet to learn ANYTHING from the finest minds in Hollywood.”

Here’s a real-world example:

I just wrapped up month 10 of a 12 month contract planning and implementing a datacenter move.  The move won’t be complete until LONG after I’m gone…  (It’s a slow, one at a time process)

So they commission a scripted move and I supply it for them.  Some beautiful scripts.  (In my opinion)

One set creates the SRDF pairing based on the source/target storage groups, choosing next available RDF Group, pairing up boot/luns, etc, and deletes them.

Another set to do the graceful SRDF/A Establish/Split, checking/changing modes, etc. (Made available to the end users)

Simple processes, right?

It is…To anyone who knows how to do it manually.

Here’s the catch – When we first started this process the proper disclaimers were made.  EMC will not support these scripts, they’re only temporary.  EMC’s official stance is they won’t support *ANY* scripts that don’t come out of the Cork, Ireland scripting team.  I don’t blame them.  They can’t be responsible for every Tom, Dick or…well…Jesse’s scripting, especially custom scripts that only apply to ONE environment.

Disclaimers were made to management, agreed to, settled.  Right?

Oops.  New management team comes in not even two months later.  One *MORE* month goes by and the Senior EMC guy leaves for another opportunity.

The new Management are very good people and seem to have a good understanding of what’s what, and all is fine.

Until I’m having a conversation with the new boss tonight and remind him that these scripts aren’t supported by EMC and as him if there is anyone on the Linux team I can sit down with and cross train to take over the scripts?

Blank Stare.  Um… not only isn’t there anyone *ON* the linux team…there really isn’t a “Linux Team” per se.  (I figured that despite it being primarily a windows shop there had to be SOMEONE there who knew Linux.  (There was, see the part about the Senior EMC guy leaving…)

So I’m hip deep in editing my scripts.  I shall comment EVERY. SINGLE. LINE. so that if something breaks, they at least have a fighting chance.

Scripting is a wonderful thing when the scripts are used to automate processes using knowledge that your storage team already has.  When it’s used to REPLACE knowledge your storage team should have…well that’s a problem.

Don’t automate a process you don’t know how to do from memory.

Leave a Reply

Your email address will not be published.