Как перестраивать продукт, которым ежедневно пользуются 65 миллионов человек

10 октября ВКонтакте исполняется 20 лет. За это время соцсеть выросла в контентную платформу, а некоторые её направления стали отдельными продуктами. Крупным командам понадобилась возможность независимо планировать обновления, развивать свои системы и управлять нагрузкой. Поэтому ВКонтакте начала переход на сервисную архитектуру.

При этом перестраивать технологии нужно было в работающем продукте. Сегодня дневная аудитория соцсети — более 65 млн человек в России. Остановить её работу даже на выходные было невозможно — изменения внедряли поэтапно.

Как трансформировали продукт по сценариям

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

Крупным направлениям ВКонтакте понадобилось именно это: отдельно планировать изменения и управлять нагрузкой. Сложность в том, что пользователь видит один продукт. Он листает ленту, открывает ролик, потом заходит в сообщество автора и даже не задумывается, что за этими экранами стоят разные системы.

Хороший пример — VK Видео. Видео появилось внутри соцсети и со временем выросло в самостоятельный продукт. Команда разделила сервисы и циклы разработки ВКонтакте и VK Видео. При этом ролики по-прежнему открываются в ленте, сообществах и отдельном приложении. Каждый продукт развивает и масштабирует свои системы сам, а зритель пользуется привычными точками входа.

Главная сложность такого разделения связана с зависимостями. Если любое изменение в одном сервисе требует одновременно обновлять соседние, отдельный репозиторий ничего не даст. Поэтому перед разделением команда выясняет, какие данные нужны, откуда они приходят и кто пострадает, если произойдет сбой.

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

Технический директор ВКонтакте Юрий Кочарян описывает этот процесс так: «Мы понимали, что остановить ВКонтакте, перестроить её и затем снова запустить — невозможно. Поэтому разделили трансформацию на отдельные сценарии и переносили их последовательно. Пока технологическая команда занималась переходом на сервисную архитектуру, продуктовые продолжали выпускать обновления, которые видели наши пользователи».

Платформа разработки вместо ручной сборки

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

VK собрала все эти шаги во внутреннюю платформу разработки. Разработчик выбирает шаблон сервиса, получает ресурсы и сам ведёт изменение от кода до запуска. Такой подход называют self-service: команда пользуется готовыми инструментами и не ждёт, пока кто-то сделает работу за неё.

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

Изолированная среда и фича-флаги закрывают разные риски. В тестовой среде ошибку ловят до выхода к людям. Ограниченная аудитория показывает, что происходит на настоящих запросах. А они бывают куда разнообразнее тех, что разработчики успели придумать в тестах.

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

Юрий Кочарян связывает с этим изменения в действиях разработчиков: «Мы не просто ускорили создание сервисов — мы изменили логику работы команд. Они могут самостоятельно пройти путь от идеи до запуска, не собирая каждый раз инфраструктуру по частям. Платформа стала одной из опор трансформации ВКонтакте».

Discovery для рекомендаций

Общие инструменты помогают быстрее развивать и рекомендации. В 2025 году инженеры AI VK запустили Discovery-платформу для рекомендаций, поиска и рекламы во всех продуктах VK.

На базе платформы раскатываются технологии Discovery. За понимание содержания и сути контента отвечают мультимодальные модели. MMLM анализирует текст, изображения, звук и видео, учитывает тематику и эмоциональный тон материалов. Данные из разных форматов переводятся в общее семантическое пространство, где их можно сравнивать по смыслу. Допустим, вы прочитали пост о ремонте велосипеда. Система может предложить ролик на похожую тему, даже если его только опубликовали и первых реакций ещё нет.

Интересы пользователя описывает нейропрофиль — собственная трансформерная нейросеть AI VK, которая объединяет сигналы о действиях пользователя в разных продуктах компании в единое векторное представление. Она учитывает долгосрочные предпочтения и то, как они меняются со временем. Это помогает использовать знания об интересах человека в разных продуктах компании и подстраивать рекомендации под его текущие увлечения.

Применение технологий Discovery только за первое полугодие 2026 года увеличило общее время, которое пользователи проводят в ленте ВКонтакте, на 11%. На основе платформы обновили и рекомендации для оригинальных авторов — тех, кто создаёт собственный контент. Их публикации могут попасть к широкой аудитории, даже если подписчиков пока мало. Просмотры постов таких авторов выросли в пять раз, а число новых подписчиков — на 22%. Эти результаты отражают совокупный эффект продуктовых изменений и внедрения новых моделей машинного обучения.

Веб на SPA

Трансформация затронула и фронтенд: ВКонтакте перевела основные разделы веб-версии на SPA (single page application), чтобы ускорить загрузку страниц и переходы между ними.

При работе с приложением браузер загружает HTML-документ один раз. Сначала появляется каркас раздела с навигацией, затем, по мере поступления данных с сервера, — контент. Раньше во многих сценариях страница отрисовывалась только после полного ответа сервера. Теперь загрузка контента не задерживает появление каркаса интерфейса.

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

Деплой фронтенда также ускорился. Сначала команда собирает новую версию и публикует её файлы в хранилище S3. Затем изменения распространяются на все серверы, которые отдают сайт пользователям. Сборка и публикация файлов в это время не входят.

«Для нас было важно не просто изменить архитектуру соцплатформы, но и сохранить скорость обновлений, надёжность и качество пользовательского опыта. Переход позволил командам сократить время деплоя фронтенда до 20 сек, а релизы проходят в среднем 6 раз за сутки», — объясняет Юрий Кочарян.

Как поменялась работа команд

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

Платформа автоматизирует типовые операции. Общие требования к разработке и эксплуатации заложены в её шаблоны и автоматические проверки. Это помогает командам соблюдать единые правила, но ответственность за работу сервиса остаётся у его разработчиков. Например, мониторинг автоматически сообщает о росте ошибок, а команда выясняет причины и устраняет проблему.

Если техническое решение затрагивает другие сервисы, его обсуждают на архитектурных встречах. Команды согласуют изменения с учётом зависимостей между системами.

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

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

Что взять в свой проект

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

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

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