Меня зовут Борзов Олег, я техлид команды разработки CRM-системы для менеджеров ипотечного кредитования крупного банка. Сегодня я хочу рассказать, как наша команда разработки упрощает часть рабочих процессов с помощью мессенджера Telegram.

Disclaimer: всё нижеописанное касается процессов разработки в компании «Домклик».

Для начала расскажу немного про нашу команду, область ответственности и про часть наших процессов.

Команда состоит из 10 разработчиков, под нашим контролем находится более 20 микросервисов, в четыре из них одновременно коммитят три смежные команды (причины обсуждать не будем, это выходит за рамки темы статьи). Основная функция наших сервисов — обслуживание ипотечного процесса, от одобрения кредита до выдачи. Системой пользуется более 30 тысяч сотрудников бек-оффиса.

Автоматизируем релизные процессы

В нашей команде достаточно высокий темп разработки. В прод мы релизимся как минимум два раза в неделю (средний размер релиза — 30 задач). За релиз у нас отвечает дежурный релиз-инженер, эта роль передаётся между всеми опытными разработчиками. Релизный процесс занимает двое суток и устроен следующим образом:

1. За день до релиза релиз-инженер собирает все задачи в отдельной ветке, унаследованной от master (release/12345). Дежурный обязан собрать pull-request’ы доработок в релизную ветку, дождаться одобрений и проследить, что все сборки корректно прошли.

2. В день релиза утром релизная ветка выливается в тестовую среду (stage), после чего доработки вручную тестируются.

3. Вечером релиз финализируется и выливается в прод. На этом этапе релиз-инженер должен следить за ошибками, которые могут возникнуть в процессе, и решать — поправить обнаруженную ошибку (если она не слишком критичная и сразу понятно, что нужно чинить), откатить задачу, которая вызвала ошибку, либо (в редких случаях) откатить релиз целиком.

Как видите, процесс достаточно трудоемкий и требует много внимания. Периодически возникали моменты, когда часть задач забывали долить в stage и их приходилось переносить в следующий релиз, что не очень хорошо, так как нарушались согласованные с другими командами сроки.

Чтобы облегчить жизнь дежурному по релизу, мы разработали специального Telegram-бота, который часть рутинных задач забрал на себя:

• напоминания релиз инженеру об этапах (сборка релиза, вывод в stage/prod);

• сбор списка pull-request’ов по задачам;

• сбор участвующих в релизе репозиториев, а также отслеживание статусов сборок и развёртываний;

• подсвечивание дежурному списка задач без pull-request’ов или невлитых pull-request’ов, а также ответственных за эти задачи;

• подсвечивание задач, на которые нужно обратить особенное внимание (например, те, где нужно пройти дополнительную проверку у команды кибер-безопасности, или задачи, где есть новые миграции в базу данных/переменные окружения). 

Выглядит сообщение от бота следующим образом (все ФИО/названия репозиториев и прочие чувствительные данные изменены):

Упрощаем дежурства по багам

Как и в любом другом крупном используемом сервисе, в нашем периодически появляются баги, которые нужно находить и исправлять причины их появления. Учитывая размер нашей системы, а также большое количество интеграций с другими системами Домклик (по последнему подсчету мы интегрированы с более чем 50 сервисами), зачастую найти источник проблемы очень непросто.

В Домклике тикеты в систему Helpdesk заводят пользователи (в нашем случае — менеджеры ипотечного кредитования). Затем сотрудники техподдержки систематизируют тикеты и заводят в Jira задачки-«баги» на команду, отвечающую за систему, в которой обнаружился баг. К этим задачам крепятся похожие тикеты.

В нашей команде принята процедура дежурства по багам (по аналогии с ролью релиз-инженера, описанной выше). Каждый рабочий день один из разработчиков, более-менее хорошо знакомых с системой, назначается дежурным. В этот день он освобождается от выполнения других задач, отслеживает все поступающие задачи-«баги» от сотрудников Helpdesk и помогает решить описанную пользователем проблему. По возможности (если исследование не занимает очень много времени), дежурный исправляет источник ошибки, а в других случаях заводит задачу на исследование и исправление.

Также раз в неделю на одной из встреч разбираются тикеты, до которых дежурный не добрался, либо не смог найти причину. Процесс разбора багов меньше всего поддаётся автоматизации, для его упрощения мы написали собственный кластеризатор поступающих задач. У него такая функциональность:

• Напоминание дежурному в общем чате команды о начале дежурства (определяется по задаче в JIRA).

• Уведомление в конце дня о количестве закрытых за сегодня багов.

• Автоматическая привязка и тегирование похожих тикетов в Jira

Уведомления о проблемах в каналах Telegram

Кроме ботов у нас также есть несколько чатов для мониторинга наших сервисов:

1. Чат SentryNotifications. В него сыпятся все ошибки из Sentry по нашим проектамБлагодаря ему удается быстро выявлять новые виды ошибок (например, после релизов).

2. Чат Alerts. В него летят не слишком критичные уведомления из Grafana: увеличение длительности ответа наших конечных точек и внешних сервисов, незначительный рост количества ошибок 4xx/5xx.

3. Чат Admin Alerts. Сюда мы шлём наиболее критичные ошибки, на которые нужно срочно среагировать. Этот чат размьючен у дежурных и техлидов, в него пишутся рост очередей-«отстойников» в RabbitMQ и ошибки на ping-ручках.

А вы как упрощаете жизнь команды с помощью мессенджеров? Поделитесь в комментариях.