Eureka! DevOps!

9 Jul 2012 I'm a systems integrator. I bring disparate systems together to work in one way, shape, or form. I embrace standards and open source because use of both makes my job easier. I bring the integrator mentality to everything I do, as a result. I recognized early on in my career that it was crucial to collaborate with software developers on all of my projects to achieve successful system deployments in the field. Hell, without the software, I'd have no reason to deploy a system!

In all my years, I've often dealt with folks that believe in a complete separation of duties between system administration and development. So much so that those same people don't believe sysadmins can code or that developers can design systems. This is extremely short-sighted and arrogant. I've spent considerable breath trying to influence those people to see that there is actually a blending of skills and disciplines. IT isn't simply a production line where one person punches a widget, someone polishes the widget, and a third person boxes it for shipment. We all integrate on same level, even if only via opaque relationships (i.e. "Here's your brand new server, dev. Enjoy!").

Because of my desire to integrate, I want to learn as much as I can about everything related to any project I work on. To that end, I build and maintain relationships with the developers I work with. I've even tried to find ways to help them get their jobs done within the confines of company policies and regulatory compliance. For example, I'd love to give my developers the ability to easily push (and revert) code updates via a simple procedure built into a configuration management solution such as Puppet or Chef.

What I didn't know was that others have been trying to do the same thing. And they call it DevOps!

Over the last several months I have been ramping up my efforts to increase the level of collaboration between my team (operations) and the development staff. We've implemented design documents to define projects/initiatives that we know need to be completed; we've been writing blameless postmortem analyses to define the root cause of system and application outages; we've instituted monthly lunch meetings with both teams to review topics and projects where both teams play major roles.

Most importantly, we share information, especially the design documents and postmortem analyses. With respect to the postmortems, we're including more and more people and departments with each outage event. That is key to getting total involvement and buy-in to their effectiveness. Just seeing the total number of postmortem analyses written lately tells us something about the state of our operations and what needs to be done to correct outstanding issues.

All of this has been put in place to achieve a (seemingly) simple goal: increase the level of communication and transparency to bring about a higher level of collaboration. In other words, let's get these guys talking to each other so that they talk to each other more, build stronger relationships, and better, more available and robust products.

There's more work to be done here and I'm excited for the challenge.