Introducing your friends to automation (and overcoming their fear)

I have been met with several different reactions when the topic of automation comes up. Believe it or not, I have seen firsthand a high number of teams not considering automation when developing a solution for new services, implementations, or deployments. The purpose of this article is to provide an outline to help you introduce friends or teammates to automation and how to overcome their fears related to the practice.

In today’s technology trends, and with the tools available, everyone that is in IT can benefit from removing manual tasks. Hopefully, by the end of this article, everyone can understand and relate to the perks of automation, whether your team is in infrastructure operations, quality assurance, security compliance, or development, and completely independent of whether your focus is on-prem or in the cloud.

The definition of automation as explained at www.dictionary.com is:

The technique, method, or system of operating or controlling a process by highly automatic means, as by electronic devices, reducing human intervention to a minimum.
A mechanical device, operated electronically, that functions automatically, without continuous input from an operator.

This "method of controlling" a process can be leveraged by all of the technology players described earlier, and in all of the processes we are familiar with, like CI/CD, smoke testing, and even configuration management.

Fears

It helps to understand what fears people have when automation comes up, and how to address them. Here are some of the most common fears.

Job security

My team and I were in a meeting a little while back with a third party vendor when they asked us what our stance was on automation. My reply was, "We want to automate everything." On top of my reply, my teammates added, "Well, we don’t want to automate ourselves out of a job."

This issue may be one of the biggest fears and misnomers of automation in the tech industry. Oddly enough, when I looked up "automate" at www.thesaurus.com, the response I received seems to encourage the fear that automation is anti-human:

However, in reality, humans are needed to build and code the systems of operating a process. Even after the process is defined, it needs constant testing and maintenance when enhancements are needed.

Programming is hard

Another fear that I face often from friends is that they don’t know any programming languages, and they believe that if they don’t know how to code, then they can’t do automation. While I think we can all agree that knowing Bash, Python, Perl, or even PowerShell is useful when defining these processes to reduce human interaction, it is not always needed.

Today we have the tools at our disposal to implement such processes without the absolute need to know a traditional programming language. For example, tools like Red Hat Ansible Automation Platform and Azure DevOps let us take advantage of already created playbooks or plugins. Rarely do we see where one tool fits all, but just getting started with one tool is sometimes enough to get a feel for automation. In turn, that beginning is enough to gain confidence and see the true benefits of automating, which encourages us just enough to try learning something new.

Errors and outages

There are also some more urgent fears when developing methods that run without continuous input from an operator. I once pulled an all-nighter after we had a widespread outage, due to a script someone ran that was only supposed to compile data regarding inventory. One part of the script was supposed to only make a list of all hosts in production but instead changed the hostname on a large number of servers, because the hostname flags had different outcomes depending on the server’s OS.

So, in the case of this fear, the solution to the problem is how we overcome the obstacle. The key to successful automation is extensive testing and monitoring. For every step or task that is automated, there should be a test and response captured to ensure the automation will not go forward without the expected successful response, as well as monitoring the task with at least a pass/fail notification.

Benefits

Now that we have exposed some of the fears of automation and pulled them out into the light, in my experience, nothing overcomes the objections like experiencing the benefits. Let’s take a look at the areas where automation really shines.

Repetitive solutions

When first introducing a friend or teammate to automation, it is important to start simple and small. Identify a manual process that can be easily implemented. Coming from a sysadmin background, a couple of processes that come to mind would be things like building out a new server or application restarts.

I remember a while back, the on-call on my old team would get called almost once a week to restart a legacy application, because the Java JVM’s memory would run out of memory. Of course, we would always see the famous OOM in the logs, so we finally wrote a small plugin for our Nagios monitor to alert when the memory hit a high threshold, and we also wrote a small script to restart the app automatically. Along with the restart script, we had error handling and monitoring to ensure the app restarted correctly.

Obviously, there should have been an opportunity to take other proactive measures, but this specific app was sort of hands-off with respect to addressing the root cause, with the exception of restarting when needed. By finding these easy-to-implement candidates we remove the need for manual intervention, and the chance of accidental "accidents," but also free up time to work on other types of work.

Monitoring

As a sysadmin, one of the most proactive opportunities we have is monitoring and alerting. We can never have enough monitoring, and there will always be tweaks to our alerting strategy. When we automate our monitoring and alerting methods, we are satisfied knowing that our environment is always being watched. Eventually, we become comfortable enough that we can automate the resolution of the problems as opposed to just receiving alerts on them.

My story here is: We had an application that was a front-end for a third party vendor that would send us data. We would take that data and update our database, which was used by on-site agents. Our application logged the connection status from the vendor who had a history of going offline. When our agents would not get updated data, they were forced to write out tickets manually instead of using the onsite tool.

We wrote a simple Python module for our Nagios monitor that checked the logs for a loss of connection. The logic in this automation would see the connection loss and then fire an email to the vendor, advising that they may want to check the connection on their end, as well as give our on-site agents a heads up that there is an issue. This boosted our agents’ confidence in us, now that we could see there was a problem before they had to let us know.

Again, the benefit here is that now with this level of automation, it removes our need to have eyes on glass, thus freeing up more time to focus on higher priority issues.

Future employment

The final beneficial reason to introduce your friends to automation is that having experience with automation makes you attractive to employers looking for a sysadmin. If you do a search for any title in the field of system administration you will see that automation is a top skill being recruited. Going away are the days of having a role that is siloed to one specific job. Today’s employers are looking for a well-rounded sysadmin that can play an integral part in the whole IT organization. More job titles like DevOps engineer and site reliability engineer are popping up that require heavy automation skills.

Wrapping up

Hopefully, at this point in the article, you have some pointers and confidence on how to introduce your friends to automation, and how to address any fears that they might have. All in all, my best suggestion when introducing anyone to automation (or even considering when it is an option) is to weigh out a couple of possibilities. Will this task need to be run more than once, and how often? How long will it take to develop a custom solution as opposed to manually performing the task? Armed with these answers, you can be confident knowing that when you introduce your friends or teammates to automation, you are setting them up for success.