ChatOps: Supercharging DevOps with group chat

How can software teams leverage chat to reduce friction and enhance collaboration? This episode of the O’Reilly Podcast features my discussion with Jason Hand, DevOps Evangelist at VictorOps and author of the recent O’Reilly book, ChatOps: Managing Infrastructure In Group Chat. We talk about ChatOps, managing incidents, and what it means to be a learning organization.

The full conversation is available through the embedded audio. Highlights from the discussion are noted below.

Learn faster. Dig deeper. See farther.

Join the O'Reilly online learning platform. Get a free trial today and find answers on the fly, or master something new and useful.

Learn more

Is ChatOps basically “ops with bots”?

In a lot of ways, it is. ChatOps doesn’t necessarily require a bot, although once you’ve gotten to a level of expertise in some of the automation that you want to do, implementing bots really does open up new opportunities. In Slack, for example, they have a nice little marketplace for all kinds of different third party applications that you can integrate with your group chat. But integration—for example, having your GitHub activity show up in a particular chat room—only goes so far. Eventually you get to a point where you realize those native integrations aren’t really providing the full level of context or the full level of command that you need. That’s when you can start using bots to leverage those APIs.

What are some common anti-patterns you see when organizations try to implement ChatOps?

The first is that people often treat chat like email, and vice versa. People will often reach out to an individual in a direct message or some sort of private message to engage in a back and forth conversation about some issue or topic, and then they’re done with that conversation. But conversations in direct message are essentially black-boxed; they’re in a silo, and no one else can be a part of that. A lot of the value of ChatOps is sharing communication in an open space. People should fight the urge to only have one-on-one conversations.

Secondly, it’s adopted as a sort of top-down decision, without buy-in from practitioners: “This is the tool we’re going to use.” Instead of dictating one tool from the top, consider doing a proof of concept on a particular tool: run it for a month or two, then try a different one, so you can evaluate what is best for your team. Make sure everyone on your team has shared their thoughts on what they like and don’t like about certain tools.

What are some tips for getting started with doing ChatOps with your team?

• Look into and evaluate a number of different group chat tools.
• In addition to Slack and HipChat, consider tools you are already using and how to pipe them into chat. If you’re a developer, GitHub’s an obvious one. Jenkins is another obvious one, perhaps VictorOps as well. Integrate the tools you use on an everyday basis.
• After adding integrations, cut down on the noise, particularly if you are doing a lot of deployments per day. Move particular conversations and integrations into separate channels. Don’t think you can just set it all up, get it going, and leave it; you need to do some pruning.

To hear more about the culture and technical challenges around ChatOps (as well as discussions around incident management and learning from failure), listen to the full audio.