Meet Our Projects: Chatbot, New Automations and Code Libraries

Paack and the chatbot case

At Paack, we are proud of working with an Automate Everything mentality and a DevOps philosophy. Last year we set up several automation projects, the aim of which was, first of all, to make technology accessible to non-IT users, and second, to make managing IT simpler.

By using automation techniques and coding as the magic glue, we are integrating all the technologies and platforms we use into one simple answer. From a higher perspective, we find alternative innovations for integrating our platforms and communities without incurring large costs.

The chatbot case

For an average user getting information about the infrastructure is slow and complicated. Often this is basic information that is not strictly confidential within the organization. It just resides in a different administration domain and thus out of their reach.

For example, a marketing user does not have access to the complex systems that manage the network, only the network team has.

In these situations, a regular user has to contact another team in order to get information about the status of a system or service in the company.

As we know, this can take some time and involve between one and several people.

So first, we abstract from the user the “how, what, and whom to ask” and replace it with a simple formulated question to the chatbot: “Is the network ok?” or “Why this thing doesn’t work?”

And then the chatbot will generate a simple on-demand automated report to answer that question in an easy and user-friendly language.

With this objective in mind, we developed and deployed a server-less container with an internal Slack Chatbot for our users to use anytime, anywhere. Also since we are present in several European countries, the chatbot speaks four languages: Spanish, English, French, and Italian.

We started by creating a welcome home page for the App, where users can see the status of the network and if there is any Jira ticket active.

And then a list of available options depending on the user privileges.

Later on Network Operations users have an extended list of options which includes inventories, capture SDN debug information and advanced reports for LAN and WAN. The same can be done for other specific users or departments uses cases.

We can also query the network to answer the famous question “Where is this IP address?”

For example Network Operations users have an extended list of options which includes inventories, capture SDN debugs information and advanced reports for LAN and WAN.

We can also query the network to answer the famous question “Where is this IP address?”

Users can also open Jira tickets from the chat app itself without needing to access external resources.

We also exposed the same functionality via an API, and now other systems can query and get the results in a programmatic way or even trigger some specific action. This enables us to go further and make integrations between our systems.

Service desk and monitoring

From the monitoring perspective, we implemented server-less cloud functions which continuously gather information, and after applying an algorithm, if anything is wrong, it will send us a Slack message and open a Jira ticket to the relevant IT team to check. Later, since the cloud function is always running, when the problem is resolved it will automatically close the Jira ticket.

We have also converted this continuous gathering of information into the Slack Dashboard from the first picture.

The never-ending documentation story

As there are daily changes in the infrastructure, keeping the documentation up to date becomes a burden and a not-likely-to-happen. So, we implemented another set of server-less cloud functions to automate this task.

For example, now all the network diagrams and IP networks are continuously updated in Confluence every time there is a change. Even our flow collectors are updated when a new device with a public IP is detected.

Closing the code feedback loop

Having created several new libraries for our use cases, now we’re re-using the code to add the functionalities to pre-existing deploys.

For example: When the code itself fails, it will post a message with the traceback (or pre-formatted message) to a Slack channel, as well as open a support ticket in Jira that even includes the name of the affected user.

Now we instantly know what has failed, what the error was, and who the person affected is.

We can therefore contact that person and say “Hey I saw you had this error, I’m on it and I will get back to you when it is fixed”.

And all of these use cases, without requiring ANY human intervention!

This site is registered on wpml.org as a development site.