On Automation March 15, 2014
System automation seems to be a term that lacks a proper definition. Due to this deficit, I tend to think of it as the repeatable application of learned knowledge.
Humans have been outfitted with a duplex mind, deliberate and automatic, with each mind performing their own specialized cognitive abilities. With our deliberate mind, we are processing conscience thoughts with the object of interest being actively manipulated within our focus. The automatic mind handles works out side of our conscience performing simple operations. These two systems work in tandem as a once deliberate object may move to the automatic mind as expected outcomes become predictable. As our knowledge of something, increases it allows us to progress deliberate thought to automatic thinking. Much of this automatic thinking takes the form of mental heuristics , or shortcuts, that allows us to quickly evaluate and make decisions based on predictable input and expected outcomes.
It is important to note that we formulate mental heuristics though case history and not statistical information.
Much of system automation follows this same flow as our knowledge of the system allows administrators/engineers to make tedious repeatable tasks automated in order for producing predictable outcomes. Of the common mental heuristics, I find that representativeness to be the most applicable to system automation as the goal is applying what would be considered the most typical case -- similiar end state.
Mental heuristics are shortcuts for a reason: reliability of accuracy in predicting outcomes are high. While this is true, there are of course cases in which errors are made: input changes, expected output changes and in precise calculations.
Common issues with heuristics:
- Our environment changes as so does the data
- Limits our solutions to the known and blocks seeking alternatives
- Formation of cognitive biases -- good list
Like our daily lives, our automatic thinking must be iterated upon as input data as well as expected outputs change. System automation thus will fail as complexity changes. The need for quick iteration is required and the errors identified as early as possible in the pipeline. Many of the errors in system automation are preventable using tests and the comparison of system automation results to these tests. I would argue that system automation requires the same thorough tests that most developers now implement in their software projects. System automation should then be treated as code (infrastructure as code) and the same principals applied.
Questions/Comments/Priases can be sent to me at joe@unicornclouds.com