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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Что под капотом у 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

Безопасность 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 #КЭДО

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

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

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

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

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

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

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

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

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

Лечим проблемы 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#КЭДО #автоматизация
@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 — мнения и управленческий опыт ИТ-лидеров

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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