Цифровизируй это

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