В Иви одну backend-команду давно пришлось разделить на две, и теперь этот инженерный тандем отвечает за вещи, которые пользователь замечает мгновенно: что видно в каталоге, какие промоблоки загружаются на главной и как быстро поддержка находит историю подписок и просмотров. Для русскоязычной IT-аудитории это не очередное знакомство с корпоративной кухней, а вполне предметный разбор того, как backend-команда Иви удерживает продукт на стыке бизнес-логики, внутренних сервисов и операционной надежности.
О внутреннем устройстве команды рассказала технический менеджер Оля Шамсутдинова, сообщает Habr / Карьера. По ее словам, исторически команда называется B2B, хотя с классическим business-to-business это почти не связано. Внутри она разделена на два направления: B2B Core и B2B Операционная. Первое отвечает за ядро логики, которое определяет, какой контент доступен пользователю, что показывать в каталоге, какие карусели и промоблоки выводить на главной странице, а также за ТВ-каналы и телепрограмму. Второе направление делает сервисы и админки для коллег внутри компании: от редакции до поддержки и маркетинга.
Состав задач у этой конструкции показательный. В операционной части есть админка для подборок вроде романтических комедий и хорроров, сервис фидов для партнерских платформ и детектор аномалий, который отслеживает статистические отклонения в продуктовых и сервисных метриках. На бумаге это выглядит как набор внутренних тулзов, но по факту именно на таких инструментах держится повседневная управляемость большого стримингового продукта. Если каталог неверно отдается, промо показывается не тем пользователям или аномалия замечена с опозданием, бизнес получает проблему не в теории, а в цифрах и жалобах. Так что backend-команда Иви здесь работает не в режиме “поддерживаем, пока не сломалось”, а как нервная система нескольких процессов сразу.
Технологический стек при этом без попыток выглядеть экзотично, и в этом как раз его сила. Команда использует Python и Go, для админок в основном Django. Причем речь не только о стандартной Django Admin, но и о кастомных интерфейсах на htmx. Это важная деталь: бэкенд-разработчики сами могут быстро собирать удобный фронт для внутренних пользователей, не превращая каждую админку в отдельный фронтенд-проект с длинной очередью задач. Из инфраструктурного набора названы Protobuf, Redis, PostgreSQL, ClickHouse, MinIO, Kafka и Celery. Ничего модного ради модного, зато хорошо видно инженерный приоритет: не “удивить стеком”, а поддерживать предсказуемую экосистему сервисов.
Отдельно интересно, с кем именно взаимодействует команда. Если верить описанию Шамсутдиновой, почти со всеми: с платформенными командами, которым backend отдает API для iOS и Android, с аналитиками, которые строят отчеты на событиях из этих сервисов, с редакцией, которая заводит контент через админки, и с маркетингом, для которого появился новый сервис. Это типичная ситуация для зрелой продуктовой разработки: backend перестает быть просто слоем между базой и клиентом и становится точкой сборки интересов нескольких функций бизнеса. Для разработчиков здесь важный сигнал: чем ближе сервис к пользовательскому сценарию и внутренним операциям, тем меньше шансов жить в уютной изоляции.
Где backend приносит прямую пользу
Самый наглядный кейс из операционного блока — веб-приложение для службы поддержки, которое команда делала в течение года как часть распила старого монолита и старой админки B2B. Сервис нужен операторам, чтобы за пару секунд собрать по пользователю всю картину: покупки, списания, подписки, историю просмотров, состав семейной подписки, привязанные телефоны и почты. Для саппорта это не “приятный бонус”, а вопрос скорости обработки обращений. Чем меньше времени оператор тратит на прыжки между сервисами, тем дешевле обходится поддержка и тем выше шанс, что пользователь не уйдет раздраженным. Здесь особенно показательно, что backend-команда взяла на себя еще и фронт на htmx, предварительно изучив реальные сценарии работы поддержки и требования ко времени ответа. То есть разработка шла не от любви к архитектурным диаграммам, а от конкретной операционной боли.
Во втором направлении Шамсутдинова выделяет сервис “Промо”, который отдает центральный промоблок на главной странице Иви. Это как раз та зона, где ошибка backend почти мгновенно превращается в бизнес-инцидент. Если блоки не показываются, показываются не тем пользователям или редакторы не понимают, почему конкретная карточка не вышла на экран, разбор быстро превращается в дорогое коллективное гадание. Судя по описанию, команда убрала именно эту часть хаоса: теперь можно указать пользователя и страницу и получить точное объяснение, что он должен увидеть и почему какой-то промоблок не отобразился. Для рынка это хороший пример того, как внутренний диагностический инструмент экономит больше времени, чем еще один слой героического ручного дебага.
Не менее полезна и история про неудачный релиз. Один из ключевых backend-сервисов дорабатывали под жесткий дедлайн, чтобы успели зарелизиться клиентские приложения. Команда выкатила изменения в пятницу около шести вечера, а через два часа выяснилось, что время ответа одного сервиса выросло в сто раз. Сначала казалось, что проблема не в этом релизе, но причина оказалась именно в новых изменениях: для двух партнерских API возник бесконечный цикл при вычислении ответа. Обычные пользователи проблему не заметили, партнеры — заметили очень хорошо. В половине одиннадцатого вечера изменения пришлось откатывать. В индустрии любят рассказывать про безошибочные процессы, но такие эпизоды обычно полезнее презентаций про engineering excellence. Здесь важнее не сам фейл, а то, что в компании есть культура постмортемов и ошибок не пытаются замести под коврик.
Что из этого стоит вынести рынку
Вся эта история хорошо ложится в более широкий тренд российских продуктовых компаний: backend-команды все чаще отвечают не только за сервисный код, но и за внутренние интерфейсы, диагностику, операционные сценарии и удобство нетехнических коллег. Если раньше админка воспринималась как что-то вторичное, то сейчас она становится прямым продолжением продукта. Иви в этом смысле показывает довольно трезвый подход: не строить культ вокруг микросервисов, а использовать их там, где они реально помогают разнести ответственность, ускорить поддержку, упростить контентные операции и снизить цену инцидентов. Для разработчиков это еще и неплохое напоминание, что сильная backend-команда Иви измеряется не количеством сервисов в схеме, а тем, насколько быстро она помогает редакции, саппорту, аналитикам и клиентским приложениям работать без лишнего шума.
Открытый вопрос здесь не в том, нужен ли backend такой уровень вовлеченности, а в том, где проходит граница между инженерной универсальностью и перегрузкой команды. Когда бэкенд одновременно держит каталог, API, админки, внутренние тулзы и диагностику, выигрывает продукт, но требования к приоритезации и качеству процессов резко растут. Похоже, именно это и становится новой нормой для крупных цифровых сервисов: писать код уже мало, нужно еще делать так, чтобы с этим кодом могли быстро и без нервов жить все остальные.