Chat is a method of communication that has become tremendously popular over the past several years alongside the growth of DevOps. ChatOps – chat plus ops – is meant to provide better communication among IT professionals, and the systems they use. One source referred to it as ‘conversation-driven development’ because it begins and ends with the recognition of moving to a shared and collaborative approach within the enterprise.
While the notion of conversation-driven collaboration isn’t new – remember AOL IM or BBSs (Bulletin Board Systems) – there is now the ability to trigger automations from chat rooms. Yet the goal has been and remains the same: to enable synchronous and asynchronous communication for distributed groups and people.
Improving communications means not just talking more but talking better. The end goal is ensuring that teams are making the most of their communications and pushing projects and teams further as a result. Indeed, the goals of ChatOps can be synthesized as follows:
• Make sure communications are open and transparent
• Create a sense of openness that enables new hires to easily see how tasks are performed
• Get the right team together to resolve incident
• Speed up the resolution of critical incidents
• Block out the noise of non-essential communications that impede resolution
The focus of this blog is not to recommend a particular tool for ChatOps. That is the work of the team which implements the tool. Rather the goal of this blog is to highlight the advantages and limitations of ChatOps and indicate how to overcome its existing limitations like it’s inability to deliver ChatOps Alerts.
The reasons for teams using ChatOps are many. However, the advantages of chat are seen most readily when you examine the limitations of the alternatives. Email, for example, is really a form of communication focused on an exchange between two people. As soon as multiple people get involved in an email thread, the communication gets muddled. Additionally, email is also not nor was it ever intended to be a real-time communication tool. There is inevitably a delay which prevents rapid resolution of the issues at hand.
SMS faces similar issues to email in that it is not meant as a collaborative tool or a tool that enables work to get done. The text messages are not integrated into the work thread and so they remain separated. In addition, and this is also an issue faced by email, it is impossible to query databases or execute functions from the command line of SMS or email.
Most importantly, these tools don’t encourage collaboration. And in a DevOps world, communication is paramount. Chat today is focused on bringing in groups to a common communication platform. In Slack, the communication is the Slack channel. In Spark, the communication is in the Spark room. Email and SMS don’t enable these sorts of separated rooms for directed and focus conversation.
To find out how OnPage enables ChatOps Alets download our e-book.
What are the best Kubernetes monitoring tools in 2025? And how can you ensure alerts…
If you still think websites are a “set it and forget it” asset, your business…
You can write clean code, test obsessively, and deploy with crossed fingers…but errors always find…
Each year, Gartner’s Hype Cycle provides a powerful lens through which to view the evolving…
Managing a facility means dealing with issues at all hours, often when no one is…
Whether you’re dealing with IT issues, customer questions, or just trying to keep track of…