When ChatOps Goes From Cool to Critical

Hi, I’m Ben, an Operations Engineer with Librato. I am very excited about ChatOps as a force for positive change at companies both small and large. If I could work solely on ChatOps and related integrations for the next several years, I would be a happy camper. When I first heard Dave Josephsen’s talk at Velocity NY 2014 and got a glimpse of Librato’s ChatOps practices, I was intrigued. When I joined the Librato team later that year and dove head-first into helping them migrate their ChatOps platform from Campfire to Slack, I was gobsmacked by how tightly integrated ChatOps was with the daily workflow of engineers.

Since I joined the company just over a year ago, our reliance on ChatOps has continued to grow as our customer base grows, our infrastructure scales, and the need for us to leverage automation increases. This caused me to stop and reflect on the following: ChatOps is no longer a nice-to-have on our team; it is no longer a convenience. It is, in fact, a critical piece of our operations. The realization led us as an operations team to pause and consider how we were designing, operating and supporting our ChatOps platform.

Before I share some of the highlights of our improvements, I would like to ask: how do you, the person implementing the platform, know when your own ChatOps operation has moved from “Cool” to “Critical?” I will review the progression of a typical ChatOps implementation to identify common patterns and demonstrate how one can predict and prepare for upcoming needs.

Illustrating a Typical ChatOps Adventure

How did ChatOps feel for you and your team when you first began prototyping it? Did you start by downloading Lita, Hubot, or Err, and any and all public plugins available? How long did it take you to disable the Google Image Search plugin? Did your team start using Slack, and begin experimenting with slash commands? What useful features did you first take advantage of in your ChatOps experimentation? Some common ChatOps features that teams use when they are first getting started include:

• Communicating emotions (gifs, pugbombs, etc.)
• Data lookups (weather, users, dig, etc.)
• Webhook Service Integration (CI, GitHub, alerting, etc.)

Congratulations! You have reached ChatOps level: Cool. 

Yes, your ChatOps prototype has turned into something very useful and beloved by your team. The Giphy lookups are flowing, GitHub notifications are coming, and you and your team begin to start having ideas about what could be done to do some more useful pieces of automation such as deploying your code from chat commands.

You realize quickly that you will need to create some custom code and configuration to make this automation happen. Now you have likely entered the world of bot and/or bot plugin development. You begin to build a deployment plugin that will allow users to initiate code deployments within your infrastructure. You work with your team members to understand which applications they want to ship into which environments, and what parameters they want to be able to specify when shipping. Internet hugs and high-fives abound as your team is using its chat platform in their daily workflow to review code, receive alerts, ship code, and more. 

This article originally appeared on the Librato blog by Ben Odom.