To Automate, or Not to Automate, That is the Question

I've been trying to think of the best way to start my new blog, and have decided that as this blog is going to focus on scripting and automation, it would be pertinent to start with a post about whether you should automate a process or not at all! It's a question that I get asked on a daily basis and thought I'd share with you the thought process that everyone should go through before commiting code to a script file.

Can we fix it? A great deal of the time most automation requests I get are to resolve system issues which come up daily but have a known reaction process that is the same response every time. In some cases, this is a perfectly acceptable approach. However, it's worth getting the right people to look at the problem first. I've found that a large number of these requests can actually be resolved first by the right technical guru taking a look (normally, me). It's always best to make the problem go away than trying to automate a work around!

Let's look at the monitoring. If your request for automation has come through due to a recurring alert in a monitoring system, perhaps a good idea would be to look at what it is exactly that you're monitoring, perhaps you're monitoring it too closely, or perhaps the alert is occurring because of another underlying issue (such as performance, or resource contention), or if the alert goes off and there isn't any form of reaction process, should you be monitoring it at all?

Is there a simpler work around? Before we take a look at utilising a run-book automation tool, perhaps take a look at using a scheduled powershell task locally on the server, or using your monitoring system to push a script down to the server to resolve the issue as it occurrs.

If all else fails. Automate it

As you can see, automation shouldn't be the first port of call, but it should definitely be a weapon availble in your armoury.

Over the coming months I plan to share with you my various findings in the world of automation. Mainly within the realms of Powershell, but I may also dive off into SQL, VB.NET, C#.NET, VBS and PERL to show you how to leaverage all of these great languages together to give you powerful (yet easy to use)  tools. Happy reading....