Привет, меня зовут Григорий. На момент написания статьи я работаю DevOps'ом в одной большой компании. Завуалируем её название как «та, что хочет вращать планету». И в этой статье я расскажу, как наша команда ChatOps внедряла (спойлер — успешно, но нет предела совершенству).
Предыстория
Команда, в которой я работаю, занимается процессами автоматизации релизных поставок в рамках платформы PaaS. Проще говоря, всем, что касается CICD и сервисов вокруг этого. Централизованный пайплан — наш основной продукт, который мы разрабатываем и предоставляем саппорт по его внедрению и обслуживанию. Используя его, продуктовая команда может, не имея личного 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-бот:
-
Увеличение скорости реагирования на обращения пользователей. За счет мгновенного оповещения ботом дежурного о создании нового обращения;
-
Возможность переноса обращения в нужный канал, если пользователь обратился не по теме канала;
-
Визуально удобное отображение статуса обращения, с помощью выставленных на них эмодзи реакций.
Второй сервис, был создан для выполнения следующих задач:
-
Cинхронизирует созданные в RocketChat обращения с Jira, создавая Jira-таски на соответствующей каналу доске;
-
Cинхронизирует созданные в Jira таски, создавая обращение в соответствующем канале RocketChat.
Опишу логику работы сервиса, которую мы реализовали для достижения ранее упомянутых задач:
-
Если создается обращение в канале RocketChat, сервис создает таску в Jira. Заполняет необходимые поля: описание задачи, название продукта, автора обращения, etc;
-
После создания прикрепляет ссылку на Jira-таску внутрь обращения в RocketChat;
Пример прикрепления ссылки на созданную в Jira таску внутри треда. -
Назначает исполнителя (дежурного по каналу RocketChat) в Jira таске;
-
Добавляет комментариями в Jira всю переписку, которая ведется внутри треда обращения.
-
Синхронизирует статусы обращения в RocketChat с таской Jira.
А как быть тем пользователям или дежурному команды, которые любят Jira и хотят создавать/решать таски там? Для этого предусмотрена обратная интеграция. Например, пользователь с помощью Jira задает вопрос по работе CI/CD. Сервис по названию услуги в таске определяет, в какой канал RocketChat его необходимо перенаправить и создает обращение. Или, если пользователь создает обращение в RocketChat, создается задача в Jira, а дежурному удобнее работать в Jira — без проблем: комментарии и статусы будут синхронизированы с обращением в RocketChat.
Все, кажется, теперь довольны все. Мы используем каналы RocketChat как главную точку входа и даем возможность тем, кто предпочитает старый метод, создавать задачи в Jira. Руководство может снимать все необходимые метрики через Jira.
Профит, который мы получили от сервиса синхронизации Jira <-> RocketChat:
-
Обращения синхронизируются между Jira и RocketChat в обе стороны;
-
Возможно использовать удобный канал коммуникации (Jira, RocketChat) без ущерба для качества решения вопроса;
-
Необходимые для анализа качества работы метрики, статистика обращений и время на решение вопроса по-прежнему могут агрегироваться в Jira. При этом команда саппорта и пользователи коммуницировать друг с другому даже не заходя в Jira.
Но кажется это еще не всё, что нужно для полного счастья...
Растим NPS с помощью RocketChat бота
Моделируем ситуацию: пришел пользователь -> задал вопрос(в RocketChat или Jira) -> получил ответ -> дежурный закрыл обращение в RocketChat/Jira -> состояние между RocketChat и Jira синхронизировалось.
Как команде получить фидбек об уровне удовлетворённости пользователей продуктом?
Конечно, сделать feedback chat бот, который приходит в личку к пользователю, задавшему вопрос, с просьбой оценить качество работы саппорта по пятибальной шкале. Результаты анонимны, и мы не вычисляем по IP тех, кто оставляет плохие отзывы, но это не точно =) Оценку бот сохраняет в БД, из которой можно в дальнейшем делать выгрузку для определения удовлетворённости клиентов.
Профит, который мы получили от сервиса синхронизации по сбору обратной связи:
-
Пользователь, не выходя из RocketChat, выставляет оценку качества оказанной услуги;
-
Команда анализирует полученные от пользователей оценки, для повышения качества услуг.
Заключение
В данной статье я попытался описать подход, с помощью которого мы реализуем поддержку платформы, собираем метрики и следим за удовлетворённостью клиентов нашими услугами. На момент написания статьи данный подход и наши сервисы активно внедряются в других командах компании.
Ах да, самый главный вопрос, который так и остался не закрыт для тех кто дочитал до конца ну и причем тут латиночка из Бразилии? а она выполняет одну из самых главных ролей, т.к. тот самый, полюбившийся уже нам RocketChat, родился, вырос, а потом пришел на замену Slack именно из Бразилии =)
Автор: grigoriidenisov
