Is "automate everything" the best approach?
As innovation escalates, the push towards universal automation is not far behind. While most organizations say they want to implement automation, there is an increasing number of questions surrounding what total automation might look or feel like, and even whether this is the best approach to take. What are the building blocks to automation? At what level should humans be involved? Where should teams begin when they’re ready to reduce manual toil?
Transposit’s CTO, Tina Huang, digs deep into these pressing questions, giving her perspective on the often touted "automate everything" approach. She shares insights on the role of humans in automation, how we can elevate the unique skills of both people and machines, and what it takes to develop a smooth intersection between humans, data, machines, and automation within DevOps and beyond.
Q: What do you at Transposit do at the intersection of humans, automation, data, and machine learning?
“We took this interesting human-in-the-loop approach to collecting data. How can we collect data in a way that includes both the human side of the process as well as the automated and machine side of the proces, with this intention of how can we then allow machines to improve and derive insights so that your organization can get better over time?”
Q: What are the building blocks to automation?
“Customers often say, ‘We want full automation. When an incident happens, we want the incident to automatically resolve without any sort of human intervention.’ And while this is the dream that we all hope to get to, we know that the majority of organizations don't even know where to start for automation. So what we have them do is begin by just codifying human processes, write it down, write down that checklist of what you want a person to do through our runbooks, and this then can act as a building block for automation.”
Q: What involvement should humans have in automation?
“You can only fully automate a system that you completely understand and is fully predictable. So, in the particular class of problems that Transposit plays in (incidents)...active development creates new system interactions that inevitably have unpredictable behavior. In those cases, the ability to fully automate without any human involvement is infeasible—because you don’t yet know or can’t have anticipated that that interaction would happen."
Q: Why is there a fear of automation?
"A lot of that is rooted in the fact that the more complex your automation is, the more intimidating it is to de-bug it when the automation doesn't work out as planned. So there's this fundamental trade-off that you have to think about between the fragility that you might introduce by trying to fully automate something versus just doing the bare bones and letting the human be effectively that glue between these different pieces. Humans have the ability to evolve with product changes at a speed that's significantly faster than you can code and evolve the automations themselves. And so I think a good way of thinking of it is to focus on automating the parts that give you 80% of the win, and then that human judgment steps in to do the other 20%"
Q: What pieces of the DevOps lifecycle should be automated?
“We hear from customers that their biggest struggle is: 'How do I start to institute a real incident lifecycle process? How do I make sure that an explicit commander is assigned to an incident? How can I start automating the pieces for auditing and tracking?' It really boils down to a few things. One is, 'How do I bring in the right people to the incident?' And that's an area that over time, as we're tracking what you do, we can easily give you suggestions that tell you, 'These are the services that you might want to escalate to based on a given alert.' Or other pieces around, 'How do I know what to do when I get an alert?' Transposit can help optimize getting that person to the right runbook and processes they need to get started.”