Information Technology Reference
In-Depth Information
Chapter 12. Automation
Progressive improvement beats delayed perfection.
—Mark Twain
Automation is when computers do work for us. The desire for automation historically has
been motivated by three main goals: more precision, more stability, and more speed. Other
factors, such as increased safety, increased capacity, and lower costs are desired side effects
of these three basic goals. As a system administrator, automating the work that needs to be
done should account for the majority of your job. We should not make changes to the sys-
tem; rather, we should instruct the automation to make those changes.
Manual work has a linear payoff. That is, it is performed once and has benefits once. By
comparison, time spent automating has a benefit every time the code is used. The payoff
multiplies the more you use the code.
Making changes to the running system should involve making changes to code and data
files stored in a revision-controlled central repository. Those changes are then picked up by
thesoftwaredeliveryplatform,tested,anddeployedtoproduction.Toworkinthiswaymod-
ern system administrators must be software developers. Ever since installing a new com-
puter became an API call, we have all become programmers. This sort of scripting isn't
heavy computer science and does not require formal training. It leads to learning more and
more software development skills over time ( Rockwood 2013 ). Automation does not put
system administrators out of work. Indeed, there is always more work to be done. System
administrators who can write code are more valuable to an employer. In fact, because sys-
tem administration can scale only through automation, not knowing how to code puts your
career at risk.
However, automation should not be approached as simply developing faster, more pre-
dictable functional replacements for the tasks that people perform. The human-computer
system needs to be viewed as a whole. It is a rare system that can be fully automated. Most
systems experience exceptions that cannot be handled by the automation, but rather need to
be handled by people. However, if the people running the automation have no insight into
how it works, it is much harder for them to figure out how and why it failed, and therefore
handle the exception appropriately, than it would be if they were more involved in the pro-
cess. This situation is common where the person handling the exception is not the person
who wrote the automation. And at some point, that is the situation for all automation.
Search WWH ::




Custom Search