Ansible Automation in the Culture of Fear

We all know the scenario: Management at organizations naturally, either consciously or subconsciously, promotes a culture of fear when it comes to changes or upgrades to the network infrastructure. The network is functioning the way it is supposed to and any changes to the procedures are frowned upon or outright rejected.

The upkeep and administration of these networks gets more complicated in attempts to keep things updated, secure and running smoothly. How do you get the version of OS images running on all your routers, switches, servers? Let us pretend you have 100 devices, 1000 devices or beyond. 

The answer is simple: an Automation package.

Automation is coming; the convenience and rewards are too numerous to ignore. There is too much to do and too few people to perform the tasks. With the large quantity of IoT devices going into an organization’s network by the day, just by sheer number it’s an equation that can’t be fixed by dumping additional precious resources on the problem. 

That’s how it was at a company I worked for, but how can the seeds of automation for the network be brought into a culture that demands the network not be touched?

Answer: We need to start at the bottom, leaving management to their beliefs and procedures. Start to work on a plan to show everyone that not only will network automation be safe, but a shrewd business decision when it comes to time saved.

Where I worked, I had to solicit the help of a few junior, but eager, IT personnel. I was always asking them what versions and types of network switches were on the network. To get an accurate count and statistics, they needed to log in to every switch, router and server, to get the OS versions and machine types. It was a boring and tedious procedure, a waste of precious time. 

They needed to open their spreadsheets listing all the IP addresses, usernames and passwords. Then, when the usernames and passwords differed from someone else’s spreadsheets, they had to coordinate the discrepancies. From their desktop, they needed to log in to all the switches, routers and servers issuing the appropriate commands.

So I told them there is a better way; we can test automation in a safe way that doesn’t configure anything and has no chance of breaking the network. We set aside an afternoon to set up Ansible, an open-source IT automation tool that works magic with all of the major (and minor) brands of network equipment and server operating systems.

As part of our test, only read-only operations were performed, to assure there would be no changes to the network.

We created an Ansible Playbook and an appropriate hosts file from the many Excel spreadsheets that held the information. The hosts file became our one accurate source of devices and login information.

When we ran the Playbook to get the OS version numbers of all the network devices running in the network, it finished in 30 seconds. The IT people ran the test again, apparently thinking there was alchemy involved, then a third time. Finally all the network devices where checked by hand to confirm there were no mistakes.

Our next step was to check the units for NTP configurations, which tuned up some routers with old NTP server addresses. The success snowballed from there: It caught the attention of the lead IT manager, then the service department starting using Ansible for their routine test procedures that were still running TCL scripts. The service department realized that changes to the TCL scripts that had taken hours could be accomplished in minutes with the Ansible setup.

Finally, it was time to document and create a presentation to the upper managers for a Lunch and Learn. In the presentation we filled our audience with more than half of the converts to the Ansible automation methods we had been testing. Any questions or comments that came from the powers-that-be were easily answered with real-world examples performed inside the company over the last few weeks.

With time savings and a central repository of information pertaining to the network, there was no longer any need to navigate the labyrinth of people and spreadsheets to find the latest login information. That in itself saved an enormous amount of time and effort.

Now that we had management’s attention, we had to explain the importance of why RESTful APIs in our devices made sense...but that is another story of subversion and manipulation for another time.