Awesome Conferences

Tools vs. Automation

Sysadmins talk a lot about "automation" but I think a more specific definition is needed.

"Tool writing" is when we create a program (script, whatever) that takes a task that that we do and does it better/faster/more accurately. For example, creating a new account used to take 10 or more manual steps (creating the homedir, setting permissions, adding a line to /etc/passwd, /etc/group, etc). Good examples include: FreeBSD "pw adduser" or Linux "useradd". In short, a tool improves our ability to do a task.

"Automation" is when we create a system that eliminates a task. Continuing with our example, if we "automate" account management we might build a system that polls our HR database and creates an account for any new employee and suspends accounts for anyone terminated. This eliminates our need to create/delete accounts completely.

A conflict arises when sysadmins on a team are used to using tools and someone creates automation. The people that are used to tools create accounts the old way which confuses the automation. It might delete the account because it doesn't see it in the HR database. Or, new features might be added to the automation and therefore might not be communicated to the system administrators. For example, the automation might be extended to create a default WWW homepage for new users; the sysadmins that work around the automation may not be aware of this and the new users they create "on the side" find themselves without the internal home page that other new users receive.

While I encourage the creation of tools to make sysadmins tasks easier, the creation of systems that eliminate tasks is much more important. While automating our tasks often involves creating tools, writing tools does not automate our work.

There's a difference.

Posted by Tom Limoncelli in Ideas

No TrackBacks

TrackBack URL:

2 Comments | Leave a comment

I agree 100% and there is a lot of pain for people that aren't used to programming automation. Often there are a LOT of corner cases that need to be thought through. Also, what I call, for lack of a better term, input/output points must be thought through VERY carefully. These are places where it is most effiecient to separate the human input from the automation.

There are places where the "architect" must interact with the automation, for example writing chef/puppet/cfengine scripts. Or perhaps even better, having tools in place to write out templates for chef/puppet/cfengine with the proper meta data such as wiki text for date created, description, owner, background, project description, ticket number, associated data acquisition and fault monitoring, etc in place so that the automation is created in a consistent way.

I call this the qualitative to quantitative workflow.

I think we need to get away from code craftmanship and get to code manufacturing as soon as possible. While I love the romantic notion of a craftsman, I very much love the consistent production quality of modern manufacturing and I think we need to apply it to our automation ASAP.

Scott M

If you want greater harmony between the two then you need good communication and documentation. Communication tends to be a challenge for introverted, shy computer nerds, but with any luck your automation mimics the tool which mimics the well-documented manual process, and your documentation is sufficiently well-organized and well-maintained that when a team member misses the memo about the new automation and goes back to refer to the fine manual, the documentation tips them off about the new way of doing things ...

Leave a comment