Automation of business processes and what does the Latin girl from Brazil have to do with it

Hi, my name is Grigoriy. At the time of writing, I work as a DevOps in a large company. Let's disguise its name as “the one that wants to rotate the planet”. And in this article, I will tell you how our ChatOps team implemented (spoiler – successfully, but there is no limit to perfection).

Background

The team I work in deals with the processes of automation of release deliveries within the PaaS platform. Simply put, everything related to CI\CD and services around it. The centralized pipeline is our main product, which we develop and provide support for its implementation and maintenance. Using it, the product team can, without having a personal DevOps engineer, perform a full development cycle and receive centralized support when necessary. In this article, using my team as an example, I will tell you how we built the support process for the entire platform and what automation tools we wrote for this.

Let's imagine a situation: the development team connects our pipeline, and at one of the stages some problem arises, there is no DevOps in the team, and the release is burning. Let's look at how a developer could interact with the team within the company:

Unofficial way. If the developer knows someone from the team, he can come to the PM, and perhaps help will be provided faster. But most likely, he will be sent to create a task in Jira, since there is a team backlog and planned tasks for the sprint, etc. 🙂

Unofficial methods:

• Go to Jira, search for the relevant service, create a ticket. Then wait for this request to be taken into work, processed, then clarify something in the comments, and so on – you know as well as I do how it works. Often it is not fast, but reliable in terms of monitoring the execution and storing the history of the request;

• If the question non-urgent — wait for a general synchronization with the platform team and voice your problem there.

Why the old approach didn't suit us

All these methods have little to do with the main criterion of good support. “speed of solving the user's problem.” There are also questions about the convenience of approaches. As a result, the quality of service and user satisfaction suffer. Don't forget about the product team, in addition to the main work responsibilities, you need to go to Jira every day, look at new tickets from users, receive a million email notifications about the status of these tickets, go to Jira again to look at the answers in the comments. Then don't forget to move them to “completed”, put the letters in folders so as not to lose them. But I wanted a simple human ….. saw new features and not worry about it …..

What to do?

Having analyzed all of the above, the question arose: why not get closer to your users and do something for them (and us) united, convenient, fast And high quality a platform for communication?

It was decided that we would implement support for the team's products using the corporate messenger RocketChat with Black Jack and the ability to create bots in Python.

Every manager likes to analyze team metrics, but not every developer likes to go to Jira and move tasks (c) Folk wisdom.

Now that you are immersed in the context of “why did we turn all this around“, I'll tell you in more detail what happened in the end.

How RocketChat and JIRA integration made it easier to support customers and collect metrics.

For each platform team, we created a thematic channel in RocketChat, in which a person on duty is assigned daily to resolve emerging questions and user problems.

While testing the idea, we clearly saw that the speed from the moment a question was asked to receiving an answer increased several times. Also, after conducting a survey of active users, it turned out that most users find it much more convenient to interact with the platform team via messenger, creating a request in the channel, rather than creating a ticket in Jira. But you can’t refuse to use JiraFlow “because it’s more convenient”. But what about the metrics, statistics on the number of requests, graphs that management needs to evaluate our team’s performance? Therefore, the duty officers were forced to process requests from two sources (tickets in Jira, requests in the RocketChat channel).

To ensure that the duty officer does not go crazy from such a zoo and the quality of support increases, three services were created.

Our team has quite a lot of services that are tied to RocketChat business logic, and their number is constantly growing, but we can probably talk about this in other articles.

I will briefly tell you about the stack of all 3 services, without going into details of the architecture, because the article is about the approach and the idea, and not about the development know-how. Python was chosen as the main language, all services live in Kubernetes, Nats is used as a message broker, we store the data necessary for life in Postgres.

The first service that our team implemented was a chat bot. The main functionality of the bot at the moment:

• Allows the duty officer to change the status of the request (“Taken for work”, “Completed”, etc.) using buttons created by the bot in the thread. The statuses have a visual display in the form of emoji, which the bot displays as a reaction to the request. The statuses to which the duty officer can transfer the request correspond to the possible statuses of Jira tasks.

• Transfers requests to a specialized chat if the user has entered the wrong door or confused the support channel;

• If there is no activity in the thread from the duty officer for a long time regarding the request, the bot tags it and asks to assign an up-to-date status;

• Sends a WebHook with a notification about the creation or change of the status of a request, as well as about the addition of a comment in the request thread to the message broker;

• Offers to leave feedback on the quality of the service provided after closing the request.

  

The profit we got from the chat bot:

1. Increased response speed to user requests. Due to instant notification by the bot to the duty officer about the creation of a new request;

2. The ability to transfer a request to the desired channel if the user's request is not related to the channel's topic;

3. Visually convenient display of the status of the request, using the reaction emoji displayed on them.

The second service was created to perform the following tasks:

1. Syncs requests created in RocketChat with Jira, creating Jira tasks on the corresponding channel board;

2. Synchronizes tasks created in Jira, creating a ticket in the corresponding RocketChat channel.

• If a request is created in the RocketChat channel, the service creates a task in Jira. Fills in the required fields: task description, product name, request author, etc;

• Once created, attaches a link to the Jira task inside the RocketChat request;

  

• Assigns an executor (on duty in the RocketChat channel) to a Jira task;

• Adds all correspondence that is conducted within the request thread as comments to Jira.

• Syncs RocketChat ticket statuses with Jira task.

But what about those users or the team duty officer who love Jira and want to create/solve tasks there? Reverse integration is provided for this. For example, a user asks a question about CI/CD using Jira. The service determines which RocketChat channel it should be redirected to by the service name in the task and creates a request. Or, if a user creates a request in RocketChat, a task is created in Jira, and the duty officer finds it more convenient to work in Jira – no problem: comments and statuses will be synchronized with the request in RocketChat.

Everyone seems happy now. We use RocketChat channels as the main entry point and allow those who prefer the old method to create issues in Jira. Management can pull all the metrics they need through Jira.

The profit we got from the Jira <-> RocketChat synchronization service:

1. Tickets are synced between Jira and RocketChat in both directions;

2. It is possible to use a convenient communication channel (Jira, RocketChat) without compromising the quality of the solution to the issue;

3. The metrics needed to analyze the quality of work, statistics of requests and time to resolve the issue can still be aggregated in Jira. At the same time, the support team and users can communicate with each other without even going into Jira.

But it seems that this is not all that is needed for complete happiness…

Grow NPS with RocketChat Bot

Let's simulate the situation: пришел пользователь -> задал вопрос(в RocketChat или Jira) -> получил ответ -> дежурный закрыл обращение в RocketChat/Jira -> состояние между RocketChat и Jira синхронизировалось.

How can a team get feedback on the level of user satisfaction with the product?

Of course, do it feedback chat botwhich comes to the user who asked the question in a personal message with a request to evaluate the quality of the support service on a five-point scale. The results are anonymous, and we do not calculate by IP those who leave bad reviews, but this is not accurate =) The bot saves the rating in the database, from which you can later download to determine customer satisfaction.

The profit we got from the feedback collection synchronization service:

1. The user, without leaving RocketChat, rates the quality of the service provided;

2. The team analyzes the ratings received from users to improve the quality of services.

Conclusion

In this article, I tried to describe the approach we use to implement platform support, collect metrics, and monitor customer satisfaction with our services. At the time of writing, this approach and our services are being actively implemented in other teams of the company.

Oh yes, the most important question, which remained unanswered for those who read to the end ну и причем тут латиночка из Бразилии? and it plays one of the most important roles, because the same RocketChat that we already love was born, grew up, and then came to replace Slack from Brazil =)