Automating Ourselves Out Of A Job
Due to my previous experience in DevOps, I sometime get dragged into conversations on “automating ourselves out of a job”. This blog post will highlight my opinions on this subject.
Why?
When I observe a company discuss DevOps and automation for the first time. It usually starts off with a business leader excitedly claim that “insert peer company name” was able to solve some outage from hours to minutes due to automation. Or they claim a fault was resolved at “insert peer company” without human intervention.
After hearing all of these stories, I conclude there are three common business drivers for the adoption of DevOps and automation:
- Shorter time to market
- Shorter resolution time for faults
- Reduction in OPEX due to lower human intervention
What?
When I discuss with my peers about DevOps and automation I like to describe it as having two work forces. There is a human resource and a robot resource. I will outline the positive characteristics of the robot resource over a human resource below:
- Never gets tired or bored from performing its task
- Always accurate and precise with its execution
- Never deviates from the plan
- Doesn’t resist rolling back even near the end of a change
- Can be replicated and scaled out
Analysing these characteristics, a robot resource is perfect for repetitive and predictable tasks. Freeing up the human resource to concentrate on new and complex activities. These new activities should bring greater value to the company then just churning out day to day operations. Eventually these new activities should be iterated enough that they become predictable and the robot can take over. I like to sum this up with the following motto “human logic, machine execution”.
Therefore as a human resource, should you be worried? Well, if you spend most of your time being a proxy or copying and pasting, you should be. If you are a human resource that challenges the norm every day, then there is a chance of survival after you evolve.
How?
So how can a human resource prepare for this evolution? I believe the following three skills areas will build a solid foundation for the future:
Linux
Most jump hosts are based on Linux. Linux has an array of powerful tools to parse and process large outputs from networking devices. I believe the best way to learn is to obtain a certification such as RHCSA/RHCE. The study guide below is a good resource.
Programming language preferably Python
Python is currently the most popular language and usually supported on EMS (Element Management System) and network devices. There are great courses or books out there, such as:
- Learn Python The Hard Way (use to be free)
- An Introduction to Interactive Programming in Python (use to be free)
Virtualisation
Virtualisation will allow you to set up a virtual lab so you can practise and learn. Nowadays most network devices have a VNF (Virtual Network Function) equivalent. In addition, this will increase your skills around virtualisation and build a path to understanding current industry trends such as cloud/containers.
BONUS TIME
Another interesting question I get asked is, where do I start? I believe the best starting point, is to automate opening support request to a vendor. Currently, this might be performed via email or web portal. Python can be leveraged to automate this process and abstract basic node information from a database or EMS. Let’s name this new tool “Case Opener”.
After a few cases, we can enhance this by creating another tool via Python called “Command Executor”. This tool can collect common support commands and attach it to the service request. Therefore, the program “Case Opener” will open a service request, call the tool “Command Executor” to collect the outputs and attach it to the request.
Finally, imagine we have a network event that triggers an internal support ticket via syslog or snmp. It contains a well know error message that can only be solved via a RMA (Return Material Authorisation). If we setup our internal support ticket to trigger “Case Opener” to open a service request, call “Command Executor” to collect the required outputs. Then the vendor will receive a populated service request with the correct information and ship the replacement to site.
As each task and process become automated in the above scenario, the more time we are freeing for the human resource to do new and exciting things. Eventually, every network event will have a corresponding automated response. At this stage, the human can start exploring at building a network that can predict and self heal from network events.