This one is a bit text heavy, and is in advance of some of my upcoming VMUG visits. It should hopefully cover some content that one cannot fit into an hour session, that is demo heavy on Orchestrator.
Process is Good
Do you have an “operations manual”? One of those big dusty D ring binders, etc? Maybe it’s a wiki, or heck, even a notepad file. Maybe it’s a series of checklists. Whatever it is and where ever it is, chances are you have something, and it’s a good idea. Process makes manual repeatable, and starts to build the guidelines around which you can automate things.
Automation is Good
I think we can all agree on this point. Any time you spend not doing a mundane thing, you can spend doing awesome things. Also, frankly, following a runbook is boring… at least for me. I’m pretty sure you have a never ending list of projects and improvements and the like. Finding time for them is hard… if you could just get away from the runbook…
So, automation is good, it will take the repetitive processes, and give them to machines who can do it, while you sleep.
Shoveling *hit
Now that we understand these two things are good, sort of like chocolate and peanut butter, why not stick them together? Sure! That is indeed what I am advocating. However, think about that carefully, because, if either the automation or the process is carp (yes you read that wrong, but that’s the point)… instead of just shoveling *ish, you have a machine that distributes *ish automatically.. Why?
Not all processes are made equal
Let’s face it. Some of these processes were written by folks who are either no longer in the role, or have made the journey from employee to customer. They’re old, not updated for modern systems and tools.
Even if they are recent processes, perhaps they were not written with automation in mind. When HR has a new hire, and they fill out the application, on paper. That in turn gets keyed into some system somewhere, that may or may not email your group to create all their various accounts, VDI assignments, etc.
Not all steps are followed in order
Like the case of the Roomba above, the steps should have been:
- Walk dog
- Run Roomba
A process done by hand can account for this, as can an automated process. However, if it’s not in your runbook, and you account for it manually as part of due course, you will likely not have a good time.
Take Away…
Outside of my rambling, inconsistent analogies, the take aways here, are:
- When working in a “brown field” or pre-existing environment, before tackling an automation project, revisit each process, and ensure you have walked it by hand, and know it’s pretty robust.
- Ensure you are using modern methods and tools. Update the process to modern standards first, then automate it. See Roomba example
- Automate ALL the things… carefully.