Google's SRE book changed my career, although I know it's a little out of date now, it's well worth reading for the concepts involved, IMO.
This though:
> With DevOps, if you can automate it, you should automate it.
Everyone at some level in this field understands this. I would even go farther and say that almost everything is automatable depending on how much effort you're willing to put into it. However, lots of bad or overwhelmed devops shops I've consulted seem to be stuck in this insane hell-loop of manual processes not ever giving them "time" or "priority" to automate some of these processes and get them off the treadmill. Usually it takes a fair amount of heroics to get out of that, but I have specific approach to such situations that I've been using successfully for a few years now.
it's always important to remember "devops" is a completely loaded term that can mean drastically different things depending on organization.
https://octopus.com/devops/reading-list/
Google's SRE book changed my career, although I know it's a little out of date now, it's well worth reading for the concepts involved, IMO.
This though:
> With DevOps, if you can automate it, you should automate it.
Everyone at some level in this field understands this. I would even go farther and say that almost everything is automatable depending on how much effort you're willing to put into it. However, lots of bad or overwhelmed devops shops I've consulted seem to be stuck in this insane hell-loop of manual processes not ever giving them "time" or "priority" to automate some of these processes and get them off the treadmill. Usually it takes a fair amount of heroics to get out of that, but I have specific approach to such situations that I've been using successfully for a few years now.
it's always important to remember "devops" is a completely loaded term that can mean drastically different things depending on organization.