Operations. You may know us as system administrators, IT guys, tech guys, or just those computer guys in the basement. Whatever the moniker, we are the people who keep your sites and services online, and wake up in the middle of the night to fix them when they’re not.
What comes to your mind when you think of operations?
For a lot of people, the answer is something along the lines of “that surly guy who seems genuinely annoyed when we make him do work, and who gets angry when we break stuff,” and the sad part is they are not wrong. Those surly individuals probably see themselves as underappreciated cannon fodder doing their best with insufficient resources, and they are quite likely correct in their assessment as well.
There exists a stereotype of IT people as angry and uncooperative lone wolves who fiercely protect against change to the detriment of the larger organization. Part of this was a response to the tendency of developers to throw code over the fence then disappear, leaving the operations team to deal with whatever problems arose; part of it was that the operations profession attracted grumpy people.
In response to those factors and a host of others, some very smart people took matters into their own hands and came up with a new philosophy and methodology to running an operations department, which they called DevOps. There are a great many definitions of DevOps and the term has been co-opted by many parties for their own purposes, but the fundamentals are basically:
- Communication, collaboration & sharing responsibilities between operations and developers
- Operations can and do write code to fit their own needs and in support of developers
- Automate as much as possible
- Frequently deploy application to production
By looking at this, we can derive that regular operations must look something like this:
- Poor communication, collaboration & sharing responsibilities between operations and developers
- Operations do not write code
- Very little automation
- Infrequently deploy application to production
Gosh, when you put it that way, operations is pretty stupid, isn’t it? Why did anyone bother with the old way? Let’s all practice DevOps!
Except the thing is, there were people who did operations the DevOps way before—they just did not have well-known, articulate and well-liked advocates or a catchy term to distinguish themselves from the non-DevOps crowd; they were just good operations engineers, and everyone else was a bad operations engineer. In what other profession exists a term to distinguish between individuals who work well with others and those who do not? It’s crazy to even consider, right? The expectations of operations professionals are so low that it is often okay for them to be horrible colleagues, and over time this has sullied the entire profession to the point where the good people have adopted a new title.
I say no more. I say we take back ops.
If you have bad operations people, fire them. Hold out to find really good people and hold them to the same standards as the rest of your employees. Stop being accepting bad behavior and stop giving bad ops jobs.
We can rehabilitate operations; we don’t need the term devops any more than we need the term smartphone. Operations is our word—bad practitioners can get their own. I nominate BadOps.