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

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

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

Привет! Меня зовут Евгений Астафуров, я ведущий разработчик в Отделе экспериментальных технологий AI VK. Мы разрабатываем Discovery AI — набор ИИ‑технологий для интеллектуального поиска, рекомендаций и взаимодействия с контентом. В него вошли нейропоиск, анализ контекста, персонализация, генеративные модели и рекомендательные алгоритмы, чтобы помогать пользователям находить нужную информацию, получать релевантные ответы и новый контент.

В этой статье подробно разберу архитектуру технологии нейропоиска в Discovery AI, которая объединяет большую языковую модель (LLM), поиск, инференс и данные многомиллиардной контентной базы VK. Технология становится важным компонентом развития рекомендательных и поисковых систем в наших продуктах и будет поэтапно внедряться в сервисы для пользователей, авторов и бизнеса (Дзен, VK, Медиапроекты Mail, VK Видео и другие). 

Привет, Хабр. Меня зовут Дмитрий Сергеев. Я менеджер продукта «виртуальные серверы» (GPU) в компании VK Tech.

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

В этой статье я на примере сервисов VK Cloud разберу, в каких сценариях востребованы физические GPU, а также где и как их можно эффективно заменить с помощью vGPU, чтобы оптимизировать бюджет и сэкономить на аренде полного объема ресурсов.

Привет, Хабр! На связи Нина Андреянова из ВКонтакте, я занимаюсь реализацией больших кросс-командных проектов последние пять лет. Недавно я рассказывала про назначение тимлидом контрибьютора (спасибо за ваш интерес к статье!). Сегодня я пришла поделиться с вами ещё одной темой: высокая продуктивность команды и как руководители иногда её ломают. За годы работы в разных корпорациях я поняла одну неприятную управленческую правду: фраза «давайте ещё немного поднажмём» звучит вдохновляюще… ровно до того момента, пока ты не слышишь её третий квартал подряд. Если эта фраза звучит в команде регулярно, то, вероятнее всего, вы уже не ускоряетесь. Вы просто медленно тратите ресурс, который не восстанавливается.

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

Привет, Хабр! Меня зовут Андрей Орлов, я QA‑инженер в команде Tarantool Database, VK Tech. Я занимаюсь функциональным тестированием: проверяю новые фичи и изменения, поддерживаю и развиваю автотесты, разбираю инциденты, анализирую логи и метрики. Нагрузочное тестирование и стресс‑тестирование тоже входит в мои задачи — в том числе для проверки поведения Tarantool Database на больших конфигурациях. В этой статье я расскажу, как мы организовали и провели тестирование Tarantool Database на 640 инстансах, какие подходы и инструменты использовали и какие выводы сделали.

Как мы пришли к локальному скану, фильтру Блума и переезду очереди на Kafka — и почему это всё случилось 

Привет, Хабр. Я Данил Кислов, разработчик команды хранилищ. У нас в One-cloud (внутренняя корпоративная облачная платформа) лежит собственная S3-совместимая реализация — one-object-storage. Хочу рассказать, как эволюционировал метастор S3— та часть, что отвечает за метаданные объектов: списки версий, индексы, настройки бакетов и прочую служебную мелочь.

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

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

VK Cloud активно использует РЕД ОС от РЕД СОФТ — в том числе в VK Secure Cloud, аттестованном контуре для значимых объектов критической информационной инфраструктуры (ЗОКИИ). На ее примере покажу, как поднять производительность гипервизора, просто обновив легаси и не трогая железо. Вместе с дистрибутивом на ноду приезжает свежий стек целиком: ядро, эмулятор, клиент хранилища, системные библиотеки. Каждый слой подтягивает свой кусок. А для тех, кто застрял на CentOS, ушедшем в EOL, у истории есть вторая часть: обновление закрывает технический разрыв и регуляторику одним движением. Ниже разберу механику по слоям с командами, которые можно выполнить на своей системе.

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

Сначала DBA оптимизируют запросы. Потом появляются новые индексы. Потом увеличивается размер серверов. Затем появляются реплики. Потом еще реплики. И через некоторое время выясняется, что значительная часть бюджета на инфраструктуру уходит на обслуживание системы, которая изначально должна была просто хранить данные.

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

Привет, Хабр. Меня зовут Сергей Фомин. Я старший менеджер продукта Tarantool DataBase. 

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

Привет, Хабр. Меня зовут Василий Щитов. Я старший инженер в команде CI-инфраструктуры ВКонтакте. 

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

Я расскажу об основных подходах и паттернах, которые мы применяем, чтобы облегчить жизнь при работе с TeamCity.

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

Привет, Хабр. Меня зовут Александр Шалудин. Я Presale-архитектор Data Services VK Tech. В этой статье я разберу, к чему может приводить работа с неактуальной информацией и как выстроить архитектуру, которая позволит устранить этот разрыв.

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

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

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

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

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

Привет, Хабр! Меня зовут Михаил, я backend-разработчик в команде Managed Kubernetes в VK Cloud. При работе с K8s всем нам приходится сталкиваться с множеством конфигураций, которые мы используем постоянно, и Service не является исключением. И вот тут мне стало любопытно: а может ли с виду безобидный конфиг Service сломать нам весь кластер? Ну или хотя бы подпортить жизнь какому-то сервису?

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

Статья будет полезна DevOps, безопасникам, админам и просто юным любителям Kubernetes. 

S3-совместимые хранилища предоставляют бизнесу и ИТ-специалистам широкий набор инструментов для работы с данными. Это и практически бесконечная масштабируемость, позволяющая хранить петабайты информации без сложной настройки, и высокая надежность за счет автоматического резервирования, и гибкое управление доступом для разных команд и сервисов. Наряду с ними важной и полезной функцией является версионирование бакетов, которое позволяет хранить полную историю изменений каждого объекта и защищает от потери данных.

Но чтобы раскрыть весь потенциал этой функции и грамотно встроить ее в рабочие процессы, важно понимать, как она устроена. 

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

Миграция в облако и переход к микросервисной архитектуре сделали Kubernetes (k8s) де-факто стандартом для управления контейнерами. По данным 2025 года, технологию уже применяют 60% крупных российских компаний, а ещё 15% планируют внедрение в будущем. Причем 59% компаний называют отказоустойчивость ключевым критерием при выборе Kubernetes, но лишь единицы реализуют его на практике. Проблема кроется в недооценке системных рисков — от отсутствия резервирования control plane до некорректных таймингов readiness-проб, пропускающих «полуживые» поды в балансировщик.

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

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

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

По данным BI.ZONE, почти треть инцидентов с шифрованием в России в 2025 году пришлась на атаки через подрядчика.

Не через FW-периметр, а через легитимный канал: учетку внешнего исполнителя, общую сеть, привилегии, выданные под задачу и оставшиеся навсегда. Это разбор-практикум: как избежать подобного с помощью модели Zero Trust и как строится  подрядный доступ, и как собрать такой контур у себя. Без теории ради теории — каждый слой идет с конкретными шагами, готовыми скриптами и проверкой, что у вас уже работает, а что нет. Материал для тех, кто проектирует или эксплуатирует доступ внешних исполнителей: ИБ-инженеров, архитекторов, системных администраторов.

Zero Trust для подрядного доступа строится по четырем слоям: Identity (кто подключается), Device (с какого устройства), Access (к чему и как) и Monitoring (что делал). Пройдем каждый слой по шагам: от IdP и MFA до Posture Check, ZTNA и VDI, PAM и мониторинга на SIEM, UEBA (User and Entity Behavior Analytics, аналитика поведения пользователей и сущностей) и SOAR, с кейсами, цифрами, схемами и двумя рабочими bash-скриптами для Linux.

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

Привет, Хабр! Меня зовут Игорь Красавин, и я работаю frontend-разработчиком в компании VK. Сегодня хочу рассказать вам, как мы объединяли несколько BI-систем (DataLens, Superset и Redash) под одним UI, как решали проблемы со SPA-навигацией, историей браузера и различными стеками, на какие грабли наступили, и что нам, в итоге, это дало. Материал будет полезен frontend-разработчикам, которые могут столкнуться со схожей задачей в рамках своих проектах.

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

Сложно представить более прикладную область, поэтому на хакатоне IT Academy Hack 2026 от IT Академии Samsung Innovation Campus в этом году, мы решили попросить студентов предложить варианты улучшения поиска по сообщениям в контуре корпоративного мессенджера. Кстати, VK Tech стал индустриальным партнером конкурса уже во второй раз — предоставил инфраструктуру для студентов, и стал одним из постановщиков задач.

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

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