Help Me Help You Deliver DevOps

i believe in devops.

actually, that’s a pretty horrible way to put it. it’s not about belief, like keeping tinkerbell alive.

i have successfully worked within an environment that implemented a devops approach to development, deployment, and maintenance. i also provide classes and consulting on how to approach devops from the ops perspective as well as write books on the topic.

because i’ve seen the devops approach work — and work well — despite the fact that my principal job description is in the ops side of devops, i am a very strong and passionate advocate for devops.

but!

devops

despite the fact that i absolutely support the concepts of devops — moving development and deployment into the production space and moving operations into better support of the development space — i frequently find myself with my face in my palm.

why?

look at the word, devops. note: it doesn’t say dev. it doesn’t say devops. it doesn’t say dev...ops (maybe later, if we have time). the core concept behind devops is that development and operations are coming together. it’s not that development is taking over operations, as i so frequently have to argue about, with both development and operations. this is an important and key concept because, there’s a reason why you see some specialization within it. frankly, it is difficult.

so, people spend time learning smaller aspects of it in order to be good at those aspects. yes, acknowledged, there is the very rare individual who truly is a superstar and can do it all, but they are, by definition, extremely rare on the ground. most of us in it are just ordinary humans.

operations

i get it. to developers, the operations team just seems like this slow moving behemoth, a dinosaur on its way to the tar pits (yeah, i know, mainly mammals in the tar pits from a different era, work with me). especially the dba team (no!) and its ability (no!) to slow things down (no!) with their constant (no!) use of the word “no” (no!).

however, operations exists for a reason — and they’ve developed a lot of special skills and knowledge that seems to be missing from development. let me outline what i mean.

failure

there has been quite a few spectacular failures recently. let’s talk about how a fundamental lack of understanding of why acid properties on a database are kind of important, especially when setting up something that resembles a bank.

no? how about the fact that backup testing , a pretty fundamental aspect of operations, is so easily overlooked. not to mention evidently being able to use the same login in dev/test and production so that you can corrupt and then drop the production database accidently.

maybe that you need a secondary location for your dr? seems like a pretty fundamental part of operations .

or even my own web site. i didn’t maintain my updates appropriately (and i know better) which allowed me to be hacked. happily, i have two sets of backups, one i maintain myself and one maintained by my wonderful service provider, dreamhost . recovery was possible in under an hour.

speaking of backups, maybe taking them at all would be a good idea.

kumbaya

not all those losses and outages are even remotely the fault of devops, but you do get the sense in our ever more development focused age that maybe a little more attention ought to be paid to the ops side of things and then we can all hang out, singing kumbaya instead of running around putting out fires. the key concept of devops is that we meet in the middle and cross over. it’s not that one side takes over the other. the old days where things were ops-centric were silly, and failed. let’s not repeat those mistakes by going completely dev-centric. let’s do devops.