Doing DevOps at VictorOps
By Jason Roth

We talk a lot about what it means to do DevOps here at VictorOps, and a lot of what we talk about comes out of real practice. In some organizations, there’s a wall between developers and ops — developers make requests of ops like they’re throwing tasks over the wall.

Here at VictorOps, that wall isn’t there. When us developers need to do something that’s traditionally in the ops domain like provisioning resources or pushing out deployments, we work closely with ops. And it works the other way too — when things change in the infrastructure that need application changes, they work closely with us. Sometimes, we will just pair on the problem together at one or the other’s desk.

Understanding how the sausage is made
Huge benefits come out of sharing responsibilities between teams. The most obvious is a shared knowledge of the ecosystem — we all want a high bus count right? Having devs know how to get around the puppet configs, and having ops know how the apps work and how they communicate, can only make the organization more resilient.

Empathy is a term that gets thrown around when talking about DevOps, and it should be. Devs and ops working together has given us all a better understanding of what’s actually going on. That added understanding and perspective really helps out when there are problems with the infrastructure or with our applications.

Personally, I better understand what to do in those situations, and if I don’t know the answer, then at least I know where to look, or who and how to ask. This goes both ways — when I’m on call, I’m on the hook for infrastructure stuff, and when ops is on call, they’re on the hook for some app stuff. This just means we’re all in it together.

Extending the DevOps Mentality

There are a few recent examples of our engineering team embracing DevOps philosophies.

We recently did some work on our Cassandra cluster. The changes were infrastructure related, and drove some changes into our applications. We paired together on this to make sure the transition went smoothly and that everyone understood what was being impacted by the change.

Another situation has involved extending support for our APIs and our web client. This has involved constant iterations between frontend, backend, and ops to work through application changes and supporting infrastructure. Since everyone involved was crossing over to collaborate, the entire team was able to better understand the changes, see the bigger picture and create a new process of inclusion.

In a way, doing this kind of thing with engineers is easier because it’s different levels of the same stack. We have a shared language around the technical functions we perform so there’s already a developed vocabulary and some basic understanding. It would be interesting to explore how to do this same thing with different disciplines, involving sales, marketing and support into more of the development cycle.

Tips to Get Started

Getting involved and giving a shit can go a long way towards building culture, respect and empathy amongst teams. That’s step one.

Don’t just ask for something and leave. Schedule time to sit down with a with your counterpart to work through a task. Follow along and be involved. Stop them and ask questions – “how are you doing that and why?” The takeaway from this experience is a shared understanding of what  the problem, solution, and process was. It’s part education and part empowerment.

Continue to push forward. There are still some small boundaries here that exist between our mobile development and platform teams, mostly because the environments are quite different. I think those boundaries are being eroded away as we all work together to unify our product design, front-to-back, cross over for things like testing and infrastructure, include front-end and mobile devs into our on-call rotations, and surface UX issues to the backend engineers. This means that everyone gets a better sense of what’s happening with our entire platform, everyone sees how customers uses the product, and that pays off as we continue to make the service better. We’re still working on it but it feels like we’re making progress.

The technology doesn’t matter. DevOps is agnostic about particular languages, platforms, or tools; it is about internal process, communication, and collaboration. If your team can work more effectively and build a better product by sharing responsibilities, it’s a win-win for everyone involved.

I consider myself lucky to work at a startup. There’s no place to hide like in a big company and you have the ability to carve out your role as you go along. We actively fight against the “not my job” mentality by helping to fix things as they break no matter what they are. For me, the heart of the DevOps philosophy is about working towards the same goal and at VictorOps, we’re all in this together.

The post Doing DevOps at VictorOps appeared first on VictorOps.