Цифровизируй это
Kanalga Telegram’da o‘tish
На этой площадке мы, команда VK Tech, собираем экспертные комментарии по текущей цифровой повестке, выясняем, что сейчас волнует бизнес, и выносим это на обсуждение.| tech.vk.com
Ko'proq ko'rsatish1 687
Obunachilar
Ma'lumot yo'q24 soatlar
-47 kunlar
-2530 kunlar
Ma'lumot yuklanmoqda...
O'xshash kanallar
Taglar buluti
Kirish va chiqish esdaliklari
---
---
---
---
---
---
Obunachilarni jalb qilish
Noyabr '25
Noyabr '25
+8
0 kanalda
Oktabr '25
+8
0 kanalda
Get PRO
Sentabr '25
+4
0 kanalda
Get PRO
Avgust '25
+3
0 kanalda
Get PRO
Iyul '25
+1
0 kanalda
Get PRO
Iyun '25
+2
0 kanalda
Get PRO
May '25
+2
0 kanalda
Get PRO
Aprel '25
+5
0 kanalda
Get PRO
Mart '25
+27
0 kanalda
Get PRO
Fevral '25
+110
0 kanalda
Get PRO
Yanvar '25
+126
0 kanalda
Get PRO
Dekabr '24
+8
0 kanalda
Get PRO
Noyabr '24
+24
0 kanalda
Get PRO
Oktabr '24
+18
0 kanalda
Get PRO
Sentabr '24
+8
0 kanalda
Get PRO
Avgust '24
+13
0 kanalda
Get PRO
Iyul '24
+11
1 kanalda
Get PRO
Iyun '24
+16
3 kanalda
Get PRO
May '24
+16
0 kanalda
Get PRO
Aprel '24
+15
0 kanalda
Get PRO
Mart '24
+26
0 kanalda
Get PRO
Fevral '24
+25
1 kanalda
Get PRO
Yanvar '24
+14
1 kanalda
Get PRO
Dekabr '23
+24
0 kanalda
Get PRO
Noyabr '23
+11
0 kanalda
Get PRO
Oktabr '23
+17
0 kanalda
Get PRO
Sentabr '23
+27
0 kanalda
Get PRO
Avgust '23
+37
0 kanalda
Get PRO
Iyul '23
+28
0 kanalda
Get PRO
Iyun '23
+14
0 kanalda
Get PRO
May '23
+20
0 kanalda
Get PRO
Aprel '23
+23
0 kanalda
Get PRO
Mart '23
+15
0 kanalda
Get PRO
Fevral '23
+9
0 kanalda
Get PRO
Yanvar '23
+22
0 kanalda
Get PRO
Dekabr '22
+6
0 kanalda
Get PRO
Noyabr '22
+15
0 kanalda
Get PRO
Oktabr '22
+15
0 kanalda
Get PRO
Sentabr '22
+8
0 kanalda
Get PRO
Avgust '22
+19
0 kanalda
Get PRO
Iyul '22
+147
0 kanalda
Get PRO
Iyun '22
+319
0 kanalda
Get PRO
May '22
+151
0 kanalda
Get PRO
Aprel '22
+783
0 kanalda
Get PRO
Mart '22
+30
0 kanalda
Get PRO
Fevral '22
+4
0 kanalda
Get PRO
Yanvar '22
+31
0 kanalda
Get PRO
Dekabr '21
+26
0 kanalda
Get PRO
Noyabr '21
+32
0 kanalda
Get PRO
Oktabr '21
+40
0 kanalda
Get PRO
Sentabr '21
+33
0 kanalda
Get PRO
Avgust '21
+45
0 kanalda
Get PRO
Iyul '21
+48
0 kanalda
Get PRO
Iyun '21
+30
0 kanalda
Get PRO
May '21
+18
0 kanalda
Get PRO
Aprel '21
+33
0 kanalda
Get PRO
Mart '21
+82
0 kanalda
Get PRO
Fevral '21
+274
0 kanalda
Get PRO
Yanvar '21
+316
0 kanalda
Get PRO
Dekabr '20
+1 810
0 kanalda
| Sana | Obunachilarni jalb qilish | Esdaliklar | Kanallar | |
| 25 Noyabr | +1 | |||
| 24 Noyabr | 0 | |||
| 23 Noyabr | 0 | |||
| 22 Noyabr | 0 | |||
| 21 Noyabr | 0 | |||
| 20 Noyabr | 0 | |||
| 19 Noyabr | 0 | |||
| 18 Noyabr | +3 | |||
| 17 Noyabr | 0 | |||
| 16 Noyabr | 0 | |||
| 15 Noyabr | 0 | |||
| 14 Noyabr | 0 | |||
| 13 Noyabr | 0 | |||
| 12 Noyabr | 0 | |||
| 11 Noyabr | 0 | |||
| 10 Noyabr | +1 | |||
| 09 Noyabr | 0 | |||
| 08 Noyabr | +1 | |||
| 07 Noyabr | +1 | |||
| 06 Noyabr | 0 | |||
| 05 Noyabr | 0 | |||
| 04 Noyabr | 0 | |||
| 03 Noyabr | +1 | |||
| 02 Noyabr | 0 | |||
| 01 Noyabr | 0 |
Kanal postlari
Как собрать и подготовить данные для процессного анализа: пошаговый план
Process Mining — это метод анализа бизнес-процессов на основе данных. Он строит цифровой двойник процесса и показывает, как он выполняется на самом деле. Такой подход помогает находить задержки, дублирование шагов, ошибки и точки для оптимизации.
Что нужно для анализа 🔄
Чтобы построить цифровой двойник процесса, технология использует три ключевых атрибута:
🔹CASE ID — уникальный номер экземпляра процесса (например, номер заказа);
🔹EVENT — событие, которое произошло (создание, сборка, доставка);
🔹TIMESTAMP — дата и время события, по которым считают длительность этапов.
Эти данные объединяют в журнал событий (Event Log) — таблицу, описывающую путь каждого экземпляра процесса. Дополнительные атрибуты, такие как информация о пользователе или поставщике, делают анализ глубже.
Как подготовить данные ↗️
1. Определить процесс для анализа — он должен быть оцифрованный, массовый, с понятными регламентами и KPI/SLA. 2. Вычислить период выгрузки: за какое время понадобятся данные. 3. Выбрать ИТ-системы, в которых фиксируются события процесса. 4. Определить объекты для выгрузки — таблицы, журналы изменений или готовые Event Log. 5. Сформировать журнал событий с обязательными атрибутами и по возможности с дополнительными данными. 6. Проверить корректность модели — загрузить данные, сверить порядок шагов, количество кейсов и время между событиями.Качественно собранный Event Log дает полную картину процесса и позволяет выявить узкие места, чтобы устранить их в дальнейшем. @digitize_IT — мнения и управленческий опыт ИТ-лидеров #processmining
| 2 | Domain-Driven Design: как управлять сложными проектами и бизнес-логикой
В масштабных ИТ-проектах сложность системы растет лавинообразно. Бизнес-правила переплетаются с техническими деталями, а любое изменение может затронуть критичный функционал. Такая ситуация ведет к росту стоимости сопровождения, снижению скорости разработки и увеличению числа ошибок.
Domain-Driven Design (DDD) помогает избежать этого хаоса. Он разделяет систему на понятные зоны:
🔹Бизнес-логика — все, что описывает правила и процессы компании.
🔹Техническая часть — базы данных, интеграции, API и прочее.
🔹Координирующий слой — управляет процессом и обращается к инфраструктурным компонентам.
Благодаря этому бизнес-правила живут отдельно от технологий. Вы можете менять инфраструктуру, не трогая логику, и наоборот.
Что это дает компании?
🔹 Прозрачность процессов — понятно, где именно реализовано каждое бизнес-правило, и легко отследить его изменения.
🔹 Гибкость и скорость адаптации — можно добавлять новые функции или корректировать процессы без переработки всей системы.
🔹 Снижение операционных рисков — изменения в одной части системы не ломают другую.
🔹 Долгосрочная экономия — проще поддерживать и масштабировать продукт, снижая нагрузку на команду.
DDD особенно полезен, если проект развивается долгие годы, имеет сложную структуру и бизнес-логику, а процессы часто меняются. Система остается управляемой и гибкой, а также позволяет быстро запускать новые функции. При этом команда тратит меньше времени на исправление ошибок и поддержку.
@digitize_IT — мнения и управленческий опыт ИТ-лидеров
#разработка | 249 |
| 3 | Что под капотом у 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 | 314 |
| 4 | Безопасность 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 #КЭДО | 287 |
| 5 | Как перестать беспокоиться и начать внедрять интеграционные тесты
Интеграционные автотесты — один из самых надежных способов снизить риски, сэкономить время и упростить жизнь разработчиков. Вот несколько советов, которые помогут внедрить их без боли, даже если вы работаете в сложной инфраструктуре с несколькими командами.
🔹 Начните с запуска существующих тестов. Если в проекте уже есть интеграционные тесты, пусть даже для другого окружения, попробуйте запустить их у себя. Настройте конфиги, задокументируйте ошибки, постепенно чините и пропускайте падающие тесты, чтобы изолировать проблемы.
🔹 Не делите тесты по окружениям — делайте их общими. Вместо того чтобы привязывать каждый тест к конкретной среде, указывайте, какие фичи должны быть активны. Это позволит запускать один и тот же тест в разных окружениях и избегать дублирования.
🔹 Автоматизируйте запуск и сделайте процесс прозрачным:
подключите CI и бота для ежедневных прогонов;
назначьте дежурного, который будет отслеживать падения;
при каждой новой фиче создавайте тест-кейсы и запускайте тесты заранее.
🔹 Работайте вместе с другими командами. Если вы делите проект с другими командами, договоритесь об общих принципах. Обсуждайте тесты, устраняйте конфликты по фичам, приглашайте коллег на ревью — это снижает число неожиданных багов.
🔹 Документируйте все, что может сломаться. Падения, обходные пути, ограничения фичей — все стоит фиксировать. Это поможет новичкам быстрее влиться в работу и избежать повторения одних и тех же ошибок.
💡 Главное: не откладывайте тесты на потом — лучше запускать даже минимальные проверки, чем надеяться на ручное тестирование.
@digitize_IT — мнения и управленческий опыт ИТ-лидеров
#vkcloud | 313 |
| 6 | Лечим проблемы 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 | 306 |
| 7 | 7 причин перейти на налоговый мониторинг 🔹
Налоговый мониторинг — это инструмент повышения прозрачности и устойчивости бизнеса. В 2025 году режим применяют 744 компании — на 30% больше, чем годом ранее. Ниже — семь причин, по которым компании выбирают налоговый мониторинг.
🔹 Повышение управляемости процессов. Переход требует системных изменений: выстраивания внутреннего контроля, перехода на ЭДО, актуализации учетной политики. Результат — более прозрачные процессы и снижение рисков ошибок. В период подготовки компании регулярно взаимодействуют с ФНС и получают консультации, что дополнительно снижает вероятность допущения критичных нарушений.
🔹 Существенное снижение проверок. Выездные и камеральные проверки в рамках мониторинга проводятся лишь в исключительных случаях. Это снижает затраты на сопровождение проверок, минимизирует риски доначислений и штрафов, а также высвобождает ресурсы налоговых и финансовых служб.
🔹 Снижение объема ручных запросов. Взаимодействие строится на постоянном доступе ФНС к данным: либо напрямую, либо через витрину, интегрированную с АИС «Налог-3». Это исключает необходимость вручную готовить документы по запросам, ускоряет информационный обмен и уменьшает административную нагрузку.
🔹 Профилактика, а не последствия. При выявлении расхождений инспекторы направляют запрос на разъяснение или корректировку. Кроме того, компания может сама запросить мотивированное мнение и, выполнив требования, избежать штрафов и пени.
🔹 Быстрый возврат НДС и акцизов. Возврат налогов в рамках мониторинга занимает до 10 рабочих дней вместо 2–3 месяцев в общем режиме.
🔹 Автоматизация отчетности. Благодаря специализированному ПО подготовка и передача отчетности упрощаются, снижается трудоемкость и исключаются ошибки, связанные с человеческим фактором.
🔹 Преимущества при кредитовании. Компании с налоговым мониторингом воспринимаются как более надежные заемщики. Повышенная прозрачность и снижение операционных рисков позволяют рассчитывать на более выгодные условия финансирования.
Переход на налоговый мониторинг — это не просто соответствие критериям ФНС, а стратегическое решение, которое может повысить эффективность бизнеса и упростить работу финансовых подразделений.
#vktaxcompliance
@digitize_IT — мнения и управленческий опыт ИТ-лидеров | 213 |
| 8 | 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 — мнения и управленческий опыт ИТ-лидеров | 282 |
| 9 | Как бизнес работает с онлайн-документами в 2025 году: исследование VK Tech 📁
В 2025 году онлайн-документы — стандарт для всех типов компаний. Офисными редакторами пользуются 81% малого и микробизнеса, 87% представителей среднего бизнеса, 84% крупного и 100% Enterprise-сегмента.
Мы проанализировали, как именно компании используют редакторы документов. Исследование провели на базе VK WorkSpace — платформы для совместной работы, куда в 2024 году мигрировали более 600 команд. Вот главные выводы.
📌 Тексты создают чаще всего, но редактируют не всегда. 70% всех создаваемых файлов — это текстовые документы. Однако только 47% пользователей возвращаются к ним после создания. Такие файлы чаще служат итогом или шаблоном, чем активной рабочей средой.
📊 Таблицы — главный инструмент B2B-команд. Именно таблицы чаще других становятся живыми рабочими документами. Более половины пользователей, которые редактируют файлы, делают это именно в таблицах. Это отражает сдвиг в сторону управления бизнесом на основе данных.
📈 На презентации приходится 5% редактируемых файлов. Их редактируют сразу после создания, а затем почти не возвращаются. Но в конце месяца и начале квартала использование презентаций резко растет: это связано с отчетностью и планированием.
#vkworkspace #исследование
@digitize_IT — мнения и управленческий опыт ИТ-лидеров | 282 |
| 10 | Что такое кросс-бизнес-разработка и зачем она нужна
Сегодня ИТ-продукты все чаще создаются не под одного конкретного клиента, а сразу под несколько сегментов: малый бизнес, корпорации, госсектор. Причем каждый сегмент предъявляет свои требования к инфраструктуре, безопасности, формату поставки. Одни хотят облако, другие — коробочное решение, а третьи — установку в закрытом контуре.
В таких условиях все чаще применяется подход кросс-бизнес-разработки. Он предполагает создание одного продукта, который одинаково хорошо работает в разных бизнес-сценариях — без необходимости переписывать его заново под каждый вариант.
ℹ️ Как это работает
Кросс-бизнес-разработка во многом похожа на кросс-платформенную. В основе — единая кодовая база и архитектура, которую адаптируют под разные окружения.
Функциональность не дублируется, а масштабируется — добавляется поддержка новых протоколов, требований ИБ, моделей аутентификации и способов интеграции.
😀 Зачем это бизнесу
🔹 Упрощение поддержки: одна команда, один стек, меньше ошибок.
🔹 Быстрая адаптация под нужды новых клиентов.
🔹 Выход на новые сегменты без радикальных доработок.
🔹 Единая логика обновлений и безопасности.
❗️ Но есть и минусы
Такой подход требует продуманной архитектуры, зрелой команды и дополнительных усилий при планировании. Нужно учитывать нюансы развертывания в каждом типе среды, обеспечивать совместимость и стандартизировать процессы.
Кросс-бизнес-разработка — это не универсальное решение, а стратегия для тех, кто работает с разными клиентами и масштабирует продукты под рынок. Если подход выстроен правильно, он позволяет выпускать надежные и гибкие ИТ-решения: один продукт, много сценариев.
#разработка
@digitize_IT — мнения и управленческий опыт ИТ-лидеров | 317 |
| 11 | 💻 Как обеспечить доверенность кода и защититься от уязвимостей при корпоративной разработке
Кибератаки на бизнес растут лавинообразно: в 2024 году число инцидентов в России выросло в 2,5 раза. И почти в половине случаев точкой входа становятся веб-приложения. Для ИТ-команд это сигнал: обеспечивать безопасность нужно не только на уровне инфраструктуры, но и прямо в коде.
Сегодня программная разработка — это работа со множеством внешних зависимостей, Open-Source-компонентов и внутренних библиотек. Их нельзя просто взять и исключить: без них продукты будут создаваться в разы дольше. Но именно эти компоненты могут содержать уязвимости или просто быть собраны с нарушением лицензионной политики.
🔗 Что с этим делать?
ИТ-компании внедряют практику обеспечения доверенности кода. Это контроль всего жизненного цикла компонентов — от момента их создания или подключения до публикации и переиспользования:
🔹 верификация источников, цифровые подписи и анализ на уязвимости (SAST/DAST);
🔹 проверка на соответствие лицензиям;
🔹 изоляция и тестирование в безопасных песочницах;
🔹 мониторинг рисков на каждом этапе сборки и деплоя.
Ключевой элемент подхода — доверенный репозиторий. Это внутреннее хранилище артефактов, куда поступают только проверенные библиотеки и модули. Все загружаемые артефакты проходят автоматический и ручной аудит. На каждом этапе участвуют инженеры, администраторы и специалисты ИБ. Только после сканирования и подписания артефакты становятся доступны для разработки.
🔹 Зачем это все?
Такой подход экономит время и снижает риски: вместо бесконечной проверки одной и той же библиотеки разные команды могут безопасно использовать один и тот же артефакт. Кроме того, это помогает выстроить зрелый процесс, где безопасность становится не внешним контролем, а частью культуры разработки.
Доверенность — это не про недоверие к разработчикам. Это про зрелость процесса, когда каждая строка кода и каждый подключенный компонент проходят проверку. И только в такой модели можно уверенно строить ПО, которое выдержит и масштаб, и атаки.
#разработка
@digitize_IT — мнения и управленческий опыт ИТ-лидеров | 269 |
| 12 | Как объектные хранилища делают бизнес эффективнее 🔹
Половина российских компаний уже работает с объемами данных более 1 петабайта. С таким масштабом традиционные СХД начинают «захлебываться»: их сложно масштабировать, дорого обслуживать и трудно адаптировать под распределенную инфраструктуру. К тому же они требуют специализированного оборудования и зависимы от вендоров.
Объектные хранилища с поддержкой протокола S3 — это следующий шаг в развитии корпоративной инфраструктуры. Они работают по другому принципу: вместо сложной иерархии — плоское пространство, где каждый объект имеет уникальный ID и набор метаданных. Такая архитектура дает бизнесу важные преимущества:
🔹 Горизонтальное масштабирование. Хранилище можно расширять, просто добавляя узлы — без полной перестройки.
🔹 Быстрая интеграция с сервисами аналитики, резервного копирования, Big Data и другими.
🔹 Снижение затрат — нет необходимости закупать дорогое специализированное железо.
🔹 Простота администрирования: легче сопровождать, особенно при распределенной структуре компании.
При этом крупные компании часто отдают предпочтение On-premise-размещению объектного хранилища. Это позволяет держать данные под полным контролем и соблюдать требования по ИБ и регуляторике.
🤔 Когда не стоит использовать объектное хранилище? Если нужны минимальные задержки при доступе к данным или если речь о частой модификации небольших файлов — здесь блочные решения эффективнее. Но в большинстве сценариев — от резервного копирования и хранения мультимедиа до интеграции с CRM и ERP — объектные хранилища выигрывают.
Объектные хранилища не замена всем видам СХД, а логичное дополнение, которое дает компаниям масштаб, гибкость и контроль над данными.
#S3 #vkcloud
@digitize_IT — мнения и управленческий опыт ИТ-лидеров | 280 |
| 13 | Мультиклауд в 2025 году: как выстроить отказоустойчивую инфраструктуру без лишних затрат 🔹
Сегодня 45% российских компаний всё еще используют одну площадку — один ЦОД или одного облачного провайдера. Такой подход удобен, но рискован: единая точка отказа, отсутствие георезервирования, невозможность быстро масштабироваться.
Чтобы снизить риски, компании всё чаще создают «второе плечо» — площадку, на которую можно перенести часть нагрузки или переключиться в случае сбоя.
Вот какие есть варианты архитектур для построения «второго плеча».
🔹 Два физических ЦОДа. Максимальный контроль, но и максимальные затраты. Нужно покупать оборудование, синхронизировать площадки, поддерживать обе. Масштабироваться сложно — только за счет покупки «железа».
🔹 Гибрид: физическая площадка + облако. Один из самых популярных вариантов. Собственная инфраструктура остаётся, облако — как запасной и масштабируемый ресурс. Обеспечивается георезервирование, быстрое восстановление, резервное копирование и масштабирование.
🔹 Мультиоблако (Multicloud). Использование сразу нескольких облачных платформ позволяет избежать привязки к одному вендору, выбрать лучшие сервисы под конкретные задачи и получить отказоустойчивость на уровне провайдеров.
Переход к распределенной инфраструктуре чаще всего начинается именно с облака. И вот почему:
🔹 Развёртывание — за минуты, без закупки оборудования.
🔹 Масштабируемость. Без запасов — по потребности.
🔹 Доступность сервисов. Облачные платформы предоставляют IaaS, S3, базы данных, резервное копирование и средства мониторинга.
🔹 Безопасность и соответствие требованиям. Можно выстроить архитектуру, которая соответствует ФЗ-152, требованиям ФСТЭК, СКЗИ и другим нормативам.
Мультиклауд — не хайп, а необходимость. Построение распределённой инфраструктуры с использованием облака помогает снизить риски, повысить доступность и адаптироваться к любым нагрузкам.
#vkcloud #devops
@digitize_IT — мнения и управленческий опыт ИТ-лидеров | 343 |
| 14 | Как оптимизировать разработку и внутренние процессы с помощью гибких инструментов автоматизации 💡
По оценкам исследователей, только 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 — мнения и управленческий опыт ИТ-лидеров | 350 |
| 15 | Как работать с 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 — мнения и управленческий опыт ИТ-лидеров | 309 |
| 16 | 📊 Как измерить эффективность КЭДО: 6 метрик для бизнеса
Внедрение кадрового электронного документооборота (КЭДО) — важный шаг для автоматизации HR-процессов. Но какие параметры отслеживать, чтобы оценить реальную пользу технологии для компании?
Анастасия Гуц, менеджер по развитию VK HR Tek, выделяет шесть ключевых метрик, которые помогут оценить эффективность КЭДО.
🔹 Трудозатраты кадрового отдела. Один из главных факторов — сколько времени сотрудники тратят на выполнение рутинных операций: оформление отпусков, переводов, приемов на работу. При бумажном документообороте многие процессы растягиваются на несколько дней. А после цифровизации могут выполняться за минуты.
📌 Что считать: сколько времени раньше занимал каждый процесс и сколько сейчас. Разница покажет экономию часов специалистов.
🔹 Расходы на бумагу, печать, архив и утилизацию. Бумажный документооборот — это принтеры, картриджи, тонны бумаги, аренда помещений под архивы и платные утилизационные услуги. После перехода в электронный формат эти расходы сокращаются полностью или частично.
📌 Что считать: затраты на бумагу и расходники, обслуживание архивов и стоимость утилизации — до и после цифровизации.
🔹 Затраты на логистику. Если компания работает в нескольких регионах, доставку бумажных документов часто приходится организовывать через курьеров или почту. Электронный документооборот позволяет отказаться от этой практики, но важно понять, насколько это сказывается на бюджете.
📌 Что считать: годовые расходы на почту и курьеров — до и после внедрения КЭДО.
🔹 Потери из-за просрочек и штрафов. Бумажные документы могут застрять между отделами, при этом контролировать сроки ознакомления и подписания сложно. Электронные системы позволяют точнее отслеживать статус, но только если процессы выстроены корректно.
📌 Что считать: сколько сотрудников не подписали документы вовремя и какую сумму могла бы потерять компания.
🔹 Количество утраченных и испорченных документов. Физические носители подвержены рискам: можно потерять бумагу или повредить ее. В электронных системах тоже возможны ошибки, но они проще отслеживаются и исправляются, если настроен аудит.
📌 Что считать: сколько документов терялось или портились до внедрения КЭДО за год или месяц.
🔹 Время на подготовку к проверкам. Сбор документов для проверяющих органов — одна из самых трудоемких задач. Электронные системы могут ее упростить, но эффективность зависит от настройки процессов и качества данных.
📌 Что считать: время на подготовку пакета документов из архива — в бумажной и электронной системе.
Отслеживание этих метрик помогает не только подтвердить пользу внедрения КЭДО, но и понять, какие узкие места остались. Для этого важно не ограничиваться общей оценкой, а регулярно сравнивать ключевые показатели и корректировать процессы.
#КЭДО #автоматизация
@digitize_IT — мнения и управленческий опыт ИТ-лидеров | 276 |
| 17 | Как бизнес в России выбирает почту, мессенджеры и ВКС: исследование 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 — мнения и управленческий опыт ИТ-лидеров | 323 |
| 18 | Иерархия ИИ-потребностей: почему не стоит начинать с вершины 🔹
Многие компании спешат внедрять ИИ, не задумываясь, насколько они к этому готовы. Команды нанимают первых дата-сайентистов, обсуждают гипотезы и архитектуры, но не получают эффекта. Причина в том, что, прежде чем запускать Data Science и машинное обучение, нужно построить фундамент: инфраструктуру, процессы и культуру работы с данными.
Вот какие этапы стоит пройти, прежде чем внедрить ИИ в компанию.
🎛 Данные и инфраструктура
На нижнем уровне цепочки ИИ — сбор и хранение данных. Важно понимать, какие данные нужны, как они поступают, где хранятся и насколько легко они доступны. Если этого нет, говорить о моделях рано.
🔃 Очистка и анализ
Даже если данные есть, с ними нужно работать: очищать, верифицировать, проверять на полноту и непротиворечивость. Именно на этом этапе закладывается качество всего, что будет построено выше, — от метрик и визуализаций до признаков для обучения моделей.
📈 Метрики и признаки
Когда данные готовы, можно перейти к аналитике: определить ключевые метрики, сегментировать пользователей, подготовить целевые переменные и признаки для моделей. На этом же уровне запускаются базовые алгоритмы. Это важный шаг: он позволяет построить работающую систему без сложного ML.
⚙️ Продуктовое мышление и тестирование
Если вы планируете выводить ML в прод, без инфраструктуры для A/B-тестов и итеративного развертывания не обойтись. Простая логистическая регрессия, запущенная правильно, может принести больше пользы, чем «глубокая» модель, внедренная вслепую.
📼 Наконец — ИИ
Когда все вышеописанное работает, можно переходить к сложным ML-алгоритмам. Это вершина иерархии: здесь возможны глубокое обучение, автоматизация и работа с внешними поставщиками. Но только если все нижележащее уже реализовано.
ИИ в кампании — это надстройка над четкой системой сбора, анализа и эксплуатации данных. Выстраивать эту систему стоит по принципу пирамиды: снизу вверх, шаг за шагом.
#AI
@digitize_IT — мнения и управленческий опыт ИТ-лидеров | 303 |
| 19 | Почему стоит изучить туториалы перед работой с облаками, даже если вы опытный инженер
Российский рынок облачных услуг растет стремительно — только за 2024 год он прибавил 36,3% и достиг 165 млрд рублей. На фоне миграции бизнеса в облака все чаще возникает вопрос — как адаптироваться к новой платформе без сбоев и неожиданных ограничений?
Один из ответов — туториалы и обучающие материалы от облачных провайдеров.
Разработчики облаков стремятся к тому, чтобы пользователи могли начинать работать с платформой без долгого изучения документации и ручного поиска решений. Поэтому все чаще обучение становится не дополнением, а частью продукта: это могут быть статьи, видеокурсы, практикумы и чат-боты, которые позволяют разобраться с архитектурой и сервисами до начала полноценной работы.
Почему это важно даже опытным пользователям?
🔹 Разные облака — разные подходы. Даже если специалист много лет работал, скажем, в Azure, это не гарантирует безошибочную работу в другой среде. Отличия могут быть в терминологии, логике организации сервисов, поведении балансировщиков, принципах расчета ресурсов.
🔹 Комплексное понимание. Туториалы не просто дают обзор интерфейса, а объясняют, как лучше конфигурировать окружение, безопасно перенести данные, выстроить CI/CD или организовать хранение объектов с учетом нюансов платформы.
🔹 Практика и тест-драйв. В ряде туториалов есть практические задания — они позволяют протестировать функциональность до запуска проекта, убедиться в работоспособности и понять, какие сценарии действительно поддерживаются.
🔹 Сертификация. Многие провайдеры выдают сертификаты по итогам обучения. Это полезно как для личного профессионального роста, так и для валидации компетенций внутри команды. Особенно для интеграторов и пресейл-инженеров, которые работают с заказчиками.
Туториалы — это не курс «для начинающих». Обычно они рассчитаны на то, что у пользователя уже есть базовые знания: как устроены ВМ, что такое S3, какие задачи решает Kubernetes.
Задача туториала — не объяснить основы, а показать, как именно они реализованы в конкретном облаке.
Если вы хотите сэкономить время и ресурсы на этапе миграции или развертывания новых сервисов, лучше заранее изучить гайд от провайдера. Это не формальность, а база для продуктивной работы с инфраструктурой.
#vkcloud #devops
@digitize_IT — мнения и управленческий опыт ИТ-лидеров | 373 |
| 20 | Почему стоит изучить туториалы перед работой с облаками, даже если вы опытный инженер
Российский рынок облачных услуг растет стремительно — только за 2024 год он прибавил 36,3% и достиг 165 млрд рублей. На фоне миграции бизнеса в облака все чаще возникает вопрос — как адаптироваться к новой платформе без сбоев и неожиданных ограничений?
Один из ответов — туториалы и обучающие материалы от облачных провайдеров.
Разработчики облаков стремятся к тому, чтобы пользователи могли начинать работать с платформой без долгого изучения документации и ручного поиска решений. Поэтому все чаще обучение становится не дополнением, а частью продукта: это могут быть статьи, видеокурсы, практикумы и чат-боты, которые позволяют разобраться с архитектурой и сервисами до начала полноценной работы.
Почему это важно даже опытным пользователям?
🔹 Разные облака — разные подходы. Даже если специалист много лет работал, скажем, в Azure, это не гарантирует безошибочную работу в другой среде. Отличия могут быть в терминологии, логике организации сервисов, поведении балансировщиков, принципах расчета ресурсов.
🔹 Комплексное понимание. Туториалы не просто дают обзор интерфейса, а объясняют, как лучше конфигурировать окружение, безопасно перенести данные, выстроить CI/CD или организовать хранение объектов с учетом нюансов платформы.
🔹 Практика и тест-драйв. В ряде туториалов есть практические задания — они позволяют протестировать функциональность до запуска проекта, убедиться в работоспособности и понять, какие сценарии действительно поддерживаются.
🔹 Сертификация. Многие провайдеры выдают сертификаты по итогам обучения. Это полезно как для личного профессионального роста, так и для валидации компетенций внутри команды. Особенно для интеграторов и пресейл-инженеров, которые работают с заказчиками.
Туториалы — это не курс «для начинающих». Обычно они рассчитаны на то, что у пользователя уже есть базовые знания: как устроены ВМ, что такое S3, какие задачи решает Kubernetes.
Задача туториала — не объяснить основы, а показать, как именно они реализованы в конкретном облаке.
Если вы хотите сэкономить время и ресурсы на этапе миграции или развертывания новых сервисов, лучше заранее изучить гайд от провайдера. Это не формальность, а база для продуктивной работы с инфраструктурой.
#vkcloud #devops
@digitize_IT — мнения и управленческий опыт ИТ-лидеров | 1 |
