Привет, меня зовут Григорий. На момент написания статьи я работаю DevOps'ом в одной большой компании. Завуалируем её название как «та, что хочет вращать планету». И в этой статье я расскажу, как наша команда ChatOps внедряла (спойлер — успешно, но нет предела совершенству).

Предыстория

Команда, в которой я работаю, занимается процессами автоматизации релизных поставок в рамках платформы PaaS. Проще говоря, всем, что касается CI\CD и сервисов вокруг этого. Централизованный пайплан — наш основной продукт, который мы разрабатываем и предоставляем саппорт по его внедрению и обслуживанию. Используя его, продуктовая команда может, не имея личного DevOps-инженера, выполнять полный цикл разработки и получать централизованный саппорт при необходимости. В статье, на примере своей команды, я расскажу, как мы выстроили процесс саппорта для всей платформы и какие инструменты автоматизации написали для этого.

Представим ситуацию: команда разработки подключает наш пайплайн, и на одной из стадий возникает какая-то проблема, DevOps'а в команде нет, а релиз горит. Разберем как в рамках компании разработчик мог взаимодействовать с командой:

Неофициальный способ. Если разработчик знает кого-то из команды, он может прийти в личку, и, возможно, помощь будет оказана быстрее. Но, скорее всего, его отправят создавать задачу в Jira, так как есть бэклог команды и запланированные задачи на спринт, итд :)

Официальные способы:

• Идти в Jira, искать там соответствующую услугу, создавать тикет. Потом ждать, когда эту заявку возьмут в работу, обработают, потом что-то уточнить в комментариях и так далее — вы не хуже меня знаете, как это работает. Зачастую это не быстро, но надежно с точки зрения контроля выполнения и хранения истории запроса;

• Если вопрос несрочный — дождаться общего синка с командой платформы и там озвучить свою проблему.

Почему старый подход нас не устраивал

Все эти способы имеют мало общего с главным критерием хорошего саппорта «скорость решения проблемы пользователя». Также есть вопросы к удобству подходов. В итоге страдает качество услуги и удовлетворенность пользователя. Не стоит забывать о команде продукта, помимо основных рабочих обязанностей нужно каждый день ходить в Jira, смотреть новые тикеты от пользователей, получать миллион уведомлений на почту о статусах этих тикетов, снова идти в Jira, чтобы посмотреть ответы в комментариях. Потом не забывать переводить в «выполнено», складывать по папкам письма, дабы не потерять. А хотелось простого человеческого .....пилить новые фичи и не париться.....

Что делать?

Проанализировав всё вышесказанное, возник вопрос: почему бы не стать ближе к своим пользователям и не сделать для них (и нас) единую, удобную, быструю и качественную площадку для коммуникации?

Было решено, что саппорт продуктов команды будем реализовывать с помощью корпоративного мессенджера RocketChat с Black Jack и возможностью пилить ботов на Python.

Всякий руководитель любит анализировать метрики тимы, но не всякий разработчик любит ходить в Jira и двигать таски (с) Народная мудрость.

Теперь, когда вы погрузились в контекст «зачем мы все это воротили», расскажу подробнее, что получилось в итоге.

Как интеграция RocketChat и JIRA позволила упростить поддержку клиентов и собирать метрики.

Для каждой команды платформы мы создали тематический канал в RocketChat, в котором ежедневно назначается дежурный для решения возникающих вопросов и проблем пользователей.

В процессе обкатки идеи мы наглядно увидели, что скорость от момента заданного вопроса до получения ответа увеличилась в разы. Также, проведя опрос активных пользователей, выяснилось, что большинству пользователей гораздо удобнее взаимодействовать с командой платформы через мессенджер, создав обращение в канале, нежели создавать тикет в Jira. Но отказаться от использования JiraFlow «потому что так удобнее» нельзя. А как же метрики, статистика количества обращений, графики, которые нужны руководству, чтобы оценивать показатели нашей команды? Поэтому дежурные были вынуждены обрабатывать обращения из двух источников (тикеты в Jira, обращения в канале RocketChat).

Чтобы дежурный не сошел с ума от такого зоопарка и качество саппорта росло, было создано три сервиса.

Сервисов, которые завязаны бизнес-логикой на RocketChat у нашей команды достаточно много, и их число постоянно растет, но об этом, возможно, в других статьях.

Кратко расскажу про стек всех 3 сервисов, не углубляясь в подробности архитектуры, т.к. статья про подход и идею, а не про ноухау разработки. В качестве основного языка был выбран Python, живут все сервисы в Kubernetes, в качестве брокера сообщений используется Nats, храним необходимые для жизни данные в Postgres.

Первым сервисом, который внедрила наша команда стал chat-бот. Основой функционал бота на данный момент:

• Тегает дежурного канала при создании обращения(Who is on duty today? вычисляем с помощью обращения бота к API Grafana OnCall);

• Позволяет дежурному изменять статус обращения («Взято в работу», «Выполнено» и т.д.) с помощью кнопок, созданных ботом в треде. Статусы имеют визуальное отображение в виде эмодзи, которые бот выставляет реакцией на обращение. Статусы, в которые дежурный может перевести обращение соответствуют возможным статусам тасок Jira.

• Переносит обращения в профильный чат, если пользователь ошибся дверью, перепутал канал саппорта;

• Если по обращению долгое время нет активности в треде от дежурного, бот тегнет его и просит назначить актуальный статус;

• Отправляет WebHook с уведомлением о создании или изменении статуса обращения, а также о добавлении комментария в треде обращения в брокер сообщений;

• Предлагает отставить обратную связь о качестве предоставленной услуги, после закрытия обращения.

  

Профит который мы получили от chat-бот:

1. Увеличение скорости реагирования на обращения пользователей. За счет мгновенного оповещения ботом дежурного о создании нового обращения;

2. Возможность переноса обращения в нужный канал, если пользователь обратился не по теме канала;

3. Визуально удобное отображение статуса обращения, с помощью выставленных на них эмодзи реакций.

Второй сервис, был создан для выполнения следующих задач:

1. Cинхронизирует созданные в RocketChat обращения с Jira, создавая Jira-таски на соответствующей каналу доске;

2. Cинхронизирует созданные в Jira таски, создавая обращение в соответствующем канале RocketChat.

• Если создается обращение в канале RocketChat, сервис создает таску в Jira. Заполняет необходимые поля: описание задачи, название продукта, автора обращения, etc;

• После создания прикрепляет ссылку на Jira-таску внутрь обращения в RocketChat;

  

• Назначает исполнителя (дежурного по каналу RocketChat) в Jira таске;

• Добавляет комментариями в Jira всю переписку, которая ведется внутри треда обращения.

• Синхронизирует статусы обращения в RocketChat с таской Jira.

А как быть тем пользователям или дежурному команды, которые любят Jira и хотят создавать/решать таски там? Для этого предусмотрена обратная интеграция. Например, пользователь с помощью Jira задает вопрос по работе CI/CD. Сервис по названию услуги в таске определяет, в какой канал RocketChat его необходимо перенаправить и создает обращение. Или, если пользователь создает обращение в RocketChat, создается задача в Jira, а дежурному удобнее работать в Jira — без проблем: комментарии и статусы будут синхронизированы с обращением в RocketChat.

Все, кажется, теперь довольны все. Мы используем каналы RocketChat как главную точку входа и даем возможность тем, кто предпочитает старый метод, создавать задачи в Jira. Руководство может снимать все необходимые метрики через Jira.

Профит, который мы получили от сервиса синхронизации Jira <-> RocketChat:

1. Обращения синхронизируются между Jira и RocketChat в обе стороны;

2. Возможно использовать удобный канал коммуникации (Jira, RocketChat) без ущерба для качества решения вопроса;

3. Необходимые для анализа качества работы метрики, статистика обращений и время на решение вопроса по-прежнему могут агрегироваться в Jira. При этом команда саппорта и пользователи коммуницировать друг с другому даже не заходя в Jira.

Но кажется это еще не всё, что нужно для полного счастья...

Растим NPS с помощью RocketChat бота

Моделируем ситуацию: пришел пользователь -> задал вопрос(в RocketChat или Jira) -> получил ответ -> дежурный закрыл обращение в RocketChat/Jira -> состояние между RocketChat и Jira синхронизировалось.

Как команде получить фидбек об уровне удовлетворённости пользователей продуктом?

Конечно, сделать feedback chat бот, который приходит в личку к пользователю, задавшему вопрос, с просьбой оценить качество работы саппорта по пятибальной шкале. Результаты анонимны, и мы не вычисляем по IP тех, кто оставляет плохие отзывы, но это не точно =) Оценку бот сохраняет в БД, из которой можно в дальнейшем делать выгрузку для определения удовлетворённости клиентов.

Профит, который мы получили от сервиса синхронизации по сбору обратной связи:

1. Пользователь, не выходя из RocketChat, выставляет оценку качества оказанной услуги;

2. Команда анализирует полученные от пользователей оценки, для повышения качества услуг.

Заключение

В данной статье я попытался описать подход, с помощью которого мы реализуем поддержку платформы, собираем метрики и следим за удовлетворённостью клиентов нашими услугами. На момент написания статьи данный подход и наши сервисы активно внедряются в других командах компании.

Ах да, самый главный вопрос, который так и остался не закрыт для тех кто дочитал до конца ну и причем тут латиночка из Бразилии? а она выполняет одну из самых главных ролей, т.к. тот самый, полюбившийся уже нам RocketChat, родился, вырос, а потом пришел на замену Slack именно из Бразилии =)