This is a guest post by James Turnbull (@kartar)
The first two guys I worked for in Ops jobs were old school mainframe guys. Both of them were kind of rough around the edges. Both heavy smokers who liked a drink and who been around before there were PCs, thought client-server was a passing fad and loved their Big Iron. Serious conversations often weren’t conducted in the office clustered around a green screen. They took place outside or downstairs in the car park with all of us sucking back tobacco smoke and shooting the breeze. They valued process, documentation, repeatability and above all else reliability.
I started off in that world as a bull in a china shop: “We’ve got a problem – perhaps if I change this that will fix the problem.” I’d get these patient looks and get dragged downstairs for a smoke and a quiet chat about exactly how “fault resolution” worked.
Those chats can be summed up as three simple principles:
- Think before you act
- Change one thing at a time not ten things at once
- If you fucked up then own up
These principles have pretty much shaped my career in Ops since then (I also picked up a pack a day smoking habit but you win some, you lose some).
Interestingly, do you notice something about those three things? Yep… all behavioral and nothing to do with technology. Indeed, in my experience, they are tenants that all Ops people should know and should
live by.
But do they? What about those people who never got exposed to people like my first colleagues? Who never got taught the ropes by someone talented and switched on about how Operations should work. There are a
lot of people out there who learned their skills and developed in the Ops world without the advantage of good experience and good mentors. From what I’ve seen there are a lot of people out there who didn’t.
Respones to the DevOps Movement
Ironically, some of the first responses to the DevOps movement have been:
- “Smart shops already do this”
- “Smart Ops people have been doing this forever”
- “You don’t need a word for common sense”
And I agree completely and 100%. There are some damn smart Ops people out there. I’d lazily cite pretty much all the folks involved in the DevOps movement, the Puppet community, and other gatherings of like-minded people, as smart. And there are probably dozens (hundreds? thousands?) more I don’t know who are equally smart and for whom many of the tenants of the DevOps movement are second-nature.
I also think that this is actually not the point at all. There are thousands more people who muddle through Operations in ways that make us both wince and laugh. Who don’t understand that automation will make free. Who don’t get the power of monitoring, metrics, documentation and process. Who don’t get to the pub on time.
I can happily debate whether “DevOps” is a good term and even some of the semantics of it. But who fucking cares? What I won’t be told is that just because some people in the Ops world already do all this good stuff that I shouldn’t be evangelising these concepts to others. That someone wrapping up common sense, best practise and good experience and marketing it to people using any means necessary is a bad thing. Because you know? I have to work in those shops too. I have to deal with the consequences of someone who hasn’t had a chance to learn how to be an awesome Ops person. In fact – I’ve earned the right to use any means I like to pass on the things I’ve learned the hard way.
Development and Operations cross-over
I’m not even all that attached to the concept of total Development and Operations cross-over. Although I think it does work and has the potential to make organizations more powerful and more effective. Make them better at delivering the services in the quantities and qualities that keep us in work and keep us all getting paid. If initially however this ends up being an Operations-centric growth then that’s good too.
We’re got a long way to go in that space before we can claim progress and there is always time to build those bridges later. Bridges that are far easier to build if Operations people understand and speak some of
the languages and use some of the techniques of developers. Bridges that are far easier to build if we understand each other better.
People who have read my previous discussions about these issues know I think it’s important, nay critical, both parties learn from one another. Some of that is purely selfish. There are things developers know and
tools they use that have made my life considerably easier. Becoming a better developer has also greatly enhanced my ability to do my job. My interactions with developers, getting them to understand where I am coming from and why we’re presented with challenges with new products and software, have also shown borne fruit though. The developers I work with now far better understand why I challenge them on things like
dependencies, performance, security and architecture. They want to work to make things better. To ensure applications are designed to be operational rather than just functional. Right from the inception of
development.
More importantly, they often do the work before it even gets to me because they better understand my requirements. It means less conflict because we understand each other better. It means better code, better
applications and all that means better results for our organizations, for us, and for our customers. Keeping the customers happy makes the business money and that pays our salaries. And I like being paid.
Invent Your Own Term, If You Like
So if you don’t like the term DevOps then invent your own. AwesomeOps, Visible Ops (taken), SuperOps, etc. Ignore a label altogether if that is what works for you. The point isn’t the name, isn’t the “movement”,
isn’t a “manifesto”. The point is making Ops better – one step at a time – and in the process making our lives easier. If DevOps does that then I’ll use that metaphor until it is no longer effective. If that
happens we will invent another construct that continues that work until we start to see the right results.
About the author
James is an Australian IT geek and author of several books on Linux, Nagios, and Puppet. He’s currently Director of Operations at PuppetLabs.
Agile Web Operations 