Простой

7 мин

0

Расскажи о своей команде?
У меня команда бэкенда, и она называется B2B. Нет, это не «бизнес для бизнеса» в классическом смысле — мы не взаимодействуем с партнерами напрямую. Но название давно устоялось, и внутри оно никого не смущает. Сама команда делится ещё на две: B2B Core и B2B Операционная. 

Первая отвечает за ядро бизнес-логики. За это у нас отвечает куча микросервисов бэкенда, которые мы в том числе и делаем. В зоне ответственности Core — что показывать пользователю в каталоге, какой контент ему доступен, какие промоблоки и карусели вылезут на главной. Сюда же относится список ТВ-каналов и программа передач.

Что касается второй команды, то это сервисы и админки для коллег из разных департаментов. Приведу три примера. Первый — админка для управления подборками: «Самые романтичные комедии», «Лучшие ужастики» и так далее. Ещё есть сервис фидов, который позволяет генерировать специальные структурированные файлы, которые содержат каталог контента, представленный в нашем онлайн-кинотеатре. Эти файлы забирают партнерские сервисы, чтобы они могли показать у себя: «Смотрите, вот этот контент доступен на Иви». И ещё один сервис — детектор аномалий. Им пользуются, чтобы вылавливать статистические отклонения в продуктовых и сервисных метриках. Если что-то пошло не так или обнаружилось нестандартное поведение — он сразу сигналит. Это, и не только, зона ответственности операционной команды.

С какими технологиями вы работаете? Что входит в ваш технологический стек?
Технологии, наверное, стандартные, как у многих. По языкам — Python и Go. Админки в основном на Django. Причём есть как стандартная джанговская админка, так и кастомная с фреймворком htmx, она позволяет бэкенд-разработчикам делать симпатичный и удобный фронт, не будучи профессиональными фронтендерами. По базам данных и остальным инструментам — обычный для индустрии набор: Protobuf, Redis, Postgresql, Clickhouse, Minio, Kafka, Celery — база, которая позволяет эффективно поддерживать и развивать внутренние сервисы.

С какими подразделениями вам чаще всего приходится взаимодействовать по работе?

Практически со всеми. Мы общаемся с командами внутри технического департамента — у нас микросервисная архитектура. Много работаем с платформенными командами: мы даём им API, которые они вызывают на клиентских приложениях, будь то iOS или Android. Очень плотно — с аналитиками, потому что мы отправляем события, по которым они строят отчёты, а ещё у нас есть сервисы, завязанные на их данные. Постоянная коммуникация с редакцией — мы поддерживаем админку, где они заводят контент. И сейчас появился новый сервис для маркетинга, так что активно взаимодействуем и с ними. В общем, мы на стыке многих операционных, бизнесовых и продуктовых процессов.

Расскажи о самых прикольных проектах, которыми вы гордитесь.

Тут расскажу по двум направлениям, потому что функционал у них разный.

В операционной команде мы за год сделали приложение для службы поддержки. Это была часть распила нашего старого монолита, старой админки B2B. Операторы используют это веб-приложение, чтобы найти всю информацию о пользователе: его покупки, списания, подписки, что он смотрел, кто в семье по подписке, какие телефоны и почты привязаны и многое-многое другое. Всё это необходимо, чтобы оперативно помогать нашим пользователям. Приложение достаточно большое, и его особенность в том, что он взаимодействует с очень многими микросервисами. Кроме прочего, были жёсткие требования к удобству интерфейса: операторы обрабатывают уйму обращений, мы должны были помочь им делать это максимально быстро. Дизайнер отрисовал прототип, а бэкенд-команда не только сделала свою часть, но и взялась за фронт — опять же на htmx. Мы изучили, как работает поддержка, посмотрели на требования ко времени ответа, проработали самые частые сценарии и сделали так, чтобы взаимодействие с приложением было максимально быстрым.

А по команде Core я бы выделила сервис «Промо». На главной странице Иви есть карусель, мы называем это блоком ЦПБ — центральный промоблок. Есть бэкенд-сервис, который отдаёт список этих блоков разным пользователям, и админка для их добавления и редактирования. Цена ошибки при разработке сервиса была очень высока. Если что-то шло не так — сразу отражалось на бизнесе. Как и с приложением для поддержки, мы сделали интерфейс максимально удобным для тех, кто заводит блоки, а сервис — безошибочным и быстрым. Раньше, когда что-то не отображалось, к нам прибегали, и мы всей командой садились разбираться. Причин могло быть море: контент недоступен, не то устройство, не то разрешение картинки. Теперь сделали удобный инструмент: указываешь пользователя и страницу — система выдаёт, что он должен увидеть. Если какой-то промоблок не показывается — сразу видишь конкретную причину. И всё, мы больше не тратим время команды на эти разборы.

Два твоих направления живут как две отдельные команды или дружат, общаются, пересекаются?

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

Как в команде принято отмечать успехи, крутые проекты и большие фичи?

Конечно же, успехи нужно отмечать обязательно. Проговариваем и хвалим друг друга на ретроспективах, обсуждаем, что классного получилось. Иногда идём в бар — благо у нас тут Хлебзавод и Флакон под боком. Часто играем в настолки, у нас два фаворита: «Письма призрака» и «Codenames». Ещё есть внутренние доклады — для них у нас нет жёстких требований к содержанию и структуре, достаточно простого плана. Это классный инструмент, чтобы показать, какую большую работу мы сделали. Потому что в моменте масштаб не замечаешь. А садишься, делаешь саммари — и думаешь: «Ничего себе, мы вообще молодцы!». Вспоминаются проблемы, сложности, как их преодолевали. Отличный способ отпраздновать и похвалить себя и коллег за отличную работу.

Какой был самый большой, эпичный фейл? Почему он произошел и чему он вас научил?

Был у нас очень сжатый дедлайн по доработке одного из главных бэкенд-сервисов. Клиентским приложениям нужно было релизиться, и для этого сначала бэкенд должен был успеть доделать функционал. Мы сделали и зарелизились… в пятницу вечером. Да-да, это было смело. Шесть вечера. Я, счастливая, поехала по своим делам. И через два часа пишет коллега: «Время ответа сервиса увеличилось в сто раз!». Я говорю: «Это не мы, сто процентов не мы, мы тот функционал вообще не трогали». Но оказалось, конечно, что это были мы.

Большинство наших запросов присылает параметр «пользовательская сессия». Но есть две команды API, куда ходят партнеры без сессии с access токеном. По этому токену вычисляется идентификатор пользователя. Из-за наших изменений получилось, что при вычислении uid-a, мы попадали в бесконечный цикл. Наши обычные пользователи не пострадали, а партнёры — да. Было стрёмно. К сожалению, в половине одиннадцатого пришлось откатывать изменения. Неприятно, больно и стыдно.

Но такие вещи случаются. Я вообще не верю в историю про идеальную команду, у которой сто процентов успешных релизов. Так не бывает. К ошибкам нужно относиться нормально, главное — делать выводы. У нас в компании есть постмортемы. Если случается крупный инцидент или даже мелкая ошибка — мы проговариваем, на каком этапе что-то пошло не так, где пропустили, где накосячили, чего не понимали, где нужно новые мониторинги повесить. Анализируем, составляем список экшен-айтемов, чтобы в будущем это не повторилось, и исправляем.

Как стать частью такой команды? Какой должен быть человек, какой опыт, какие личные качества важны?

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

Ещё нужна гибкость. Если тебе не нравится, что в любой момент могут выдернуть из текущей задачи и сказать: «Срочно, бросай, переключаемся на более горящее», — будет тяжело. Инициативность тоже важна. Предлагаешь идеи по улучшению процессов — круто. 

Наличие определённого хобби (аниме, спортзал или что-то ещё) не важно, у всех в команде разные интересы. Самое главное, в команде важно общаться не только на рабочие темы, иметь интерес к другим людям и желание взаимодействовать. Если ты работаешь в команде, но ни с кем не общаешься, влиться в командные проекты будет непросто. А когда есть совместные шутки, разговоры, походы на обед — это очень сближает. У нас, например, традиция: в девять утра мы идём на завтрак с теми, кто приходит рано, и говорим в основном о нерабочем.

Как относишься к экспериментам, которые предлагают сотрудники?

Стараюсь поддерживать такие инициативы, хотя, не скрою, иногда отношусь скептически. Но заставляю себя не говорить «нет» сразу. Договариваемся, что попробуем, и посмотрим — взлетит или нет.

Сейчас все внедряют AI-инструменты.У нас из таких инициатив было создание универсального промта для написания хороших тестов нейронкой. Написали все правила, которые нам важны в тестировании и теперь везде в проектах используем в виде файла AGENTS.md который по дефолту всегда читается нейронкой.

Из недавних инициатив — использование нейронки при анализе ошибок, которые прилетают в Sentry. Ребята предложили: «Было бы классно, если бы бот при получении алерта смотрел стектрейс, лез в репозиторий сервиса и пытался понять, что произошло и почему». Договорились с ребятами, что попробуем это реализовать.