Привет, Хабр! Меня зовут Юрий Соловьёв, я ведущий инженер в команде экосистемы Tarantool. С опытом я пришел к тому, что конфигурация должна иметь строгую спецификацию, так же как и HTTP API. В этой статье я предлагаю альтернативный подход на базе protobuf и постараюсь показать, что это не избыточная сложность, а необходимый уровень инженерной гигиены — особенно для систем, рассчитанных на долгую и стабильную жизнь. Это в какой-то мере технорассказ, которым я хочу поделиться — и именно в такой форме.

Меня зовут Родион, и я уже около 2,5 лет работаю в VK Android-разработчиком в крупном многомодульном проекте с сотнями экранов и довольно большой аудиторией. Когда я попал на проект, стек был классическим и проверенным: XML-вёрстка, навигация через Cicerone, Dagger 2 для DI, Coroutines и Flow для асинхронщины, а в качестве архитектурного паттерна — MVVM. 

Рано или поздно любая растущая кодовая база упирается в потолок своих архитектурных решений. У нас этот момент настал, когда количество экранов выросло до нескольких сотен и команда начала тратить больше времени на борьбу с неконсистентным состоянием UI. Классическая связка XML + ViewBinding + MVVM работала, но с каждым новым экраном мы всё острее чувствовали её ограничения: разрозненные StateFlow, дублирование кода во фрагментах, сложность переиспользования компонентов. 

Нужно было что-то менять — пересмотреть сам подход к построению UI. Так мы начали миграцию на Jetpack Compose (который на момент начала перехода уже был стабильным и самодостаточным). Полтора года спустя, пройдя через рефакторинг базовых классов, переход с MVVM на MVI и постепенную замену содержимого всех фрагментов, мы получили стек, на котором разработка ускорилась, а баги, связанные с состоянием экрана, практически исчезли. 

Полный переход на Jetpack Compose мы разделили на три больших этапа:

- переписываем содержимое всех фрагментов на ComposeView;

- переходим с Dagger2 на Koin;

- меняем навигацию с Cicerone на Compose-навигацию.

О втором и третьем этапах кратко расскажу ниже —  в главе стратегии перехода, а на первом этапе остановлюсь подробнее.

В этой статье не будет разбора плюсов и минусов Jetpack Compose, скорее она будет полезна тем, кто уже знаком с технологией, хочет её использовать, но боится нести в проект. Я расскажу, как мы шаг за шагом выполняли первый этап, и к чему в итоге пришли.

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

Причина часто кроется в том, что меры обеспечения катастрофоустойчивости либо обеспечиваются формально («чтобы было»), либо проектируются без учета полного цикла рисков — от технических ограничений до организационной готовности.

В статье разберем, как проектировать решения, которые переживают не отдельные сбои, а крупные аварии.

В аналитике больших данных есть старая проблема: код ETL-витрин живет своей жизнью, а документация — своей. Изменяешь логику, забываешь обновить описание колонки — и через месяц никто не помнит, что означает wallet_cards_category_hits. 

В Почте Mail (VK) мы решили эту проблему системно, разработав внутренний фреймворк, который делает код витрины и ее документацию неразрывными.

На связи Дима Швеенков. Я все так же руковожу направлением аналитики в команде и отвечаю за данные в Почте Mail, а теперь еще и отвечаю за DWH в VK Tech.

В предыдущих статьях я подробно рассказывал о нашем Data Driven-подходе к работе с данными, а также, в частности, как мы работаем со Spark и какие ключевые проблемы с данными мы решили, чтобы построить свое хранилище данных. Сегодня хотел бы остановиться на более узкой теме — как держать в порядке документацию, если у вас такое же огромное хранилище, как и у нас. Материал короткий, но, надеюсь, будет для вас полезным. 

Когда команда запускает витрину продукта — каталог, рекомендации или подборки, —  почти сразу возникают вопросы: «Будут ли пользователи что-то из неё скачивать или покупать и какая будет конверсия?»

До запуска на них сложно ответить честно: у пользователей ещё нет привычки, у продукта — стабильной выдачи, у витрины — накопленного доверия, а у команды — реальных данных поведения. Поэтому полезнее временно отложить вопрос «какая будет конверсия?» и спросить иначе: «Сможет ли витрина запустить выбор, когда у пользователя ещё нет сформулированного запроса?»

Меня зовут Таня Лескова, я ведущий UX-исследователь в магазине приложений RuStore. На примере исследований витрины RuStore расскажу, как мы проверяем такие сценарии до запуска: смотрим не на гипотетическое «скачал бы или не скачал», а на более раннюю цепочку — заметил, понял, поверил, захотел разобраться дальше.

Привет! Меня зовут Нина, я уже больше пяти лет занимаюсь реализацией больших кросс-командных проектов в VK. В структуре моего отдела есть две крупные команды, всего в моём подчинении 18 человек. Когда структура разрастается и плоское управление уже не так хорошо работает, настаёт время фокусировать экспертизу в группах и назначать тимлидов.

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

Привет, Хабр! Меня зовут Максим Шакуров, я ML-инженер в VK.

Сегодня индустрия активно внедряет LLM для оптимизации рабочих процессов. Наша команда решила идти не от самой технологии, а от реальных потребностей. Чтобы найти процессы с наибольшим потенциалом для автоматизации, мы начали с аудита текущей рутины: проанализировали, с какими запросами аналитики и менеджеры приходят в чаты поддержки к инженерам Data Office (специалистам, отвечающим за сбор, хранение и миграцию корпоративных данных) и к разработчикам нашей платформы данных (команде, которая поддерживает и дорабатывает DWH).

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

Привет, Хабр! Меня зовут Евгений Грибков, я ведущий разработчик в центре технологий VK. В этой статье я покажу решение, к которому мы с коллегами пришли при работе над одной из наших внутренних систем.

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

Внедрение современных инструментов Data Governance (управления данными) часто воспринимается как финальная точка в построении культуры работы с данными. Компании инвестируют в Data Quality-проверки (качества данных), создают каталоги данных и выстраивают красивые дашборды, которые сигнализируют о полном порядке. Однако на практике бизнес часто обнаруживает, что за фасадом «зеленых галочек» скрывается хаос: отчеты не сходятся, ключевые метрики вызывают вопросы, а доверие к аналитике падает. Этот разрыв между формальным качеством данных и их реальной ценностью для бизнеса приводит к финансовым потерям и неверным управленческим решениям. 

Меня зовут Сергей Петриченко. Я продуктовый менеджер VK Data Platform. В этой статье я покажу типовой путь компании и расскажу, как сделать работу с данными не самоцелью для ИТ, а инструментом, который полезен для бизнеса.

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

Именно на этом уровне возникает основной объём рутины. Инженер по безопасности снова и снова выполняет одни и те же базовые действия: читает постановку, анализирует контекст, проверяет типовые паттерны, отсеивает очевидные проблемы. Эта работа необходима, но она отнимает кучу времени, которое должно уходить на более сложный анализ и принятие решений.

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

Мы посмотрели на процесс ИБ внутри релизного цикла и выделили участки с наибольшей повторяемостью. Таких точек оказалось три: первичный разбор Security Check-задач, анализ кода в merge request и динамическое тестирование приложений. Во всех этих сценариях сначала выполняется типовая работа, и только потом начинается действительно экспертная часть.

Баланс между производительностью, читаемостью и поддерживаемостью — ключевая задача при разработке микросервисов на Go. На практике всё сложнее из-за неочевидных факторов: от влияния частоты вызовов GC на время отклика до последствий избыточной вложенности в контрактах API. Если не учесть эти нюансы, даже грамотно спроектированный сервис может просаживаться по RPS (requests per second) — или его может быть сложно обновлять и дорабатывать.

Меня зовут Артём Кущ. Я Go-разработчик в команде VK Видео. В статье поделюсь подходами к оптимизации микросервисов и расскажу, как балансировать между скоростью и простотой.

Привет, Хабр. Сегодня делимся кейсами студентов Инженерно-математической школы (или просто ИМШ) — совместного образовательного проекта VK и НИУ ВШЭ в сфере машинного обучения, развития высоконагруженных систем и технологий ИИ. Здесь студенты участвуют в проектных мастерских: учатся, предлагают и реализуют идеи, которые уже сейчас влияют на будущее ИТ.

Трое студентов школы кратко расскажут о своих проектах, учёбе в ИМШ и опыте работы над реальными задачами в проектах VK.

А ещё вы узнаете: 

- о том, какие навыки помогает прокачать учёба в ИМШ;

- что делает студенческие проекты полноценными научно-прикладными работами, которые хорошо выглядят в резюме;

- как попасть в ИМШ.

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

Меня зовут Катя Бурлакина, я старший продуктовый дизайнер в VK Tech и занимаюсь развитием дизайн-системы. В этой статье я не буду рассказывать про весь наш путь, а расскажу про его часть — систему дизайн-токенов. Спойлер: при помощи нее у нас получилось устранить некоторые проблемы, ускорить процесс разработки и даже исключить изобретение велосипеда. 

Привет, Хабр! Меня зовут Саша Митрохина, я руковожу блоком проектной деятельности модерации и взаимодействия с пользователями VK. Сегодня расскажу об одной из самых дорогих кнопок любого цифрового продукта.

В интерфейсе кнопка «Пожаловаться» выглядит почти бесплатной: небольшой элемент UI, который можно добавить за один спринт. Но зачем она вообще нужна?

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

На уровне системы каждое нажатие запускает одну из самых дорогих цепочек обработки в продукте. И чем быстрее растёт аудитория и UGC от неё, тем заметнее становится эта стоимость.

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

Когда RuStore только запускался, мы строили дизайн на основе UI-кита от VK — удобно, практично, а главное помогло нам быстро вывести продукт на рынок. Но стор рос, интерфейсов становилось больше, дизайнеры — смелее, а требования — сложнее. И вот настал день, когда мы решили добавить тёмную тему. И всё сломалось. 

Именно тёмная тема вскрыла нашу главную проблему — ранняя структура цветовых токенов не готова к масштабируемости. Любое изменение запускало каскад правок и ломало синхронизацию между макетами и кодом. 

Под катом мы — Элина Шевченко, продуктовый дизайнер RuStore, и frontend-разработчик Андрей Едунов — расскажем историю, как мы полностью перестроили систему, не останавливая разработку, аккуратно вынесли всё из Figma в код и почему теперь можем масштабировать дизайн без драмы, даже если завтра понадобится не только тёмная тема, но и ностальгия по 2008-му, где primary — это чистый #000000, а secondary — оттенок тоски.

Привет, Хабр! Меня зовут Екатерина Сивакова, я тимлид аналитики в Дзене (VK), а до этого работала в других бигтехах, и везде так или иначе сталкивалась с изучением CJM и пользовательской аналитикой. Сегодня хочу рассказать, как мы в Дзене делали единый инструмент по изучению пользовательского пути, зачем это понадобилось и что из этого вышло. А ещё о том, сколько это реально стоило по времени и ресурсам, потому что ответ отличается от первоначальной оценки примерно в 60 раз.

Текст будет вам полезен, если у вас продукт с большим количеством страниц и разветвлённой навигацией, с многочисленными однотипными переходами пользователей.

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

Меня зовут Антон Ленев, я разработчик на платформе VK Mini Apps. В этой статье я расскажу, как от шуточного пет-проекта пришёл к мини-приложению «Отредач — ИИ-фоторедактор» на платформе VK Mini Apps и победе в грантовом конкурсе VK Dev Grants 2025.

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

Меня зовут Сергей Емельянов. Я руководитель Core-команды VK Tech. В этой статье я пошагово покажу процесс построения синтетической платформы для обработки потоковых данных на Kubernetes.

В большом мобильном продукте коммуникации запускаются разными командами. Подписки, апселлы, промоакции и A/B-эксперименты развиваются параллельно и часто независимо друг от друга.

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

Меня зовут Михаил Христокьян. Я работаю над мобильными продуктами Почты и Облака Mail и занимаюсь архитектурой и развитием системы продуктовых коммуникаций внутри приложения. Сегодня я расскажу о том, как мы решили эту проблему и при чём тут «Разборки».

Смотреть шоу, телеканалы, спортивные трансляции, фильмы и другой контент на Smart TV, используя приложения видеоплатформ — уже типовой сценарий. По данным на конец 2025 года, объём потребления контента в VK Видео увеличился в 2,1 раза (на 110%) по сравнению с аналогичным периодом 2024 года. Наибольшее вовлечение аудитории зафиксировано на платформе Smart TV: в начале 2026 года среднее время просмотра на одного пользователя — 241 минута. При этом многие не думают, как устроен софт для большого экрана.