Don't start automating it until it's documented.

Before you can script a thing you have to understand the steps to complete the task.  You should also have some level of consensus with your team about the tasks that need to be undertaken to complete it.  Ultimately the process should be documented to a point where you can hand the document to novice and they can make it work.  However, documenting to this level is often not cost or time effective. That doesn't mean it's not a great goal.  You need to be pragmatic and document enough to fully understand what needs to be done.  

Documenting your processes helps verify that you know everything that must be automated.  The document is the automation just in a different language.  Having someone review your documentation and execute it in a virtual environment is really your first level of functional testing.  A second set of eyes will often finds little things you do so automatically you don't need to think about them.  This can be a serious issue if that thing you do as a reflex manually is skipped in the automated form.  If you don't do step b, and slip straight to step c you can get what looks like a successful run but really just failed silently.  

Once you are done it also helps you to answer questions like:  Should we be taking advantage of any silent installers?  Could we do this with a simple shell script or do we need something with more power?  How many steps are there?  Can anyone write this or does it need to be a specialist?

This gives you an understand of the complexity of the process.  That will then help you direct the automation responsibility to the correct resource.  If only one person on the team has ever done anything with a certain piece of software assigning it to someone to script it will likely fail.  Asking a new Admin to write something to determine the available free space on a system will help then to grow.  While asking a Senior Admin to do the same task will likely be bore them.  Senior Admin's often try to cover all the things that could go wrong.  This can lead to unneeded complexity.  So when just covering the bases will handle ninety percent of the possible issues they shoot for the one hundred percent goal. Possibly leaving you with a seven hundred line script that should have been done in one hundred.  (Yeah that is personal experience talking.)  So never underestimate the value of being a novice.  If you don't know it can be done you probably won't try to do it.

This all points back to another of my principles in system administration.  Plan your work and work your plan.  When you don't have a plan it takes at least twice as long and produces results normally half as good.  Your documents like your plans should be short and to the point.  You should plan for expansion when you need to.  Don't be afraid that you will miss something.  Count on it.  


Remember the only way to fail at DevOps is not to do DevOps.