ChatOps: Peopling without People

Coming to a network near you. Brought to you by the Other API Economy.

There’s been a shift lately in the DevOps community to focusing more on culture. That’s likely because without the cultural change to a more open, collaborative cross-IT environment, many of the benefits of DevOps can’t be fully realized. Closed, “need to know” sharing of information leads to those siloes that stand like defensive towers encasing the tribal knowledge unique to each of the operational domains that make up what we fondly refer to as “IT.”

But breaking them down can be painful. And awkward. And exceedingly difficult. While we can make jokes about the “anti-social” nature of just about every IT inhabitant and mock the caricatures, the reality is that like most legends and fairy tales, those archetypes arose from real behavior and characteristics that still do typify many in the field.

I’m an INTJ on the Meyers-Briggs. Every time. Yes, “The Architect.” I’m a Reforming Observer on the Insights spectrum, which is really just a hyper-idealized Jungian test that claims greater accuracy than Meyers-Briggs. Either way, I’m pretty much an introvert. Today, researchers estimate that nearly 50% of the population are introverts. And I’m sure it wouldn’t surprise you to find that many of them made their way into IT as I did, while our incomprehensible extrovert counterparts bounced into marketing and management positions.

Introverts aren’t fond of peopling – which is what the kids call interacting with people, these days. It’s not you, really, it’s us. We just process information and data differently than extroverts and find too much active interaction overwhelming. We can people, but it’s exhausting. We prefer text and time to think before responding. Which is why we actually do pretty well in the digital age, where much of our communication is just that – from a distance and via text. You might even mistake us for extroverts, if you know us only in our digital form.

If you consider the premise of the cultural shift required with DevOps, you’ll see there’s a conflict right away. Sharing and communication are both critical components of DevOps, and that means trying to get a bunch of introverts to not only people, but be effective at peopling. That means finding a way to “people without peopling” is like finding the pot of gold at the end of the rainbow.

Turns out that ChatOps might just be that pot of gold.

ChatOps: Peopling without People

So what is ChatOps? Jason Hand, who is one of the foremost experts on ChatOps, gives us a concise definition: “Think of ChatOps as a shared command line.”

It’s more than that, of course, but at its most basic this is an excellent place to start.

Tools like HipChat and Slack are not designed for 1:1 communication, like old school IM systems. You can do that, but the real power of these modern communication platforms is to enable an open communications environment where information and updates are shared instantly with anyone and everyone in the organization that’s interested in it. Lurking is encouraged, because it’s the availability and accessibility of the information that’s important, not a continual conversation.

Channels (like #IRC) provide the means to control the signal:noise ratio, and often a clear audit trail of who did what and when. These tools accomplish that by being more than chat clients. They’re platforms, with the ability to extend functionality through APIs to provide bidirectional communication with not just people, but systems, too. That means I can add an #alerts channel to which I might funnel, well, alerts from infrastructure components.

You can – relatively easily, I might add – build an “app” for Slack that queries and returns information via their APIs. Maybe that’s your switch, or your load balancer, or the local weather. Whatever it might be, you can invoke commands from within these tools that automatically execute tasks. And you can share the invocation – and the results – without everyone who needs to know or might benefit from knowing. Tasks are then documented by what you did and leave a trail for others to understand what’s going on. Status updates from monitoring systems, new tickets from the help desk, a note that a server just fell down and is the no longer available. Just about anything you can think of that can be communicated via an API can be shared with other people – without really peopling.

This process opens up a wealth of opportunities for mentoring, training, and freeing tribal knowledge that benefits other areas of IT – including development. It’s sharing on a grand scale, without crowding in rooms full of people or conducting training exercises for bright-eyed new engineers. It’s also one of the few tools that enables the cultural shift needed to successfully adopt a DevOps approach in “the network”.

And adopt it, we must. If you’re still wary, consider this question posed by Atlassian and xMatters in their 2017 DevOps Maturity Survey:

The authors have their own hypotheses, based on their data, but I have another – based largely on the Fallacy of Composition which reminds us that the application released for deployment is not the same application in production. The insertion of app services and interaction with the network change the composition. The vetting of that application, unless done in an exact replica of the production environment, no longer completely applies.

Worse, for nearly 1/3 of companies, those issues aren’t discovered until customers notify them of service disruptions. That may be due to the way information is shared between development and IT. Twenty-nine percent say information is shared between teams when specifically requested. Only 16.8% make information “open to everyone supplying technical information, goals, plans and results”. 

Without the information peculiar to the behavior of an app in production, it is often difficult to discern what the problem is, let alone its source. “It works on my machine” is a defensive mantra born of developers’ frustration with not being able to replicate bad behavior that more often than not stems from a lack of environmental information.

Even if we’re not gung ho to start automating all the network things, ChatOps is a good way to open the lines of communication between IT and development and provide greater insight into issues that work toward faster MTTR (Mean Time to Resolution).  It’s a means to provide a more comprehensive view of what’s going on “in the network” without being obtrusive or micromanaging engineers. It offers a way for your introverts to people without peopling, which encourages them to share more frequently and thoroughly and, you might find, enthusiastically.

If you’re new to ChatOps, I highly recommend giving Jason Hand’s e-book, “ChatOps for Dummies” a read. It requires you give up your e-mail, but it’s worth it. 

And stay tuned here. There’ll be more on ChatOps in the future, I can guarantee it.