🔹 Как 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 — мнения и управленческий опыт ИТ-лидеров

Лечим проблемы Kubernetes по мере масштабирования проекта: разбор от VK Cloud

Один из клиентов VK Cloud решил масштабировать BI-сервис на Kubernetes с 1 000 до 5 000 подов. Но уже в первый месяц достиг 5 000 и столкнулся с задержками в etcd. Вместо стабильного кластера — лаги, нестабильность и ошибки в работе Kubernetes.

🔹 Почему масштабирование не помогло. Изначально гипотеза была в увеличении количества мастер-нод с 5 до 7. Но производительность только упала: etcd — это не просто распределенное хранилище, оно требует кворума для каждой записи. Чем больше нод, тем дольше запись. В чтении тоже не все гладко: работает через RAFT и одного лидера, даже если у вас 7 нод.

🔹 Что сработало: шардирование etcd. Вынесли часть данных (/events) из основного etcd в отдельный экземпляр с быстрым диском. Это снизило нагрузку на кластер и повысило стабильность.

🔹 На 10 000 подов — уперлись в квоту. По умолчанию квота etcd — 2 Гб. При превышении — ошибка mvcc: database space exceeded. Расширили до 8 Гб, как рекомендует etcd, и все заработало.

🔹 25 000 подов — grpc переполнен. Ошибки Helm при запросе helm list -A: размер сообщения > 2 Гб. Причина — в etcd хранилось по 7–8 релизов на каждого из 25 000 клиентов. Почистили историю релизов, выставили --history-max=2 и удалили тестовые namespace.

🔹 17 000 подов — но etcd продолжает деградировать. Снижение количества подов не помогло. Количество объектов в etcd продолжало расти из-за неочищенных секретов. Анализ показал: 63% etcd занимают secrets от Helm. Миграция secrets в Postgres вернула кластер в норму.

Выводы 🔹

🔹 Kubernetes ≠ масштаб по умолчанию. Без глубокой экспертизы мелкие проблемы становятся системными.

🔹 etcd — узкое горлышко при масштабировании. Даже «правильная» архитектура может не выдержать роста.

🔹 Настройка Helm, шардирование, контроль KV-объектов и ограничение истории релизов обязательны для больших кластеров.

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

Как перестать беспокоиться и начать внедрять интеграционные тесты

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

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

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

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

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

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

💡 Главное: не откладывайте тесты на потом — лучше запускать даже минимальные проверки, чем надеяться на ручное тестирование.

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

Безопасность HR-системы: на что стоит обратить внимание

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

Команда VK HR Tek делится техническими решениями, которые позволяют обеспечить устойчивую инфраструктуру.

⭐️ Отказоустойчивость и катастрофоустойчивость
VK HR Tek развернута в трех ЦОДах VK Tech (Tier III), данные реплицируются между ними в режиме реального времени. Это позволяет сохранять доступность даже при полном выходе из строя одного из дата-центров. SLA на простой — не более 1,6 часа в год. Поддерживается DR-сценарий и горячее резервирование.

🌐 Защита от DDoS и фильтрация трафика
На периметре работает Hitman — разработка VK Tech, которая фильтрует вредоносный трафик и защищает от перегрузок. Даже при DDoS-атаке система не теряет доступность и сохраняет целостность данных.

🔍 Полное логирование всех действий
Фиксируются как успешные действия, так и попытки доступа без прав. Логи хранятся весь срок действия контракта и могут использоваться для внутреннего аудита, расследования ИБ-инцидентов или аналитики.

🛡 Многоуровневая аутентификация
Вход в систему — только по HTTPS. Доступ возможен через 2FA и SSO. Пароли не хранятся в открытом виде, а шифруются. Поддерживаются парольные политики и разграничение доступа до конкретных ролей.

📍 Гибкое управление доступом
Каждая роль имеет строго ограниченный доступ к функциям. Изменение роли автоматически влечет пересмотр прав — это снижает риск ошибок и утечек при переводах сотрудников.

🔄 Непрерывный аудит безопасности
Платформа регулярно проходит сканирование на уязвимости, внутренние аудиты, внешний пентест и автоматическую проверку через Security Gate — пайплайн с анализаторами для выявления уязвимостей. А еще VK HR Tek участвует в Bug Bounty.

🔑 Разграничение прав на уровне продакшена
Доступ к продакшен-среде есть только у сотрудников с необходимыми правами. Установлены агенты SOC, обеспечивающие мониторинг действий на серверах.

Комплексная защита HR-систем — это не один компонент, а целый набор решений. Такой подход помогает обеспечить стабильную работу с персональными данными и снизить риски для бизнеса.

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

Что под капотом у VK Cloud: три подхода к дисковым хранилищам и их ограничения

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

Команда VK Cloud рассказала, как устроены ее дисковые хранилища и почему универсального решения до сих пор нет.

🔹 Локальный диск
Самый простой вариант — диск прямо на сервере виртуализации, на RAID. Дает до 75 000 IOPS на чтение, до 50 000 на запись. Но плохо масштабируется: VM жестко привязана к хосту, миграция медленная, потери доступа — реальны.

🔹 Ceph (SDS)
Классика для распределенного хранения: «нарезка» на объекты и репликация по мастеру. Позволяет безболезненно переносить ВМ и держит доступность. Но производительность ниже, настройка сложнее, а ребаланс при масштабировании непредсказуем.

🔹 High-IOPS
Компромисс между локальными дисками и Ceph. Диски на NVME/SSD, подключены к одному хосту, с мастером и слейвом. Чтение — до 45 000 IOPS, запись — до 30 000. Масштабируется горизонтально, но требует резервных объемов и ребалансов при расширении. Управляется просто.

🔹 Есть ли серебряная пуля?
Нет. Зато есть эксперименты с аллокацией в начале жизненного цикла, альтернативной репликацией (клиент — источник правды), и новыми технологиями: io_uring, RDMA, vhost-user-blk, Zerocopy. Пока они сложные и нишевые, но могут лечь в основу следующих поколений SDS.

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

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

Domain-Driven Design: как управлять сложными проектами и бизнес-логикой

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

Domain-Driven Design (DDD) помогает избежать этого хаоса. Он разделяет систему на понятные зоны:

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

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

Что это дает компании?

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

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

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

Как собрать и подготовить данные для процессного анализа: пошаговый план

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

Что нужно для анализа 🔄

Чтобы построить цифровой двойник процесса, технология использует три ключевых атрибута:

🔹CASE ID — уникальный номер экземпляра процесса (например, номер заказа);
🔹EVENT — событие, которое произошло (создание, сборка, доставка);
🔹TIMESTAMP — дата и время события, по которым считают длительность этапов.

Эти данные объединяют в журнал событий (Event Log) — таблицу, описывающую путь каждого экземпляра процесса. Дополнительные атрибуты, такие как информация о пользователе или поставщике, делают анализ глубже.

Как подготовить данные ↗️

1. Определить процесс для анализа — он должен быть оцифрованный, массовый, с понятными регламентами и KPI/SLA.
2. Вычислить период выгрузки: за какое время понадобятся данные.
3. Выбрать ИТ-системы, в которых фиксируются события процесса.
4. Определить объекты для выгрузки — таблицы, журналы изменений или готовые Event Log.
5. Сформировать журнал событий с обязательными атрибутами и по возможности с дополнительными данными.
6. Проверить корректность модели — загрузить данные, сверить порядок шагов, количество кейсов и время между событиями.

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

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