Как начинался VK Teams и что у него под капотом 💙

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

В самом начале мы создали для VK Teams собственное хранилище KUST (Customizable Storage). Это встраиваемая key-value-база, оптимизированная под чтение и работу с HDD-дисками. Она обеспечивала надежность и потоковый дамп логов, но при переходе к On-Prem-внедрению мы решили, что клиентам нужно больше контроля над СУБД.

Сейчас большая часть сервисов работает на Tarantool — промежуточном ПО для работы с данными, которое ускоряет цифровые сервисы и снижает нагрузку на core-cистемы. Этот переход увеличил скорость работы, улучшил управляемость и повысил удобство для пользователей On-Prem-решений.

🔄 Как сервисы общаются между собой

Для коммуникации сервисов мы используем бинарный протокол IPROTO, дополненный контроллером Ctlr. Он реализует Service Discovery и управляет потоками данных. Так появился IPROS.

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

🔹 Как мы добились отказоустойчивости

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

🔹 Почему мы работаем с ячейками

🔹 Простота управления — работать с одной сущностью легче, а при масштабировании достаточно выполнить шардирование.
🔹 Локализованность контекста — всегда понятно, куда поступает запрос и где возникла ошибка.
🔹 Минимальное влияние сети — сервис и БД размещены рядом, что снижает задержки.
🔹 Безопасность данных — взлом одной ячейки не даст злоумышленнику доступа ко всей системе.

#коммуникации #разработка
@digitize_IT — мнения и управленческий опыт ИТ-лидеров

Три ошибки с метриками Kubernetes в PromQL, которые проще не допускать, чем исправлять

Запрос в PromQL может выглядеть просто, но скрывать подводные камни. Например, он должен возвращать сведения об использовании памяти пода, но выдает ошибку.

container_memory_working_set_bytes{pod="agency-dashboard-api-89b7f557c-xd4l7"}

Вот какие ошибки есть в этом запросе.

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

🔹 Неверная агрегация. Попытка исправить дубли суммированием и усреднением (sum() by (pod) / 2) не решает проблему, а запутывает данные. Прежде чем агрегировать, стоит разобраться, почему появились дубликаты.

🔹 Pause-контейнеры. В Kubernetes у каждого пода есть вспомогательный контейнер Pause. Если запрос не фильтрует его, метрики будут включать лишние значения. Добавляем условие container!="" — и дубликаты исчезают.

Мы разобрали ошибки на конкретном примере, но эти же принципы можно использовать и в других запросах.

#DevOps #Kubernetes
@digitize_IT — мнения и управленческий опыт ИТ-лидеров

Классические СХД vs объектное хранение на базе S3

Традиционные системы хранения данных (СХД) долгое время оставались основным решением для бизнеса. Однако количество данных растет: уже сейчас у половины компаний более 1 ПБ информации, и СХД уже не могут отвечать всем запросам рынка.

В качестве альтернативы стали развиваться объектные хранилища, в том числе на базе S3. По прогнозам Gartner, к 2028 году их доля составит 35% рынка корпоративных хранилищ. Разберем ключевые различия между этими решениями.

Классические СХД: ограничения и проблемы

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

Преимущества объектного хранения S3

🔹 Горизонтальное масштабирование — объем хранилища растет без ограничения.
🔹 Экономичность — более низкая стоимость хранения, особенно для архивных и редко используемых данных.
🔹 Гибкость — API-ориентированная архитектура, удобная интеграция с аналитическими и ML-инструментами.
🔹 Надежность — высокая отказоустойчивость благодаря распределенной архитектуре.

Минусы объектного хранения

🔹 Отсутствие традиционной структуры данных — доступ по ключу вместо привычной файловой системы.
🔹 Задержки при запросах — не подходит для высоконагруженных транзакционных операций.

Что выбрать?

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

#vkcloud
@digitize_IT — мнения и управленческий опыт ИТ-лидеров

Что важно знать о проектировании высоконагруженных систем 💻

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

🔹 Главная сложность в том, что мало кто проектирует системы под highload с самого начала. Чаще всего бизнес сталкивается с ростом нагрузки внезапно — и оказывается не готов к последствиям.

Где чаще всего встречаются высоконагруженные системы

🔹 Финансы: онлайн-банкинг, антифрод, мобильные платежи.
🔹 Ритейл: заказы, омниканальные продажи, логистика.
🔹 Телеком: программы лояльности, персонализация.
🔹 Медицина и страхование: обработка медданных и клиентских историй.
🔹 Производство и IoT: сбор данных с датчиков и управление процессами.

Какие подходы помогают справляться с такими нагрузками

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

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

#highload
@digitize_IT — мнения и управленческий опыт ИТ-лидеров

🔹 Что такое Real-Time-маркетинг и зачем он бизнесу

Рекламные кампании, одинаковые для всех клиентов, теперь работают хуже. Люди ждут персонального подхода, и в этом помогает Real-Time-маркетинг. Это технология, которая позволяет бизнесу обращаться к клиенту в нужный момент с точным предложением.

Основная формула RTM:

правильный продукт + правильное время + правильное место + правильный клиент

Чтобы реализовать ее, компании объединяют несколько компонентов:
🔹 потоковые данные о поведении клиента;
🔹 аналитику в реальном времени;
🔹 автоматические триггеры и персонализированные сценарии.

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

Пример из практики: как RTM работает в банках

Задача: привлечь клиентов в мобильное приложение для инвестиций, отправив персональное предложение в нужный момент.

Какие инструменты использовали

🔹 Машинное обучение. На старте применили ML-модели, чтобы сегментировать клиентов по цифровым психотипам. В расчет брали не только соцдем и историю транзакций, но и поведенческие характеристики: склонность к риску, стремление к стабильности, готовность пробовать новое.

🔹 Потоковая аналитика. Каждое действие клиента — клик в приложении, посещение определенного раздела, запрос в чате — обрабатывалось в реальном времени. Для этого использовали стриминговые движки.

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

🔹 Омниканальная доставка. В зависимости от контекста использовался нужный канал: push-уведомление в приложении, СМС, баннер на сайте. Вся логика доставки управлялась централизованной политикой триггеров.

Результат
🔹 Увеличение узнаваемости бренда с 30% до 50%.
🔹 Рост конверсии в установку приложения на 40%.

#Tarantool
@digitize_IT — мнения и управленческий опыт ИТ-лидеров

🔹 Как VK Tech развивает корпоративное ПО и выстраивает стратегию выхода на международные рынки

Директор по продуктам VK Tech Иван Мыздриков дал большое интервью Hi-Tech Mail, в котором поделился, как компания строит экосистему для цифровизации бизнеса: от облака и дата-сервисов до продуктового офиса и решений в области AI.

Смотрите, чтобы узнать:

🔹Какое будущее ждет почтовые сервисы?
🔹В чем цели и задачи экосистемы VK Tech?
🔹Зачем VK Tech выходит за пределы России — в Узбекистан, Казахстан и Китай?

Если вы разрабатываете ИТ-решения, отвечаете за импортозамещение или просто следите за рынком — это интервью стоит посмотреть.

Смотреть 🔹

#опыт #интервью
@digitize_IT — мнения и управленческий опыт ИТ-лидеров

🔹 Как Process Mining помогает ускорить разработку и устранить слепые зоны

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

Чтобы навести порядок и устранить узкие места разработки, можно внедрить технологию Process Mining.

🔹 Что такое Process Mining

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

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

🔹 Как применять Process Mining в разработке

В процессной аналитике можно выстраивать цепочку прохождения задачи по статусам. Такая схема показывает, где происходят основные задержки. Часто это этапы ожидания: «Ready for Development», «In Progress», «Ready for Test», «In Testing».

Дополнительно можно анализировать ключевые метрики:
🔹Time-to-market — от момента постановки задачи до релиза;
🔹Lead Time — от анализа до завершения разработки;
🔹Cycle Time — только разработка и тестирование.

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

🔹 Что еще можно узнать с помощью Process Mining

🔹Эффективность отдельных команд и сотрудников.
🔹Объем задач и скорость их выполнения.
🔹Долю задач с код-ревью, без него и с повторной доработкой.
🔹Качество планирования и выпусков релизов: сдвиги сроков, изменение скоупа, частоту релизов.

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

В итоге Process Mining помогает увидеть, как работают команды на практике, где теряется время и ресурсы и какие шаги можно автоматизировать. Это не только ускоряет Time-to-market, но и дает объективную основу для управленческих решений.

#processmining
@digitize_IT — мнения и управленческий опыт ИТ-лидеров

Почему стоит изучить туториалы перед работой с облаками, даже если вы опытный инженер

Российский рынок облачных услуг растет стремительно — только за 2024 год он прибавил 36,3% и достиг 165 млрд рублей. На фоне миграции бизнеса в облака все чаще возникает вопрос — как адаптироваться к новой платформе без сбоев и неожиданных ограничений?

Один из ответов — туториалы и обучающие материалы от облачных провайдеров.

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

Почему это важно даже опытным пользователям?

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

🔹 Комплексное понимание. Туториалы не просто дают обзор интерфейса, а объясняют, как лучше конфигурировать окружение, безопасно перенести данные, выстроить CI/CD или организовать хранение объектов с учетом нюансов платформы.

🔹 Практика и тест-драйв. В ряде туториалов есть практические задания — они позволяют протестировать функциональность до запуска проекта, убедиться в работоспособности и понять, какие сценарии действительно поддерживаются.

🔹 Сертификация. Многие провайдеры выдают сертификаты по итогам обучения. Это полезно как для личного профессионального роста, так и для валидации компетенций внутри команды. Особенно для интеграторов и пресейл-инженеров, которые работают с заказчиками.

Туториалы — это не курс «для начинающих». Обычно они рассчитаны на то, что у пользователя уже есть базовые знания: как устроены ВМ, что такое S3, какие задачи решает Kubernetes.

Задача туториала — не объяснить основы, а показать, как именно они реализованы в конкретном облаке.

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

#vkcloud #devops
@digitize_IT — мнения и управленческий опыт ИТ-лидеров

Иерархия ИИ-потребностей: почему не стоит начинать с вершины 🔹

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

Вот какие этапы стоит пройти, прежде чем внедрить ИИ в компанию.

🎛 Данные и инфраструктура
На нижнем уровне цепочки ИИ — сбор и хранение данных. Важно понимать, какие данные нужны, как они поступают, где хранятся и насколько легко они доступны. Если этого нет, говорить о моделях рано.

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

📈 Метрики и признаки
Когда данные готовы, можно перейти к аналитике: определить ключевые метрики, сегментировать пользователей, подготовить целевые переменные и признаки для моделей. На этом же уровне запускаются базовые алгоритмы. Это важный шаг: он позволяет построить работающую систему без сложного ML.

⚙️ Продуктовое мышление и тестирование
Если вы планируете выводить ML в прод, без инфраструктуры для A/B-тестов и итеративного развертывания не обойтись. Простая логистическая регрессия, запущенная правильно, может принести больше пользы, чем «глубокая» модель, внедренная вслепую.

📼 Наконец — ИИ
Когда все вышеописанное работает, можно переходить к сложным ML-алгоритмам. Это вершина иерархии: здесь возможны глубокое обучение, автоматизация и работа с внешними поставщиками. Но только если все нижележащее уже реализовано.

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

#AI
@digitize_IT — мнения и управленческий опыт ИТ-лидеров

Как бизнес в России выбирает почту, мессенджеры и ВКС: исследование VK Tech 🔹

Команда VK Tech провела исследование, чтобы понять, как компании в России — от стартапов до корпораций — выбирают корпоративные коммуникационные сервисы. Были опрошены 750 представителей бизнеса из разных отраслей и регионов. Вот ключевые выводы.

SaaS — выбор большинства

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

Однако среди крупных компаний и в сегменте enterprise примерно 30–35% респондентов выбирают On-premise-решения — в первую очередь из-за требований к безопасности и необходимости локального хранения данных.

Приоритеты меняются по мере роста компании

🔹 Малый бизнес выбирает простоту и скорость: важно быстро настроить и запустить сервис, а интерфейс должен быть интуитивно понятным.

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

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

Как используют коммуникационные сервисы

📌 Видеосвязь используют 91% микро- и малого бизнеса, 94% среднего, 85% крупного и 94% enterprise. Чем больше компания, тем больше значимость безопасности и функций совместной работы.

📌 Мессенджеры — один из самых востребованных инструментов: ими пользуются 91% малых компаний и 100% enterprise. В крупных компаниях важны десктопные версии, централизованное управление и защита данных.

📌 Электронная почта — основной рабочий инструмент в 86–94% компаний. Крупные игроки ожидают от почты не просто отправки писем, а полноценного набора функций: совместное редактирование, антифишинг, отслеживание задач.

📌 Редакторы документов используют 81% микро- и малого бизнеса и 100% enterprise. Основные запросы — управление доступом, интеграция с хранилищами, автоматизация форматирования.

📌 Корпоративные хранилища востребованы у 80–93% компаний независимо от масштаба.

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

#коммуникации
@digitize_IT — мнения и управленческий опыт ИТ-лидеров

📊 Как измерить эффективность КЭДО: 6 метрик для бизнеса

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

Анастасия Гуц, менеджер по развитию VK HR Tek, выделяет шесть ключевых метрик, которые помогут оценить эффективность КЭДО.

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

📌 Что считать: сколько времени раньше занимал каждый процесс и сколько сейчас. Разница покажет экономию часов специалистов.

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

📌 Что считать: затраты на бумагу и расходники, обслуживание архивов и стоимость утилизации — до и после цифровизации.

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

📌 Что считать: годовые расходы на почту и курьеров — до и после внедрения КЭДО.

🔹 Потери из-за просрочек и штрафов. Бумажные документы могут застрять между отделами, при этом контролировать сроки ознакомления и подписания сложно. Электронные системы позволяют точнее отслеживать статус, но только если процессы выстроены корректно.

📌 Что считать: сколько сотрудников не подписали документы вовремя и какую сумму могла бы потерять компания.

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

📌 Что считать: сколько документов терялось или портились до внедрения КЭДО за год или месяц.

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

📌 Что считать: время на подготовку пакета документов из архива — в бумажной и электронной системе.

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

#КЭДО #автоматизация
@digitize_IT — мнения и управленческий опыт ИТ-лидеров

Как работать с Kubernetes и не тратить лишнего: чек-лист для ИТ-команд

По данным VK Cloud, K8s используют 56% компаний, работающих с оркестраторами, и 53% из них — в облаке. Но популярность не гарантирует экономичность: неоптимальная архитектура, неаккуратная работа с ресурсами и лишние нагрузки могут дорого обойтись. Делимся практиками, которые помогут сэкономить без потери стабильности.

🔹 Архитектура. Если приложение еще в разработке, заложите микросервисную архитектуру. Так K8s будет работать эффективно «из коробки». Следуйте рекомендациям The Twelve-Factor App: собирайте минимальные образы, тестируйте нагрузки, используйте облачные PaaS.

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

🔹 Автомасштабирование. Фиксированные мощности без нагрузки — главный источник перерасхода. Вместо этого используйте:

‎🔹 HorizontalPodAutoscaler (HPA) — функция автомасштабирования в K8s, которая подстраивает число подов под нагрузку.
🔹 Автомасштабирование worker-групп — регулирует количество нод в зависимости от активности. Не забудьте задать верхние лимиты, чтобы избежать скачкообразного роста расходов при ошибках или DDoS.

🔹 Режим Spot и работа с данными. Для разовых задач и stateless-сервисов лучше использовать Spot-инстансы. Экономия составит до 90%, если учесть риски отключения. Данные храните вне контура Kubernetes — например, в S3-хранилище, чтобы не переплачивать за ресурсоемкие объемы.

🔹 Оптимизация на уровне кластера

🔹Лимиты и requests для контейнеров — контроль потребления CPU и памяти.
🔹Квоты ресурсов по namespace — предотвращают перерасход на уровне команд.
🔹Правильный размер нод — минимизирует неиспользуемые мощности.
🔹Автоотключение простаивающих кластеров — экономия на ВМ и дисках.
🔹Удаление «мусора» — старые тесты и ненужные данные быстро съедают ресурсы.

🔹 Мониторинг. Используйте OpenCost — Open-Source-инструмент, который показывает, куда уходят ресурсы и как влияют изменения. Разбивка по кластерам, подам, сервисам, namespace — это must-have для контролируемой оптимизации.

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

#vkcloud #kubernetes #devops
@digitize_IT — мнения и управленческий опыт ИТ-лидеров

Как оптимизировать разработку и внутренние процессы с помощью гибких инструментов автоматизации 💡

По оценкам исследователей, только 25% времени разработчика уходит на написание кода. Остальное — ревью, митинги, сбор требований, ручная сборка отчетов, внутренняя поддержка, работа с документацией. Чтобы высвободить время для ключевых задач, компании все чаще автоматизируют рутинные процессы. Но классических CI/CD и скриптов бывает недостаточно.

Решением могут стать гибкие инструменты класса BPM и ETL, которые позволяют обрабатывать данные и выстраивать процессы. Рассказываем, как они могут помочь в разных задачах команд разработки, на примере решения VK Data Symphony.

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

🔹 Оптимизация управления доступом. В ситуациях, когда к данным или функциям требуется ограниченный доступ (например, для апрува налоговой отчетности или финальных расчетов), платформа позволяет централизованно управлять ролями и полномочиями. Это снижает нагрузку на разработку и делает систему соответствующей требованиям ИБ.

🔹 Автоматизация сервисных процессов. Сбор данных из разных систем, расчет показателей, передача в витрины, согласование — типичный цикл, который приходится реализовывать вручную. В VK Data Symphony это можно оформить как единый сценарий, который запускается по расписанию или вручную и логирует каждый шаг.

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

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

🔹 Сборка корпоративных решений. Благодаря широкому стеку компонентов VK Data Symphony можно использовать как среду для полноценной разработки внутренних сервисов: отчетов, калькуляторов, интеграционных процессов. При этом ее легко связать с другими системами — например, через API или встроенные коннекторы.

Если команда разработки вручную собирает отчеты, отдает задачи смежным командам по почте или строит интерфейсы под каждую мелкую фичу — значит, есть потенциал для оптимизации. Гибкие low-code и data-driven-платформы вроде VK Data Symphony позволяют сократить time-to-market и сосредоточиться на задачах с бизнес-ценностью.

#разработка #автоматизация
@digitize_IT — мнения и управленческий опыт ИТ-лидеров

Мультиклауд в 2025 году: как выстроить отказоустойчивую инфраструктуру без лишних затрат 🔹

Сегодня 45% российских компаний всё еще используют одну площадку — один ЦОД или одного облачного провайдера. Такой подход удобен, но рискован: единая точка отказа, отсутствие георезервирования, невозможность быстро масштабироваться.

Чтобы снизить риски, компании всё чаще создают «второе плечо» — площадку, на которую можно перенести часть нагрузки или переключиться в случае сбоя.

Вот какие есть варианты архитектур для построения «второго плеча».

🔹 Два физических ЦОДа. Максимальный контроль, но и максимальные затраты. Нужно покупать оборудование, синхронизировать площадки, поддерживать обе. Масштабироваться сложно — только за счет покупки «железа».

🔹 Гибрид: физическая площадка + облако. Один из самых популярных вариантов. Собственная инфраструктура остаётся, облако — как запасной и масштабируемый ресурс. Обеспечивается георезервирование, быстрое восстановление, резервное копирование и масштабирование.

🔹 Мультиоблако (Multicloud). Использование сразу нескольких облачных платформ позволяет избежать привязки к одному вендору, выбрать лучшие сервисы под конкретные задачи и получить отказоустойчивость на уровне провайдеров.

Переход к распределенной инфраструктуре чаще всего начинается именно с облака. И вот почему:

🔹 Развёртывание — за минуты, без закупки оборудования.
🔹 Масштабируемость. Без запасов — по потребности.
🔹 Доступность сервисов. Облачные платформы предоставляют IaaS, S3, базы данных, резервное копирование и средства мониторинга.
🔹 Безопасность и соответствие требованиям. Можно выстроить архитектуру, которая соответствует ФЗ-152, требованиям ФСТЭК, СКЗИ и другим нормативам.

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

#vkcloud #devops
@digitize_IT — мнения и управленческий опыт ИТ-лидеров

Как объектные хранилища делают бизнес эффективнее 🔹

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

Объектные хранилища с поддержкой протокола S3 — это следующий шаг в развитии корпоративной инфраструктуры. Они работают по другому принципу: вместо сложной иерархии — плоское пространство, где каждый объект имеет уникальный ID и набор метаданных. Такая архитектура дает бизнесу важные преимущества:

🔹 Горизонтальное масштабирование. Хранилище можно расширять, просто добавляя узлы — без полной перестройки.
🔹 Быстрая интеграция с сервисами аналитики, резервного копирования, Big Data и другими.
🔹 Снижение затрат — нет необходимости закупать дорогое специализированное железо.
🔹 Простота администрирования: легче сопровождать, особенно при распределенной структуре компании.

При этом крупные компании часто отдают предпочтение On-premise-размещению объектного хранилища. Это позволяет держать данные под полным контролем и соблюдать требования по ИБ и регуляторике.

🤔 Когда не стоит использовать объектное хранилище? Если нужны минимальные задержки при доступе к данным или если речь о частой модификации небольших файлов — здесь блочные решения эффективнее. Но в большинстве сценариев — от резервного копирования и хранения мультимедиа до интеграции с CRM и ERP — объектные хранилища выигрывают.

Объектные хранилища не замена всем видам СХД, а логичное дополнение, которое дает компаниям масштаб, гибкость и контроль над данными.

#S3 #vkcloud
@digitize_IT — мнения и управленческий опыт ИТ-лидеров

💻 Как обеспечить доверенность кода и защититься от уязвимостей при корпоративной разработке

Кибератаки на бизнес растут лавинообразно: в 2024 году число инцидентов в России выросло в 2,5 раза. И почти в половине случаев точкой входа становятся веб-приложения. Для ИТ-команд это сигнал: обеспечивать безопасность нужно не только на уровне инфраструктуры, но и прямо в коде.

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

🔗 Что с этим делать?

ИТ-компании внедряют практику обеспечения доверенности кода. Это контроль всего жизненного цикла компонентов — от момента их создания или подключения до публикации и переиспользования:

🔹 верификация источников, цифровые подписи и анализ на уязвимости (SAST/DAST);
🔹 проверка на соответствие лицензиям;
🔹 изоляция и тестирование в безопасных песочницах;
🔹 мониторинг рисков на каждом этапе сборки и деплоя.

Ключевой элемент подхода — доверенный репозиторий. Это внутреннее хранилище артефактов, куда поступают только проверенные библиотеки и модули. Все загружаемые артефакты проходят автоматический и ручной аудит. На каждом этапе участвуют инженеры, администраторы и специалисты ИБ. Только после сканирования и подписания артефакты становятся доступны для разработки.

🔹 Зачем это все?

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

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

#разработка
@digitize_IT — мнения и управленческий опыт ИТ-лидеров

Что такое кросс-бизнес-разработка и зачем она нужна

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

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

ℹ️ Как это работает

Кросс-бизнес-разработка во многом похожа на кросс-платформенную. В основе — единая кодовая база и архитектура, которую адаптируют под разные окружения.

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

😀 Зачем это бизнесу

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

❗️ Но есть и минусы

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

Кросс-бизнес-разработка — это не универсальное решение, а стратегия для тех, кто работает с разными клиентами и масштабирует продукты под рынок. Если подход выстроен правильно, он позволяет выпускать надежные и гибкие ИТ-решения: один продукт, много сценариев.

#разработка
@digitize_IT — мнения и управленческий опыт ИТ-лидеров

Как бизнес работает с онлайн-документами в 2025 году: исследование VK Tech 📁

В 2025 году онлайн-документы — стандарт для всех типов компаний. Офисными редакторами пользуются 81% малого и микробизнеса, 87% представителей среднего бизнеса, 84% крупного и 100% Enterprise-сегмента.

Мы проанализировали, как именно компании используют редакторы документов. Исследование провели на базе VK WorkSpace — платформы для совместной работы, куда в 2024 году мигрировали более 600 команд. Вот главные выводы.

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

📊 Таблицы — главный инструмент B2B-команд. Именно таблицы чаще других становятся живыми рабочими документами. Более половины пользователей, которые редактируют файлы, делают это именно в таблицах. Это отражает сдвиг в сторону управления бизнесом на основе данных.

📈 На презентации приходится 5% редактируемых файлов. Их редактируют сразу после создания, а затем почти не возвращаются. Но в конце месяца и начале квартала использование презентаций резко растет: это связано с отчетностью и планированием.

#vkworkspace #исследование
@digitize_IT — мнения и управленческий опыт ИТ-лидеров

Tarantool: 10 возможностей, о которых вы могли не знать

Tarantool давно вышел за рамки In-memory-базы данных. Это мощная платформа для работы с данными, и сегодня мы напомним о возможностях, которые часто упускают даже опытные инженеры.

📼 Конфигурация в одном месте. В Tarantool 3.0 появилась поддержка кластерного YAML-конфига: теперь можно централизованно задавать топологию, роли и параметры всех узлов. В Enterprise-версии — еще и с динамической загрузкой через etcd. Подходит, если настраивать Tarantool через box.cfg слишком сложно.

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

📁 Vinyl и хранение на диске. Tarantool поддерживает Disk-based движок vinyl. Он не вытесняет In-memory-возможности, а дополняет их, позволяя создавать холодные хранилища без дополнительного стека.

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

💡 Predictable SQL. Полноценный SQL-интерфейс не новость, но многие не знают, насколько он зрелый. Сложные выборки, джойны и агрегации легко выполняются без Lua.

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

📊 Поддержка разных моделей. Tarantool — это не только Key-value: поддерживаются очереди, графы, Document storage, Column-oriented-модели и даже Federation для мультикластерных сценариев.

🔄 Гибкая архитектура транзакций. С MVCC-движком доступны отменяемые и интерактивные транзакции, стримы и настройка тайм-аутов на запросы.

🖌 Удобный интерфейс. Tarantool поставляется с дашбордами в Grafana и UI-решениями для управления кластером: Cartridge и Cluster Manager (для 3.x, Enterprise).

💳 Кластер из коробки. Модуль vshard позволяет быстро развернуть шардированный кластер. Все параметры — в одном конфиге.

Если вы до сих пор думаете, что Tarantool — это просто кэш, самое время пересмотреть подход.

#tarantool
@digitize_IT — мнения и управленческий опыт ИТ-лидеров

7 причин перейти на налоговый мониторинг 🔹

Налоговый мониторинг — это инструмент повышения прозрачности и устойчивости бизнеса. В 2025 году режим применяют 744 компании — на 30% больше, чем годом ранее. Ниже — семь причин, по которым компании выбирают налоговый мониторинг.

🔹 Повышение управляемости процессов. Переход требует системных изменений: выстраивания внутреннего контроля, перехода на ЭДО, актуализации учетной политики. Результат — более прозрачные процессы и снижение рисков ошибок. В период подготовки компании регулярно взаимодействуют с ФНС и получают консультации, что дополнительно снижает вероятность допущения критичных нарушений.

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

🔹 Снижение объема ручных запросов. Взаимодействие строится на постоянном доступе ФНС к данным: либо напрямую, либо через витрину, интегрированную с АИС «Налог-3». Это исключает необходимость вручную готовить документы по запросам, ускоряет информационный обмен и уменьшает административную нагрузку.

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

🔹 Быстрый возврат НДС и акцизов. Возврат налогов в рамках мониторинга занимает до 10 рабочих дней вместо 2–3 месяцев в общем режиме.

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

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

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

#vktaxcompliance
@digitize_IT — мнения и управленческий опыт ИТ-лидеров