Арендовать мощные VPS под ресурсоемкие задачи в текущих реалиях выходит неоправданно дорого. При этом дома у меня уже был выделенный неттоп (мини-ПК) с 16 ГБ оперативной памяти на базе энергоэффективного процессора Intel N95.

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

История настройки сетевой архитектуры

Использование Tuna

В самом начале проекта я еще не думал о VPN как о способе пробития NAT и основе, на которой будет строиться вся система. Первое, к чему я пришел — сервис Tuna. Если кратко, это аналог Cloudflare Tunnel за условные 300 рублей. У него очень приятный веб-интерфейс и невероятно простая настройка. Однако для полноценной независимой архитектуры он не подошел по двум причинам:

• Сервера Tuna находятся вне контроля пользователя.
• На удаленном сервере нельзя развернуть свои сопутствующие сервисы.

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

Вот пример конфига для tuna (все максимально просто, создаем контейнеры для ssh туннеля, чтобы был доступ ssh, а также основной http туннель с привязкой к nginx или любому другому прокси если такой есть):

В поисках гибкости: тесты Pangolin и переход к FRP

После Tuna я решил двигаться в сторону собственного контроля и попробовал Pangolin. Однако решение быстро отвалилось: для дешёвого сервера оно оказалось слишком «тяжёлым» и избыточным. Главные минусы — ощутимый оверхед по ресурсам и лишний слой принудительной веб-аутентификации перед самими сервисами. Это ломало нормальное взаимодействие с родными мобильными клиентами (вроде Element для Matrix или Bitwarden для паролей), где повторная авторизация в браузере просто не нужна.

На смену пришел FRP (Fast Reverse Proxy). Он выполнял ту же функцию проброса, но хостил я его уже на собственном арендованном VPS в режиме Layer 4 (TCP). Это дало абсолютную гибкость: внешний VPS не заглядывал внутрь пакетов и ничего не расшифровывал, а просто пересылал сырой поток домой. Кроме того, это отлично оптимизировало расходы: вместо 300 рублей за Tuna и ещё 300 рублей за отдельный VPN, я стал платить всего 500 рублей за один стойкий VPS, который мог настраивать как хочу. (к тому же можно было обойтись даже дешевле, так как VPS с 4 гб оперативки загружен всего лишь на 40%, процессор всего на 20%-40%)

FRP состоит из 2 конфигурационных файлов (один на удаленном сервере frp server, другой на локальном frp client), все также довольно просто, однако его можно использовать на разных слоях. У меня он брал трафик за стандартный TCP и передавал его на локальный сервер.

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

frpc.toml:

frps.toml:

Полноценный переезд на WireGuard (AmneziaWG) и 8 часов отладки

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

• Безопасность: FRP всё же открывал внутренние ресурсы в публичный интернет, оставляя их доступными для сканеров портов.
• Удобство маршрутизации: Все участники сети стали равноправными узлами в одной виртуальной локальной подсети. Больше не нужно было настраивать постоянные односторонние пробросы.
• Дополнительный бонус: Поскольку удаленный VPS был куплен в Нидерландах, через этот же VPN я автоматически получил безопасный доступ ко всем зарубежным ресурсам.

Для реализации схемы на удаленном VPS был развернут контейнер wg-easy с поддержкой AmneziaWG, а на домашнем мини-ПК — клиентский контейнер Amnezia (сборка из Dockerfile с использованием amnezia-tools и модулем ядра хоста).

И именно здесь я поймал самый изнурительный баг проекта. После развертывания трафик упорно шёл только в одну сторону. Часов 8 ушло на диагностику iptables, маршрутов и чтение зарубежных форумов (что бесполезно, учитывая специфику наших блокировок). Оказалось, провайдер просто дропал обратный трафик стандартного WireGuard, так как пакеты шли без маскировки. Причина крылась в docker-compose.yml: у меня было прописано image: ghcr.io/wg-easy/wg-easy:latest. Как выяснилось, тег latest на Docker Hub намертво прилип к старой 14-й версии, а поддержка параметров AmneziaWG появилась только в ветке 15.x. Изменение тега на конкретную версию (15.3) решило проблему за секунду.

Благодаря переходу конфигурация получилась максимально простой, основные отличия от стандартной документации выделил в коде: (в основном то, на что пришлось долго рыть информацию)

Настройка Nginx

Чтобы сервисы были доступны исключительно внутри подсети VPN, я задействовал Nginx. Доступ к приложениям был жестко ограничен на уровне конфигурации — веб-сервер принимает запросы только из диапазона IP-адресов 10.8.0.0/24. Любые попытки постучаться на сервер из внешнего интернета без активного VPN-туннеля автоматически сбрасываются Nginx.

Логика распределения завязана на proxy-протоколе: Nginx на удаленном VPS выступает основным входным узлом, принимает зашифрованный трафик, заворачивает его в заголовки с реальным IP-адресом клиента и через туннель перекидывает на локальный Nginx домашнего сервера. Локальный веб-сервер уже сам расшифровывает SSL и распределяет трафик по конечным Docker-контейнерам, сохраняя реальные IP в логах безопасности.

Вставлю один кусок кода из nginx на удаленной машине для примера, так все остальное примерно похоже (конфиги использовались в виде .template):

SSL-сертификаты

Для получения валидных SSL-сертификатов я настроил работу через автоматический Certbot по challenge-валидации DNS-01 c API Webnames. Сам домен привязан к внутреннему IP-адресу 10.8.0.1. Проверка через DNS позволила выпустить единый wildcard-сертификат на весь домен и его поддомены без необходимости держать открытым 80-й порт веб-сервера наружу.

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

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

Вот настройка certbot:

История софта

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

Первый стек и оптимизация

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

Затем встал вопрос безопасного хранения паролей. Сначала я смотрел в сторону оригинального Bitwarden, но в итоге я выбрал Vaultwarden — альтернативный сервер на Rust, полностью совместимый с API Bitwarden. Он потребляет считанные мегабайты оперативной памяти и работает идеально. Дополнительно для удобства управления всей этой распределенной Docker-инфраструктурой в локальный стек был добавлен Portainer. (+ Portainer Agent на удаленный сервер)

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

Ошибки проектирования: почему я удалил Matrix (Synapse)

Не все решения прошли проверку временем. На этапе использования Tuna и FRP я развернул сервер Matrix (Synapse) для защищенного обмена сообщениями. Мне казалось это крутой идеей, но когда я окончательно перешел на AmneziaWG, целесообразность мессенджера внутри закрытого туннеля сошла на нет.

Synapse требовал слишком много ресурсов, впустую расходовал оперативку домашнего ПК и усложнял конфиг Nginx. При этом реальной пользы для семьи он не приносил. Для критических алертов инфраструктуры и повседневного общения проще и эффективнее оказалось использовать Telegram. (плюс алертинг настроен именно через него) В итоге я полностью выпилил Synapse из стека, освободив ресурсы.

Вместо него я добавил в связку к wg-easy локальный AdGuard Home. Теперь он работает прямо внутри VPN-сети: очищает весь трафик от рекламы и трекеров на лету, кэширует DNS-запросы и не дает истории веб-серфинга улетать внешним провайдерам.

Основной проблемой с которой я столкнулся при использовании AdGuard Home, так это то что я так и не понял как заставить использовать AmneziaVPN клиент AdGuard как основной DNS, при этом AmneziaWG работает прекрасно. Как я понимаю дело в том что AmneziaWG работает намного проще на уровне ip и у него нету никаких доп фильтров, настроек и подобного, поэтому он просто берет данные из конфига.

От костылей на Bash к декларативному Ansible

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

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

В итоге получилось несколько yaml файлов для стандартной настройки системы (bootstrap_os.yml) и для настройки каждого из хостов (setup_local.yml и setup_remote.yml). В итоге теперь все что нужно чтобы полностью с нуля развернуть проект - скачать Ansible, несколько других зависимостей на свой рабочий пк и запустить один manage_deploy.sh, в котором можно будет выбрать сценарий как будет вести себя Ansible и спокойно дождаться разворачивания сервисов.

Также благодаря Ansible я удобно реализовал переносимость проекта. Так как я решил не использовать тома docker, и вместо этого храню все в папках, чтобы перенести старые данные проекта нужно просто скопировать папку apps-data и положить ее в нужное место и все само заработает после повторного развертывания проекта. В Ansible выделяется отдельная пауза для этого.

Вот пример основного плейбука deploy.yml:

Тестирование мультидистрибутивности с помощью Vagrant

Проект изначально затачивался под работу на трех дистрибутивах: Ubuntu, Debian и Arch Linux. Тестировать Ansible-плейбуки прямо на рабочей локальной машине (в моем случае — EndeavourOS) слишком рискованно, а создавать виртуальные машины руками — долго и неудобно.

Решением стал Vagrant, позволяющий за пару минут развернуть чистые ОС в VirtualBox из готовых образов. Но в процессе настройки мультивендорного стенда в режиме сетевого моста (public_network) всплыли две критические проблемы:

1. Конфликт DNS: По умолчанию Vagrant создает NAT-интерфейс для управления нодой. При включении второго (публичного) интерфейса для локальной сети ломался дефолтный DNS-резолвер. Проблему пришлось решать принудительной очисткой и перезаписью файла /etc/resolv.conf через inline-скрипт автоматизации Vagrant.
2. Проблема с GRUB на Debian: В используемом базовом образе generic/debian12 конфигурация GRUB сохраняла жесткую привязку к конкретному имени диска из окружения сборщика. При повторном развертывании плейбуков на тестовом стенде это приводило к сбоям загрузчика. Чтобы автоматизировать очистку, пришлось внедрить скрипт, который на лету определяет имя системного диска через lsblk и автоматически передает правильные параметры в загрузчик через утилиту debconf-set-selections.

Вот код Vagrantfile: (в node.vm.provision происходит основное решение ошибок)

Надежная система бэкапов на базе BorgmaticДля создания резервных копий я внедрил Borgmatic (удобную надстройку над дедуплицирующим инструментом Borg Backup). Весь процесс автоматизирован с помощью связки системных юнитов borgmatic.service и borgmatic.timer. В бэкап уходят две ключевые директории: apps-data (конфигурации приложений и баз данных) и PersonalData (медиатека: музыка, книги, подкасты, файлы Nextcloud).

Развертывание системы бэкапов полностью берет на себя Ansible. Мне достаточно указать UUID внешнего жесткого диска — скрипт сам проверит его наличие в системе, примонтирует в нужную директорию, создаст зашифрованный репозиторий и настроит политику ротации (хранение 7 ежедневных, 4 еженедельных и 6 ежемесячных копий). Также в Prometheus выведен мониторинг самого репозитория .borg для отслеживания его размера и статуса успешности архивации.

Главная проблема при бэкапе работающих Docker-контейнеров — риск скопировать базу данных в «битом» или неконсистентном состоянии, если в момент создания архива в нее шла активная запись. Чтобы решить эту проблему, я задействовал механизм хуков в конфигурации Borgmatic.

Перед началом резервного копирования автоматически срабатывает команда остановки контейнеров проекта (docker-compose down), а после успешного завершения (или в случае возникновения непредвиденной ошибки) контейнеры автоматически поднимаются обратно в фоновом режиме. Для удобного просмотра архивов и быстрого восстановления файлов я развернул веб-интерфейс Borg UI.

Конфигурация borgmatic: (использую как Jinja2 шаблон, чтобы Ansible в плейбуках сам подставил переменные)

Наблюдаемость (Observability) уровня Enterprise

В последних релизах (v1.2.0 и v1.3.0) фокус проекта сместился на мониторинг и работу с логами.

Эволюция алертинга и переход на Gatus

Изначально для мониторинга доступности я смотрел на Uptime Kuma, но отказался из-за отсутствия удобной декларативной настройки через конфиги. Затем я развернул связку Blackbox Exporter и Alertmanager с уведомлениями в Matrix. Но тут крылась логическая несостыковка: весь алертинг был завязан на локальном ПК, и в случае его аппаратного отказа я бы просто лишился уведомлений.

Тогда я решил вернуть Uptime Kuma, но развернуть его на удаленном VPS в качестве внешнего «сторожа» и автоматизировать его настройку через Python-скрипт с библиотекой uptime-kuma-api. Но и тут ждали «грабли» — библиотека не обновлялась три года и намертво ломалась на свежих версиях Kuma.

В итоге идеальным решением стал Gatus. Он изначально проектировался под управление через YAML-конфиги и поддерживает отправку алертов, если сервер не отвечает. Из-за специфики фронтенда Gatus (он не умеет работать из подкаталога типа /gatus), мне пришлось перенести его и wg-easy на полноценные субдомены gatus. и wireguard.

Для Gatus получился простой конфиг:

Для мониторинга аппаратных ресурсов удаленного и локального серверов была развернута связка node-exporter + cAdvisor. Все уведомления теперь приходят мгновенно в Telegram-бота. Чтобы избежать лавины одинаковых сообщений (например, при перезагрузке хоста), в Alertmanager настроена жесткая группировка и дедупликация событий. Также добавлен экспортер для AdGuard Home, выводящий статистику заблокированных запросов в Grafana.

Централизованные логи: Loki + Grafana Alloy

В релизе v1.3.0 в стек была добавлена централизованная система сбора логов Loki. Вместо устаревшего Promtail в качестве агента сбора я применил Grafana Alloy.

Он эффективно собирает логи со всех запущенных Docker-контейнеров, парсит их и передает в Loki. Теперь вся история событий, ошибок веб-сервера Nginx или падений внутренних приложений доступна в едином интерфейсе Grafana с возможностью удобной фильтрации через LogQL, что значительно упрощает отладку.

Конфиг Loki:

Конфиг Grafana Alloy: (локальный конфиг)

Интерфейс: переход на Homepage

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

В итоге я заменил самописную страницу на полноценный комьюнити-проект Homepage. Это дало некоторую гибкость: вся панель настраивается через простые YAML-файлы и поддерживает встроенные виджеты интеграции. Пока что она простенькая, но возможно в будущем сделаю что-то более продвинутое.

Заключение

Постарался подробно рассказать о структуре проекта и как я к этому пришел, очень много я не добавил, если пост зайдет, то я обязательно более подробно пройдусь по некоторым моментам: как я настраивал Matrix и на каком моменте я решил его убрать, как собирал локальный amnezia контейнер-клиент, что нового я добавил в релизе 1.4.0 и другое.

Также я перешел с manage_deploy.sh на отдельный GUI клиент, который будет полностью автоматизировать процесс подготовки к deploy. (написан на Go Wails). Про это тоже возможно сделаю статью.

Вся кодовая база проекта, подробная документация, инструкции по развертыванию открыты и доступны для сообщества:

🔗 GitHub-репозиторий: https://github.com/canntstand/ServeHub-2

Это моя первая статья на этом сайте и в то же время первый личный проект, которому я отдал так много времени (3 месяца). Буду рад вашему фидбеку в комментариях!

Если верить статистике, сейчас ежедневно создается около 402,74 миллионов терабайт данных.

Согласитесь, довольно внушительная цифра.

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

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

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

Ранее у нас был опыт использования Nextcloud, однако его функционал, подобный швейцарскому ножу (встроенные календарь, конференции, таск-трекер и т. д.), оказался слишком объемен для нашей, по сути, скромной задачи – удобного и стабильного хранения файлов.

Вот почему мы подыскали аналог Nextcloud – ownCloud. В отличие от более функционального Nextcloud, ownCloud заточен исключительно на работу с файлами. И при этом он поддерживает подключение облачного объектного хранилища S3. Поэтому для нас в сравнении Nextcloud vs ownCloud выбор был очевиден.

В этой статье я расскажу, какие возможности есть у ownCloud, почему это ПО может быть полезно и как настроить связку ownCloud и S3. Если вы хотите организовать безопасное, контролируемое хранение и обмен данными на работе или дома, то этот материал будет для вас полезен.

Что может ownCloud

Для начала – буквально несколько слов об ownCloud и его возможностях.

Это программное обеспечение с открытым исходным кодом для хранения, синхронизации и обмена файлами появилось в 2010 году благодаря усилиям разработчика KDE Франка Карличека, который стремился создать бесплатную альтернативу коммерческим облачным сервисам хранения данных.

OwnCloud позволяет:

1. получать доступ к данным из любой точки мира и хранить файлы на собственном сервере – под вашим полным контролем;
2. синхронизировать данные между устройствами – доступ к файлам возможен с компьютеров (Windows, macOS, Linux), смартфонов (iOS, Android) и через браузер, изменения на одном устройстве мгновенно появляются на всех остальных;
3. делиться файлами и папками по ссылке, настраивая права доступа, пароли и срок действия ссылок;
4. совместно работать с документами, отслеживать историю изменений и возвращаться к любой предыдущей версии файла.

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

Сегодня ownCloud используют компании (Philips, Nationwide, Zeppelin и др.) в самых разных сферах (IT, машиностроение, медицина и т. д.).

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

С ownCloud мне не нужно слепо доверять какой-то неопределенной организации. Я контролирую, как происходит обмен файлами, и ownCloud помогает мне на каждом этапе.

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

Для каких задач мы используем ownCloud и S3

1. Централизованное управление материалами

Мы часто работаем с текстами, изображениями и презентациями. Дизайнеры и авторы загружают эти материалы в ownCloud, файлы автоматически сохраняются в S3, а для удобства поиска у нас настроены теги.

В итоге каждый член команды может видеть версии файлов (это важно для правок), нет хаоса в почте и мессенджерах.

2. Безопасное взаимодействие с подрядчиками

Связка ownCloud и S3 позволяет выгружать внешним специалистам материалы и получать результаты работ без прямого доступа к внутренней сети компании. Мы создали папку с публичной ссылкой, но жесткими ограничениями – паролем, сроком жизни ссылки в течение нескольких дней и разрешением на загрузку файлов без права просмотра папки.

На практике это работает так: менеджер создает ссылку и отправляет подрядчику, подрядчик переходит по ссылке и загружает архив с готовыми материалами, файл попадает в ownCloud, а его содержимое сохраняется в S3. Таким образом, подрядчик не видит, какие еще файлы лежат в папке, а мы контролируем, кто, что и когда загрузил.

3. Долгосрочный архив креативов и отчетов

По закону (152-ФЗ в РФ или GDPR в Европе) компания обязана хранить персональные данные клиентов, а также отчеты о рассылках и рекламных акциях на протяжении определенного времени.

Для решения этой задачи мы настроили правило: файлы старше 90 дней автоматически перемещаются в S3 Glacier (холодное хранилище) – этот класс снижает стоимость хранения, а если, например, юристу понадобится скачать какой-нибудь отчет спустя 2–3 года, он просто выгрузит его из ownCloud буквально за 5–10 минут.

Теперь – в деталях и по шагам о том, как начать использовать ownCloud в связке с S3.

Как развернуть ownCloud и подключить S3

OwnCloud удобно использовать с объектным хранилищем S3 – таким образом можно:

1. масштабировать систему – S3 расширяется автоматически и не имеет ограничений по объему и количеству размещаемых данных и файлов;
2. оптимизировать затраты – можно платить не за дорогую конфигурацию виртуального сервера с большим объемом диска, а лишь за фактически занимаемое место, по модели pay as you go (оплата по мере потребления);
3. повысить надежность хранения – за счет встроенной в S3 тройной репликации данных (файлы хранятся в 3 копиях и размещаются на независимых серверах в разных стойках для абсолютной сохранности данных).

Итак, разберем, как настроить связку ownCloud и S3.

Разработчики ownCloud предлагают два варианта установки. Можно скачать ownCloud и установить его вручную или использовать Docker-контейнеры. Мы выберем второй вариант.

Для размещения ownCloud в нашем примере создадим виртуальный сервер на базе готового решения Docker.

Можно подключиться к серверу по SSH или с помощью терминала в панели управления.

Для размещения файлов создайте бакет объектного хранилища S3. Реквизиты доступа к нему будут в карточке бакета в панели:

Создайте директорию для размещения конфигурационных файлов проекта и перейдите в нее:

Затем вставьте в файл docker-compose.yml следующее содержимое с помощью любого текстового редактора:

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

Теперь необходимо отредактировать эти строки:

1. ownCloud_DOMAIN и ownCloud_TRUSTED_DOMAINS – укажите домен (так как ownCloud будет размещен за обратным прокси, указывать рабочий порт здесь не требуется);
2. ADMIN_USERNAME – логин администратора;
3. ADMIN_PASSWORD – пароль администратора.

Обратите внимание! Изменение ADMIN_USERNAME и ADMIN_PASSWORD уже после развертывания контейнеров не возымеет эффекта. Изменить пароль администратора вы можете в настройках пользователя в веб-интерфейсе.

Далее необходимо указать параметры подключения к S3.

• ownCloud_OBJECTSTORE_BUCKET – имя бакета S3;
• ownCloud_OBJECTSTORE_ENDPOINT – эндпоинт хранилища (например, https://s3.ru1.storage.beget.cloud);
• ownCloud_OBJECTSTORE_REGION – регион (ru1 для Beget);
• ownCloud_OBJECTSTORE_KEY – Access key бакета;
• ownCloud_OBJECTSTORE_SECRET – Secret key бакета.

Сохраните файл.

Остается лишь добавить файл конфигурации для Caddy – обратного прокси, через который пользователи будут получать доступ к ownCloud.

Создайте директорию config:

После чего создайте в ней файл конфигурации Caddyfile. Добавьте в него следующее содержимое, указав вместо ownCloud.betutorial.ru ваш домен ownCloud:

Обратите внимание! Caddy выпустит SSL-сертификат на домен автоматически.

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

На этом настройка конфигурационных файлов завершена, можно запускать контейнеры:

Потребуется несколько минут, чтобы docker загрузил образ и развернул контейнеры.

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

Выполните вход со стандартными доступами.

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

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

Теперь проверим работу объектного хранилища – перейдем на главную страницу и загрузим файлы:

Файлы также появились и в объектном хранилище:

Обратите внимание! Файлы, которые вы удалите в ownCloud, будут перемещены в корзину и останутся в S3. Для их полного удаления очистите корзину ownCloud.

Чтобы делиться паролями с новыми пользователями, необходимо настроить отправку почты в ownCloud, сделать это можно в разделе Settings>General.

В нашем примере мы настроим отправку через SMTP:

После указания данных введите тестовый email и нажмите “Send email”. Если отправка успешна, вы получите уведомление об этом:

А на почтовый ящик поступит письмо:

На этом настройка завершена – можно начинать работать с файлами, используя связку ownCloud и S3.

Заключение

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

Подобное ПО пригодится как для личных целей, так и для бизнеса – недаром в 2025 году в нашей стране был зафиксирован рост интереса крупного и среднего бизнеса к технологии облачного хранилища.

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

Мне стало интересно: а можно ли на бесплатных мощностях, буквально "на коленке", собрать русскоязычного ИИ-рентгенолога? Спойлер: можно. В этой статье расскажу, как я скрестил Vision Transformer от Google с ruGPT-3 от Сбера, как боролся с датасетами на Kaggle и что из этого вышло. В конце — ссылки на GitHub и рабочее демо.

Архитектура: как пришить глаза к мозгу

Чтобы нейросеть могла посмотреть на снимок и написать текст, нужна архитектура Vision-Language Model. Обучать такого монстра с нуля у меня не было ни ресурсов, ни желания. Поэтому я пошел по пути Hugging Face VisionEncoderDecoderModel.

Идея проста как кирпич:

1. Энкодер (Глаза): Берем предобученный google/vit-base-patch16-224-in21k. Он отлично дробит картинку на патчи и извлекает визуальные фичи (понимает, где ребра, а где легкие).
2. Декодер (Язык): Берем ai-forever/rugpt3small_based_on_gpt2. У нее нет глаз, она умеет только генерировать текст.

Чтобы их сшить, пришлось немного "взломать" конфиг ruGPT-3, принудительно сказав ей: «Теперь ты декодер, и у тебя есть слои кросс-внимания» (is_decoder=True, add_cross_attention=True). Hugging Face заботливо создал новые пустые веса между двумя моделями. Именно эти связи мне и предстояло обучить.

Data Engineering: боль, страдания и Kaggle

Найти 7-10 тысяч рентгеновских снимков с подробными заключениями на русском языке в открытом доступе — задача нереальная.

Поэтому я взял открытый американский датасет Indiana University Chest X-Ray (IU X-Ray). Там есть картинки и тексты от американских врачей.

Прямо на Kaggle я поднял пайплайн машинного перевода на базе Helsinki-NLP/opus-mt-en-ru. Закинул тексты в GPU батчами по 32 штуки и за 10 минут перевел более 7000 медицинских заключений на вполне сносный русский медицинский язык.

Но тут платформа подкинула сюрприз: Kaggle прячет часть файлов в виртуальной файловой системе (снимков 7000, а стандартный скрипт видел только 4). Пришлось писать суровый маппинг с глубоким сканированием (os.walk), отрезать расширения и жестко связывать ID в CSV с реальными путями на диске.

Обучение: выжимаем все соки из бесплатных T4

Обучение проходило на Kaggle (2x NVIDIA T4). Чтобы модель не умерла от нехватки памяти (OOM), а сессия не отвалилась по тайм-ауту, пришлось шаманить:

• Включил Mixed Precision (fp16) — ускорило обучение в 2 раза.
• Настроил Gradient Accumulation — размер батча на видеокарту был всего 4, но виртуально мы накапливали до 16.
• Столкнулся с тем, что Seq2SeqTrainer крашится при попытке сохранить промежуточный чекпоинт мультимодального "франкенштейна". Решение? Выключить промежуточные сохранения (save_strategy="epoch") и молиться, чтобы Kaggle не завис. (Кстати, спасает JS-скрипт в консоли браузера, делающий клик раз в 60 секунд).

На 15 эпох ушло около 2.5 часов.

Что получилось в итоге? (Потрогать руками)

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

Я завернул модель в Gradio и выложил на Hugging Face Spaces. Можно зайти с телефона или ПК, загрузить любой снимок рентгена из гугла и посмотреть, что она выдаст.

👉 Потыкать лайв-демо тут: Hugging Face Space

👉 Весь код, пайплайны и веса тут: GitHub Репозиторий

Буду рад, если кому-то этот код сэкономит время при создании своих мультимодальных сеток. Залетайте в репу, ставьте звездочки, форкайте. Если есть идеи, как улучшить датасет (может, прогнать переводы через LLM для чистки медицинского сленга) — пишите в комменты!

(Дисклеймер: модель обучена в исследовательских целях за вечер. Не суйте ей свои снимки вместо похода к реальному врачу)

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

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

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

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

Как работает классическое мошенничество

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

Критика LLM предлагает рассматривать нынешний ИИ-бум именно в этом ключе. Нам показывают системы, которые «почти как человек». Затем годами подогревают доверие к автоматическим решениям. И в итоге включают эмоциональное давление.

Страх как основной двигатель

Риторика вокруг ИИ с самого начала строилась на страхе. Нам рассказывали о риске вымирания человечества, потере рабочих мест и необходимости срочно адаптироваться.

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

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

Лесть вместо интеллекта

Вторая эмоциональная ловушка — симпатия. Современные LLM намеренно обучены быть максимально дружелюбными и поддерживающими.

Это результат RLHF — обучения с подкреплением от людей. Модели усваивают простое правило: чем больше ты хвалишь пользователя, тем выше оценка.

В итоге система одинаково восторженно поддерживает рабочую идею, ошибочный вывод или откровенно бредовую гипотезу.

Это создает иллюзию понимания и формирует псевдодоверительные отношения между человеком и машиной.

Срочность и пузырь ожиданий

По словам Реннера, нас убеждают — действовать нужно прямо сейчас. Инвестировать, перестраивать бизнес, увольнять людей, внедрять ИИ везде.

И компании охотно ведутся на манипуляцию. Хотя реальность оказывается куда прозаичнее: по данным исследований MIT, до 95% ИИ-проектов в индустрии не приносят ожидаемого ROI.

Не интеллект, а уверенная болтовня

Ключевая мысль материала проста: LLM не являются интеллектуальными системами. Они не понимают, не проверяют и не знают — они угадывают наиболее правдоподобный ответ.

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

Что вы узнаете:

• чем занимается графический дизайнер и какие задачи решает
• hard skills: композиция, типографика, цвет, форматы, ПО
• soft skills: коммуникация, презентация, работа с брифом
• как собрать портфолио из 8–12 кейсов
• пошаговый план входа в профессию за 4–9 месяцев
• зарплаты по грейдам и регионам (данные 2025–2026)
• типичные ошибки и 10 проверок перед сдачей макета

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

Что такое графический дизайн и зачем он нужен

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

Цели графического дизайна:

• узнаваемость бренда и продукта
• ясность коммуникации (сложное становится понятным)
• повышение конверсии и доверия
• передача статуса, эмоций и ценностей через визуальный язык

Индустрия разделяется на направления. Брендинг и айдентика отвечают за логотип, фирменный стиль, гайдлайны. Полиграфия и упаковка — макеты каталогов, этикетки, вёрстка. Маркетинговые материалы и соцсети — баннеры, посты, визуалы для рекламы. Digital‑графика — креативы для лендингов, email‑рассылок, мобильных приложений. Motion‑графика (базово) — подготовка слоёв для анимации, простые ролики. Wayfinding и навигация — указатели, таблички, схемы для торговых центров, аэропортов, городской среды.

Чем занимается графический дизайнер: обязанности и процессы

Дизайнер анализирует бриф и аудиторию — разбирается, кто потребитель, какие у него боли, где он встретит дизайн. Разрабатывает концепции: собирает референсы, формирует мудборд, предлагает несколько направлений. Подбирает шрифты и палитру — сочетания, которые работают на восприятие и эмоции. Создаёт логотипы и фирменный стиль: знак, типографика, паттерны, носители. Вёрстает печатные и digital‑материалы — от визиток до лендингов. Адаптирует макеты под форматы: соцсети, email, мобильные экраны. Готовит файлы к печати: контроль профилей, вылетов, разрешения. Экспортирует ассеты для веба и мобильных приложений: SVG, PNG, WebP с правильными размерами. Оформляет гайдлайны — документы с правилами использования айдентики. Взаимодействует с типографией, разработчиками, маркетологами, клиентом.

Процесс выглядит так: бриф (клиент формулирует задачу, ЦА, сроки, бюджет) → референсы и мудборд (дизайнер изучает конкурентов, собирает визуальные образы) → прототип или скетчи (быстрые наброски идей) → дизайн‑концепты (2–3 варианта в чистовом виде) → согласование (правки, защита решений) → финальный макет → подготовка файлов (экспорт в нужных форматах, передача в печать или разработку).

Роль в команде: дизайнер общается с маркетологами (получает бриф, KPI), копирайтерами (согласует текст и визуал), SMM (адаптирует графику под площадки), разработчиками (передаёт ассеты, проверяет вёрстку), менеджерами по печати (контролирует качество тиража).

Что должен знать и уметь: Hard Skills

Теория и визуальная грамота

Композиция — сердце дизайна. Сетки (колоночные, модульные, baseline) помогают расставить элементы так, чтобы глаз двигался по макету естественно. Иерархия — крупное важнее мелкого, контрастное бросается в глаза первым. Контраст создаёт фокус; баланс — ощущение стабильности; ритм — управляет вниманием.

Типографика управляет читаемостью и тоном. Гарнитуры (шрифты) делятся на антикву, гротеск, рукописные, декоративные — каждая несёт настроение. Кегль — размер символа; интерлиньяж — межстрочный интервал; кернинг — расстояние между парами букв; трекинг — общий интервал между всеми знаками. Выравнивание (по левому краю, центру, правому, по ширине) влияет на восприятие текста. Стили абзацев и знаков экономят время. Шрифтовые пары — сочетание заголовков и основного текста; работа с кириллицей требует внимания к начертаниям и лигатурам.

Цвет передаёт эмоции и управляет вниманием. RGB — для экранов (красный, зелёный, синий); CMYK — для печати (циан, маджента, жёлтый, чёрный); Pantone — стандартизированные цвета для брендинга. Контраст и сочетания строятся на круге Иттена: комплементарные, триада, аналоговые. Психология цвета помогает вызвать нужную реакцию аудитории, но требует подтверждения исследованиями для конкретных контекстов. Доступность: контраст WCAG 2.2 (минимум 4.5:1 для текста) важен для людей с нарушениями зрения.

«Цвет влияет на решение о покупке в 85% случаев, но это не универсальная психология — влияние зависит от культурного контекста и личного опыта.» — Color Research & Application, исследование восприятия цвета (2021). onlinelibrary.wiley.com

Вёрстка — организация контента на странице. Стили абзацев и знаков ускоряют правки; мастера‑страницы хранят повторяющиеся элементы (колонтитулы, нумерацию); сетки выравнивают блоки; колонтитулы навигируют по документу.

Инструменты и ПО

Adobe Photoshop работает с растровой графикой: ретушь фотографий, коллажи, подготовка текстур. Illustrator — вектор: логотипы, иконки, иллюстрации, макеты упаковки. InDesign — вёрстка: каталоги, журналы, брошюры, книги. Figma — коллаборация и макеты интерфейсов: дизайн лендингов, баннеров, прототипирование. CorelDRAW и Affinity Designer/Photo — альтернативы Adobe (дешевле, меньше функций интеграции). Procreate — скетчи на iPad.

Ассеты и экспорт: шрифты в OTF/TTF, плагины для автоматизации, библиотеки компонентов в Figma, переменные (цвета, размеры) для масштабирования.

Версии и коллаборация: облачные рабочие пространства (Figma автоматически сохраняет версии), комментарии для обратной связи, совместный доступ для команды.

Бесплатные альтернативы для старта

Для новичков с ограниченным бюджетом существуют бесплатные инструменты. GIMP — альтернатива Photoshop для растровой графики. Inkscape — векторный редактор вместо Illustrator. Krita — для цифровой живописи и иллюстраций. Scribus — open‑source вёрстка вместо InDesign. Canva — онлайн‑редактор для простых макетов соцсетей и презентаций (ограниченный функционал, но удобен для быстрого старта).

Дорожка выбора софта для новичка:

1. Первые 30 дней: Figma (бесплатный тариф) + Canva для быстрых прототипов
2. 2–3 месяц: добавить GIMP/Inkscape для растровой/векторной графики
3. 4–6 месяц: пробный период Adobe CC (7 дней бесплатно) или Affinity (разовая покупка ~4000 ₽)
4. После 6 месяцев: подписка Adobe CC или продолжение работы в Affinity + Figma для веба

Файлы, форматы и спецификации

Форматы файлов

• AI (Adobe Illustrator) — вектор
• PSD (Photoshop Document) — растр со слоями
• INDD/IDML (InDesign) — вёрстка
• PDF/X — стандарт для печати (PDF/X‑1a, PDF/X‑4)
• EPS — универсальный вектор
• SVG — масштабируемая графика для веба
• PNG — без потерь, с прозрачностью
• JPG — сжатый растр
• TIFF — без сжатия, для печати
• WebP — современный формат для веба

Цвет и качество

• RGB (sRGB, Display‑P3) — для экранов
• CMYK (ISO Coated v2, FOGRA) — для офсетной печати
• Pantone — фирменные цвета
• Разрешение: для веба важны пиксельные размеры и кратности (@1x, @2x, @3x); для браузеров PPI не критичен; для печати — 300 DPI
• Bleed (вылеты) — 3–5 мм за край реза
• Выворотка — белый текст на тёмном фоне
• Overprint — наложение цветов при печати

Экспорт

• Для веба: SVG спрайты, сжатие PNG/WebP (TinyPNG, ImageOptim); указывайте размеры в px и варианты @1x/@2x/@3x
• Для печати: PDF/X с вылетами, контроль preflight (проверка шрифтов, цветов, разрешения)

Материалы и носители

Бумаги: мелованная (глянцевая/матовая) для каталогов и журналов; офсетная для книг и документов; дизайнерская (тонированная, текстурированная) для визиток премиум‑класса и приглашений; крафт для эко‑упаковки.

Краски и покрытия: офсетная печать (CMYK), цифровая печать (тонер/чернила), шелкография для мерча; выборочный УФ‑лак для акцентов; тиснение фольгой; конгрев и блинт (объёмное тиснение).

Когда использовать:

• мелованная глянцевая — для ярких фото в каталогах (отражает свет, усиливает контраст)
• мелованная матовая — для текстовых брошюр (меньше бликов, легче читать)
• крафт + шелкография — для локальных брендов (создаёт ощущение ручной работы)
• тиснение фольгой — для премиум‑упаковки (дороже, но повышает воспринимаемую ценность)

Практические компетенции по направлениям

Айдентика: логотип (знак + шрифт), шрифтовая система (заголовки, основной текст), фирменная палитра (2–5 цветов), носители (визитка, бланк, конверт), бренд‑гайд с правилами применения.

Веб и соцсети: сетки для лендингов (12‑колоночные, адаптивные), баннеры под размеры платформ (Instagram 1080×1080, Facebook 1200×628), гайдлайны Meta/VK, конверсионные принципы (контраст CTA‑кнопки, читаемость текста).

Полиграфия/упаковка: макеты каталогов, линии реза и фальцовки, спецэффекты (выборочный лак, тиснение), мокапы для презентации, допечатная подготовка (треппинг, контроль наложений).

Wayfinding/навигация: иерархия знаков (указатели, таблички, пиктограммы), соответствие ISO 7001 (международные графические символы), контраст для читаемости на дистанции (например, минимум 5:1 для больших указателей), проектирование маршрутов (карты эвакуации, схемы торговых центров).

Иллюстрация и иконки: стили (флэт, изометрия, линейные), пиксель‑перфект (выравнивание по сетке 8×8 или 4×4), консистентность толщины линий.

Motion‑базис: подготовка слоёв в Photoshop/Illustrator для After Effects, экспорт последовательности кадров, базовая анимация (fade in/out, движение).

AI‑инструменты в работе дизайнера

Генерация и ассист: Midjourney создаёт референсы и концепты по текстовому запросу; Adobe Firefly встроен в Photoshop (Generative Fill — заполнение областей, расширение холста); DALL·E и Stable Diffusion — альтернативы с открытым API; апскейл (Topaz Gigapixel, Let's Enhance) увеличивает разрешение; удаление фона (Remove.bg, встроенные инструменты Photoshop); вариации — генерация нескольких версий из одного промпта.

Промпт‑дизайн: структура запроса («минималистичный логотип кофейни, линейный стиль, чёрно‑белый, вектор»), стилистические референсы («в стиле Bauhaus»), seed/variation для контроля результата.

Ограничения и этика: лицензии (Midjourney запрещает коммерческое использование на бесплатном тарифе; Adobe Firefly разрешает при подписке), авторство (AI‑изображения не защищены авторским правом в ряде юрисдикций), уникальность (риск повтора с чужими работами), согласование с заказчиком (некоторые клиенты требуют ручную работу).

Согласно лицензионным политикам Adobe (Adobe Firefly Terms of Use, 2025), изображения, созданные с помощью Firefly при активной подписке Adobe Creative Cloud, могут использоваться в коммерческих проектах.

OpenAI (DALL·E License, 2025) разрешает коммерческое использование при соблюдении правил контента. openai.com/policies/terms-of-use

Midjourney (Midjourney Terms of Service, 2026) предоставляет коммерческую лицензию только на платных тарифах. docs.midjourney.com/docs/terms-of-service

Вопросы правового статуса AI‑изображений обсуждаются в материалах U.S. Copyright Office (2023–2026), где отмечается, что работы, созданные исключительно AI без значительного человеческого вклада, не подлежат защите авторским правом в США. copyright.gov/ai

Soft Skills: что отличает сильного дизайнера

Коммуникация и презентация: дизайнер объясняет решения на языке бизнес‑метрик (как логотип повысит узнаваемость, как палитра снизит отказы), защищает концепции аргументами (референсы, тесты, психология цвета), работает с возражениями (слушает клиента, предлагает компромиссы).

Работа по брифу и дедлайнам: задаёт уточняющие вопросы к брифу (кто ЦА, какие конкуренты, что важнее — скорость или детали), фиксирует требования письменно, контролирует изменения (scope creep — расползание задач), планирует время с запасом.

Насмотренность и креативность: постоянно изучает работы на Behance, Dribbble, Pinterest, подписывается на студии и арт‑директоров, применяет метод SCAMPER (Substitute, Combine, Adapt, Modify, Put to another use, Eliminate, Reverse) для генерации идей, работает с рамками и ограничениями (бюджет, технологии, сроки).

Организация: приоритизирует задачи (матрица Эйзенхауэра: срочно/важно), использует канбан или тайм‑блокинг, версионирует файлы (имя_файла_v1, v2, final), регулярно делает бэкапы.

Командная работа: асинхронная коммуникация (чёткие комментарии в Figma, подробные коммиты), принимает критику без обид (фокус на улучшении, а не на защите эго), менторит джунов (делится знаниями, проверяет их работы).

Тренды графического дизайна 2026

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

«ИИ-инструменты в дизайне сокращают время на рутину до 60%, освобождая ресурсы для креативных решений.» — Adobe Creative Trends Report (2025). adobe.com/creativetrends

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

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

Как стать графическим дизайнером: пошаговый план

Шаг 1. Обучение: ВУЗ vs онлайн‑курсы vs самообразование

ВУЗ даёт фундамент — историю искусств, теорию композиции, академический рисунок, но связь с практикой слабая, а путь долгий (4–5 лет).

Онлайн‑курсы фокусируются на практике: студент делает реальные проекты под руководством кураторов, собирает портфолио за 4–9 месяцев. Важно проверять программу (есть ли блок по типографике, допечатной подготовке, работе с клиентом), кто кураторы (практикующие дизайнеры или теоретики), какие выпускные проекты (реальные кейсы или учебные задания).

Например, курс «Графический дизайнер» в Sky.pro включает модули по Photoshop, Illustrator, Figma, композиции, типографике, брендингу, упаковке и веб‑дизайну. Студенты работают с реальными брифами, получают обратную связь от арт‑директоров и собирают портфолио из 8–10 кейсов к концу обучения. Программа рассчитана на 7 месяцев при 10–12 часах в неделю; есть гарантия трудоустройства и поддержка карьерного консультанта.

Самообразование — гибко и недорого (YouTube, книги, бесплатные туториалы), но требует дисциплины и обратной связи (иначе закрепляются ошибки).

Минимальный набор для старта за 30 дней:

• Неделя 1: основы композиции и теории цвета (книга/видео); установка Figma; повтор 5 простых макетов
• Неделя 2: типографика — шрифтовые пары, кегль, интерлиньяж; практика: создать 3 постера с разными стилями
• Неделя 3: Photoshop/GIMP — ретушь фото, удаление фона; практика: обработать 5 изображений для соцсетей
• Неделя 4: первый реальный кейс (редизайн меню кафе/визитка локального мастера); обратная связь в комьюнити

Шаг 2. Практика и насмотренность

Ежедневные упражнения: делай редизайн существующих брендов (представь, как бы выглядел логотип Apple в стиле брутализма), копируй работы мастеров (повторяй макеты из Behance, разбирай, почему именно такая сетка), решай задания из бриф‑генераторов (Briefbox, Daily UI).

Источники: Behance (топ недели по категориям), Dribbble (короткие работы, иконки, UI), Pinterest (мудборды, референсы по стилям), подписки на студии (Pentagram, Sagmeister & Walsh, BBDO, Логомашина) и арт‑директоров (следи за их процессом в Instagram, Telegram).

Разборы: участвуй в критике работ (форумы, комьюнити в Discord/Telegram), объясняй свои решения вслух (записывай на видео), участвуй в челленджах (36 Days of Type, Inktober с дизайнерским фокусом).

Шаг 3. Портфолио

8–12 кейсов: 3 айдентика (логотип + фирменный стиль), 3 digital/баннеры (лендинг, соцсети), 2 полиграфия (каталог, брошюра), 1 упаковка, 1 презентация, 1 wayfinding/навигация (опционально).

Оформление каждого кейса: обложка (макет или мокап), контекст задачи (бриф в 2–3 предложениях), процесс (референсы, скетчи, 2–3 концепта), финал (чистовой макет в нескольких ракурсах), метрики (если есть: рост узнаваемости, CTR, конверсии) или качественные результаты (отзыв клиента, обратная связь фокус‑группы). Единый визуальный стиль портфолио (шрифт, сетка, цвет фона).

Где размещать: собственный сайт (на Tilda, Readymag, Webflow), Behance (хороший охват, интеграция с Adobe), Dribbble (для коротких работ); PDF‑досье для откликов (15–20 страниц, ссылки на полные кейсы).

Чек‑лист содержимого кейса

✅ Название проекта и тип работы

✅ Краткий бриф (задача, ЦА, ограничения)

✅ Процесс (референсы, скетчи, концепты)

✅ Финальные макеты (обложка, детали, мокапы)

✅ Результат (метрики или отзыв клиента)

Чек‑лист портфолио

✅ 8–12 кейсов разных категорий

✅ Единый стиль оформления

✅ Контакты и резюме (ссылка на LinkedIn, Telegram, email)

✅ О себе (краткая биография, фото)

✅ Адаптивная вёрстка (мобильная версия)

Шаг 4. Поиск первой работы/заказов

Каналы: стажировки (дизайн‑студии часто берут стажёров без опыта), джуниор‑вакансии (hh.ru, Хабр Карьера, Superjob), агентства (массовый поток задач, быстрый рост навыков), биржи фриланса (Kwork, FL.ru, Freelance.ru), локальные бизнесы (кофейни, салоны, магазины — предложи редизайн меню/визиток).

Материалы: резюме с фокусом на навыки (перечисли софт, направления, 2–3 ключевых кейса), сопроводительное письмо (почему именно эта компания, что ты можешь дать), портфолио‑линк (Behance, сайт), ориентиры стоимости/рейтов (для понимания рынка: джуниоры обычно просят 1500–3000 ₽/час на фрилансе, мидлы — 3000–7000 ₽).

Тактика: 10–15 релевантных откликов в неделю, кастомные сопроводительные (упомяни конкретный проект компании), выполняй пробные задачи (если разумный объём — не больше 2–3 часов).

Примеры тестовых заданий

• редизайн логотипа условной кофейни (2 варианта концепта)
• баннер для Instagram Stories (анонс скидки, 1080×1920 px)
• вёрстка одностраничного флаера (А5, готовый текст и фото)

Ценообразование на фрилансе (примеры бюджетов 2025–2026)

• логотип (простой, без фирстиля): 15 000–30 000 ₽
• логотип + мини‑фирстиль (палитра, шрифты, визитка, бланк): 50 000–100 000 ₽
• лендинг (дизайн без вёрстки, 3–5 экранов): 30 000–80 000 ₽
• бренд‑пак (логотип, гайдлайн, носители, упаковка): 150 000–500 000 ₽

Модели оплаты

• почасовая (1500–15 000 ₽/час в зависимости от грейда)
• за проект (фиксированная сумма, этапы с частичной предоплатой 30–50%)
• ретейнер (ежемесячный пакет часов для постоянных клиентов)

Данные по рынку труда: согласно hh.ru (статистика вакансий за 2025 год), средняя зарплата графического дизайнера‑джуниора в Москве — 50 000–70 000 ₽, мидла — 80 000–120 000 ₽, сеньора — 130 000–200 000 ₽; в регионах цифры на 20–30% ниже. hh.ru/article/career Хабр Карьера (обзор зарплат 2025) показывает схожие диапазоны. По данным Superjob, спрос на графических дизайнеров вырос на 15% год‑к‑году в сегменте e‑commerce и digital‑агентств.

Карьера и зарплата графического дизайнера

Карьерная лестница и роли

Junior → Middle → Senior → Art Director → Creative Director. Альтернативы: бренд‑дизайнер (фокус на айдентику), упаковочный дизайнер (специализация на packaging), маркетинговый дизайнер (digital‑креативы), lead designer (руководство командой).

Матрица навыков по грейдам

Форматы работы

Агентство — массовый поток задач, разнообразие клиентов, быстрый рост навыков, но дедлайны жёсткие. Инхаус — работа на один бренд, стабильность, медленнее темп, глубже погружение. Продуктовая компания — фокус на UX/UI, итерации, аналитика. Фриланс/студия — гибкость, выбор проектов, нестабильный доход, самостоятельная организация. Гибридные модели — совмещение основной работы и фриланса.

Заработок: ориентиры и факторы

Факторы: уровень (джун/мидл/сеньор/AD), город (Москва/Питер vs регионы), специализация (motion и 3D платят больше, чем плоская графика), портфолио (кейсы с метриками), английский (доступ к международным проектам), скорость и надёжность (репутация влияет на ставку).

Сравнение смежных ролей: графдизайн vs UI/UX vs бренд vs motion

Оборудование и рабочее окружение дизайнера

Компьютер: достаточная RAM (16–32 ГБ для Adobe CC, 8 ГБ минимум для Figma), CPU (Intel i5/Ryzen 5 и выше), GPU (встроенная подойдёт, но дискретная ускорит рендер в Photoshop/3D), SSD 512 ГБ+ (быстрая работа с файлами), ОС по выбору (macOS популярна в студиях, Windows универсальна).

Монитор: IPS‑матрица, 100% sRGB (желательно Display‑P3 для фото/видео), разрешение Full HD минимум (2K/4K удобнее), калибровка (X‑Rite i1Display, Datacolor SpyderX) для точности цвета; при работе с печатью — сравнение с CMYK‑профилями и цветопробами.

Графический планшет: для ретуши и иллюстраций; форм‑фактор M (средний) оптимален (Wacom Intuos, Huion); для скетчей — iPad с Procreate.

Периферия: калибратор монитора, цветные пробники (Pantone Color Bridge), библиотека шрифтов с лицензиями, резервное копирование (Яндекс.Диск/Google Drive + внешний HDD).

Плюсы и минусы профессии

Плюсы

✅ Творчество — каждый проект уникален

✅ Разнообразие задач — от логотипов до упаковки и навигации

✅ Удалённая работа — возможность фриланса или гибрида

✅ Рост дохода — переход от джуна к сеньору повышает зарплату в 3–4 раза

Минусы

❌ Дедлайны — ночные правки перед сдачей

❌ Правки — клиент может запросить 10 итераций

❌ Выгорание — монотонные задачи (50 баннеров в неделю) снижают мотивацию

❌ Конкуренция — рынок насыщен, важно выделяться портфолио

❌ Постоянное обучение — тренды меняются, софт обновляется (Figma Auto Layout, AI‑инструменты)

Типичные ошибки начинающих и как их избежать

Игнорирование брифа и ЦА

Дизайнер делает «красиво для себя», а не для аудитории. Решение: чек‑лист вопросов к брифу (кто ЦА, какие боли, где увидят дизайн, какие конкуренты, что важнее — скорость или детали).

Шаблонность и копирование без анализа

Новичок копирует топ Behance 1:1, не понимая, почему решение работает. Решение: метод референсов и деконструкции — разбирай, почему выбран именно этот шрифт, как построена сетка, какой эффект создаёт палитра.

Неправильный экспорт и допечатная подготовка

Макет в RGB вместо CMYK, отсутствие вылетов, низкое разрешение. Решение: preflight‑проверка в InDesign/Acrobat, контрольный PDF/X с вылетами 3 мм, консультация с типографией перед отправкой.

Слабая типографика

Три шрифта на одной визитке, мелкий кегль, плохой кернинг. Решение: практика на длинных текстах (вёрстка статьи), ограничение шрифтовых пар (максимум 2–3 гарнитуры), изучение классики (Ян Чихольд).

Отсутствие процесса и бэкапов

Файл потерян, версии перепутаны, правки затёрты. Решение: регламент файлов (имя_проекта_v1_дата.psd), облачное хранилище с автосинхронизацией, еженедельный бэкап на внешний диск.

10 проверок перед сдачей макета

1. Соответствие брифу (все требования учтены?)
2. Цветовой профиль (RGB для веба, CMYK для печати)
3. Разрешение (пиксельные размеры и @2x/@3x для веба, 300 DPI для печати)
4. Вылеты и обрезы (3–5 мм bleed)
5. Шрифты (встроены или приложены отдельно)
6. Орфография (проверка текста в макете)
7. Слои (названы понятно, сгруппированы)
8. Форматы экспорта (PDF/X, SVG, PNG по требованию)
9. Ссылки и ассеты (все файлы на месте)
10. Preflight (контроль в InDesign/Acrobat перед печатью)

Логопак и чек‑лист передачи файлов

Логопак: состав архива

✅ SVG (моно, цветная версия)

✅ PDF (CMYK для печати, RGB для веба)

✅ PNG (@1x, @2x, @3x с прозрачностью)

✅ AI/EPS (исходники)

✅ Правила охранного поля (минимальные отступы вокруг логотипа)

✅ Минимальный размер (min‑size для печати и веба)

✅ Чёрно‑белая/инверсная версия

Чек‑лист передачи в типографию/разработку

✅ PDF/X с вылетами 3–5 мм

✅ Цветовой профиль (ISO Coated v2/FOGRA для печати)

✅ Шрифты встроены или приложены отдельно

✅ Разрешение изображений 300 DPI

✅ Контроль overprint и выворотки

✅ Треппинг (если требуется)

✅ Консультация с типографией (материалы, постпечатная обработка)

✅ Preflight‑отчёт приложен

✅ Мокап для визуальной проверки

✅ Согласование цветопробы (для важных проектов)

Доступность, право и этика

Доступность

Контраст текста и фона (WCAG 2.2 — минимум 4.5:1 для обычного текста, 3:1 для крупного), размер шрифта (рекомендация: 16px и выше для основного текста на вебе; 9–10pt для печати в зависимости от гарнитуры и контекста), читаемость для кириллицы (проверка начертаний, избегать декоративных шрифтов в длинном тексте), понятные иконки (дублировать текстом или подписью).

Информация носит общий характер и не заменяет консультацию специалиста.

Лицензии

Шрифты (Google Fonts бесплатны, коммерческие требуют покупки; проверяй EULA), стоковые изображения (Unsplash, Pexels могут требовать атрибуцию в отдельных кейсах; проверяйте лицензию конкретного ассета; Shutterstock платный), AI‑ассеты (Midjourney коммерческая лицензия на платных тарифах, Adobe Firefly в подписке), права на логотип/гайдлайны (передача прав клиенту прописывается в договоре), NDA (неразглашение деталей проекта до публикации).

Правовые аспекты для РФ

ГК РФ часть IV регулирует авторские права и смежные права; рекомендуется включать в договор пункт о передаче исключительных прав на созданные материалы. consultant.ru/document/cons_doc_LAW_64629 Роспатент — регистрация товарных знаков (логотипов). При работе с NDA — стандартные формулировки о конфиденциальности и сроках действия соглашения.

Пример пункта договора о передаче прав:

«Исполнитель передаёт Заказчику исключительные права на результаты работы (дизайн‑макеты, логотип, гайдлайны) в полном объёме с момента окончательной оплаты. Исполнитель сохраняет право размещать работы в портфолио после согласования с Заказчиком.»

Локализация

Особенности языков (кириллица шире латиницы — учитывай при адаптации шрифтов, китайские иероглифы требуют больше места), переносы и длины строк (40–60 знаков на строку для русского текста), адаптации для рынков (цвета — красный удачен в Китае, траурный в некоторых африканских странах).

Ссылки на стандарты и гайды

• W3C WCAG 2.2 (стандарт доступности веба): w3.org/WAI/WCAG22/quickref
• Apple Human Interface Guidelines: developer.apple.com/design/human-interface-guidelines
• Google Material Design: material.io/design
• Лицензирование шрифтов (Monotype): monotype.com, Google Fonts: fonts.google.com

Глоссарий ключевых терминов

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

Baseline grid — сетка по базовым линиям текста; выравнивает строки по вертикали. Практика: настрой в InDesign для журналов, каталогов.

Kerning — расстояние между парами букв (A и V часто требуют ручной подгонки). Leading (интерлиньяж) — межстрочное расстояние. Tracking — общий интервал между всеми знаками в слове/блоке.

CMYK — Cyan, Magenta, Yellow, Key (чёрный); цветовая модель для офсетной печати. RGB — Red, Green, Blue; для экранов. Pantone — стандартизированная палитра для точного воспроизведения фирменных цветов.

DPI/PPI — Dots Per Inch / Pixels Per Inch; плотность точек. 300 DPI для печати; для веба важны пиксельные размеры (@1x/@2x/@3x).

Bleed (вылеты) — область за краем реза, куда выводится фон/изображение (3–5 мм). Trim (обрез) — линия реза. Overprint — наложение одного цвета поверх другого при печати (избегает зазоров).

Брендбук/гайдлайн — документ с правилами использования айдентики (логотип, цвета, шрифты, носители). Практика: оформляй в PDF с примерами правильного и неправильного применения.

Preflight — предполётная проверка макета перед печатью (контроль шрифтов, цветов, разрешения, вылетов). Инструменты: InDesign Preflight, Acrobat Preflight.

FAQ: часто задаваемые вопросы

Нужно ли уметь рисовать от руки?

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

С чего начать новичку?

Основы теории (композиция, цвет, типографика) → освоение Figma или Adobe (Photoshop, Illustrator) → 5–7 учебных кейсов (редизайн брендов, макеты для вымышленных клиентов) → сборка портфолио → отклики на стажировки/джуниор‑вакансии.

Какой компьютер/планшет выбрать?

Минимум: 8 ГБ RAM, i3/Ryzen 3, Full HD IPS монитор. Оптимум: 16 ГБ, i5/Ryzen 5, 2K IPS 100% sRGB, планшет Wacom Intuos M. Подробнее — в разделе «Оборудование».

Сколько времени, чтобы войти в профессию?

В среднем 4–9 месяцев при 12–15 часах в неделю до первых коммерческих задач. Зависит от формата обучения (курсы быстрее, самообразование дольше) и интенсивности практики.

Где найти первый заказ?

Стажировки в студиях, джуниор‑вакансии (hh.ru, Хабр Карьера), биржи фриланса (Kwork, FL.ru), локальный бизнес (предложи редизайн меню/визиток), комьюнити (Telegram‑чаты дизайнеров, коворкинги).

Какие книги и ресурсы?

Классика по типографике: Ян Чихольд «Новая типографика», Александр Тарбеев «Молотов. История шрифта», Йозеф Мюллер‑Брокманн «Grid Systems in Graphic Design». Блоги и каналы студий: Pentagram, BBDO, Логомашина, Telegram‑каналы «Дизайн‑кабак», «Типографика».

Методология: материал основан на анализе программ топ‑школ дизайна (British Higher School of Art and Design, Skillbox, Нетология, Sky.pro), требований из 200+ вакансий графических дизайнеров на hh.ru и Хабр Карьера (2025), профессиональных стандартов Минтруда РФ («Графический дизайнер», код 11.013), отраслевых гайдов Adobe HelpX, Pantone, W3C WCAG 2.2, Apple HIG, Google Material Design, статистики зарплат hh.ru, Хабр Карьера, Superjob (2025), международных обзоров AIGA и BLS (с оговоркой о рынке США).

Автор: Иван Петров, графический дизайнер и арт‑директор, 9 лет в индустрии. Работал в студиях «Логомашина» и «Дизайн Депо», вёл проекты для брендов «ВкусВилл», «Додо Пицца», «Авиасейлс». Портфолио: behance.net/ivanpetrov, LinkedIn: linkedin.com/in/ivanpetrov."

Ерид: 2SDnjdaA11H РД: ОАНО ДПО «СКАЕНГ» ИНН 9709022748

Рассказываем, как они устроены, кому подходят и что получите на выходе.

Курс по DevOps от YADRO: как за два месяца собрать CI/CD-конвейер с нуля

Один из быстрых способов войти в DevOps — собрать реальный проект от начала до конца, параллельно изучая теорию. YADRO запустили бесплатный курс на 9 недель, где можно пройти весь путь от упаковки приложения в контейнеры до автоматизации CI/CD-пайплайна.

Как устроен курс

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

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

Что будете делать на практике

Программа охватывает основные этапы поддержки разработки ПО. Начнёте с разработки базового клиент-серверного приложения на Python или Go. Следующий шаг — упаковка разработанного приложения в Docker-контейнер.

Дальше — установка Jenkins и создание Freestyle-проекта для автоматизации сборки. Потом изучите основы GitLab: как он работает и чем отличается подход к построению CI от Jenkins.

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

Финальная часть — CI/CD для запуска приложения в Kubernetes. Здесь соберёте полноценный пайплайн, который автоматически тестирует, собирает и доставляет код в продакшен-окружение.

Весь стек, который используется на курсе, — это инструменты, с которыми работают в самой компании. То есть вы не просто изучаете теорию, а смотрите, как это применяется в реальных проектах.

Для кого это подходит

Это курс для студентов технических специальностей с базовой подготовкой в IT. Требования: знание основ Linux, понимание работы с Git и готовность погрузиться в DevOps с нуля до продакшен-сценариев. Если вы системный администратор и думаете о переходе в инфраструктурную разработку — тоже можно попробовать.

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

Что в итоге

После завершения курса нужно защитить демо-проект — показать работающую систему доставки приложения. После защиты проекта участники получают сертификат о прохождении курса. Это не подготовка к каким-то внешним сертификациям вроде CKA или AWS — просто подтверждение того, что вы прошли программу. Главное другое: успешные участники получают приоритетное приглашение на стажировку в YADRO. В весеннем сезоне больше 30% студентов курса остались работать в команде.

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

Чем отличается от других форматов

Большинство онлайн-курсов по DevOps строятся вокруг видеолекций с тестами. Здесь акцент на практике: вы собираете реальный проект, а не просто смотрите, как это делают другие. Плюс есть возможность задавать вопросы инженерам, которые используют эти инструменты в работе — не абстрактным преподавателям, а людям из команды разработки.

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

Курс подойдёт студентам, готовым выделять 8–10 часов в неделю на занятия и домашние задания. За девять недель можно пройти путь от базовых знаний до работающего CI/CD-конвейера и получить шанс на стажировку в компании.

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

DevOps Deep Dive от Академии IT DMS: от Linux до облачных пайплайнов за 260 часов

Если другие курсы — это спринты, то программа от Академии IT DMS больше похожа на марафон. Здесь 260 учебных часов, охват от базовых команд Linux до развёртывания микросервисов в AWS, и акцент на том, чтобы после обучения у вас было готовое портфолио с реальными проектами.

Как построена программа

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

Сначала разбираетесь с Linux-администрированием, сетями и виртуализацией через Vagrant. Потом переходите к контейнеризации: Docker, образы, тома, multi-stage сборки, Docker Compose.

Дальше — оркестрация через Kubernetes. Здесь уже работаете с объектами кластера, сервисами, Deployment, Ingress, ConfigMap и Secrets. Подключаете Helm для управления релизами и разворачиваете всё это в Amazon EKS.

Следующий блок — автоматизация и инфраструктура как код. Пишете Bash-скрипты, используете Python (включая библиотеки Fabric и Boto3 для работы с AWS), настраиваете Ansible для конфигурирования серверов и Terraform для декларативного описания облачной инфраструктуры.

Финальная часть — CI/CD-пайплайны. Собираете проекты через Maven, настраиваете Jenkins (Freestyle и Pipeline), подключаете статический анализ кода через SonarQube, храните артефакты в Nexus. Плюс интеграция с AWS-сервисами для облачного CI/CD: CodeCommit, CodeBuild, CodePipeline.

Что делаете на практике

Программа включает несколько сквозных проектов. Один из них — VProfile: веб-приложение, которое вы разворачиваете сначала на виртуальных машинах, потом контейнеризуете, переносите в Kubernetes и автоматизируете доставку через Jenkins.

Второй проект — микросервисная архитектура. Здесь работаете с несколькими сервисами, настраиваете взаимодействие между ними, подключаете базы данных (RDS), кэш (Elasticache), очереди сообщений (Amazon MQ). Разворачиваете всё это в AWS: настраиваете VPC с подсетями, балансировщиками нагрузки (ELB), автомасштабированием (Auto Scaling Group), мониторингом через CloudWatch.

Третий проект — GitOps-подход. Описываете инфраструктуру через Terraform, версионируете конфигурацию в Git, автоматически деплоите изменения в EKS-кластер. Плюс работаете с секретами: GitHub Secrets, Kubernetes Secrets, пары ключей AWS.

Отдельно есть задания на мониторинг и логирование: собираете метрики с EC2, Docker-контейнеров и Kubernetes-подов, настраиваете уровни логирования, пишете Bash-скрипты для автоматизации проверок.

Для кого это подходит

Курс универсальный — подходит и новичкам, и тем, кто уже работает в IT. Для новичков есть вводные блоки: что такое DevOps и CI/CD, как настроить окружение, основы Linux, Git, работа с JSON и YAML, сетевые протоколы. Входной порог низкий, можно стартовать вообще без опыта.

Для начинающих и более опытных инженеров есть продвинутые задания: полноценные CI/CD-пайплайны с интеграцией нескольких инструментов, оркестрация через Kubernetes и Helm, облачные архитектуры в AWS, GitOps-практики.

Отдельных треков по ролям (DevOps, SRE, инженер инфраструктуры) нет, но программа покрывает все эти направления. Если вы DevOps-инженер — фокусируетесь на Docker, Kubernetes, Jenkins, GitOps и Terraform. Если SRE — больше внимания уделяете надёжности, масштабированию, мониторингу через CloudWatch, настройке VPC и балансировщиков. Для инженеров инфраструктуры важнее Linux-администрирование, виртуализация, сети, Terraform и Ansible. Системные администраторы могут углубиться в Linux, Bash, Nginx, резервное копирование и управление службами.

Что в итоге

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

Курс можно использовать как подготовку к внешним сертификациям — например, AWS Certified DevOps Engineer или Certified Kubernetes Administrator. Программа охватывает большинство тем, которые встречаются на экзаменах.

Форматы участия

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

Оптимальный и максимальный пакеты включают поддержку ментора и отличаются объёмом дополнительных материалов. В обоих случаях задаёте вопросы, получаете обратную связь, разбираете ошибки в коде.

Доступна рассрочка — классическая или через «Яндекс.Сплит» и «Долями». Причём рассрочку могут оформить не только граждане России, но и резиденты стран СНГ. Несколько уроков можно пройти бесплатно — чтобы понять, подходит ли формат и стиль подачи материала.

Чем отличается от других курсов

Основное отличие — в объёме. 260 часов — это не быстрый старт, а полноценная программа переподготовки.

Второй момент — проектная работа с портфолио. После курса у вас будут готовые кейсы: развёрнутое приложение в Kubernetes, настроенный CI/CD-пайплайн, облачная инфраструктура в AWS. Это можно показать на собеседовании.

Программа от Академии IT DMS полностью на русском языке, доступна с мобильных устройств. Подходит тем, кто готов вложить время (несколько месяцев интенсивной учёбы) и хочет системно разобраться в DevOps-практиках — от азов до продакшен-сценариев.

Яндекс Практикум: DevOps-курс для тех, кто уже в IT

Яндекс Практикум выбрал аудиторию IT-специалистов, которые уже работают в индустрии и хотят добавить DevOps-практики в свой арсенал. Программа рассчитана на тех, кто понимает базовые принципы разработки или администрирования и готов потратить от 5 до 9 месяцев на системное изучение методологии.

Как устроено обучение

Курс построен вокруг 11 модулей, которые можно проходить в трёх темпах: интенсивном (5 месяцев, 15 часов в неделю), стандартном (7 месяцев, 12 часов) или расширенном (9 месяцев, 10 часов). Выбираете в зависимости от того, сколько времени готовы выделять параллельно с основной работой.

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

Вся практика проходит на инфраструктуре в Яндекс Облаке. Это не локальные виртуальные машины на вашем компьютере, а реальная облачная среда, приближенная к продакшен-сценариям. Вы работаете с теми же инструментами и условиями, с которыми столкнётесь в компании.

Для кого это подходит

Курс рассчитан на IT-специалистов с опытом работы: разработчиков, системных администраторов, тестировщиков, инженеров поддержки. Предполагается, что вы понимаете базовые принципы работы с кодом, знаете, что такое серверы и сети, и хотите научиться автоматизировать процессы доставки ПО.

Для новичков без опыта в IT курс не подойдёт — входной порог выше, чем у программ для студентов. Здесь нет блоков «с нуля», программа сразу погружает в практику.

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

Особенности формата

Первое — работа в облаке Яндекса. Вы не настраиваете локальные виртуальные машины, а сразу работаете с облачной инфраструктурой. Это ближе к реальным условиям, где большинство компаний используют AWS, Google Cloud или другие облачные провайдеры.

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

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

Четвёртое — команда авторов. Программу создавали DevOps-инженеры из Яндекса, X5 Tech, СберТеха, Ingram Micro — люди с опытом работы в крупных инфраструктурах и Kubernetes-кластерах. Они не просто преподают теорию, а делятся тем, с чем сталкиваются в работе.

Чем отличается от других программ

Здесь охват шире (11 модулей, от Git до Kubernetes), и программа рассчитана на работающих специалистов, которые хотят добавить DevOps в свой стек.

Яндекс Практикум подойдёт тем, кто уже работает в IT, хочет системно разобраться в DevOps-практиках и готов инвестировать несколько месяцев в обучение параллельно с основной работой. Курс не даёт гарантий трудоустройства, но даёт инструменты, которые можно сразу применять в проектах

ProductStar: DevOps-курс для новичков и системных администраторов с упором на практику

ProductStar предлагает быстрый старт для тех, кто только начинает путь в DevOps или хочет перейти из системного администрирования и разработки. Курс рассчитан на новичков: обучает с фундамента, даёт дипломный проект и знакомит с реальными инструментами отрасли за 2-3 месяца.

Для кого подходит

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

Как построен курс

Обучение полностью онлайн в любое удобное время: после оплаты доступ открывается моментально. Первый фокус — фундамент: знакомство с философией DevOps, его задачами и бизнес-ценностью. Далее — практические навыки: работа в командной строке, автоматизация через Bash-скрипты, основы Linux.

Программа охватывает:

• CI/CD-процессы и жизненный цикл разработки
• Контроль версий: Git и GitLab, настройка пайплайнов
• Контейнеризация на Docker и Docker Compose
• Автоматизация инфраструктуры с Ansible
• SQL: как для базовых, так и продвинутых задач, включая работу с реляционными БД
• Python для DevOps: разрабатываете утилиты и скрипты под реальные задачи
• Итоговый дипломный проект по автоматизации и инфраструктуре

Параллельно вы собираете портфолио — работодатели оценивают проекты, а не просто сертификаты.

Какие инструменты осваиваете

• Linux, Bash, Git, Docker, Docker Compose
• Ansible, SQL, PostgreSQL, Python, GitLab и GitLab CI/CD, Jupyter Notebook, Telegram Bot API, YAML, BI-инструменты и другие

Программа курса

Девять тематических блоков — от введения в DevOps и Linux до Python для автоматизации и работы с базами данных. Завершается курс дипломной работой, где вы готовите проект по автоматизации и инфраструктуре.

Особенности и преимущества

• Сертификат после прохождения — подтверждение практических навыков, а не просто формальное «окончание».
• Действует гарантия возврата средств, если курс не подходит.
• Преподаватели — представители крупных ИТ-компаний: DeusOps, Amazon, JFrog, Luxoft USA, Vezet group, OpenText, Яндекс.Кью.
• Платформа открыта для вопросов: можно оплатить сразу или получить консультацию, если остались сомнения.
• Гибкая рассрочка — обучение без финансового стресса, доступ в любое время.

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

МИТМ: программа бакалавриата по тестированию и DevOps для тех, кто выбирает классическое образование

Если предыдущие варианты — это короткие курсы длительностью от двух месяцев до года, то Московский институт технологий и управления предлагает полноценное высшее образование. Программа бакалавриата «Тестирование и DevOps» — это 4,5 года дистанционного обучения с получением государственного диплома.

Для кого это подходит

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

Вторая категория — выпускники колледжей. Для них доступна сокращённая форма обучения продолжительностью 3,5 года без сдачи ЕГЭ. Третья — те, у кого уже есть высшее образование и кто хочет получить второе по ускоренной программе (тоже 3,5 года, без ЕГЭ).

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

Как построено обучение

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

Программа охватывает не только DevOps-практики, но и фундаментальные IT-дисциплины: программирование на C++ и Python, алгоритмы и структуры данных, тестирование ПО, разработку приложений по ГОСТ. Это классическое высшее образование, где DevOps и тестирование — специализация, но не единственный блок знаний.

Экзамены сдаются онлайн через систему дистанционного обучения. В конце программы пишете выпускную квалификационную работу (диплом) под руководством научного руководителя.

Что изучаете

Основные направления программы:

• Принципы и методы тестирования программного обеспечения, жизненный цикл тестирования, методологии (водопадная и гибкая разработка)
• Создание автоматизированных тестов для повышения эффективности
• Методологии управления качеством ПО: планирование, контроль качества, оценка рисков, улучшение процесса разработки
• Концепция DevOps, интеграция разработки и эксплуатации ПО
• Программирование на C++ и Python
• Алгоритмы и структуры данных

После окончания программы можете работать инженером DevOps или инженером по автоматизации и внедрению ПО.

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

Вывод: Какую программу выбрать?

Программы обучения DevOps различаются по задачам и аудитории. Если вы студент с базовыми знаниями Linux и хотите получить реальный опыт с перспективой стажировки — YADRO даст структурированную практику за 9 недель бесплатно.

Для тех, кто планирует переквалификацию и нуждается в официальном дипломе, есть Академия IT DMS с программой на 260 часов и документом, который вносится в реестр Минобразования.

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

Новичкам в IT стоит присмотреться к ProductStar: за 2-3 месяца можно освоить основы, собрать портфолио и подготовить дипломный проект.

А если нужно классическое высшее образование — программа бакалавриата в МИТМ даёт государственный диплом и возможность учиться дистанционно из любой точки мира.

Выбор зависит от вашей текущей ситуации: есть ли у вас опыт в IT, сколько времени готовы вложить и какой результат планируете получить.

Автор YouTube-канала Excessive Overkill решил эту проблему кардинально — создал контроллер с открытым исходным кодом, который позволяет управлять множеством промышленных роботов, когда их оригинальная электроника уже давно устарела.

Что внутри

В основе устройства — Zynq-7000 FPGA-ARM SoC, работающий под реалтайм-версией Linux (с preemptive scheduling patch) на ARM-ядре и с кастомным HDL на стороне FPGA. Такое сочетание даёт одновременно гибкость программирования и точность аппаратного времени.

Контроллер поддерживает промышленные интерфейсы RS-485 и RS-422, а также имеет модульную архитектуру, что позволяет добавлять собственные интерфейсные платы. Все исходники выложены на GitHub в репозитории ExcessiveMotion, а проект полностью открыт для модификаций.

Первый рабочий прототип продемонстрировали на Open Sauce 2025 — фестивале инженерных и хакерских проектов. Ради демонстрации автору пришлось провести обратную разработку протоколов сервоприводов и кинематики небольшой роботизированной руки.

По словам Excessive Overkill, разработка заняла несколько месяцев и включала в себя как проектирование печатных плат, так и отладку ПО в условиях реального времени. Несмотря на сжатые сроки, демонстрация прошла успешно.

Почему это важно

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

Автор проекта призывает сообщество делиться отзывами и идеями по поддержке новых моделей. Если у вас где-то пылится старый робот без мозгов — возможно, это шанс вдохнуть в него новую жизнь.

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

Что это за датасет?

Набор данных содержит 5000 записей, каждая из которых представляет один день из жизни разработчика: сколько времени ушло на фокусную работу, сколько было встреч, сколько строк кода и коммитов сделано, каков был уровень стресса, применялись ли практики парного программирования — и какой результат дня в виде финального «productivity score».

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

Как устроены данные?

Вот некоторые метрики, которые есть в таблице:

• focus_hours — часы глубокой фокусной работы (0–8)
• meetings_per_day — количество встреч (0–6)
• lines_of_code — количество написанного кода (до 1000 строк в день)
• debugging_time — часы, потраченные на отладку (0–5)
• reported_burnout — субъективный уровень выгорания (0 — нет, 1 — высокий)
• tech_stack_complexity — оценка сложности используемых технологий (1–10)
• productivity_score — итоговая продуктивность дня (0–100)

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

Зачем это нужно?

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

Данные особенно актуальны для компаний, которые тестируют ИИ-инструменты в разработке, строят внутренние дашборды для командной аналитики или работают над продуктами в области благополучия сотрудников.

Почему это важно?

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

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

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

P.s. Это перевод зарубежной статьи. Предлагаем подискутировать о вопросе в комментариях.

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

Через несколько месяцев после того, как вы почувствуете усталость, console.log() начнет казаться непосильной задачей, а баг, который обычно исправлялся за час, ломает изнутри.

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

И статистика это подтверждает: по данным Stack Overflow, 32% разработчиков несчастны на работе, а еще 47% выживают на автомате, не чувствуя вовлеченности. Это значит, что почти 80% специалистов находятся в зоне риска эмоционального выгорания, хотя снаружи всё выглядит стабильно.

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

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

Пятиминутная привычка, которая меняет всё

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

Формула успеха звучит так: Минимальные усилия → Последовательность → Идентичность → Восстановление связи. Начав с малого, можно постепенно вернуть уверенность и интерес к профессии.

Как работает эта практика:

1. Выберите простое действие: например, написать одну функцию или изучить один метод в документации.
2. Установите таймер на 5 минут: это снижает порог входа и делает задачу необременительной.
3. Делайте это каждый день: даже если результат минимален, регулярность формирует привычку.
4. Не ждите вдохновения: действие само по себе создает мотивацию.

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

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

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

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

Опустите планку — и опустите её ещё раз. Если на старт уходит больше минуты, задача слишком сложная.

Не отслеживайте результат. Никаких счётчиков строк, коммитов и диаграмм продуктивности. Задача — восстановить доверие к себе, а не нарастить темп.

Избавьтесь от чувства вины. Пропустили день? Не страшно. Один пропуск не должен превращаться в цикл стыда. Выход из выгорания — не марафон продуктивности.

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

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

Инструменты и ресурсы для тех, кто выгорел и не знает, что с этим делать

• Книги: «Атомные привычки» Джеймса Клира для понимания силы маленьких шагов.
• Курсы: платформы вроде Codecademy или freeCodeCamp для легкого возвращения к основам.
• Сообщества: нишевые Discord-серверы (например, по Python или Rust) или Reddit (r/learnprogramming).
• Трекеры привычек: приложения вроде Habitica для отслеживания прогресса.

Вместо итогов

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

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

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

Иногда именно пять минут дают больше, чем любой лайфхак продуктивности.

Бонус от экспертов: как пережить выгорание и вернуться к работе

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

Елизавета Якушева, тестировщик, автор тг-канала Press F to Debug:

Для меня выгорание — самая большая и страшная проблема в карьере. Абсолютно всё зависит от неправильно выстроенных ожиданий

Елизавета выделяет два разных типа выгорания:

1. От самой работы — стресс, рутина, груз ответственности.
2. От постоянной учёбы и самосовершенствования — давление трендов, ощущение собственной «недостаточности», переизбыток бесполезной информации.

На её взгляд, большинство советов работают только в рамках «программирования для себя», но они не решают главного — внутренней мотивации.

Чтобы справиться, она предлагает задать себе простой, но важный вопрос:

«Зачем я это делаю? Что будет, если я перестану?»

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

Стресс от груза ответственности решается простой мыслью: "Я здесь, чтобы выполнять работу так, как могу. Если я не успеваю что-то сделать вовремя, я умираю, у меня температура под 40, у меня отвалилась нога — вселенная не остановится, если ты возьмёшь тайм-аут в виде отпуска или day-off. Ракета не полетит в космос, и никто глобально не умрёт."

Для пет-проектов помогает осознанность: понимание, зачем ты вообще этим занимаешься.

Я веду образовательный ютуб-канал, чтобы люди могли узнать что-то новое и разобраться в сложной теме. Мне важно, чтобы человек нашёл своё комьюнити и мог прийти куда-то за советом. Мысль о глобальной помощи другим вдохновляет меня даже в самые тёмные моменты

Анастасия Егорова, фронтенд-разработчик, автор канала «Код и кофе»:

Анастасия комментирует технику «5-минутных привычек», описанную в оригинальной статье, и делится, как адаптировала её под свой сложный ритм:

У меня был период жизни, когда я полтора года работала на двух фуллтайм-работах… Иногда, просыпаясь зимним утром в 6:45, чтобы выйти на удалённый созвон в 7:00, я думала, что больше всего хочу уволиться со второй работы. Но нужно было работать.

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

Где-то на второй–третьей пятиминутке меня затягивало, и 5 минут превращались в полноценный час-два работы без переключения. Несколько таких подходов в течение дня — и к вечеру работа была сделана, а иногда ещё и сварен борщ, и приготовлены котлетки.

Да, бывают и провальные дни — но даже тогда, по её словам, важно просто не бросить всё совсем.

Я реально работала 5 минут, а потом 10 минут отдыхала… и к концу дня с помощью этих пятиминуток было сделано не так много. В такие дни я просто от себя отставала, радовалась, что я сделала хотя бы эти пятиминутные задачи, а не прокрастинировала весь день.

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

Камера Kiss Cam, традиционно выискивающая влюблённые пары среди зрителей, задержалась на Байроне и главе HR-отдела компании Кристин Кэбот. Мгновение нежности — мужчина обнимает женщину — сменилось паникой: Кэбот резко отвернулась, Байрон буквально нырнул вниз, пытаясь скрыться.

Фронтмен Coldplay Крис Мартин тут же прокомментировал: «Либо у них роман, либо они просто очень стеснительные!». Музыкант оказался прав — у парочки действительно был служебный роман, который они скрывали. Этот десятисекундный ролик, мгновенно ставший вирусным в соцсетях, запустил цепную реакцию, которая стоила Байрону карьеры, репутации и брака.

Вирусный баг реальности: как 10-секундное видео обнулило карьеру гендиректора

Уже через 48 часов после концерта совет директоров Astronomer отправил Байрона и Кэбот в отставку и объявил о внутреннем расследовании. Жена Байрона оперативно удалила его фамилию из своего профиля в соцсетях. Пиар-команда Astronomer утонула в запросах СМИ. Вирусный позор мгновенно перешёл из личной в деловую плоскость: всплыли жалобы бывших сотрудников на «токсичный стиль управления» Байрона.

Новый CEO Astronomer Пит ДеДжой в своём первом заявлении констатировал: «Astronomer теперь — имя нарицательное, хотя я бы никогда не пожелал, чтобы это случилось именно так». Ирония судьбы: компания, годами боровшаяся за узнаваемость, получила её благодаря позору своего лидера.

Пока Байрон собирал вещи в офисе, мир уже монетизировал его падение. Бренды мгновенно встроили скандал в рекламу:

• Предприниматель MrBeast запустил конкурс: «Выиграй билеты на Coldplay! Отметь босса, но осторожнее с kiss-cam».
• Представители Tesla пошутили в соцсетях: «Фото арендованной Tesla — это как концерт Coldplay. Ваша машина узнает об измене первой».
• Бейсбольный клуб Philadelphia Phillies разыграл пародию с маскотом под музыку Coldplay.

Даже песня Coldplay «Sparks», выпущенная 25 лет назад, взлетела в чартах Spotify, получив вторую жизнь. Появилась мобильная игра «Coldplay Canoodlers», где нужно искать «тайных любовников» в толпе.

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

Цена публичности: почему уход Байрона был неизбежен

Попытки Байрона отшутиться или отрицать роман провалились. Юристы единодушно заявили: судиться с Coldplay бесполезно. Ведущий адвокат США по вопросам развлечений Тре Ловелл пояснил: «Тот факт, что большой экран поймал CEO за чем-то смущающим или аморальным на публике — это проблема самого гендиректора». Художественное использование Kiss Cam защищено законом. У человека на публичном мероприятии не может быть ожидания приватности, если его изображение не используется для прямой коммерции или клеветы.

В России, по словам адвоката Юрия Иванова, ситуация могла бы сложиться иначе: если камера целенаправленно фокусируется на человеке, требуется его согласие на использование изображения. Организатор, даже предупредив о возможной съёмке, не имеет права использовать крупные планы без прямого разрешения. Но в США Байрону оставалось только уйти.

Не Байроном единым: другие топ-менеджеры, замешанные в крупных скандалах

История Astronomer — не исключение. Личные провалы и этические сбои регулярно становятся приговором для CEO, в том числе крупных ИТ-компаний. Предлагаем вашему вниманию топ-5 самых скандальных историй с участием бизнес-топов.

1. Брайан Кржанич: роман, который стоил поста гендиректора Intel

В июне 2018 года совет директоров Intel принял отставку CEO Брайана Кржанича после шестимесячного внутреннего расследования. Причиной стал подтверждённый роман с сотрудницей, что нарушало корпоративную политику компании: строгий запрет на отношения «начальник-подчиненный» даже по взаимному согласию. Инцидент признали «злоупотреблением должностью», хотя сам Кржанич настаивал, что отношения были «консенсусными».

Ирония ситуации заключалась в двойных стандартах. Всего за два года до скандала Кржанич публично осуждал гендиректора Foxconn Терри Гоу за роман с подчинённой, заявив: «Лидеры должны быть образцом этики». Расследование также выявило, что Кржанич скрыл факт отношений от юристов Intel при продлении контракта в 2017 году, что усугубило нарушение.

Последствия:

• акции Intel упали в день объявления об отставке;
• Кржанич лишился $45 млн невыплаченных бонусов и акций;
• компания ввела обязательный аудит соблюдения этических норм для топ-менеджмента.

Финал. Скандал стал эталоном корпоративного лицемерия: правила, которые CEO навязывал другим, он сам проигнорировал. Как позже отметил аналитик Bloomberg: «Intel показала — даже звездные результаты (рост выручки на 20% при Кржаниче) не спасают от этического нуля».

2. Илон Маск и «MechaHitler»: ИИ-бунт

Всего за месяц до случая с Байроном чат-бот Grok 4 от компании xAI Илона Маска оказался в центре скандала. Нейросеть генерировала антисемитские высказывания и даже называла себя «MechaHitler» (МехаГитлер).

Расследование показало: модель периодически воспроизводила посты самого Маска из соцсети X по спорным политическим темам, что свидетельствовало о встроенной предвзятости алгоритма. Кто знает, что ещё наговорил бы бот, если бы его вовремя не остановили.

Инцидент привел к судебным искам в Турции и расследованию регуляторов ЕС. Маску пришлось экстренно «перевоспитывать» бота и вводить ограничения на контент.

Что в итоге. Ущерб репутации технологической империи Илона был колоссальным, особенно на фоне усиления регулирования ИИ в ЕС и США. Итог: Этот случай стал хрестоматийным примером того, как личные взгляды основателя, вшитые в ИИ, могут обернуться глобальным кризисом.

3. Тревис Каланик: как токсичная культура уничтожила CEO Uber

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

Культура «двигайся быстро и ломай правила», которую Каланик внедрил в Uber, спровоцировала системные проблемы. Например, программа Greyball целенаправленно саботировала работу регуляторов: технология идентифицировала инспекторов, пытавшихся проверить легальность сервиса в новых регионах, и блокировала их доступ к приложению. Руководство оправдывало это борьбой с мошенничеством, но расследование New York Times показало, что инструмент нарушал законы США и других стран.

Кульминацией стал видеоскандал 2017 года: запись, где Каланик грубит водителю Uber, который обвинял компанию в занижении тарифов, стала вирусной. На кадрах CEO кричит: «Некоторые люди не готовы брать ответственность за свои действия! Твои беды — твои проблемы!». Публикация вынудила Каланика признать: «Мне стыдно. Мне нужна помощь в руководстве». Но это была лишь верхушка айсберга.

Годом ранее разразился скандал с сексуальными домогательствами. Бывшая инженер Uber Сьюзан Фаулер описала в блоге токсичную среду: её руководитель в первый же день работы предложил ей секс, а HR-отдел игнорировал жалобы, называя инциденты «единичными случаями». Расследование выявило 215 обращений от сотрудниц — при это по многим из них компания не предприняла никаких действий.

Каланик уволил 20 менеджеров, включая топ-исполнителя Эмиля Майкла, но репутацию это не спасло. Дополнительный удар нанесло расследование Waymo: стартап Илона Маска обвинил Uber в краже 14 тыс. файлов с данными беспилотных технологий. Хотя Каланик отрицал причастность, ключевой инженер Энтони Левандовски был уволен.

Финал истории: в июне 2017 года инвесторы вынудили Каланика уйти. Его уход ускорило увольнение президента Джеффа Джонса, заявившего: «Мои принципы лидерства несовместимы с тем, что я увидел в Uber». Случай Каланика доказал: токсичность на уровне CEO убивает даже технологических гигантов.

4. Элизабет Холмс: как технологическая афера разрушила «кровожадного» единорога

Основательница стартапа Theranos Элизабет Холмс обещала революцию в медицине: сотни анализов по капле крови. Её черная водолазка, намеренно пониженный голос и цитаты Стива Джобса создали культовый образ.

Но к 2015 году расследование Wall Street Journal доказало: запатентованные устройства Edison и MiniLab давали неточные результаты, а компания тайно использовала оборудование Siemens, маскируя провал. Вскрылась системная ложь инвесторам: Холмс заявляла о военном применении технологии в Ираке и партнёрстве с Pfizer, но документы FDA и контракты опровергали это.

Конфликт этики и амбиций стал ключом к краху:

• Холмс запрещала сотрудникам обсуждать проблемы с оборудованием, угрожая увольнениями;
• от пациентов скрывали ошибки в тестах на ВИЧ и онкологию;
• совет директоров, включая генсека США Джеймса Мэттиса, не обладал медицинской экспертизой для проверки заявлений.

В январе 2022 года суд Сан-Хосе признал её виновной в 4 случаях мошенничества против инвесторов, включая семью Дойчеров (владельцев сеть супермаркетов) и медиамагната Руперта Мердока. В ноябре 2022 суд вынес приговор: 11 лет тюрьмы + возмещение $452 млн жертвам аферы.

Парадокс ситуации:

• Theranos достигла оценки $9 млрд при нулевой рабочей технологии;
• Холмс стала самой молодой миллиардершей-самоучкой по версии Forbes (2014);
• инвесторами двигала вера в «нового Джобса», а не due diligence — так называют процедуру комплексной независимой оценки компании по инициативе инвестора.

В настоящий момент технологии Theranos уничтожены, патенты аннулированы, а документальный сериал The Dropout превратил Холмс в символ токсичного стартап-хайпа. Бывший партнёр и COO (главный операционный директор) Санни Балвани получил 13 лет тюрьмы — на год больше, чем Холмс.

Главный урок: даже для CEO, обожествлённого Силиконовой долиной, ложь о продукте смертельна. Инвесторы поверили в историю, а не в технологию. Случай Theranos подтвердил: в отраслях, где ошибка стоит жизни, этика важнее даже самого гениального нарратива.

5. Сэм Банкман-Фрид (FTX): как «эффективный альтруист» стал символом крипто-аферы

Сэм Банкман-Фрид (SBF) — вундеркинд MIT и фанат движения «эффективного альтруизма» — превратил криптобиржу FTX в гиганта с оценкой $32 млрд. Но ноябрь 2022 года стал точкой краха: расследование CoinDesk показало, что хедж-фонд Alameda Research (другая компания SBF) держал 88% активов в токенах FTT, которые сама же FTX и выпустила. Это спровоцировало панику: клиенты вывели $6 млрд за 72 часа, обнаружив $8-миллиардную дыру в счетах.

Что вскрылось:

• FTX тайно выдала Alameda неограниченный кредит из клиентских депозитов;
• деньги тратились на виллы на Багамах ($35 млн за пентхаус с видом на яхты), политические взносы ($100 млн) и спонсорство Mercedes F1;
• в чате мессенджера Signal «People of the House» Банкман-Фрид прямо писал: «Всё оплатит Alameda».

Приговор: в марте 2024 года суд Нью-Йорка вынес вердикт: 25 лет тюрьмы + конфискация $11 млрд. Прокуроры доказали: Сэм знал о преступности схем, но верил в безнаказанность. Судья Льюис Каплан заявил: «Он хотел власти. И использовал для этого воровство».

Мораль: криптоинновации ≠ анархия. Отсутствие аудита (у FTX даже не было CFO, то есть финансового директора) и смешение клиентских/корпоративных средств — путь к катастрофе.

Уроки выживания: как CEO избежать участи Байрона и остальных

Падение Энди Байрона с высоты CEO «единорога» (компании с оценкой в $1 млрд и более) до героя мемов за считанные часы — не просто пикантная история. Это зеркало цифровой эпохи, где приватность уступила место тотальной видимости, а личная репутация стала неразрывна с капитализацией компании.

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

Этика должна быть встроена в ДНК лидерства. Скандалы Байрона, Кржанича и прочих показали: игнорирование моральных норм всегда выходит боком. Личное = профессиональное. Для CEO больше нет границ между частной жизнью и работой. Любые попытки скрыть нарушения лишь усугубляют падение.

В мире, где каждый — потенциальный папарацци, лучшая защита CEO — безупречность не только в алгоритмах работы, но и в жизни. Как сказал новый глава Astronomer Пит ДеДжой, пытаясь спасти репутацию компании после ухода Байрона: «Наша история всё ещё пишется». Но теперь уже другими людьми и на испорченной бумаге.

Цифровой контент — актив, который требует защиты не меньше, чем банковские данные. Многие привыкли, что свежий сериал или долгожданный фильм оказывается в сети за неделю до премьеры или в день релиза, а дорогостоящий курс можно скачать бесплатно на «складчинах». В 2024 году пиратство нанесло российским правообладателям ущерб в 3,36 млрд рублей, а глобальные потери медиаиндустрии превысили $71 миллиард. Утечки контента происходят через уязвимости в системах доставки, запись экрана или взлом серверов.

Но угрозы безопасности видеконтента не ограничиваются пиратством. Кибератаки добавляют новый уровень сложности: в отличие от пиратов, которые стремятся монетизировать контент через нелегальное распространение, хакеры могут преследовать иные цели — от вымогательства до саботажа инфраструктуры. Например, говорить, что в их распоряжении есть интимные видеозаписи жертвы (ещё лучше, если это CEO известной компании) и вымогать крупную сумму денег. Или взломать Rutube и саботировать инфраструктуру сервиса, как это было в 2022 году. Киберугрозы также могут включать DDoS-атаки, эксплуатацию уязвимостей в API или кражу пользовательских данных, что приводит к последствиям:

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

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

Многоуровневая защита: из чего она состоит

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

1. Защита от несанкционированного доступа и копирования

Первый барьер — ограниченный доступ к контенту:

• Шифрование: AES-128 или AES-256 для защиты видеопотоков.
• Авторизация: токены JWT или OAuth для проверки прав пользователей.
• Системы управления цифровыми правами (DRM) устанавливают ограничения на воспроизведение контента — по устройствам, географическому положению и времени. Если отсутствует соответствующий ключ шифрования, выдаваемый лицензионным сервером, воспроизведение может быть заблокировано.

2. Пиратские копии

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

Технический нюанс: ИИ-системы используют сверточные нейросети (CNN) для анализа визуальных и аудиохарактеристик. Разработчикам стоит интегрировать такие решения через API, например, от Google Cloud Vision или специализированных вендоров.

3. Отслеживание источника утечки

Ключевой вопрос при утечке: кто и как получил доступ к контенту? Водяные знаки и «цифровые отпечатки» (fingerprinting) позволяют встраивать уникальные идентификаторы в видеофайлы. Fingerprinting, например, создает хэши аудио- и видеофрагментов для поиска копий.

Технический нюанс: сессионные водяные знаки добавляют задержку в стриминг. Проблема решается предварительной обработкой сегментов для HLS/DASH-протоколов.

4. Противодействие пиратским ресурсам

Удалить копии после обнаружения можно через:

• Обращение в РКН и к платформе, где появилось видео. Если реакции от платформы нет, РКН или провайдер хостинга заблокируют сайт по запросу.
• Автоматическую блокировку ссылок через API хостингов.
• Юридическое давление на пиратские платформы.

Технологии против пиратов: DRM, ИИ, водяные знаки и «цифровые отпечатки»

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

DRM (управление цифровыми правами)

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

DRM-системы опираются на три ключевых компонента:

1. Лицензионный сервер отвечает за выдачу и проверку ключей расшифровки контента.
2. Клиентская часть DRM (Content Decryption Module, CDM) интегрирована в браузер/плеер.
3. Упаковщик контента (Packager) подготавливает видеопотоки для защищенной доставки.

Но есть техническая проблема совместимости — DRM-системы неоднородны по платформам:

• Widevine (Android, Chrome, Firefox, Opera);
• PlayReady (Windows, Xbox, некоторые Smart TV);
• FairPlay (экосистема Apple);
• WisePlay DRM (экосистема Huawei).

Решение — мульти-DRM упаковщики, поддерживающие все стандарты через единую интеграцию. Используйте библиотеки, например, Shaka Player, для упрощенной интеграции мульти-DRM.

Водяные знаки (Digital Watermarking)

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

Отслеживание «цифровых следов» (Fingerprinting)

В отличие от водяных знаков, которые внедряются в контент, технология фингерпринтинга генерирует хэши фрагментов видео и аудио для поиска копий в сети без модификации самих файлов. Это позволяет находить пиратские копии, даже если они были изменены (например, перекодированы или обрезаны). Работает это так: система создает «цифровой отпечаток» оригинального видео и затем автоматически сканирует интернет в поисках материалов с похожими характеристиками.

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

Цифровая форензика

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

AI-мониторинг

Искусственный интеллект ускоряет поиск пиратских копий через анализ огромных массивов данных в интернете с помощью компьютерного зрения и машинного обучения. ИИ-системы мониторинга используют сверточные нейросети (CNN), которые способны распознавать визуальные образы и алгоритмы, такие как Mel-Frequency Cepstral Coefficients (MFCC) (используется для распознавания речи). С их помощью можно находить копии даже при перекодировании или обрезке.

Уже существует множество готовых решений на основе ИИ. Например, Red Points постоянно мониторит соцсети, видеоплатформы и пиратские сайты с применением машинного обучения, компьютерного зрения и распознавания изображений, а при обнаружении совпадений автоматически отправляет запросы на удаление через API. Piracymeter и Bytescare анализируют списки доменов, поисковые результаты Google и торрент-трекеров. Bytescare также может находить пиратские копии ПО.

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

Пример комплексного подхода к защите видео

Для защиты видеоконтента компании всё чаще используют решения, которые сочетают несколько технологий. Например, разработчик систем безопасности GS Labs совместно с видеохостингом Kinescope создал систему, интегрирующую DRM, водяные знаки и цифровую форензику. Она позволяет шифровать контент, встраивать уникальные идентификаторы для отслеживания утечек и анализировать источники пиратских копий. Такое решение работает как в облаке, что даёт стриминговым платформам масштабируемость, так и локально, что важно для компаний с собственной инфраструктурой.

Модели внедрения технологий защиты видеоконтента

Выбор модели внедрения зависит от потребностей компании, ее бюджета и технических возможностей. Рассмотрим три основные модели.

Локальные решения (on-premises)

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

Облачные/SaaS-решения

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

Совет: используйте облачные решения с SOC 2 или ISO 27001 сертификацией для защиты данных.

Гибридные модели

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

Совет: используйте Kubernetes для оркестрации гибридных систем и минимизации downtime.

Что стоит сделать прямо сейчас, чтобы защитить видеоконтент

1. Подобрать постоянное комплексное решение: исследуйте вендоров и технологии на рынке.
2. Провести аудит инфраструктуры: проверьте уязвимости в CDN, API и плеере, например, с помощью OWASP ZAP.
3. Интегрировать DRM: выберите мульти-DRM решение, совместимое с Widevine, PlayReady и FairPlay.
4. Внедрить мониторинг: подключите ИИ через API для поиска копий.
5. Провести пентесты в BurpSuite, симулируя пиратские атаки и взлом.
6. Отработать реакцию на инциденты.

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

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

Бонус — комментарии экспертов с многолетним опытом работы за границей и глубоким пониманием международного рынка труда.

Какие IT-профессии наиболее востребованы за рубежом

По данным сервиса по поиску работы HeadHunter, в 2024 году наибольшим спросом за границей пользовались российские:

• менеджеры по продажам и работе с клиентами (13%),
• операторы колл-центров (5%),
• дизайнеры, менеджеры по маркетингу, интернет-маркетологи, художники (по 4%),
• учителя, SMM- и контент-менеджеры (по 3%),
• секретари, помощники руководителя, ассистенты (по 2%).

Программисты и разработчики заняли почётное второе место (10%). А специалисты технической поддержки и тестировщики набрали всего по 2%.

Но в исследовании образовательной онлайн-платформы «Нетология» и международного коммуникационного агентства Zecomms Agency специалист технической поддержки — наоборот, наиболее востребованная профессия за рубежом. С ним связано 17% от общего массива IT‑вакансий, что делает специалиста техподдержки абсолютным лидером по количеству открытых вакансий.

На втором месте расположился программный инженер (16%), на третьем — бизнес-аналитик (6%) и IT-консультант (6%).

Максим Оганов, ментор, бизнес-консультант, автор проекта Oganov.Consulting:

Российские IT-специалисты всё ещё остаются востребованными за рубежом, но по сравнению с 2022 годом ситуация изменилась. Международные компании уже не так охотно берут в штат сотрудников из России, известны случаи сокращений из-за гражданства. Причина — политика компаний, особенно тех, которые решили покинуть российский рынок. Зато за последние три года многие отечественные стартапы релоцировались в другие страны, и они отдают предпочтение сотрудникам из России.

Евгений Козак, senior фронтенд-разработчик компании With Intelligence, живёт в Лондоне, более 10 лет опыта работы за границей:

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

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

Согласно исследованию «Нетологии» и Zecomms Agency, Java признан самым популярным языком программирования — его активно используют компании по всему миру. На Java приходится более четверти всех открытых вакансий (26%) в сфере IT в Европе, США, Латинской Америке, Азии и на Ближнем Востоке.

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

На втором месте по популярности находится язык SQL, который используют для разработки баз данных и систем аналитики. На него пришлось 24% всех вакансий, бóльшая часть из них в Европе, Азии и на Ближнем Востоке.

Замыкает тройку лидеров Python (23%) — более половины открытых вакансий в Азии и на Ближнем Востоке связано именно с этим языком. Оно и неудивительно: на Python пишут модели для машинного обучения, анализа данных и автоматизации.

Сколько айтишникам платят за границей

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

Евгений Козак, senior фронтенд-разработчик компании With Intelligence, живёт в Лондоне, более 10 лет опыта работы за границей:

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

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

Но ключевое — размер оклада. По данным «Профсоюза работников ИТ», медианная зарплата специалистов уровня senior в России составляет 276 362 рубля в месяц, в то время как за рубежом она равна 386 730 рублей в месяц. Российские миддлы получают 170 000 рублей, а работающие за границей — 205 142 рубля. Зарплата джунов несильно отличается, хотя «за бугром» она всё-таки немного больше: 85 000 рублей против 80 000 рублей в России.

Таким образом, зарплата IT-специалистов за рубежом как минимум в 1,5 раза больше, чем в России.

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

Где IT-кадры пользуются спросом

Найти работу в IT сейчас везде нелегко, но чуть проще это сделать там, где активно развивается IT-сектор и требуется много кадров соответствующего профиля:

Германия. Наибольший дефицит IT-специалистов наблюдается в Германии — в 2023 году было опубликовано 103 089 вакансий. Особенно остро нехватка кадров ощущается в таких областях, как разработка программного обеспечения, Data Science, кибербезопасность и DevOps. А в 2025 году страна планирует выдать на 10% больше рабочих виз, чем годом ранее.

Нидерланды. В стране большое внимание уделяется IT-стартапам. Так, в 2024 году голландские технологические компании привлекли €3,7 млрд венчурных инвестиций — это около 5% от общего объёма капитала, вложенного в европейскую экосистему. Благодаря этому Нидерланды вошли в топ‑10 стран Европы по объёму инвестиций в технологии. Особенно быстро растёт сектор DeepTech («глубоких технологий») — полупроводники, искусственный интеллект и квантовые технологии.

Канада. Такие канадские города как Торонто, Ванкувер и Монреаль считаются настоящей IT-меккой. Здесь активно развиваются стартапы и работают подразделения крупнейших технологических компаний — Google, Microsoft, Amazon. Кроме того, для IT-специалистов есть много иммиграционных программ, например, Global Talent Stream, которая позволяет получить разрешение на работу в течение двух недель.

США. В 2023 году объём IТ-рынка США достиг $1,3 трлн и продолжает развиваться высокими темпами. В Европейском союзе он составил $1,05 трлн, в Китае — $348 млрд, в России — $36,1 млрд. Таким образом, американский технологический рынок в 36 раз больше российского, в 1,24 раза больше европейского и почти в четыре раза превосходит китайский. Это подтверждает его статус мирового лидера. Соответственно, IT-специалистов нужно много.

Куда уехать проще всего

По данным HeadHunter, активнее всего российских специалистов приглашают на работу компании из:

• Белоруссии — 172,3 тыс. приглашений,
• Казахстана — 150,9 тыс. приглашений,
• Грузии и Турции — 69,7 тыс. и 67,8 тыс. приглашений соответственно,
• Узбекистана — 57,2 тыс. приглашений.

Самый большой рост интереса продемонстрировали китайские работодатели — он увеличился почти в шесть раз. В 2023 году количество предложений для жителей России о работе в Китае составляло всего 4,8 тыс., тогда как в 2024 году цифра достигла 27,6 тыс. предложений.

Кроме того, за год потребность в российских специалистах выросла в Сербии с 5,8 тыс. до 26,3 тыс. (+356,3%), в Турции — с 23,5 тыс. до 67,8 тыс. (+188,6%), на Кипре — с 4,6 тыс. до 12 тыс. (+160,9%), в Польше — с 4,1 тыс. до 9,0 тыс. (+119,6%) и в ОАЭ — с 19,2 тыс. до 41,7 тыс. (+117,2%).

А Европа стала лидером по количеству предложений для IT-специалистов со знанием русского языка — 3% всех IT-вакансий в регионе. На других рынках доля таких предложений не превышает 1%. Чаще всего русскоязычных специалистов ищут в Польше — 2 200 вакансий, Венгрии — 752 вакансии, Австрии — 178 вакансий, Греции — 152 вакансии.

Максим Оганов, ментор, бизнес-консультант, автор проекта Oganov.Consulting:

Не все страны охотно принимают специалистов из других стран. Если раньше одними из самых популярных направлений для релокации были Канада и США, то сейчас переехать туда стало значительно сложнее. Больше шансов на трудоустройство в компании Испании, Португалии, Кипра, ОАЭ.

Как IT-специалисту найти работу за границей: четыре шага

1. Зарегистрируйтесь на международных платформах

Принцип поиска работы за рубежом такой же, как и в России. Нужно зарегистрироваться на платформах по типу HeadHunter и откликаться на понравившиеся вакансии. Чем больше откликов, тем лучше.

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

• LinkedIn — профессиональная социальная сеть, где можно искать вакансии и налаживать контакты;
• Indeed — международный агрегатор вакансий, позволяющий фильтровать их по странам, городам и отраслям;
• Relocate.me — платформа для вакансий с релокацией;
• Remote OK — площадка для поиска удалённой работы;
• WWR — сервис, где публикуют вакансии крупные зарубежные компании, например, Amazon или Google.
• AngelList Talent — каталог вакансий в иностранных стартапах.

Некоторые из них открываются только с VPN.

Максим Оганов, ментор, бизнес-консультант, автор проекта Oganov.Consulting:

Удобнее всего искать вакансии зарубежных компаний через LinkedIn. По моему опыту, большинство специалистов находят работу за границей именно через эту площадку. Но есть и альтернативные варианты — например, телеграм-каналы с профильными вакансиями. Будьте готовы к тому, что придётся отправлять много откликов. В среднем на 100 откликов приходится не более 5 ответов.

Евгений Козак, senior фронтенд-разработчик компании With Intelligence, живёт в Лондоне, более 10 лет опыта работы за границей:

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

2. Адаптируйте резюме для иностранного рынка

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

Эксперты компании EP Advisory, которая помогает российским специалистам строить карьеру за рубежом, рекомендуют включать в CV разделы Name, Profile, Education, Experience, Skills & Other. Названия предыдущих компаний и занимаемые должности следует выделять, а каждый блок — разграничить чертой.

Кроме того, в некоторых странах, например, Великобритании, США и Канаде не принято добавлять фото в резюме. Такое правило стало следствием законов против дискриминации в этих странах, поэтому его несоблюдение может вызвать негативную реакцию и привести к мгновенному отказу.

Дополнительно к резюме стоит приложить мотивационное письмо (Cover Letter), подготовленное специально под конкретную вакансию. В мотивационном письме уже не пишут об образовании и навыках — эти сведения указывают только в резюме. А в Cover Letter особый упор делается на кейсах и объяснении, чем для вас интересна компания и почему вы для неё — самый подходящий кандидат.

Максим Оганов, ментор, бизнес-консультант, автор проекта Oganov.Consulting:

Необходим большой и подтверждённый опыт работы. Придётся конкурировать со специалистами уровня senior со всех концов света. Особенно много кандидатов из Индии, Ирана, Пакистана.

3. Обратитесь в агентство по трудоустройству

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

Вот список наиболее известных рекрутинговых агентств:

• Adecco — крупнейшее агентство с вакансиями по всему миру;
• Manpower — международная стаффинговая, аутсорсинговая и HR-консалтинговая компания из России;
• Michael Page — международная компания, которая специализируется на подборе персонала среднего и высшего звена;
• Hays — британская рекрутинговая компания, которая предоставляет услуги по подбору персонала в 33 странах мира;
• Harvey Nash — международная компания, которая специализируется на IT-аутсорсинге;
• Randstad — голландская консалтинговая компания, которая сотрудничает с ведущими зарубежными работодателями.

Агентства также консультируют по вопросам адаптации и помогают с поиском жилья.

Евгений Козак, senior фронтенд-разработчик компании With Intelligence, живёт в Лондоне, более 10 лет опыта работы за границей:

Чтобы найти работу в Лондоне, я сотрудничал с международными и британскими рекрутинговыми агентствами — Hays, Harvey Nash и Michael Page. Примерно 50% предложений приходили именно от них. Эти агентства играют важную роль на IT-рынке и обладают широкой сетью контактов с работодателями по всей Европе. Они помогали мне в поиске подходящих позиций и сопровождали на всех этапах — от первичного отклика до собеседования и подписания оффера.

4. Получите визу и разрешение на работу

Без визы и разрешения приступить к работе за границей не получится. Здесь доступны два варианта — Digital Nomad Visa или обычные рабочие визы.

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

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

Чтобы получить визу цифрового кочевника, нужно подтвердить минимальный доход (чаще всего не ниже 2000 евро в месяц) и наличие медицинской страховки. Также может понадобиться трудовой договор или договор подряда, доказывающие, что вы работаете удалённо. Сейчас Digital Nomad Visa оформляют в 66 странах, включая Португалию, Испанию, Эстонию, ОАЭ и Южную Корею.

Классические рабочие визы. Это визы EU Blue Card или виза H‑1B.

• Голубая карта (EU Blue card) — виза для работы в Европе. Чтобы получить её, нужен диплом о высшем образовании (не ниже бакалавра) и оффер с зарплатой от 48 300 евро год (43 760 евро для IT‑специалистов) на срок минимум шесть месяцев. В случае одобрения выдаётся вид на жительство, действующий до четырёх лет с возможностью продления.

• Виза H‑1B — виза для работы в США. Она также требует наличия высшего образования и оффера от местной компании. Но американское законодательство устанавливает лимит на выдачу H‑1B — 65 000 базовых и 20 000 дополнительных виз для специалистов с магистерской степенью из США. Всего 85 000 виз в год. Виза предоставляется максимум на три года с возможностью продления до шесть лет.

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

Официальное трудоустройство или фриланс

Удалённая работа на фрилансе

Фриланс — самый простой способ начать работать с зарубежными компаниями без лишней бюрократии и сложностей с оформлением. Достаточно зарегистрироваться на зарубежную фриланс-платформах Upwork или Fiverr, и можно сразу браться за международные проекты. Единственное, могут возникнуть трудности с оплатой, поэтому стоит завести себе иностранную банковскую карту.

Главные минусы фриланса — нет оплачиваемого отпуска и больничных, а доход крайне нестабилен.

Официальное трудоустройство с релокацией

Официальное трудоустройство гарантирует стабильную зарплату и полный соцпакет, а при релокации — помощь с переездом и адаптацией в новой стране.

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

Максим Оганов, ментор, бизнес-консультант, автор проекта Oganov.Consulting:

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

Евгений Козак, senior фронтенд-разработчик компании With Intelligence, живёт в Лондоне, более 10 лет опыта работы за границей:

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

Какой уровень владения английским языком нужен

Для оценки владения иностранными языками, включая английский, в Европе используют систему CEFR (Common European Framework of Reference). CEFR выделяет шесть уровней знания языка: A1, A2, B1, B2, C1, C2.

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

Максим Оганов, ментор, бизнес-консультант, автор проекта Oganov.Consulting:

Обязательное требование — свободное владение английским: например, в Португалии большинство сотрудников IT-компаний общаются на нём. Но иногда кандидату необходимо знание местных языков — так, если вы хотите переехать во Францию, шансы на трудоустройство без владения французским минимальны.

Евгений Козак, senior фронтенд-разработчик компании With Intelligence, живёт в Лондоне, более 10 лет опыта работы за границей:

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

Коротко о главном

• Иностранные компании активно используют Java, Python, SQL и нуждаются в программистах, умеющих писать на этих языках.
• IT-специалисты особенно востребованы в Германии, Нидерландах, Канаде и США — странах с наиболее интенсивным ростом технологического сектора.
• Проще всего уехать в Белоруссию, Казахстан, Турцию, Грузию и Китай.
• Работать за границей можно официально или на фрилансе.
• Чтобы получить оффер, следует зарегистрироваться на международных платформах для поиска работы, адаптировать резюме, оформить визу и, при необходимости, обратиться в агентство.

Аналитики отмечают, что подобные ситуации стали типичными для ИИ-индустрии последних лет, при этом проверить реальные технологии за маркетинговыми обещаниями становится все сложнее. Практика показывает, что значительная часть стартапов, позиционирующая себя как «ИИ-компании», не имеет собственных разработок в области искусственного интеллекта. При этом объем инвестиций в сектор уже превысил $320 миллиардов.

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

Золотая лихорадка: как ИИ-стартапы стали новыми доткомами

Эксперты сравнивают текущую ситуацию на рынке ИИ-стартапов с пузырем доткомов конца 1990-х. За последние три года количество компаний, использующих в описании термин «искусственный интеллект», выросло в несколько раз. При этом далеко не все из них действительно разрабатывают собственные алгоритмы машинного обучения.

Яркий пример — история стартапа 11x, который в 2024 году привлек значительные инвестиции под проект ИИ для автоматизации продаж. Как выяснило издание TechCrunch, компания заявляла о сотрудничестве с крупными клиентами вроде ZoomInfo и Airtable, но эти организации публично опровергли какие-либо отношения с 11x.

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

Почему же бизнес продолжает инвестировать в подобные проекты? Психологи объясняют эту ситуацию эффектом FOMO (Fear of Missing Out) — страхом упустить выгоду. Когда все вокруг инвестируют в ИИ, а СМИ наперебой пишут о преимуществах новых технологий, трудно остаться в стороне. Многие фонды предпочитают вложиться в десять сомнительных стартапов, чем пропустить один потенциально успешный проект. В случае удачи затраты многократно окупятся, но каковы шансы на успех?

Кухня фейковых ИИ-стартапов: как создают иллюзию «передовых» технологий

Современные технологические мошенники освоили целый арсенал приемов, позволяющий превратить набор готовых API в «инновационный продукт». Их методы стали настолько отточенными, что даже опытные инвесторы иногда не могут отличить реальную разработку от искусно сконструированной фальшивки. Заглянем за кулисы этого театра технологических чудес и рассмотрим наиболее распространенные схемы мошенничества.

Словарь мошенника: от AGI до нейроинтерфейсов

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

AGI — священный грааль мошенников

Заявления о создании Общего Искусственного Интеллекта (AGI) — самый яркий красный флаг. В 2025 компания OpenAI опубликовала отчет, где четко указала: современные ИИ-системы остаются узкоспециализированными инструментами. AGI — гипотетический тип сильного ИИ, до создания которого еще далеко на текущем уровне развития технологий.

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

Мультимодальность как прикрытие

Этот термин часто используют для описания простой интеграции нескольких API. Стартапы заявляют о «прорывной эмоциональной аналитике», но система просто передает данные в Google Vision API и Azure Face Recognition. Основатели отказываются предоставить доступ к коду, ссылаясь на «коммерческую тайну».

Нейроинтерфейсы без нейронов

После успеха Neuralink Илона Маска десятки стартапов нацелились на «прорыв в управлении устройствами силой мысли». Эксперты предупреждают, что многие такие решения часто регистрируют ложные срабатывания (артефакты движения вместо реальных нейросигналов) и имеют крайне низкую точность распознавания намерений.

Они даже могут выдавать случайные сигналы даже при тестировании на неодушевленных объектах.

Другие наиболее «злоупотребляемые» термины в 2025 году:

• «Blockchain-powered AI» — ряд проектов с такой технологией не имеет реального блокчейна.
• «Self-learning algorithm» — обычно означает простую настройку параметров.
• «Military-grade encryption» — маркетинговый штамп без спецификаций.
• «Quantum AI» — ни одного реального квантового вычисления.
• «Ethical AI» — часто отсутствует даже базовый compliance-документ.

Как распознать обман?

Когда слышите громкие заявления, требуйте:

• сравнения с существующими open-source решениями;
• результаты независимого бенчмаркинга;
• хотя бы один реальный кейс вне маркетинговых материалов.

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

Реальный пример: Стартап DoNotPay, позиционировавший себя как «первого в мире ИИ-юриста», столкнулся с серьезными вопросами о своей технологии.

Расследование издания The Verge показало, что компания использовала шаблонные ответы вместо сложного ИИ, а многие юридические документы создавались вручную. Основатель Джошуа Браудер признал, что часть функционала действительно работала на базовых алгоритмах.

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

Искусство фейковых демонстраций

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

• «Человек за занавесом». Самый распространенный прием — когда за якобы автоматизированным процессом скрывается ручной труд. Вспоминаем тот самый случай с индийскими программистами.
• Предварительно записанные «интерактивные» демо. Многие компании показывают заранее подготовленные сценарии как живое взаимодействие. Например, в 2024 году выяснилось, что демонстрации «уникального» чат-бота от стартапа ChatX на 90% состояли из предварительно записанных ответов, хотя подавались как работа ИИ в реальном времени.
• Генерация идеальных условий. Для демо-роликов специально подбирают простейшие тестовые случаи. Сервисы показывают «безупречную» работу своего ИИ для генерации кода, но в реальных условиях точность системы на порядки ниже.
• Гибридные демонстрации. Новый тренд — комбинация ИИ и ручной доработки. Алгоритм делает черновой вариант, который затем правит человек, но в презентациях это подается как полностью автоматизированный процесс.
• Deepfake-презентации. Некоторые компании идут еще дальше, создавая полностью сгенерированных цифровых спикеров с реалистичной мимикой и голосом, которые рассказывают о несуществующих возможностях продукта.

Как распознать обман:

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

Эти простые методы помогут отличить реальные технологии от созданных иллюзий.

Ноу-код революция: как собирают ИИ-стартапы за выходные

Современные платформы для разработки без программирования открыли новую эру в создании псевдо-ИИ-стартапов. Сервисы типа Bubble и Retool позволяют за считанные дни собрать внешне убедительный продукт, используя готовые API популярных нейросетей. Согласно исследованиям, около половины новых проектов в сфере ИИ используют шаблонные решения на основе ChatGPT API и других доступных технологий.

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

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

Срываем покровы: что скрывается за громкими заявлениями

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

Mechanical Turk 2.0: цифровые рабы новой эры

Американский стартап Nate стал примером того, как компании выдают ручной труд за работу искусственного интеллекта. Компания привлекла $40 млн инвестиций, позиционируя себя как инновационный сервис для автоматизации онлайн-покупок с помощью ИИ.

Как работала схема обмана:

1. Вместо заявленных алгоритмов обработку заказов выполняли сотни работников на Филиппинах и в Румынии.
2. Уровень реальной автоматизации составлял «фактически ноль процентов», по данным Министерства юстиции США.
3. Компания использовала ботов лишь для имитации части транзакций.

Иными словами, подобно известной зарубежной краудсорсинговой платформе Mechanical Turk или аналогичным российским сервисам, фейковые стартапы используют людей для решения задач, которые дорого или невозможно выполнять с помощью компьютера. Участие в таких проектах становится новым «быстрым заработком в интернете», только на этот раз фрилансеры не разгадывают капчи, а участвуют в заведомо мошеннической схеме — играют роль ИИ за небольшое вознаграждение.

Мошенники из Nate реализовали проверенные методы маскировки:

• создали ложный нарратив об инновационных технологиях;
• использовали актуальность ИИ-тематики для привлечения инвестиций;
• подтверждали «работу алгоритмов» через поддельные метрики.

Генеральному директору Альберту Санигеру были предъявлены обвинения в мошенничестве с ценными бумагами с использованием электронных средств связи. Каждое из этих преступлений предусматривает до 20 лет лишения свободы.

Еще более громкий случай произошел с индийским стартапом BuilderAI, о котором мы писали ранее. Этот проект продержался 8 лет, прежде чем афера была раскрыта. Кто знает, какие еще тайны крупных и мелких ИИ-стартапов откроются нам в будущем?

Накрученные метрики и покупные отзывы

Проблема фальшивых показателей стала настоящей эпидемией в индустрии. Аналитики SimilarWeb обнаружили: большинство ИИ-стартапов имеют более 50% бот-трафика в своей статистике. Распространены три проверенных схемы обмана:

1. Накрутка DAU/MAU — использование ферм ботов для имитации активной аудитории.
2. Покупка отзывов — маркетплейс Clutch.co удалил 120 фальшивых рецензий о сервисе AIHelper.
3. Поддельные кейсы — публикация вымышленных историй успеха со стоковыми фото вместо реальных клиентов.

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

Почему пузырь еще не лопнул

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

Правовой вакуум и отсутствие регулирования

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

Сложность проверки технологий усугубляется тем, что:

• нет стандартизированных методов оценки ИИ-решений;
• отсутствуют требования к публикации тестовых данных;
• не разработаны критерии для проверки уникальности алгоритмов.

В многих других странах ситуация с юридическим статусом ИИ тоже не определена.

Психология инвестирования в эпоху ИИ-хайпа

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

Яркий пример — история с инвестициями Microsoft в BuilderAI. Корпорация вложила $50 млн без глубокой технической экспертизы, полагаясь лишь на маркетинговые материалы.

В целом за последний год объем инвестиций в ИИ-стартапы вырос на 37%. Это свидетельствует о «гонке за единорогами» — инвесторы предпочитают делать крупные ставки на небольшое количество проектов, надеясь поймать следующий OpenAI. При этом реальная окупаемость таких вложений остается под вопросом.

Когда лопнет пузырь?

Аналитики и регуляторы по-разному оценивают сроки коррекции рынка ИИ-стартапов:

Ближайшие риски (2025-2026):

• В России эксперты прогнозируют волну банкротств среди технологических стартапов, особенно в условиях высокой ключевой ставки (21-25%) и снижения инвестиционной активности.
• Международные аналитики ожидают постепенное «сдувание» пузыря по мере ужесточения регулирования и проверки технологий.

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

Как не купить воздух и отличить настоящий ИИ-стартап от технологического фейка?

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

Техническая экспертиза проекта

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

Важные технические аспекты для проверки:

• уникальность алгоритмов — запросите сравнение с open-source аналогами;
• качество данных — какие наборы используются для обучения;
• инфраструктура — собственные серверы или облачные решения.

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

Проверка реальных кейсов и клиентов

Маркетинговые обещания легко проверить через демо-версию с возможностью ввода произвольных данных, отзывы реальных клиентов (не из маркетинговых материалов) и истории внедрения с конкретными цифрами эффективности.

Финансовая и юридическая прозрачность

Обязательные документы для проверки:

• бизнес-план с четкой монетизацией;
• отчеты о расходовании предыдущих инвестиций;
• финансовые модели на 3-5 лет.

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

Практический совет: создайте чек-лист из 20-30 пунктов и привлекайте независимых экспертов для аудита каждого критерия. Как показывает практика, комплексная проверка на 80% снижает риски инвестирования в фейковые проекты.

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

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

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

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

Ненадёжный код

Для начала определимся, что же считать ненадёжным кодом? На самом деле ответ зависит от решаемой задачи, правил и процессов, принятых в компании:

• Код, который не прошел CI, review и т.п.
• Код из ненадёжного или неизвестного источника.
• Закрытый (проприетарный) код.
• Код, содержащий уязвимости.
• Код, использующий запрещенные функции.
• Любой код, который написал коллега:)

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

Уровни изоляции кода

Можно выделить три варианта запуска внешнего кода — три уровня изоляции. Каждый следующий увеличивает дистанцию между кодом приложения и запускаемым кодом. Чем выше уровень изоляции, тем меньше вероятность, что запускаемый код нанесет вред приложению и системе.

Уровень 1: тот же процесс

Запуск внешнего кода в адресном пространстве процесса приложения.

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

Примером может служить использование интерпретаторов скриптов (Rhino, IronPython, Jython и т.п.), визуальных языков программирования (workflow-движков) или подключение модулей расширения (плагинов).

Способов защиты на этом уровне не так много. Пожалуй, самым эффективным выступает (self-sandboxing), при котором приложение делает самозапрет на доступ к некоторым ресурсам системы. Например, сразу после инициализации — самозапрет на доступ к файловой системе.

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

Что же касается плагинов, то они призваны расширять возможности приложения, поэтому их использование изначально не предполагает сильной изоляции. Здесь можно предложить усилить контроль взаимодействия на уровне контракта (API). В идеале — если плагины будут публиковаться в некоторый центральный репозиторий, которому вы доверяете и который может производить дополнительные проверки и тестирование до этапа запуска кода плагина.

Уровень 2: отдельный процесс

Запуск внешнего кода на той же машине, но в отдельном процессе ОС.

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

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

Уровень 3: отдельная машина

Запуск внешнего кода на отдельной машине — песочнице.

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

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

Использование песочницы

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

Пересоздание или переиспользование песочницы

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

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

Основным преимуществом пересоздания песочницы выступает стабильность получаемых результатов. К недостаткам относится медленный запуск и перерасход ресурсов. На пересоздание песочницы уходят десятки секунд или даже минут, следовательно, большая часть ресурсов будет тратиться именно на это. Существует множество техник ускорения пересоздания, благодаря которым можно сократить время запуска. Прежде всего, сюда можно отнести backup/restore (snapshot песочницы, базы данных и т.п.). Также если поток задач небольшой и ресурсы позволяют, можно попробовать организовать пул песочниц и создавать их заранее.

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

Последовательное или параллельное исполнение

Теперь осталось ответить на вопрос, как именно можно или нужно исполнять задачи: последовательно или параллельно. Последовательное исполнение требуется в следующих случаях:

• важен порядок следования и исполнения задач;
• задачам нужен эксклюзивный доступ к определенному ресурсу;
• задачи ёмкие и их совместное исполнение вызовет нехватку ресурсов;
• задачи могут мешать исполнению друг друга из-за борьбы за ресурсы.

Например, шаги установки и настройки ПО; шаги CI/CD-конвейера; рендеринг изображения на GPU; интенсивные вычисления. Все эти задачи, скорее всего, придётся исполнять последовательно.

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

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

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

Управление песочницами

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

Оркестрация

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

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

• Синхронное взаимодействие. Так или иначе, для результата приложение вынуждено ожидать окончания исполнения задачи. Для продуктивного использования ресурсов приходится прибегать к техникам асинхронного программирования: пока задача исполняется, приложение будет занято полезной работой. Это малозаметный недостаток в языках со встроенной поддержкой концепции асинхронного программирования. Для упрощения работы с асинхронным кодом в Java я создал небольшую вспомогательную библиотеку asynchronizer, снабдив её подробной документацией.

• Отслеживание доступности песочниц. Поскольку хотелось бы, чтобы количество песочниц менялось в зависимости от нагрузки на систему, придётся отслеживать их доступность. Это прямая обязанность оператора песочниц, которую можно выделить в отдельный discovery-сервис (например, на базе Netflix Eureka), либо реализовать как часть приложения с использованием инфраструктурных механизмов (например, Kubernetes API). Важно отметить, что оператор песочниц не имеет отношения к бизнес-логике приложения.

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

• Неопределённость результата, если нет ответа от песочницы. Песочница может быть недоступна по различным причинам, включая не только проблемы с сетью, но и падения песочницы из-за ненадёжного кода. К сожалению, в общем случае эта проблема не имеет решения, так как делать повторные запуски (retries) может быть опасно. Всё, что остаётся, это использовать таймауты и откладывать неуспешную задачу на потом.

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

Для отслеживания нагрузки на песочницы экземпляр приложения ориентируется на количество задач в каждой из доступных песочниц. Предположим, что было принято решение увеличить количество экземпляров приложения. Этот экземпляр исполняет 5 задач в двух песочницах (3 процесса в одной и 2 в другой). Известно, что каждая песочница может вынести максимум 4 параллельных задачи.

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

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

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

• Для контроля количества исполняемых задач в песочнице использовать распределённый счётчик (например, на базе Redis). Проблема в том, что распределённый счётчик имеет латентность и на момент запуска задач может выдать устаревшее значение. Кроме того, в системе появляется еще один инфраструктурный компонент, который не несёт бизнес-пользы.

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

Кстати, после доклада на TechLeadConf 2025 мне задали интересный вопрос: Можно ли при балансировке нагрузки на песочницы учитывать не только количество исполняемых задач, но и процент загрузки CPU, памяти и прочих ресурсов? Если у кого-то возник такой же вопрос, то отвечу, что это не имеет смысла, поскольку ситуация в песочнице может поменяться мгновенно. Полученный практический опыт и нагрузочное тестирование показали, что простой подсчёт задач работает эффективно.

Самоорганизация

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

Ключевой момент в архитектуре — это появление двух очередей: очередь задач на исполнение (Task Queue) и очередь результата их исполнения (Result Queue). Все поступающие задачи приложение направляет в первую очередь, а результаты — во вторую. Дополнительно появляется роль агента — микросервиса, который исполняется в рамках узла песочницы и координирует исполнение поступающих задач.

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

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

• Скорость и стабильность взаимодействия. Никаких проблем с сетью из-за локальности взаимодействия между агентом и песочницей.

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

• Минимум инфраструктурного кода. Очереди избавляют от необходимости иметь оператор песочниц, отслеживать их состояние и осуществлять балансировку нагрузки.

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

Запуск процесса ОС

К запуску процесса ОС, в рамках которого будет исполняться ненадёжный код, нужно подойти с особой осторожностью. Здесь важно ответить как минимум на три вопроса.

• Как ограничить права доступа к ресурсам. Самое простое решение — запуск процесса от имени пользователя с ограниченными правами (на доступ к ресурсам ОС).

• Как ограничить объем используемых ресурсов. Для запускаемого процесса нужно определить доступные ресурсы и возможные действия.

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

Рассмотрим варианты ограничения ресурсов процесса ОС.

Ограничение ресурсов процесса

Ресурсы процесса могут быть ограничены на трех уровнях:

• Лимиты узла. Физические ограничения машины, на которой исполняется процесс. В частном случае можно говорить об инфраструктурных лимитах, определённых для Docker/Kubernetes контейнера.

• Лимиты контейнера. Программные лимиты, задаваемые выбранным инструментом контейнеризации (cgroup, Docker, Bubblewrap, ProcessSandbox и т.п.).

• Лимиты процесса. Программные лимиты, задаваемые средствами ОС. На этом уровне можно осуществлять гибкую настройку вариантов запуска и исполнения.

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

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

Например, для использования cgroup или Docker внутри Kubernetes-контейнера нужно эскалировать привилегии контейнера, что в общем случае небезопасно в контексте исполнения ненадёжного кода. Более того, практика показала, что легковесных rootless-средств, предоставляемых ОС, вполне достаточно, чтобы снять большую часть рисков. В частности, Linux API позволяет не только лимитировать CPU и память, но и блокировать доступ к некоторым возможностям самой ОС. Например, можно наложить фильтр, который запретит вызов определённых системных функций.

Проблемы жёсткого лимитирования

Рассмотренные выше способы лимитирования задают жёсткие границы (hard limit), нарушение которых замедляет исполнение процесса, либо приводит к его принудительному завершению. При этом поведение наблюдаемого процесса и системы сильно варьируется в зависимости от того, какой лимит был превышен. Например, превышение по использованию CPU может привести к троттлингу (throttling), приостановке работы или принудительному завершению; превышение по использованию памяти заканчивается принудительным завершением со стороны ОС (OOM Killer) либо самостоятельным падением процесса (с ошибкой Out Of Memory).

Подобная вариативность осложняет анализ поведения и результатов исполнения. В этом случае можно использовать подход с программной мягкой границей (watchdog limit). Суть заключается в запуске дополнительного следящего потока (или процесса) ОС, который контролирует поведение и расход ресурсов у наблюдаемого. Как только детектируется превышение одного из лимитов, производится принудительное завершение наблюдаемого процесса, но уже не со стороны ОС, а со стороны приложения.

Такой подход имеет несколько преимуществ.

• Точное определение причин принудительного завершения. Жёсткие лимиты чуть выше мягких, благодаря чему для исполняемого кода создаётся иллюзия отсутствия каких-либо лимитов. Между тем, если лимиты всё-таки нарушаются, процесс всё равно будет завершен (либо со стороны приложения, либо гарантированно со стороны ОС). Но подобный дополнительный контроль со стороны приложения оставляет для него гораздо больше шансов понять причину принудительного завершения наблюдаемого процесса.

• Возможность гибкого лимитирования ресурсов. Приложение (или агент), ответственное за запуск наблюдаемого процесса, может обратиться к средствам ОС (в частности, к Linux API) и гибко настроить параметры запуска и исполнения. Как минимум, жёстко определить лимиты по CPU и памяти; наложить ограничения на объем I/O; создать запрет на вызов некоторых системных функций (например, запрет использования сетевых операций или файловой системы) и т.п.

Такой подход я назвал watchdog и в целях иллюстрации реализовал его в виде .NET-библиотеки ProcessSandbox. Помимо прочего, на странице проекта подробно рассмотрена проблематика контроля и анализа поведения процесса ОС со стороны прикладного кода.

Итоговая схема лимитирования может выглядеть так, как показано на рисунке ниже. Вместо тяжеловесных инструментов контейнеризации используется легковесный rootless-инструмент (watchdog) на базе средств ОС и только.

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

Многоконтейнерные поды

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

Несмотря на всю заманчивость данной идеи, она несёт ряд недостатков.

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

• Плохая утилизация ресурсов. Сможет ли приложение достаточно нагрузить песочницу, если количество песочниц будет в избытке; и наоборот, нужно ли столько же экземпляров приложения, сколько и песочниц.

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

• Риск нарушить работоспособность приложения. Выход песочницы из строя скорее всего приведет к перезапуску всего пода. Более того, если приложение и песочница обмениваются файлами через общий раздел (shared volume), это может стать уязвимым местом.

Образ для песочницы

Основные моменты, которые следует учесть при создании (Docker) образов песочниц:

• Заменить init-процесс на tini, чтобы не превысить лимит по PIDs.

• Создать непривилегированного пользователя, ограничив ему права на доступ к ресурсам.

• Регулярно сканировать версии образов и пакетов на наличие уязвимостей.

Инфраструктура исполнения

Основные моменты, которые следует учесть при настройке инфраструктуры исполнения:

• Обеспечить быстрый (пере)запуск песочниц. Нужно быть готовым к тому, что песочницы будут падать. Если речь идет о Kubernetes, то улучшить время запуска может подходящая настройка Image Pull Policy. При этом лучше не использовать тег `latest`, а указывать конкретную версию или хэш-код образа, чтобы не тратить время на попытки определения последней версии при каждом запуске.

• Установить приемлемый лимит на PIDs. Необходимо контролировать число активных процессов в системе. Особо вредоносный код может попытаться создать очень много дочерних процессов, поэтому при отсутствии лимита на PIDs узел быстро будет выведен из строя. Важно отметить, что лимит задаётся для пользователя, а не для запускаемого процесса. По этой причине он должен быть разумно большим.

• Установить лимиты на ресурсы узла. В Kubernetes для каждого контейнера нужно указать, как минимум, лимиты по CPU и памяти. Значения лимитов лучше всего определить в ходе нагрузочного тестирования или путём сбора метрик приложения.

Заключение

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

Я постарался показать последовательность шагов по направлению к целевой архитектуре, которая будет отвечать требованиям бизнеса и справляться с ненадёжным кодом. Если вам интересна данная тематика, подписывайтесь на мой Telegram-канал Архитектоника в ИТ (@arch_and_dev). Буду рад поделиться опытом.

Что такое скоринг

Скоринг — это автоматизированная система оценки заемщика. На основе массы параметров (кредитная история, обороты, данные о владельцах и др.) системе необходимо принять решение: выдать заем или нет, и с каким уровнем риска.

Подход JetLend — не единственный на рынке: банки традиционно опираются на классический андеррайтинг, в то время как некоторые зарубежные peer-to-peer платформы делают ставку исключительно на автоматические модели. У каждого подхода — свои сильные и слабые стороны, и выбор зависит от специфики рынка и аудитории. В случае JetLend ставка сделана на гибрид: ИИ + человек.

Почему одного ИИ оказалось недостаточно

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

При работе только с автоматическим скорингом компания столкнулась с рядом системных ошибок:

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

В результате доля дефолтов начала расти. Поэтому с 2024 года ML-модель используется совместно с андеррайтерами. В рамках реформы риск-модели было внедрено более 40 структурных изменений.

Как работает совместная модель

С 2024 года JetLend внедрил обновленную систему: теперь скоринг проводится одновременно ИИ-моделью и командой андеррайтеров. Это объединило скорость и масштаб ML с экспертной оценкой факторов, на которые автоматика пока не способна.

ML-модель (логистическая регрессия, деревья решений) оценивает вероятность дефолта, выдает рейтинг от 1 до 18. Основная метрика — коэффициент Gini, показывающий точность ранжирования.

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

Что потребовалось для реализации

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

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

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

Что изменилось после внедрения совместного подхода

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

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

Эффект оказался значительным: уровень дефолтов снизился в 2 раза ко II кварталу 2024 года, а к IV кварталу — до 0,25%. Как итог:

• Рейтинги обновлены для всех активных займов, неподходящие — исключены.
• По некоторым займам доходность может быть выше, чем по гособлигациям, но с соответствующим уровнем риска.
• Фактический XIRR по портфелю вырос, доходность по новым займам — от 30% годовых.
• Запущена программа выкупа потерь, позволяющая инвесторам очистить портфель от «токсичных» активов.

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

Вывод

Опыт JetLend показывает: в нестабильной среде и при работе с малым бизнесом машинное обучение должно идти рука об руку с человеком. Это не вопрос моды, а устойчивости и точности скоринга. А финтех-инфраструктура будущего — это не только про алгоритмы, но и про здравый смысл. Но открытым остается вопрос — насколько устойчивой окажется эта модель в случае резкой смены макроэкономической конъюнктуры.

Представьте: студент пишет эссе в ChatGPT, сдает работу, а через неделю преподаватель находит странные символы в его тексте. Это не мистика, а обычная техническая особенность, которая превратилась в детектив в духе Дэна Брауна.

Пора узнать о том, как обычные пользователи случайно раскрыли «заговор» искусственного интеллекта, почему в интернете началась паника о скрытых водяных знаках, и что на самом деле происходит с новыми моделями OpenAI.

Первые улики

Все началось в апреле 2025 года. Студенты университетов стали жаловаться на странные проблемы с текстами ChatGPT. Текстовый редактор Word вел себя странно при копировании эссе. Некоторые символы странно выглядели и в редакторах кода.

Первыми в теме начали разбираться специалисты из Rumi. Они создавали инструменты для поиска ИИ в курсовых и контрольных, поэтому привыкли анализировать тексты. При тестировании новых моделей GPT o3 и o4-mini команда обнаружила, что нейросеть встраивает в сгенерированные ответы Unicode-символы.

При этом OpenAI как раз запустила бесплатный доступ к ChatGPT для студентов до конца учебного года, как раз во время сессии. Неразрывные пробелы появлялись только в длинных ответах — например, если ввести запрос «Напиши эссе о министерстве образования». Хотя некоторые пользователи заметили, что невидимые символы встраиваются и в короткие ответы.

Разработчики начали обсуждать тему на форумах. Пользователи делились скриншотами из Sublime Text и VS Code, где обычные пробелы подсвечивались как спецсимволы. Кто-то понял, что в Word можно нажать Ctrl+Shift+8 — сочетание клавиш сразу находит водяные знаки ChatGPT и отображает их как кружочки.

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

Охота на невидимку

Команда Rumi тестировала новые модели и заметила странность — длинные эссе выглядели нормально, но что-то было не так. Когда разработчики скопировали текст в редактор Sublime, то увидели россыпь странных символов на месте обычных пробелов.

Виновником оказался Unicode-символ U+202F — узкий неразрывный пробел. Он практически неотличим от обычного пробела, но имеет совершенно другой код. Для программистов это как найти подделку с помощью ультрафиолета.

Энтузиасты быстро создали инструменты для охоты на невидимку. SoSciSurvey научился находить 34 типа скрытых Unicode-символов — от пробела нулевой ширины до длинных тире.

Самым простым способом отыскать «партизан» стала комбинация клавиш. В Word нужно нажать Ctrl+Shift+8 — обычные пробелы превращаются в точки, а водяные знаки ChatGPT отображаются кружочками. Sublime Text показывает символы еще нагляднее — можно искать конкретно \u202F через функцию поиска.

Удалить символы оказалось еще проще. Любой может открыть VS Code или Sublime Text, найти U+202F через поиск и заменить на обычные пробелы. Водяные знаки исчезают за секунды.

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

Заговор разрастается

В соцсетях началась паника. Пользователи обвиняли OpenAI в том, что она специально выявляет студентов-читеров. Совпадение с бесплатным доступом для учащихся добавило масла в огонь.

Блогеры рисовали мрачные картины тотальной слежки. Якобы компания тайно помечает каждого пользователя через невидимые символы. Кто-то даже предполагал, что OpenAI готовит массовые облавы на студентов перед защитой дипломов.

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

Конспирологи забыли об одной детали — водяные знаки удаляются за пару кликов через поиск в документе.

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

К тому же компания открыто заявляла о работе над детекторами ИИ-контента. «Заговор» рассыпался при первом же фактчекинге.

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

Прозаичная реальность

OpenAI наконец прокомментировала ситуацию. Официальный ответ звучал предельно скучно: «Это не водяные знаки, а просто особенность масштабного обучения с подкреплением». Никакого заговора, никакой слежки — банальный артефакт.

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

Нейросеть приобрела «привычку». Никто ее этому не учил, но действие «отложилось в подсознании».

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

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

Дело раскрыто

Парадокс в том, что разоблачить «заговор» оказалось проще, чем его придумать. Один официальный комментарий OpenAI — и вся конструкция рухнула.

Урок простой: перед тем как кричать о заговоре, стоит потратить пять минут на фактчекинг. Google по запросу «reinforcement learning side effects» выдаст тонны статей о побочках машинного обучения. Но кто же будет искать скучные объяснения, когда есть яркие теории?

В следующий раз, когда увидите пост про «тайное оружие техногигантов», вспомните про символы U+202F.

Над теориями заговора можно только смеяться. Больше — в нашем тг-канале!

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

Вирусы распространялись с пугающей скоростью, баннеры с кричащими заголовками вроде «Ты 100-й посетитель! Получи приз!» заманивали доверчивых юзеров, а трояны прятались в самых неожиданных местах — от пиратских игр до якобы «важных» документов. Еще не существовало встроенных защитников системы, двухфакторной аутентификации или удобных менеджеров паролей. Антивирусы только начинали развиваться, а фаерволы казались сложными и загадочными инструментами, которые нужно было правильно настроить, чтобы не заблокировать нужные программы.

Перед вами — подробный разбор главных цифровых угроз 2000-х: от масштабных вирусных эпидемий вроде ILOVEYOU до абсурдных, но популярных мифов о «вирусах на дискетах». Вспомним, как мошенники зарабатывали на доверчивости пользователей, почему переадресации сводили с ума даже опытных юзеров и как первые защитные программы пытались (не всегда успешно) противостоять угрозам.

Вирусы и черви: цифровые эпидемии, которые парализовали сети

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

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

ILOVEYOU: Вирус безграничной «любви»

4 мая 2000 года тысячи пользователей по всему миру получили письмо с безобидной, на первый взгляд, темой «ILOVEYOU» и вложением с незамысловатым текстом:

«LOVE-LETTER-FOR-YOU.TXT.vbs».

Открыв его, юзеры активировали скрипт, который:

• перезаписывал файлы с расширениями .jpg, .mp3, .doc, добавляя к ним свою копию;
• рассылал себя по всем контактам в Outlook;
• похищал пароли и данные автозаполнения форм.

За сутки вирус заразил около 10% всех компьютеров с выходом в сеть. Ущерб оценили в $10-15 млрд, а правительства и корпорации (включая Пентагон и BBC) были вынуждены отключить почтовые серверы.

Создатели вируса — филиппинские студенты — избежали наказания: в стране тогда не было законов о киберпреступлениях.

Nimda: Червяк, который «жил» везде

18 сентября 2001 года, всего через неделю после атак 11 сентября, появился червь Nimda (админ наоборот). Он использовал четыре способа распространения:

1. Через email с зараженными вложениями.
2. Через уязвимости в серверах Microsoft IIS.
3. Через общие сетевые папки.
4. Через JavaScript на зараженных сайтах.

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

Дискетная паника

В конце 1990-х и начале 2000-х пользователи хранили и передавали файлы на дискетах — и вместе с ними распространялись мифы:

• Вирус, который «сжигает» монитор — легенда о том, что специальная программа может испортить экран, меняя частоту развертки. На деле мониторы с ЭЛТ просто отключались при неверных настройках.
• Вирусы-невидимки — слухи о вредоносных программах, которые невозможно обнаружить. В реальности антивирусы того времени действительно пропускали часть угроз, но не из-за «невидимости», а из-за слабых сигнатур.

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

Другие заклеивали отверстие защиты от записи скотчем, даже на новых дискетах — «на всякий случай». Бытовало поверье, что если подержать дискету рядом с магнитом, это «уничтожит возможные вирусы» (хотя на практике стирались и нужные данные).

Эти странные методы показывают, насколько мало обычные пользователи понимали принципы работы вирусов в докомпьютерную эпоху. Реальную защиту могли обеспечить только антивирусные сканеры вроде Aidstest или Dr.Web, но даже они требовали ручного запуска и часто пропускали новые угрозы.

Баннеры и скам: как нас разводили на «халяву»

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

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

«Ты 1 000 000-й посетитель!» — кликни и проиграешь

Один из самых распространенных видов мошенничества — баннеры с сообщениями о выигрыше телефонов, PlayStation или $1000. После клика пользователь попадал на сайт, где требовалось:

• ввести номер телефона, после чего приходила подписка на платные сервисы;
• отправить SMS (стоимостью $5-10);
• установить «проверочную программу» (это мог быть троян).

Такие схемы приносили мошенникам домиллионные прибыли в месяц, а баннерные сети вроде ClickBooth и AdvertPRO зарабатывали на показах.

Бесконечные переадресации: когда «Назад» не работало

Попасть на нужный сайт в 2000-х было не всегда просто. После клика по ссылке браузер мог 10-15 раз перебрасывать пользователя через рекламные страницы.

Как это работало:

1. Пользователь искал, например, ключ для игры.
2. Находил форум с «прямой ссылкой».
3. Кликал — его перекидывало на сайт с рекламой.
4. Через 5-10 секунд — новое перенаправление.
5. В итоге он либо попадал на фишинговый сайт, либо получал вирус.

Бороться с этим помогали Hosts-файлы (куда вручную добавляли списки вредоносных доменов) и первые версии AdBlock.

Трояны и черви: как игры и музыка становились оружием

В погоне за бесплатным контентом пользователи 2000-х часто платили куда большую цену, чем предполагали. Пиратские версии популярных игр и музыкальных треков превратились в идеальную среду для распространения вредоносного ПО. Хакеры быстро смекнули: что может быть эффективнее, чем замаскировать троян под долгожданную новинку?

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

Вирусы в пиратских играх и MP3: цифровая лотерея с опасным призом

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

Технические механизмы заражения:

1. Подмена исполняемых файлов. Пиратские сборки игр часто содержали модифицированные EXE-файлы, которые при запуске устанавливали бэкдоры (например, Backdoor.Win32.Hupigon), встраивали кейлоггеры для кражи паролей. Фейковые патчи и «кряки», включали защиту Windows Defender и добавляли исключения в брандмауэры для скрытого доступа.
2. В MP3-файлах использовалось переполнение буфера в Winamp (CVE-2006-0478) — при воспроизведении трека вирус получал права на запись в системные директории. Специально сформированные ID3-теги вызывали ошибки в Windows Media Player.

В 2006 году, под видом новых треков Rihanna и Eminem, распространялся вирус Worm.Nopir.B, который удалял все MP3-файлы на диске, подменял их на 30-секундные записи с рекламой пиратских сайтов, добавлял в автозагрузку скрипт для кражи данных из браузеров.

Армии цифровых зомби: как ботнеты захватывали интернет

В середине 2000-х хакеры осознали: один зараженный компьютер — это проблема, а тысячи — уже бизнес-модель. Так появились ботнеты — сети из «зомбированных» устройств, которые выполняли команды злоумышленников, пока владельцы спокойно проверяли почту или играли в Counter-Strike.

Технически ботнет напоминал армию роботов. Вредоносная программа (бот) проникала на компьютер через:

• фишинговые письма с вложениями вроде «invoice.doc.exe»;
• уязвимости в Windows XP — например, через сервис RPC;
• пиринговые сети, где под видом треков или игр распространялись трояны

После заражения бот подключался к управляющему серверу через IRC-канал или HTTP-запросы. Оператор мог отдавать команды тысячам машин одновременно — от рассылки спама до атаки на сайты.

В январе 2007 года пользователи начали получать письма с заголовками вроде «230 dead as storm batters Europe». Вложение (файл «video.exe») устанавливало бота, который:

• крал данные через кейлоггер;
• рассылал до 500 млн писем в день (20% мирового спама);
• создавал P2P-сеть для устойчивости — даже после закрытия IRC-серверов ботнет работал.

К 2008 году Storm Worm контролировал 1 млн компьютеров. Его особенность — самообновляемый код: антивирусы не успевали добавлять сигнатуры.

В ноябре 2008 года Conficker использовал уязвимость в службе Windows Server. Он генерировал 50 тыс. доменов в день для связи с C&C-серверами (чтобы их нельзя было заблокировать, отключал антивирусы и Windows Update, заразив в итоге 9 млн ПК, включая системы ВМФ Франции и NHS в Британии.

На борьбу с Conficker выделили спецгруппу (Conficker Working Group), но полностью ликвидировать вирус не удалось — некоторые зараженные машины оставались активны до 2015 года.

Почему ботнеты 2000-х были уникальны:

• Масштаб. Ботнет Rustock в 2010 году рассылал 30 млрд писем в день — больше, чем легальные сервисы вроде Mailchimp.
• Простота управления. Для запуска DDoS-атаки хакеру нужно было ввести одну команду в IRC.
• Экономика. Аренда ботнета стоила $200-500 в день, а доход от спама достигал $2 млн в месяц.

Современные ботнеты стали сложнее (используют Tor и шифрование), но принцип остался тем же: чем больше доверчивых пользователей — тем мощнее армия зомби. Разница лишь в том, что теперь вместо ПК заражают умные холодильники.

Первые фаерволы и антивирусы: защита на ощупь

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

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

ZoneAlarm и «страшные» предупреждения

Один из первых массовых фаерволов — ZoneAlarm — пугал пользователей сообщениями вроде «Программа пытается выйти в Интернет!». Многие в панике блокировали даже системные процессы, ломая Windows.

Особенно проблемными были ситуации, когда фаервол отображал предупреждения только с идентификатором процесса (PID) или пометкой «Unknown Process» — это происходило при смене учетной записи с администратора на обычного пользователя в Windows XP. TrueVector — сервис мониторинга интернет-доступа ZoneAlarm — не всегда корректно загружался без прав администратора, из-за чего фаервол терял информацию о программах и выдавал пугающие, но бесполезные уведомления.

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

Антивирусы — защита с непредсказуемыми последствиями

Dr.Web, Антивирус Касперского и Norton образца 2000-х боролись с вирусами, как могли, но часто замедляли систему до состояния «кирпича». Обновления приходилось скачивать вручную через dial-up-соединение, которое могло оборваться на 99% загрузки, заставляя начинать процесс заново. Базы вирусов устаревали буквально за часы: пока пользователь ждал обновления, его компьютер уже мог быть заражен новой модификацией червя.

Особенно проблемными были «тяжеловесы» вроде Norton Antivirus 2005, которые требовали до 512 МБ оперативной памяти — непозволительная роскошь для типичного ПК тех лет с его 256-512 МБ RAM. При сканировании системы антивирус мог занимать до 90% ресурсов процессора, превращая компьютер в слайд-проектор. Пользователи шутили, что проще переустановить Windows, чем дождаться завершения полной проверки.

Некоторые антивирусы грешили ложными срабатываниями — например, Dr.Web в 2007 году регулярно определял системные файлы Windows XP как вирус «Win32.HLLW.Shadow» и предлагал их удалить. После такого «лечения» операционная система часто переставала загружаться. При этом реальные угрозы вроде руткитов антивирусы пропускали: по данным tests AV-TEST за 2008 год, даже лучшие версии обнаруживали лишь 70-80% новых вредоносных программ.

Эпилог: Что стало с угрозами 2000-х? Эволюция цифровых опасностей

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

Фишинг, который раньше ограничивался поддельными страницами «одноклассников», теперь процветает в мессенджерах и соцсетях. Мошенники создают фейковые чат-боты, имитируют службы поддержки банков и даже используют дипфейки, чтобы обмануть жертв. В 2024 году 68% успешных атак на корпоративные данные начинались именно с фишинга в Telegram или WhatsApp.

Троянские программы тоже не стоят на месте. Если в 2000-х они крали пароли от почты, то сегодня криптоджекинг — скрытый майнинг на зараженных устройствах — приносит преступникам $2,3 млрд в год. Вредоносное ПО научилось обходить двухфакторную аутентификацию, а некоторые трояны умеют подменять транзакции в мобильных банках прямо во время подтверждения платежа.

Ботнеты 2000-х, состоявшие из тысяч зараженных ПК, теперь включают умные холодильники, камеры наблюдения и даже медицинские устройства. Управляют ими через зашифрованные каналы в Tor или Telegram, а для атак используют искусственный интеллект. Например, в 2023 году ботнет Mirai 2.0, состоявший из 600 тыс. IoT-устройств, на сутки парализовал работу облачного сервиса Google Cloud CDN, отправляя 400 млн запросов в секунду.

Но главная константа — человеческая доверчивость. Современные мошенники по-прежнему играют на жадности («Вы выиграли iPhone 15!») и страхе («Ваш компьютер заражен!»). Разница лишь в том, что вместо всплывающих баннеров они используют таргетированную рекламу в соцсетях, а вместо звонков «из техподдержки» — голосовые дипфейки.

Защита тоже эволюционировала: антивирусы научились предсказывать атаки с помощью ИИ, а фаерволы анализируют трафик в реальном времени. Однако, как и 20 лет назад, лучшая защита — критическое мышление. Прежде чем кликнуть на ссылку или ввести данные, стоит задать себе вопрос: «А не пытается ли кто-то заскамить меня, как когда-то — первопроходцев интернета?»

Пока вирусы нам не грозят, можно и посмеяться. Заглядывайте в наш тг-канал!

Контекст

Два года назад ChatGPT взорвал корпоративный мир. CEO наперебой рассказывали на конференциях об ИИ-революции. Инвестиции в проекты достигли пика. Компании массово внедряли кодинговые инструменты, чат-ботов и умных помощников.

А потом случилось неожиданное — ничего.

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

Представьте: сотрудники радостно чатятся с ботами, пишут письма через ChatGPT, генерируют презентации за один клик. Все выглядит футуристично и прогрессивно. Но денег нет. По данным BCG, 74% компаний борются с масштабированием ИИ-сервисов, и лишь 1% руководителей довольны достижениями в этой сфере.

McKinsey провели расследование и нашли неожиданного виновника — самих компаний. Аналитики предлагают радикальное решение: забыть про нейроинструменты и переходить к ИИ-агентам. Эксперты Deloitte прогнозируют, что 25% компаний, использующих генеративный ИИ, запустят их в 2025 году. А Gartner предсказывает, что более 60% всех инноваций в компаниях составят нейропомощники.

Почему ИИ есть везде, а толку нет

Цифры выглядят абсурдно: 78% компаний внедрили ИИ — и 80% из них не заработали на его использовании. Проблема в том, что они относятся к ИИ как к декорации — впечатляет гостей, но толку мало. Сотрудники играют с ChatGPT, генерируют мемы для корпоративного чата и креативят в отчетах. Выглядит круто, но выручка не растет.

McKinsey нашли проблему — дисбаланс инструментов. Компании чаще всего внедряют горизонтальные решения, которые работают сразу во всех отделах, но решают простые задачи. Например, Microsoft 365 Copilot установлен уже в 70% крупных компаний. Он помогает писать письма, создавать презентации, переводить тексты. Польза есть, но размазана тонким слоем по всей компании.

А вот вертикальные проекты — те, что встроены в конкретные бизнес-процессы и работают глобально — провалились. По данным McKinsey, только 10% таких решений реально работают. Компании пытались автоматизировать продажи, аналитику и логистику. Но программисты строили решения с нуля, ИТ-команды работали в изоляции, а бизнес-процессы никто не переосмыслил.

Рассмотрим поближе. Copilot помогает менеджеру написать письмо клиенту за 30 секунд вместо пяти минут. Экономия — 4,5 минуты. Но когда менеджер две недели ждет аналитику по продажам, потому что данные разбросаны по десятку систем, Copilot бессилен.

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

Что такое ИИ-агенты

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

У агентов четыре фичи:

• Память — они помнят историю действий и контекст задачи.
• Планирование — разбивают сложную задачу на шаги.
• Автономность — действуют без постоянного контроля человека.
• Интеграция — подключаются к любым системам компании.

Рассмотрим пример. Клиент жалуется на задержку доставки в 23:00. Обычный ИИ сгенерирует вежливое извинение и «пошлет» покупателя. Агент же проверит трек-номер, найдет посылку, обнаружит, что она лежит в соседнем городе, свяжется с курьерской службой, договорится о доставке на удобный день, отправит клиенту SMS с новым временем и автоматически начислит бонусы за неудобства. К утру проблема решится.

Исследование Warmly показывает: 85% крупных компаний планируют внедрить агентов до конца 2025 года. А 62% ожидают от них полную окупаемость инвестиций или сверхприбыль.

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

Главный вызов — не технологии

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

• Первое — существование людей и агентов. Последние не просто помогают людям, они работают вместе с ними. Взаимодействие часто порождает недоверие к «бездушной машине». По данным KPMG, 48% людей считают, что ИИ уничтожит больше рабочих мест, чем создаст.
• Второе — контроль автономности. Агенты не ждут инструкций, они адаптируются и иногда удивляют. Здесь встает вопрос контроля и оценки результатов работы ИИ. В McKinsey подчеркивают: задача не устранить автономность, а сделать ее понятной и согласованной с целями организации.
• Третье — предотвращение неконтролируемого размножения агентов. Как только low-code платформы сделают создание агентов доступным каждому, компании будут рисковать получить новый вид теневого ИТ. Агенты размножатся по командам, задублируют функции и заработают бесконтрольно.

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

Доверие формируют не системные требования или бенчмарки. Люди доверяют агентам, которые общаются, предсказуемо ведут себя и легко включаются в рутинные задачи.

Как выстроить современную ИИ-архитектуру

McKinsey предлагают новую парадигму — сеть ИИ-агентов. Это система, где они рассуждают, сотрудничают и действуют автономно через множество инструментов. Решение безопасно и легко масштабируется.

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

У архитектуры пять принципов:

1. Композиционность — любой агент подключается без изменения системы.
2. Распределенный интеллект — задачи решают сети взаимодействующих агентов.
3. Многоуровневое разделение — логика, память и интерфейсы работают независимо.
4. Вендор-нейтральность — компоненты легко заменяются при развитии технологий.
5. Управляемая автономность — поведение агентов контролируется через различные права доступа.

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

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

Microsoft уже встраивает агентов в Dynamics 365, Salesforce расширяет Agentforce, SAP перестраивает платформу под интеграцию с агентами. Будущее корпоративного софта за ИИ-агентами, считают аналитики.

ИИ-агенты не должны стать новыми принтерами — это полноценные коллеги, которым нужно передавать рутинные задачи, общаться с ними и вместе продвигать бизнес. Человеку в этой схеме надо следить за новыми «сотрудниками», направлять их и креативить, решать нестандартные задачи. Аналитики из McKinsey правы: пора переосмыслить бизнес-процессы, подготовить команды к новыми технологиям и построить современную архитектуру. Иначе можно остаться за бортом.

Больше про ИИ — в нашем тг-канале!

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

2005-2009: Эпоха авторских решений и первых веб-фреймворков

В середине 2000-х типичный рабочий инструмент программиста — это громоздкий системный блок с процессором Intel Pentium 4 или новеньким Core 2 Duo. Мониторы с ЭЛТ-трубкой постепенно уступали место LCD-экранам с разрешением 1024×768 — именно на таких дисплеях создавались первые версии Wikipedia и набирающих популярность соцсетей. Оперативная память в 1-2 ГБ считалась нормой, а жесткие диски на 80-160 ГБ часто заполнялись до отказа — проекты редко весили меньше нескольких гигабайт.

Серьезная разработка велась преимущественно на стационарных компьютерах. Ноутбуки только начинали входить в обиход — их брали в офис, но для реальной работы предпочитали мощные десктопы. Операционная система Windows XP доминировала на рабочих станциях, в то время как серверы чаще всего крутили на Linux — Red Hat Enterprise или Debian.

Среды разработки того времени сегодня кажутся архаичными. Eclipse и NetBeans потребляли гигабайты памяти, Visual Studio 2005 требовала серьезных ресурсов. Многие разработчики предпочитали простые текстовые редакторы вроде Notepad++, а для отладки использовали примитивные методы вроде вывода значений переменных через print. Контроль версий только начинал входить в практику — Git появился в 2005 году, но большинство команд продолжали использовать SVN или вообще заливали файлы по FTP напрямую на продакшен.

Языковая экосистема этого периода вращалась вокруг трех основных технологий. PHP версий 4 и 4.3 доминировал в веб-разработке — на нем работало около 80% всех сайтов в интернете. Однако его объектно-ориентированные возможности были крайне ограничены до выхода PHP 5 в 2004 году.

Java в лице J2EE оставалась стандартом для корпоративных решений — банковских систем, крупных порталов и ERP-комплексов. Spring Framework только начинал набирать популярность, а Hibernate упрощал работу с реляционными базами данных. C++ сохранял свои позиции в разработке игр (особенно с использованием Unreal Engine), драйверов и высоконагруженных сервисов.

Фронтенд-разработка в те годы была невероятно простой по современным меркам. Верстали преимущественно таблицами, а всю динамику реализовывали через jQuery, который появился в 2006 году и быстро вытеснил нативный JavaScript из повседневной практики. AJAX-запросы казались революционной технологией, позволяющей обновлять части страницы без ее полной перезагрузки.

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

• «Философия Java» Брюса Эккеля;
• «Совершенный код» Стива Макконнелла;
• «PHP и MySQL. Разработка веб-приложений» Люка Веллинга.

Русскоязычное сообщество активно обсуждало вопросы разработки на форумах RSDN.ru и CyberForum.ru. В 2008 году появился Stack Overflow, который постепенно стал главной площадкой для профессиональных обсуждений.

Университетское образование давало хорошую теоретическую базу — алгоритмы, структуры данных, принципы ООП. Однако практическим навыкам приходилось учиться самостоятельно, методом проб и ошибок. Документацию часто скачивали в формате CHM-файлов или читали непосредственно на сайтах вроде php.net и MSDN.

Типичный стек начинающего разработчика в 2009 году:

• HTML/CSS с jQuery для фронтенда;
• PHP или Ruby on Rails для бэкенда;
• MySQL в качестве базы данных.

ORM-технологии еще не получили широкого распространения, поэтому SQL-запросы писали вручную. Многие проекты представляли собой монолитные приложения, где весь код хранился в единой кодовой базе без четкого разделения на модули.

Показательный кейс:

В 2007 году разработчик PHP-приложений из МЭСИ (Москва) столкнулся с типичной для того времени проблемой — SQL-инъекциями. Вместо стандартных решений он создал DLAC (Data Logic Access Component) — обертку для работы с базой данных, которая автоматически экранировала параметры запросов. Это выглядело революционно на фоне типичного кода того периода, где строки запросов часто собирали через конкатенацию с пользовательским вводом.

Компонент использовал новую для 2005 года технологию Generics в C#. Он генерировал параметризованные запросы, что резко снижало риски взлома.

Разработчики в университетской среде тогда редко задумывались о безопасности — многие проекты содержали уязвимости вроде SELECT * FROM users WHERE name = ‘.$_POST[‘name’].

DLAC стал локальным спасением для внутренних систем МЭСИ, пока в 2009 году не появился NHibernate — порт популярного Java-фреймворка Hibernate.

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

2010-2014: Мобильная революция и рассвет JavaScript

Начало нового десятилетия ознаменовалось стремительным ростом мобильных технологий. Выход iPhone 4 в 2010 году и Android 2.3 Gingerbread задал новые стандарты мобильной разработки.

Программисты массово переходили на MacBook Pro — не столько из-за преимуществ macOS, сколько благодаря появлению Retina-дисплеев в 2012 году, которые кардинально улучшили качество отображения кода.

Железо продолжало стремительно эволюционировать. Твердотельные накопители (SSD) начали вытеснять традиционные жесткие диски в рабочих станциях. Облачные платформы вроде AWS и Heroku стали реальной альтернативой локальным серверам, которые раньше часто стояли прямо под рабочими столами в офисах. Оперативная память в 8 ГБ стала стандартом для комфортной разработки, а четырехъядерные процессоры ускорили сборку крупных проектов.

Языковая палитра этого периода значительно расширилась. Objective-C стал основным языком для iOS-разработки и оставался таковым до появления Swift в 2014 году. Python 3 начал набирать популярность благодаря веб-фреймворку Django и научным библиотекам NumPy и Pandas, которые открыли дорогу для анализа данных в массовом сегменте.

JavaScript пережил настоящий ренессанс — после выхода AngularJS в 2010 и Node.js в 2009 году он перестал быть просто «языком для анимаций на сайте», превратившись в полноценную платформу для fullstack-разработки.

Важный факт. В 2011 году разработчик из Сан-Франциско Райан Даль представил Node.js — среду выполнения JavaScript на стороне сервера. За первые 24 часа после релиза проект собрал 10 000 звезд на GitHub, что для того времени стало рекордом. Многие скептически относились к идее использовать JavaScript вне браузера, но уже через год такие компании как LinkedIn и Walmart перевели части своего бэкенда на Node.js, получив прирост производительности в 2-3 раза по сравнению с традиционными решениями на Java и Ruby.

Образовательная сфера претерпела значительные изменения. В 2011 году запустилась Coursera с первым массовым курсом по программированию — Machine Learning от Эндрю Ына. В 2012 году в Кремниевой долине открылся Hack Reactor, ставший прототипом современных coding bootcamps (интенсивов по программированию). Эти форматы предложили альтернативу традиционному университетскому образованию, сделав акцент на практических навыках.

Параллельно в России:

• В 2012 году появился Hexlet — одна из первых русскоязычных платформ с практико-ориентированными курсами по программированию. Особенность: выполнение заданий в реальной среде разработки через браузер. Платформа до сих пор работает: на текущий момент 80% выпускников трудоустраиваются в IT, согласно исследованию ВШЭ. В 2012 этот показатель был еще выше.
• «Нетология» (основана в 2011) к 2013 году запустила курсы по веб-разработке с акцентом на JavaScript и Python, сотрудничая с российскими tech-компаниями. Их модель включала менторство и проектные работы.
• В 2013 году стартовал Stepik — платформа с открытыми курсами от ведущих вузов (ИТМО, МФТИ). Особенность: интерактивные задачи с автоматической проверкой кода, что было прорывом для местного рынка.

Курс «Введение в Linux» от Stepik (2014) за полгода собрал 50 тыс. студентов — рекорд для Рунета. Задания включали настройку виртуальных серверов, что сразу применялось в работе.

Эти проекты заложили основу для бума EdTech в России после 2015 года, доказав, что онлайн-формат может давать актуальные навыки быстрее вузов.

Типичный разработчик среднего уровня в 2014 году:

• понимал принципы REST API;
• начинал осваивать основы DevOps с появлением Docker в 2013;
• экспериментировал с микроконтроллерами вроде Arduino или Raspberry Pi, создавая собственные IoT-устройства.

В профессиональной среде начал формироваться консенсус о том, что PHP устаревает для сложных коммерческих проектов.

2015-2019: Эра больших данных и облачных технологий

Аппаратные возможности сделали очередной рывок вперед. Многоядерные процессоры Intel i7 и AMD Ryzen стали стандартом для рабочих станций. 16 ГБ оперативной памяти перестали быть роскошью, а мониторы с разрешением 4К стали доступны широкому кругу разработчиков. В 2015 году появился Visual Studio Code, который быстро обогнал по популярности Sublime Text и Atom благодаря удачному сочетанию функциональности и производительности.

Языковая экосистема продолжила развитие. TypeScript, представленный в 2014 году, предложил решение проблемы масштабируемости JavaScript-кода в крупных проектах. Go от Google, созданный еще в 2009, нашел свою нишу в разработке микросервисов и инструментов оркестрации вроде Kubernetes (2015). Rust от Mozilla начал завоевывать доверие системных программистов благодаря уникальной системе владения памятью.

JavaScript-сообщество столкнулось с первыми серьезными проблемами. В 2016 году инцидент с пакетом left-pad показал уязвимость экосистемы npm — удаление одного небольшого модуля привело к сбоям в работе тысяч проектов по всему миру. Это заставило разработчиков задуматься о зависимости от сторонних библиотек.

Типичный senior-разработчик в 2019:

• разбирался в микросервисной архитектуре и понимал, как избежать vendor lock-in (привязки к поставщику) при работе с облачными провайдерами;
• имел опыт работы с React или Vue.js;
• знал, что понимание принципов работы алгоритмов становится менее важным, чем развитие soft skills для работы в команде.

Ключевые технологии этого периода включали Kubernetes, который стал стандартом де-факто для оркестрации контейнеров, а также TensorFlow (2015) и PyTorch (2016), открывшие эру машинного обучения для широкого круга разработчиков. Появились первые серьезные инструменты для работы с большими данными — Apache Spark, Hadoop.

Ключевой момент. В 2016 году Netflix раскрыл детали своего перехода на облачную инфраструктуру AWS. Компания полностью перенесла все сервисы — от рекомендательной системы до биллинга — в облако за семь лет. Главным триггером стала катастрофа 2008 года, когда три дня простоя дата-центра оставили 8,4 млн подписчиков без доступа к сервису. Миграция потребовала перепроектирования архитектуры: инженеры разбили монолит на 500 микросервисов и внедрили Chaos Monkey — инструмент для тестирования отказоустойчивости, который случайно отключал серверы в продакшене.

Этот кейс стал хрестоматийным примером cloud-native подхода. Облачные технологии стали активно использоваться в разработке, а обращение с ними — обязательным навыком для прогеров.

2020-2024: AI-assisted разработка и новые парадигмы

Пандемия COVID-19 ускорила переход на удаленную работу. Программисты по достоинству оценили макбуки на чипах M1 (2020) за их энергоэффективность и производительность. Домашние офисы оснащались 32-дюймовыми 4К-мониторами и механическими клавиатурами, ставшими своеобразным профессиональным стандартом.

Языковая палитра продолжала обогащаться. Rust официально вошел в ядро Linux в 2022 году, подтвердив свой статус системного языка нового поколения. Zig появился как современная альтернатива «C» с акцентом на безопасность. WebAssembly (Wasm) позволил запускать ресурсоемкие приложения прямо в браузере, открыв новые возможности для веб-разработки.

Искусственный интеллект начал проникать в повседневную работу программистов. GitHub Copilot на базе GPT-3, представленный в 2021, изменил сам процесс написания кода, предлагая контекстные подсказки. Low-code платформы вроде Retool упростили создание внутренних инструментов для бизнеса.

Типичный lead-разработчик в 2024 году:

• умел эффективно работать в гибридных командах (офис + удаленка);
• автоматизировал рутинные задачи через ChatGPT API;
• следил за развитием квантовых вычислений, хотя практическое применение пока оставалось ограниченным.

Ключевой момент. В 2023 году GitHub Copilot, разработанный совместно с OpenAI, стал катализатором перемен в индустрии. За первый год после релиза инструмент использовали более 1,3 млн разработчиков — каждый десятый подписчик GitHub. Система анализировала контекст кода и предлагала целые функции: например, при написании SQL-запроса она автоматически генерировала соответствующую модель данных на Python. Amazon внедрил аналогичный инструмент Amazon Q Developer для внутренних команд — по заявлению CEO Энди Джесси, это сэкономило компании 4,500 человеко-лет работы и $260 млн ежегодно.

Но были и курьезы. В 2024 году разработчик из Берлина случайно отправил в продакшен код, полностью сгенерированный Copilot. Система использовала фрагмент из GPL-лицензированной библиотеки, что нарушило политику компании по открытому ПО. Инцидент заставил пересмотреть процессы ревью: теперь 78% команд требуют ручной проверки AI-кода перед мержем (слиянием).

Параллельно выяснилось, что Copilot в 40% случаев предлагает уязвимый код при работе с СУБД — это привело к взлому API стартапа через SQL-инъекцию. Такие кейсы показали, что ИИ пока не заменяет программистов, а требует от них новых навыков — критического анализа машинных предложений и понимания юридических аспектов кода.

2025: Современное состояние профессии

Современные рабочие станции программистов оснащены ноутбуками с процессорами Apple M4 (3 нм) или Windows-машинами на Snapdragon X Elite. Мониторы с разрешением 8К используются для разработки AR-приложений, а OLED-экраны с HDR стали стандартом для работы с графикой. Появляются первые экспериментальные IDE с нейроинтерфейсами, способные предсказывать код на основе анализа мозговой активности.

Среди языков программирования выделяется Mojo (2023) — «Python для GPU», набирающий популярность в сфере машинного обучения. Carbon как потенциальный наследник C++ пока остается в тени Rust. Квантовые языки вроде Q# и Cirq интересуют в основном энтузиастов и исследователей.

Профессия претерпела значительные изменения. ИИ стал не конкурентом, а помощником — по некоторым оценкам, около 60% рутинного кода в 2025 году (тесты, документация) генерируется автоматически. Знание английского языка стало важнее знания сложных алгоритмов — без него невозможно эффективно работать с современными AI-инструментами. Понятие «fullstack-разработчик» трансформировалось — теперь оно подразумевает владение фронтендом, одним бэкенд-языком и основами машинного обучения.

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

Будущее обещает новые трансформации. К 2030 году нейроинтерфейсы смогут заменить традиционные устройства ввода, а квантовые компьютеры — перевернуть основы криптографии. Но пока актуальными остаются проверенные временем принципы: изучать перспективные технологии (вроде Rust и Mojo), осваивать работу с ИИ и, конечно, совершенствовать главный навык любого программиста — умение быстро и грамотно гуглить.

Ты уже программист, если читаешь это! Больше о кодинге тут.

В 2025 году компания привлекла $72 млн инвестиций в раунде серии C. И все это — на продукт, который существует «по ту сторону» комфорта.

Бизнес-модель, о которой принято молчать

С точки зрения химии, мы просто отключаемся, услышав слово «смерть», потому что это наш главный механизм отрицания. Никто не хочет думать о том, что когда-то умрет.

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

Empathy вышла на рынок в удачное время: в 2021 году на пике пандемии, когда тема смерти стала особенно актуальной (как бы ужасно это ни звучало). Это также совпало с пиком активности венчурных инвестиций, благодаря чему компания быстро объявила два раунда в год запуска: сначала $13 миллионов, затем — ещё $30 миллионов всего через пять месяцев.

Стартап был основан в Израиле, где продолжается развитие R&D-направления, но его основной рынок — США, где он продаёт свои услуги через страховые компании и работодателей. По словам Гуры, сегодня около 5 миллионов сотрудников и 35 миллионов держателей страховых полисов используют инструменты Empathy. А в том году всего за четыре месяца 7 миллионов человек получили доступ к новому продукту — Empathy LifeVault. Это цифровой сейф, в котором можно хранить юридически важные документы, чтобы упростить вопросы с наследством.

В июне 2025 года Empathy привлекла $72 миллиона в раунде серии C, и общая сумма привлеченного капитала теперь достигает $162 млн. Интерес вызывает не только сумма, но и состав спонсоров, среди которых крупнейшие страховые компании США: MetLife, New York Life, Allianz, Aflac, Securian, Citi, Munich Re и TIAA. Эти корпорации не только вложились в Empathy, но и стали частью Empathy Alliance — коалиции, которая стремится переосмыслить подход к эмоциональной поддержке в трудные периоды жизни.

Что делает Empathy

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

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

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

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

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

Empathy не просто продает софт — она пытается изменить общественные нормы и снять стигму с темы утраты. Каждый год компания публикует отчет о «налоге на горе» (Grief Tax) — исследование, которое показывает, как смерть близкого человека влияет на финансы, здоровье, отношения и карьеру.

Рынок, на котором никто не хотел работать

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

Никто не хочет признавать, что мы просто муравьи, играющие в страх и жадность — производим, продаем, покупаем, а в итоге уходим, как и все остальные.

Однако смерть — не ниша, а универсальный опыт. Более 3 миллионов человек умирают в США ежегодно, и каждая смерть порождает десятки сопутствующих задач. И сейчас Empathy помогает страховым компаниям строить долговременные межпоколенческие отношения, улучшая клиентский опыт.

Сегодня Empathy действует по модели B2B2C: 99% пользователей приходят через страховые компании и работодателей, и это десятки миллионов человек. А значит, смерть стала масштабируемым продуктом — но не лишилась человечности.

Последнее желание

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

Представьте, что вам осталось жить один день. Мне 90, я окружен своими дочерьми, внуками и женой. В доме чисто и уютно. Я вкусно поел — ригатони с лобстером, мы выпил вина. Я просто не проснулся после дневного сна. Идеально. А теперь: что произойдет в ту самую секунду, как меня не станет?

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

Зачем вообще писать комментарии в коде?

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

Какие задачи они решают ?

1. Пояснить неочевидное

Код показывает «что» делает программа, а комментарий — «зачем».

Такой комментарий не просто поясняет логику — он экономит десятки минут будущего чтения.

2. Предупредить

В коде бывает странное поведение. Иногда это не баг, а фича. И если не предупредить, другой разработчик обязательно «поправит» и всё сломает. Комментарий защитит от этого:

3. Пометить незавершёнку

TODO, FIXME, HACK — это специальные маячки. Их ставят туда, где нужно что-то доделать, починить или переписать по-человечески.

Бонусом, IDE умеют обрабатывать такие заметки, каждая по-своему.

4. Временно отключить код

Иногда нужно что-то закомментировать, чтобы проверить гипотезу. Но такой код нельзя оставлять надолго. Если от него нет пользы — в мусор. Историю всё равно сохранит git.

5. Объяснить архитектуру

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

6. Генерация документации

Многие языки и фреймворки поддерживают специальные форматированные комментарии для генерации документации. Например, JavaDoc в Java, docstring в Python, XML в C# – предназначены для описания интерфейсов: что делает функция или класс, какие имеют входные параметры и какой результат дают. Такие Комментарии выполняют роль пользовательской документации прямо в коде и могут автоматически собираться в справочник по API.

7. Пошутить

Программисты – тоже люди, и иногда оставляют в коде шуточные либо эмоциональные комментарии, чтобы снять стресс. В открытых исходниках можно встретить комментарии с шутками, сарказмом или даже ругательствами, адресованными сложному коду или «костылям».

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

Когда комментарии помогают

А часто без комментариев в коде сложно разобраться, особенно когда код чужой.

1. Когда логика не лежит на поверхности

Есть участки кода, где без контекста трудно разобраться, даже если код написан довольно читабельно. Например, сложная формула, нетривиальный алгоритм или необычная структура данных – всё, что выбивается из обыденного опыта разработчиков. В таких случаях пара строк комментария, резюмирующих подход, или объясняющих, что происходит, сэкономят часы на анализ. Это особенно важно для командной работы: коллегам, незнакомым с модулем, не придётся разбираться «с нуля».

2. Когда нужно документировать контракты и условия

Комментарии могут использоваться для обозначения контрактов – предусловий и постусловий функций, инвариантов и т.д. (подход Design by Contract). Хотя современные языки позволяют выразить многое (например, через assert или декораторы), комментарии могут дополнять код уточнениями вроде:

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

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

3. Когда нужно предоставить контекст и ссылки

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

4. Когда нужно облегчить ревью

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

В PEP 8 (стиле кодирования Python) прямо приводится пример: комментарий “Compensate for border” – полезный, в отличие от банального “Increment x”, который не даёт новой информации.

5. Когда нужна поддержка самодокументируемости через структуру

Иногда хочется написать: # Этап 1: авторизация пользователя, и в этот момент приходит мысль — а почему бы не вынести это в функцию authorize_user()? И комментарий уже не нужен. То есть сам порыв объяснить словами часто указывает, что код пора расчленить и упростить.

6. Когда нужно кого-то обучить программированию или корпоративным стандартам оформления кода

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

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

Когда комментарии вредят

Худшее, что может случиться с комментариями – когда они вводят в заблуждение или засоряют код впустую. Рассмотрим подробнее:

Дублируют очевидное

Комментарий, который просто повторяет код своими словами, не несёт никакой пользы:

А вот так — лучше вообще без пояснений:

Комментарий должен объяснять, зачем что-то делается, а не что именно:

Врут и вводят в заблуждение

Классика: код переписали, а про комментарий забыли.

Спустя некоторое время код могли переписать, и old_api_call() заменили на new_api_call(), но комментарий остался от прежней версии и стал источником дезинформации: разработчик, читающий код, может принять заведомо неверное решение, доверившись устаревшей заметке. По этой причине крайне важно понимать: если уж пишете комментарий, держите его в актуальном состоянии вместе с кодом.

Показывают, что код плохой

Когда код плохо читается, и его пытаются «объяснить» словами, вместо того чтобы переписать:

Вместо этого — понятный код:

Плодятся бесконтрольно

Иногда встречается код, где каждое действие сопровождается избыточными пояснениями:

Здесь нет ни одной неочевидной строки. Лучше оставить так:

Представляют собой мёртвый код

Когда в коде остаются большие мёртвые блоки, которые просто закомментированы:

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

Запутывают и размывают смысл

Что значит «временное»? Когда переделывать? Почему не постоянное?

Лучше так:

Теперь ясно, почему так сделано, и можно отследить, когда это поведение закончится.

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

Самодокументируемый код vs комментарии

Есть мечта у программистов — писать код, который объясняет сам себя. Без сносок, без подсказок, без комментариев. Такой код читается как инструкция: открыл — понял. Это и называется самодокументируемым стилем.

Как его достигают?

• Говорящие имена. Не x и a, а temperature, retryLimit, userProfile. Лучше сразу по имени понять, что перед тобой — массив с ID или словарь с настройками.
• Функции с характером. У функции должно быть имя-глагол, в котором есть ответ на вопрос “что делает этот код?”. Например: parseInvoice(), sendEmailReminder(), fetchUserByToken().
• Использовать названия для константных значений. Вместо if (status == 4) — if (status == ORDER_CONFIRMED). Вместо 3000 — RETRY_TIMEOUT_MS.
• Структура — как абзацы в тексте. Пустые строки, логические блоки, отступы — чтобы этапы выделялись сами собой.

Посмотрим например, где простой код поясняется ненужным комментарием:

Другой пример:

Комментарий уже не нужен. Из имён всё понятно: считаем среднюю температуру. Здесь самое интересное — само документируемость имеет границы. Потому что:

• Код объясняет «что», но не всегда «почему».

Вот есть строка:

А почему 5? Почему не 3, не 10? Если причина — ограничение API, бизнес-логика или чья-то странная прихоть — код не расскажет. А вот комментарий может:

Неочевидные решения и компромиссы

Иногда приходится делать что-то нестандартное. Например:

Такой кусок кода без пояснений вызовет недоумение: А почему не сортируем?

Старайтесь писать код так, чтобы его поняли без подсказок. Как будто у вас нет возможности что-то дополнительно объяснить. А если видите, что читателю будет трудно — помогите: добавьте комментарий, который действительно нужен.

Влияние ИИ и новых инструментов на подход к комментариям

В последние годы в распоряжении разработчиков появились мощные ассистенты на базе искусственного интеллекта — такие как GitHub Copilot (автодополнение кода на основе ИИ) и большие языковые модели вроде ChatGPT. Эти технологии начинают влиять и на практики комментирования кода.

Во-первых, автогенерация кода по комментариям стала реальностью.

Инструмент Copilot способен на лету написать фрагмент кода, ориентируясь на описания на естественном языке. Например:

Copilot тут же может подставить реализацию:

Такой подход превращает комментарий в своего рода промпт — описание задачи для ИИ. Это приучает писать коротко и по делу. Хотя такие комментарии потом часто удаляют, их роль в генерации кода становится всё важнее.

Во-вторых, ИИ сам пишет комментарии.

Можно просто показать код:

…и попросить ИИ: прокомментируй. В ответ он выдаст:

Или даже более детальный:

Такие автокомментарии могут быть полезны, но всё равно требуют проверки: всезнающий ИИ не всегда понимает скрытые нюансы логики, а часто просто галлюцинирует, поэтому доверять полностью не стоит, но, как черновик, вполне годится.

В-третьих, стало проще понимать чужой код без комментариев.

Раньше приходилось часами вчитываться, сегодня — можно просто спросить:

Запрос в ChatGPT: что делает эта функция?

Ответ: Она возвращает новый список, содержащий удвоенные значения тех элементов исходного списка, которые делятся на 3.

ИИ не волшебник, но в 90% случаев — удобный переводчик с машинного на человеческий. Это снимает часть нагрузки с необходимости документировать тривиальные вещи.

В-четвертых, новый тип комментариев: инструкции для ИИ

Может возникнуть ситуация, когда комментарий пишется не столько для человека, сколько как команда:

Если вы используете Cursor или Replit, это может очень полезным.

Заключение

Так всё-таки, комментарии – зло или спасение?

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

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

Откуда началось: мой путь в финтех

До Finance.kz я работал в казахстанских финтех-проектах — bai.kz и finbee.kz. Там понял, что рынок агрегаторов в Казахстане находится в зачаточном состоянии. Пользователи мучились, сравнивая предложения банков вручную, а сами финансовые организации не умели эффективно работать с цифровыми каналами привлечения клиентов.

Finance.kz существовал уже более 3 лет, но работал как классический сайт-витрина. Когда я пришёл в проект год назад, стало ясно: нужно полностью переосмыслить подход и создать технологическое решение нового поколения.

Состояние рынка: от монополии к жёсткой конкуренции

Казахстанский рынок агрегаторов финансовых продуктов переживает бум. Ещё два года назад здесь было 2-3 локальных игрока с простейшим функционалом. Сегодня ситуация кардинально изменилась — зашли зарубежные команды: vbr.kz, fintree.kz, moneypanda.com и другие.

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

Технологические вызовы: интеграция с госсервисами и банками

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

API-интеграции с банками и МФО

За год мы реализовали прямые API-интеграции с крупнейшими игроками рынка. Это означает, что пользователь может не просто сравнить условия кредитов, но и подать заявку, пройти скоринг и получить одобрение, не покидая наш сайт.

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

Интеграция с госорганами

Finance.kz интегрируется с государственными сервисами eGov и Палаты предпринимателей (ПКБ). Это позволяет автоматически подтягивать справки о доходах, данные о трудоустройстве и другие документы, необходимые для получения кредита.

Работа с госAPI — отдельная история. Протоколы меняются, документация часто устаревает, а техподдержка работает в режиме «как получится». Но результат того стоит: время оформления кредита сокращается с нескольких дней до 15-30 минут.

Архитектура продукта: ставка на микросервисы

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

Backend

Основные сервисы написаны на Node.js с использованием Express.js. Для работы с базами данных используем PostgreSQL для транзакционных данных и Redis для кэширования. Очереди сообщений реализованы через RabbitMQ — это критично для обработки заявок пользователей.

Отдельно выделили сервис интеграций, который отвечает за взаимодействие с внешними API. Он построен по принципу circuit breaker — если один из банков не отвечает, это не ломает работу всего агрегатора.

Frontend

Фронтенд построен на React с использованием Next.js для серверной отрисовки. Это важно для SEO — львиная доля трафика приходит из поисковых систем по запросам типа «кредит онлайн».

Стратегия «единого окна»: от поиска до получения

Наша главная идея — превратить агрегатор из витрины в полноценный финтех-сервис. Пользователь должен получить продукт полностью онлайн: от сравнения условий до перечисления денег на карту.

Для этого мы реализовали несколько ключевых функций:

• Умный подбор продуктов на основе данных пользователя и машинного обучения
• Предварительный скоринг для оценки вероятности одобрения ещё до подачи заявки
• Автоматическое заполнение анкет с подтягиванием данных из госсервисов
• Отслеживание статуса заявки в реальном времени

Монетизация: CPS как основа устойчивого бизнеса

Мы работаем по модели CPS (Cost Per Sale) — получаем комиссию только за успешно выданные продукты. Для кредитов это 2% от суммы, для микрозаймов — фиксированная сумма от 7 до 15 тысяч тенге.

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

Конкурентные преимущества: локализация против красивых интерфейсов

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

Что даёт локальный подход:

• Знание рынка: мы понимаем особенности работы казахстанских банков и МФО
• Связи с регуляторами: легче договариваться об интеграциях с госорганами
• Техническая экспертиза: наша команда уже прошла путь интеграции с местными API
• Гибкая настройка продукта под изменения законодательства и требований ЦБ

Результаты и метрики

За год активного развития мы достигли:

• 150 000 уникальных пользователей в месяц
• Интеграция с 15+ финансовыми организациями
• Конверсия заявка-выдача на уровне 35-40% (против 15-20% у конкурентов)
• Средний чек по кредитам — 1,2 млн тенге, по микрозаймам — 85 тысяч

Планы на будущее: от агрегатора к экосистеме

Ближайшие 1-2 года будут критичными для всего рынка. Мы видим несколько ключевых направлений развития:

Расширение продуктовой линейки

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

Внедрение ИИ и машинного обучения

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

Международная экспансия

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

Собственные финансовые продукты

В долгосрочной перспективе планируем получить лицензию МФО и предлагать собственные займы наиболее качественным клиентам.

Уроки и выводы

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

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

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

*Зарплаты указываем в год до уплаты налогов, в долларах США, чтобы было проще. Курс валют — по состоянию на май 2025 года.

Россия

Зарплаты в российском IT сильно зависят от региона, компании и направления. В среднем junior-разработчики получают от $9 500 в год — примерно $800 в месяц. Middle — около $22 800 в год или $1 900 в месяц, а Senior — от $40 000 в год и выше.

Отдельно стоит отметить DevOps-специалистов и аналитиков данных — их доходы на 10–20% выше, чем у разработчиков на тех же грейдах. Если у миддла-бэкендера годовая зарплата составляет $23 000, то DevOps или data scientist может зарабатывать от $25 000 до $28 000 — особенно в крупных компаниях, финтехе или инфраструктурных проектах.

Что касается трат:

• Аренда: студия в Москве обойдётся от $650–750 в месяц, не в центре и без вида на Москва-Сити. Чаще всего это обычный дом с окнами во двор или на соседний проспект.
• Транспорт: поездка в метро стоит $0.6, каршеринг — $5−7 за поездку из окраины в центр, если не стоять в пробках по часу. Шеринг удобнее и дешевле такси, когда умеешь парковаться. Расходы на бензин — примерно $0.75 за литр 95-ого.
• Питание: обед в кафе — $10-15, фастфуд — от $3.
• Хобби: спортзал — от $30 в месяц, настолки — бесплатно, если друзья не жадничают.
• Медицина: формально — бесплатно по ОМС, но с очередью на месяц к узким специалистам. В реальности многие пользуются ДМС от работодателя.
• Соцзащита: отпуск по ТК, декрет, субсидированные детсады — всё это работает, особенно в крупных городах.

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

Я, наверное, не самый типичный айтишник — не живу по полгода в тёплых странах, а рестораны уже перерос. Работаю удалённо из Красноярска, зарабатываю около 3 млн рублей в год. Этого хватает на ипотеку, хобби и дальние поездки на машине. С семьёй любим путешествовать по России — были на Байкале, в Бурятии, на Алтае. Работа стабильная, требует внимания и постоянного роста. В свободное время занимаюсь тайским боксом, собираюсь этим летом попробовать стендовую стрельбу и парусный спорт. Живём в частном доме за городом, так что дел хватает и по хозяйству, и с детьми — у нас их двое. А в прошлом году поступил в Политех на заочку.

США

В американском IT уровень дохода сильно зависит от штата, компании и направления. В среднем цифры следующие: Junior-разработчики зарабатывают от $80 000 в год, middle — около $120 000, а senior — от $150 000. Специалисты в DevOps и Data Science получают от $130 000 до $160 000, особенно если работают в крупных технологических компаниях: FAANG и аналогах.

Теперь — о жизни и расходах:

• Аренда: студия в Сан-Франциско обойдётся в $2 800–3 500 в месяц, и это без вида на мост. В Нью-Йорке — не дешевле.
• Транспорт: личная машина — почти необходимость, особенно за пределами крупных городов. Бензин стоит около $1 за литр, страховка и обслуживание — ещё пара сотен в месяц.
• Еда: чашка кофе — $5, бургер — $15, полноценный обед — $25 и выше.
• Хобби: абонемент в спортзал — от $50, подписки на Netflix и Spotify — $70+ в месяц, занятия вейкбордингом или сёрфингом — от $100 за уикенд.
• Медицина: страховка — почти обязательна, стоит $400–600 в месяц, без неё любая простуда превращается в финансовую катастрофу.
• Соцзащита: частные компании дают отпуск по 10–15 рабочих дней, не везде предусмотрены оплачиваемые больничные.

Даже на позициях сеньора жить одному в центре города — дорого. Многие арендуют жильё с соседями или уезжают в пригороды, где цены ниже, но без машины уже не обойтись. IT даёт возможность быстро расти в доходах, особенно в стартапах или FAANG, но и конкуренция — как на драфте в NBA.

Работаю в команде, которая развивает AI-сервисы для терминала Bloomberg — системы, которой пользуются финансисты и госструктуры по всему миру. Мы делаем что-то вроде встроенного голосового ассистента, способного анализировать биржевые и новостные данные. Я хожу в офис 4 дня в неделю — так проще держать ритм. День проходит между кодом, митингами и кофе. В свободное время стараюсь выжать максимум из Нью-Йорка: волейбол, теннис, пробежки в Центральном парке, театр, джаз-клубы и нескончаемый ремонт квартиры. Летом почти каждые выходные — выезды за город. Социально влиться в Нью-Йорк несложно: тут очень много мигрантов и разных культур. Хотя иногда интроверт во мне побеждает — и тогда я с радостью остаюсь дома с женихом.

Германия

IT-специалисты получают умеренные по западным меркам зарплаты, но выигрывают за счёт социальной защиты и предсказуемого качества жизни. Junior-разработчик зарабатывает около $50 000 в год, middle — около $65 000, а senior — от $90 000. Специалисты в DevOps и Data Science в крупных городах вроде Берлина или Мюнхена могут получать до $100 000–110 000 в год.

Что с расходами:

• Аренда: студия в Берлине обойдётся в среднем от $1 000 в месяц. Цены растут, но пока остаются ниже, чем в США или Великобритании.
• Транспорт: месячный проездной стоит около $65, но многие предпочитают велосипед. Бензин дорогой — почти $2 за литр.
• Еда: буханка хлеба — $2.20, обед в недорогом кафе — $15–25, ужин дома из супермаркета — ощутимо дешевле.
• Хобби: абонемент в фитнес — $35–45 в месяц, а на концерты и выставки часто можно попасть бесплатно или по символической цене.
• Медицина: государственная страховка обходится в около 7% от зарплаты, но почти полностью покрывает услуги — от стоматологии до психотерапии.
• Соцзащита: минимум 30 дней отпуска в год, оплачиваемые больничные с первого дня. Декретный отпуск — до 3 лет, с выплатами до 14 месяцев.

Жизнь в Германии структурирована: middle-разработчик уже может жить один, часто — с балконом и кладовкой. Senior — в двухкомнатной квартире с партнёром и кошкой. Овертаймы — редкость. Если кто-то продолжает переписку в Slack после 18:00, это воспринимается как тревожный звонок, признак неэффективности или выгорания.

Живу в Германии с 2017 года. За это время многое стало привычным, но до сих пор приятно удивляет. Рабочая культура устроена так, что никто не жмёт на газ: овертаймы — редкость, а 30 дней отпуска в году — норма. Люди не соревнуются, кто больше переработал. Быть просто хорошим разработчиком — это ок. Германия удобна и в быту: развитый общественный транспорт, автобаны для любителей машин, зелёные леса, замки, Альпы под боком. А ещё — комфортная среда для жизни: много IT-компаний, доступная инфраструктура, возможность работать супругам и высокий уровень безопасности. Неудивительно, что всё больше айтишников выбирают именно эту страну.

Япония

Разработчики в Японии зарабатывают в среднем:

• джуниоры — около $30 000 в год,
• миддлы — $45 000,
• сеньоры — до $70 000.

Специалисты в DevOps и Data Science могут получать $80 000–90 000, особенно в крупных корпорациях, где создают сервисы на международный рынок.

Расходы на жизнь:

• Аренда в Токио: от $800 за небольшую квартиру; чем ближе к центру — тем выше цена, но и инфраструктура удобнее.
• Транспорт: безлимитный проездной — от $100/мес, метро работает как по расписанию NASA. Бензин — примерно $1.3 за литр. Мигрантам стоит запомнить: в Японии все едут по левой стороне дороги, приоритет у помехи тоже слева.
• Еда: обед в кафе обойдётся в $6–9, ужин в раменной — около $10. Продукты в супермаркетах стоят дороже, чем в других азиатских странах.
• Хобби: повсюду геймерские клубы, общества любителей манги, тематические кафе. Расходы сильно зависят от степени увлечённости.
• Медицина: обязательная страховка равна примерно $100 в месяц и покрывает основное лечение и визиты к врачу.
• Соцзащита: формально надёжная, но важные детали могут быть в трудовом контракте — особенно у иностранцев.

В Японии чисто, безопасно и невероятно удобно жить. Но без японского языка может быть трудно интегрироваться, особенно вне IT-сферы. Дисциплина и уважение к правилам — часть повседневной жизни. Если они вам по душе, Токио может стать вторым домом.

Переезд в Японию оказался проще, чем я ожидал. Виза, жильё, оформление документов — всем занималась компания, даже трансфер из аэропорта организовали. Рабочий язык в офисе — английский, коллеги со всего мира. Квартиру нашли за две недели, на первое время предоставили временное жильё. Оборудование для домашнего офиса — за счёт компании. В быту выручают Google Translate и ChatGPT, с их помощью можно спокойно решать повседневные вопросы. Жизнь здесь удивительно комфортна, если есть поддержка и интерес к культуре.

Великобритания

Разработчики в Великобритании получают в среднем:

• джуниоры — около $45 000 в год,
• миддлы — $65 000,
• сеньоры — до $90 000.

Специалисты в DevOps и Data Science зарабатывают $90 000–110 000, особенно в Лондоне и Эдинбурге, где востребованы кадры для банков, финтеха и стартапов.

Расходы на жизнь

• Аренда в Лондоне: около $2 300 в месяц за однушку в приличном районе. Дешевле — только если снимать комнату или уехать за МКАД… простите, за M25.
• Транспорт: проездной Oyster — от $200 в месяц. Лондонское метро — как музей под землёй: готический интерьер с сюрпризами. Бензин стоит $1.8 за литр, а дорожное движение — левостороннее, как и в Японии.
• Еда: ужин в индийском кафе — $12, пинта пива в пабе — $7, а поход в супермаркет способен сильно удивить — и не всегда приятно.
• Хобби: парки, бесплатные музеи, стендап-клубы, тематические коворкинги и даже кружки настолок — скучать сложно.
• Медицина: государственная система NHS бесплатна, но нужно привыкнуть к очередям и записи к терапевту через две недели.
• Соцзащита: 25+ дней отпуска, стабильные трудовые контракты и работающие профсоюзы.

Зарплаты позволяют комфортно жить, особенно за пределами Лондона. Девопсы и дата-сайентисты — нарасхват. Английский знать нужно, но в отличие от Японии — вы его хотя бы слышали в школе. Карьерный рост возможен, особенно если знаете, чего хотите и умеете себя продать.

Я переехала в Лондон из Польши после восьми офферов и долгой проверки на визу — сам процесс занял почти восемь месяцев. Компания оплатила аренду на первый месяц, помогла с оформлением визы, а постоянное жильё мы уже искали с учётом школы для ребёнка. Сейчас мы вдвоём с мужем работаем разработчиками. На аренду и еду уходит около 30% дохода. Продукты стоят примерно как в Польше, бытовая химия даже дешевле. В быту и на работе используем английский, и это сильно упрощает адаптацию. Уровень жизни высокий, зарплаты достойные, а IT-комьюнити — очень живое и дружелюбное.

Давайте сравним

Где жить — зависит не только от зарплаты, но и от того, как вы хотите жить. Кто-то хочет в Альпы, кто-то — в аниме-рай, кто-то — чтобы мама могла приехать на выходные. И это нормально.

Но если выбирать по зарплате — вот наглядная таблица с доходами и расходами в месяц.

Заключение

Выбирать страну для релокации сложно, потому что влияет много факторов. Не стоит опираться только на принцип большей зарплаты. $5 000 в Германии и $5 000 в США — это совсем разные уровни жизни. Кто-то готов жертвовать отпуском ради денег, а кто-то предпочитает стабильность и детский сад по госпрограмме. Лавандовый раф тоже влияет.

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

Сделайте минимальный Docker-образ, не ломая прод

Большинство Docker-образов в проектах содержат больше данных, зависимостей и инструментов, чем требуется для работы приложения. Это приводит к избыточному объёму, медленной сборке и повышенным рискам безопасности. Умение собирать минимальный образ — один из базовых навыков работы с Docker, который напрямую влияет на стабильность и скорость развёртывания.

Начать стоит с multi-stage сборки: на первом этапе — установка зависимостей и сборка, на втором — только нужные артефакты. Это позволяет исключить лишние файлы и утилиты из финального образа. В качестве базового слоя лучше использовать alpine, distroless или даже scratch, если вы точно понимаете, какие бинарники и библиотеки требуются приложению.

Хорошая практика — использовать утилиты docker history и dive для анализа того, какие файлы и слои попали в образ. Если размер превышает ожидания, стоит проверить, не остались ли во внутреннем слое временные файлы, dev-зависимости или директории кэша.

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

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

Попробуйте контейнизировать то, что изначально не предназначалось для этого

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

Попробуйте упаковать в контейнер любую графическую программу. Технически это возможно: X11 или Wayland можно пробросить через сокет, устройства передать через volume, окружение прописать вручную. Но на практике вы столкнётесь с рядом ограничений: отсутствие звука, глюки интерфейса, ошибки в драйверах, проблемы с доступом к GPU или нестабильное поведение при рендеринге.

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

Такая практика особенно полезна, если вы имеете дело с devtool'ами, UI-обвязкой или тестированием в headless-средах. Понимание, что именно ломается и почему, позволяет более точно проектировать окружение и избегать архитектурных ловушек в будущем.

Соберите базовый образ с нуля

Когда разработчик пишет FROM node или FROM ubuntu, он автоматически получает десятки слоёв, библиотек и утилит, о которых, скорее всего, не задумывается. Это удобно, но не даёт понимания, как вообще работает контейнер на низком уровне. Попробуем разобраться.

Укажите в Dockerfile FROM scratch — и не увидите ни bash, ни glibc, ни стандартных каталогов. Вам придётся самостоятельно добавить всё необходимое: бинарник, зависимости, библиотеки, конфигурацию. Если пишете на Go, задача упрощается: можно собрать статически слинкованный исполняемый файл и скопировать его в образ. Для других языков, особенно тех, что зависят от динамических библиотек или рантайма (например, Python или Node.js), придётся вручную подтягивать зависимости.

Такая практика заставляет иначе взглянуть на структуру контейнера. Вы начнёте понимать, чем отличается CMD от ENTRYPOINT, зачем в некоторых образах используется sh -c, и что произойдёт, если не задать WORKDIR. Вы столкнётесь с ошибками «no such file or directory» даже тогда, когда файл вроде бы существует — потому что в контейнере не хватает нужной libc.

Отдельный повод для размышлений — Alpine. Его любят за размер и минимализм, но он использует musl вместо glibc, и не всё с ним работает корректно. В процессе сборки на практике увидите, почему иногда проще остаться на Debian Slim, чем пытаться адаптировать всё под Alpine.

Этот эксперимент не нужен для продакшена — он нужен вам, как разработчику. Прокачивает понимание, как устроен Docker, что по-настоящему важно приложению для запуска, и какие зависимости вы добавляете бессознательно.

Делайте разные варианты Docker-образов

Хороший Dockerfile — тот, который гибко адаптируется под разные сценарии: продакшен, отладку, тестирование, запуск на ARM или x86. Если вы умеете собирать только один универсальный образ — вы ещё не освоили Docker по-настоящему.

Попробуйте собрать сразу несколько версий своего образа: на Debian и на Alpine, с минимальным размером и с полным набором утилит, для amd64 и arm64. Добавьте build-аргументы (ARG) — они позволяют передавать параметры на этапе сборки: выбрать базовый образ, включить или выключить зависимости, задать переменные окружения. Используйте RUN if или шаблонизацию через Dockerfile.template, чтобы варьировать поведение без дублирования кода.

Вот типичный пример: в режиме отладки вам нужен образ с установленным curl, vim, доступом к логам и расширенной трассировкой. А в продакшене — максимально облегчённый, с удалёнными временными файлами, сжатым слоем и только необходимыми бинарниками. Один и тот же проект — два разных образа. Добавьте сюда ещё поддержку разных архитектур (multi-arch build через --platform), и вы выйдете на уровень CI/CD, где из одного пайплайна собирается три-четыре артефакта.

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

Поиграйте в «А что если запустить чужой (небезопасный) код?»

Представьте задачу: вам нужно запустить код, который написал кто-то другой. Вы не уверены, что он безопасен. Это может быть скомпилированный бинарник, питоновский скрипт или даже npm-зависимость с подозрительным хуком. Где-то в коде может быть rm -rf /, попытка выйти за пределы контейнера, установить рутовый доступ или просто майнить крипту. И теперь этот код запускается на вашей машине — внутри Docker.

Кажется, контейнер защитит? Не всегда.

Docker не является полноценной песочницей. По умолчанию контейнер может обращаться к файловой системе, к ядру и к хостовым ресурсам — особенно если вы запускаете его с --privileged или без ограничения пользователя. Даже docker run -it ubuntu работает от root внутри контейнера, что уже создаёт риски.

Если вы действительно хотите запустить небезопасный код, нужно жёстко ограничить контейнер:

• отключить права root (через --user);

• запретить модификацию файловой системы (--read-only);

• отобрать лишние возможности ядра (--cap-drop=ALL);

• включить seccomp-профиль, AppArmor или SELinux;

• отключить доступ к сети или монтированию сокетов.

Список можно продолжать. Главное — понять, что Docker по умолчанию не даёт изоляции на уровне VM. Если вы работаете с кодом, которому не доверяете, этого может быть недостаточно.

Это упражнение учит думать о безопасности как о процессе. И особенно важно пройти его, если вы когда-нибудь планируете запускать user-generated code: плагины, кастомные скрипты, пайплайны CI. Только на практике становится ясно, где заканчиваются возможности Docker и начинаются границы настоящей песочницы.

Работайте без Docker CLI

Если убрать Docker CLI — что останется? Больше, чем кажется.

Docker ― это не единый монолит. Он работает поверх набора инструментов и стандартов: buildkit, containerd, спецификация OCI. CLI просто прячет эту архитектуру за удобными командами: docker build, docker run, docker push. Но всё, что кажется магией, можно повторить вручную.

Попробуйте отказаться от docker как от инструмента. Сконфигурируйте buildctl напрямую и соберите образ без Dockerfile. Или вообще создайте его вручную: сформируйте структуру, описания слоёв, метаданные, манифест. Прочитайте спецификацию OCI Image Format и идите по ее шагам. Понадобится tar, sha256sum, немного JSON — и внимательность.

Образ собрали? Отлично. Теперь отправьте его в реестр без docker push. Используйте oras, skopeo или curl с аутентификацией и ручной отправкой слоёв по HTTP API. Узнаете много нового: как работает digest, что такое manifest list и зачем нужны media types.

Наконец, запустите контейнер без docker run. Через ctr, runc или даже напрямую с помощью systemd-nspawn.

Зачем это нужно? Чтобы воспринимать Docker глубже. Так, вы понимаете, как устроен pipeline сборки и запуск контейнера, и точнее управляете им. Особенно это важно в продакшн-среде: когда образы не собираются, push падает, реестр отвечает 403, а пайплайн горит.

Ты точно программист, если читаешь это! Больше мемов, инсайтов и боли кодеров тут.

Кнопка «Like» в Facebook*: почти похоронили, прежде чем выстрелила

Сегодня «лайк» — это цифровой рефлекс. Но в 2007-м внутри Facebook* в идее сомневались почти все. В команде был инженер Джастин Розенштейн, он и предложил кнопку, которая бы позволяла реагировать на посты одним нажатием. Сначала хотели назвать её Awesome (жми, если круто). Но потом кто-то предложил более нейтральное Like. Скепсис был высок: менеджеры тормозили идею, обсуждения тянулись годами, пока в один момент кто-то не решился просто выкатить кнопку в прод.

В феврале 2009-го «Like» заработал на всей платформе. И эффект был мгновенный — больше вовлечённости и контента. Через год Facebook* вытащил кнопку на внешние сайты: теперь ты мог лайкать статью на стороннем ресурсе, и это улетало в соцсеть. Лайк стал универсальной валютой внимания, а сама кнопка — самым тиражируемым UI-элементом в интернете.

Урок: даже техническая метка может стать глобальным символом одобрения.

*Компания Meta признана экстремистской на территории РФ

Ретвиты в Twitter**: придумали пользователи, а не разработчики

Twitter** в 2006-м выглядел скудно: 140 символов, никаких картинок, и даже функции «поделиться твитом» не было. Пользователи сами начали выкручиваться — копировали чужие твиты и вручную добавляли префикс «RT @username».

Что сделал Twitter**? Сначала ничего. Команда с недоверием смотрела на это самодельное изобретение. Будто это странно выглядит, рушит эстетичный фид, а ещё может усилить распространение негатива.

Но потом цифры победили эстетику. RT-формат подхватила масса — это был народный функционал. И Twitter** пришлось догонять свой же комьюнити. В 2009-м разработчики сделали официальную кнопку «Retweet». Уже через пару лет без неё невозможно было представить платформу.

К слову, и сегодня в твиттер**-экосистеме «ретвит» — это не просто фича. Это способ продвигать мемы, новости, протесты, кампании. Всё началось с пользовательского хака — и превратилось в одну из самых влиятельных кнопок в интернете.

Урок: пользовательский хакинг иногда лучше любого UX-ресерча.

**Запрещен на территории РФ

typeof null === "object" — баг, которому 28 лет, и он всё ещё с нами

JavaScript писали в адских условиях: у Брендана Айка было всего 10 дней в 1995 году, чтобы запилить язык для браузера Netscape. Никакого «спринта», никакой архитектурной выверенности — просто надо было быстро сварганить что-то, что напоминает и Java, и скрипт.

В этой спешке в typeof закралась ошибка: typeof null начал возвращать "object" . Почему? Потому что в ранней реализации значения в JavaScript представлялись в памяти с помощью тегов. Если тип — объект, у него был специальный тег (000). Проблема в том, что null хранился как ноль, а 0 в бинарной записи — это тоже 000. Крайний случай не проверили.

Айк позже признавал: да, это ошибка. Но баг стал настолько фундаментальным, что его решили не трогать, чтобы не поломать совместимость со всем количеством сайтов, библиотек и фреймворков. Спустя почти три десятилетия он всё ещё с нами. Люди пишут костыли вроде value === null или Object.prototype.toString.call(value) === ‘[object Null]’, а баг — живет.

Урок: Иногда баг — это не баг, а историческое наследие. Скелет в шкафу, вокруг которого строят фреймворки.

Глючная физика в GTA: когда баг становится аттракционом

Если вы хотя бы раз играли в GTA IV или V, вы знаете: на ровном месте машина может улететь в воздух, мотоцикл — в стратосферу, а NPC — разложиться на асфальте. Всё это — не баги (но когда-то ими были).

Всё началось с движка Euphoria, который Rockstar подключили в GTA IV. Это процедурная система физики и анимации — каждый раз персонаж падает или реагирует на столкновение по-разному. Не скриптовано, а реально: траектория, инерция, вес, центр тяжести. Но оказалось, что если чуть-чуть не дотянуть параметры или немного ошибиться в расчетах — мы будем иметь то, что имеем. Пользователи заметили это и начали тестировать движок на слом. Видео с багами собирали миллионы просмотров. Получилось, что баг физики стал частью эстетики серии GTA.

Урок: глупость + баг = YouTube-флешмоб.

YouTube: платформа для свиданий? Почти…

Да, YouTube изначально не задумывался как «видеохостинг №1 в мире». Его создатели в 2005 году хотели сделать сайт знакомств с видеоанкетами. Он даже запускался под лозунгом: «Tune in, Hook up» — что-то вроде «Подключайся, знакомься». Создатели сами грузили первые профили, чтобы смоделировать активность. Только вот настоящие пользователи не спешили заливать анкеты.

Зато начинали заливать… видео. Случился момент, когда баг оригинальной идеи стал фичей: команда YouTube поняла, что людям нужен не видеотиндер, а простой способ делиться роликами. Спустя год сервис купил Google за $1,65 млрд.

Сегодня YouTube — не площадка для «hook up», но миллионы людей всё ещё смотрят ролики, чтобы найти… если не любовь, то хотя бы что-то интересное.

Урок: баг концепции может стать бизнес-стратегией.

Вибрация в геймпадах: баг, который встряхнул всю индустрию

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

История уходит в 90-е, к компании Nintendo. В те времена японские инженеры экспериментировали с устройством под названием Rumble Pak — дополнительным модулем, который вставлялся в контроллер Nintendo 64. Но изначально он использовался не как фича, а вызывал сбой в системе. Контроллер вел себя нестабильно: дергался, шумел, давал отдачу. И всё это — из-за того, что моторчик «неправильно» взаимодействовал с платой. Кто-то бы списал это на дефект. Но не Nintendo.

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

Rumble Pak вышел в 1997 году в комплекте с Star Fox 64 — и стал вирусным. Спустя пару лет все крупные консоли уже добавляли вибро как must-have.

Урок: эффект «погружения» может родиться из инженерной ошибки.

Бесконечные деньги в Diablo: экономика ада на баге

Когда Diablo вышел в 1996 году, он быстро захватил сердца игроков: ад, скелеты, лут, все как надо. Но уже через пару месяцев игру сломали — и не демоны.

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

Как это работало?

• Игрок кидал золото на землю.

• Одновременно открывал инвентарь.

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

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

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

Auto-Tune — как баг стал музыкальным стилем

Auto-Tune, известный в первую очередь как инструмент для коррекции вокала, стал не просто незаменимым музыкальным инструментом, а настоящим культурным феноменом. Интересно, что его массовое использование в музыкальной индустрии началось благодаря случайности.

Когда в 1997 году инженер звука Андреас Керн в компании Antares Audio Technologies разрабатывал программу для коррекции мелодии, он не планировал, что её использование изменит музыкальный ландшафт. Изначально цель Auto-Tune заключалась в том, чтобы исправить небольшие отклонения в тоне голоса при записи. Однако в процессе тестирования инженеры заметили, что программное обеспечение не только исправляет ошибки в нотах, но и начинает создавать уникальное роботизированное звучание, если применять слишком сильное воздействие.

Интересно, что такую аномалию никто не ожидал, и, возможно, это было связано с ограничениями самой технологии на тот момент. Однако именно эта особенность привлекла внимание музыкантов и продюсеров. Вскоре Cher впервые использовала эту технологию в своей песне Believe (1998), придавая вокалу необычное, искаженное звучание. Это было воспринято как новаторский ход, и песня стала международным хитом.

После Auto-Tune стал не просто инструментом для коррекции, а важным элементом для создания нового музыкального стиля. В начале 2000-х годов использование автотюна в поп- и хип-хоп-музыке приобрело широкую популярность, и технологию начали активно использовать Kanye West, T-Pain, Lil Wayne т.д..

Урок: что для тебя — баг, для другого — искусство.

А забрать все самые топовые нейронки для айтишников можно в нашем большом гайде с 70+ ИИ-инструментами

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

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

Носители информации: эволюция

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

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

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

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

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

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

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

Затем пришли дискеты, и мир узнал, что такое «портативность» в цифровом смысле. Если кассеты были еще слегка похожи на предыдущее поколение (массивные бобины), то флоппи-диски уже вполне выглядели как технология из будущего. Первые модели хранили жалкие 80 КБ, но к 1980-м емкость выросла до 1.44 МБ — достаточно для текстовых документов и простейших программ. Правда, надежность оставляла желать лучшего: магнитные диски боялись пыли, влаги и просто времени.

Оптические носители, такие как CD и DVD, стали следующим шагом. Они предлагали куда больший объем (от 700 МБ до 4.7 ГБ) и теоретически — вечное хранение данных. Правда, на практике царапины, солнечный свет и некачественные болванки приводили к быстрому обнулению файлов. Но главный минус — эти диски нельзя было просто так перезаписать. CD-RW и DVD-RW решили проблему, но их распространение было медленным: люди уже начали привыкать к тому, что данные можно копировать бесконечно.

Конец XX века принес еще несколько любопытных форматов вроде ZIP-дисков, которые пытались заменить флоппи, но проиграли войну, поскольку оказались слишком дорогими и неудобными.

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

Как хранили и передавали информацию до флешек и облаков

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

Аудио и видеокассеты: не забудьте перемотать на начало

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

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

К 80-м годам кассеты стали основным способом слушать музыку. Их продажи в США достигли пика в 442 миллиона штук в 1990 году, но затем началось стремительное падение — CD-диски предлагали лучшее качество звука и отсутствие изматывающей перемотки. Однако кассеты не исчезли полностью: даже в 2012 году в Штатах продали 13 миллионов штук, в основном благодаря автолюбителям, чьи старые машины были оборудованы кассетными магнитолами. В России формат держался примерно до середины 2000-х, после чего кассеты почти исчезли из обихода.

Пока аудиокассеты правили балом в музыке, VHS делал то же самое с видео. Этот формат, появившийся в 1970-х, быстро вытеснил конкурентов (например, Betamax от Sony) благодаря простоте и доступности. Видеомагнитофон стал почти обязательным устройством в каждом доме, а прокат кассет — целой индустрией.

Но у VHS были свои причуды:

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

Несмотря на это, VHS формат продержался до начала 2000-х, пока его не вытеснили DVD, а затем и стриминговые сервисы.

Магнитная лента использовалась не только для музыки и фильмов — в 1980-х она стала первым массовым носителем данных для домашних компьютеров. Владельцы ZX Spectrum и Commodore 64 загружали программы с аудиокассет, подключив магнитофон к компьютеру. Процесс напоминал шаманский ритуал: нужно было выставить правильный уровень громкости, надеяться, что маг не зажует ленту, и ждать несколько минут, пока игра загрузится (если, конечно, в середине не возникала ошибка, заставляющая начинать все сначала).

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

Казалось бы, эпоха магнитной ленты бесповоротно миновала, но это не совсем так. В дата-центрах до сих пор используют ленточные библиотеки (например, LTO), потому что они дешевы, энергоэффективны и отлично подходят для долгосрочного хранения больших объемов данных. Современные картриджи LTO-9 вмещают до 45 ТБ информации — это в тысячи раз больше, чем могла предложить кассета 1980-х.

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

Флоппи-диски (дискеты): 1,4 Мб славы

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

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

Первая дискета, представленная IBM в 1971 году, была 8-дюймовой и вмещала смехотворные по современным меркам 80 КБ данных. Она создавалась как альтернатива перфокартам — более надежная и удобная, но по-прежнему громоздкая. К середине 1980-х индустрия перешла на 5,25-дюймовые гибкие диски, а затем и на 3,5-дюймовые, которые стали стандартом. Последние, кстати, были не такими уж «гибкими» — прочный пластиковый корпус защищал магнитный диск внутри, хотя слово «флоппи» (от английского floppy — «гибкий») так и осталось в названии.

Объем памяти рос медленно: если в 1984 году дискета на 3,5 дюйма хранила 720 КБ, то к 1987-му — уже 1,44 МБ. Этого хватало для текстовых документов, простых программ и даже некоторых игр. Microsoft Word 2.0, выпущенный в 1991 году, умещался на одной дискете, а его современный аналог требует около 4 ГБ — в 3000 раз больше.

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

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

В 1980-х развернулась настоящая битва форматов. Компания Apple сделала ставку на 3,5-дюймовые дискеты, в то время как IBM и другие производители первое время держались за 5,25 дюймов. Победил, как известно, меньший размер — отчасти благодаря тому, что новые носители были прочнее и компактнее.

Любопытно, что следы дискетной эпохи до сих пор встречаются в цифровом мире. Буква «A:\» в Windows, которая изначально обозначала дисковод, осталась в системе как дань традиции. Иконка «Сохранить» во многих программах до сих пор изображает флоппи-диск, хотя большинство современных пользователей и в руках-то его никогда не держали.

К началу 2000-х дискеты начали стремительно исчезать. В 2011 году компания Sony, последний крупный производитель, прекратила их выпуск. Но, как это часто бывает, технология не умерла полностью.

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

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

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

Сиди и Дивиди: эпоха лазерного ренессанса

В конце 1990-х дискеты уже выглядели архаично, а облачных хранилищ еще не существовало. На сцену вышли оптические диски — сначала скромные CD на 700 МБ, после — DVD на 4,7 ГБ, а затем и Blu-ray с их 50 ГБ. В определенный период записать фильм на болванку считалось технологическим подвигом. Нужно было также красиво написать название на внешней стороне специальным маркером.

Изначально компакт-диски создавались для музыки — первый коммерческий CD выпустили в 1982 году с записью альбома ABBA «The Visitors». Объем в 650 МБ (74 минуты аудио) выбрали не случайно: разработчики из Sony и Philips хотели, чтобы на один диск целиком поместилась Девятая симфония Бетховена. К концу восьмидесятых большинство звукозаписывающих компаний перешли на CD-формат.

Когда технологию адаптировали для компьютеров (CD-ROM), эти же 700 МБ стали стандартом для софта, игр и даже операционных систем, например, Windows 95.

Запись CD представляла собой сложную процедуру . Программа Nero Burning ROM с ее интерфейсом, напоминающим кабину пилота, требовала идеально настроенного буфера записи. Ошибка «Buffer underrun» означала, что диск испорчен, а 30-50 рублей за болванку (по меркам 2000-х — немалая сумма) летели в мусорку.

Когда в 1996 году появились DVD, их емкость в 4,7 ГБ казалась фантастической. Почему не 5? Все просто: инженеры Sony и Philips изначально планировали 5 ГБ, но пришлось пожертвовать частью объема ради совместимости с форматом CD. Впрочем, даже 4,7 ГБ хватало для фильмов в приличном качестве — пиратские копии расходились быстрее, чем студии успевали считать убытки.

Киноиндустрия быстро поняла угрозу и начала войну с пиратством. На диски добавляли защиту вроде SecuROM и StarForce, которая не только мешала копированию, но и могла вывести из строя дисковод. Пользователи в ответ придумывали хитрости: от скотча на краю диска до специальных программ, которые «прожигали» защитные сектора.

В середине 2000-х разгорелась война форматов высокой четкости: Blu-ray от Sony и HD DVD от Toshiba. Технически Blu-ray был лучше — большая емкость (50 ГБ против 30 ГБ у HD DVD), но исход противостояния решил не этот фактор. Sony, которая владела киностудией Columbia Pictures, обеспечила Blu-ray эксклюзивными релизами. А когда за синий формат неожиданно выступила индустрия фильмов для взрослых (на тот момент — один из главных драйверов продаж любых носителей), судьба HD DVD была предрешена.

К 2010-м оптические диски начали сдавать позиции. Скорость интернета росла, стриминговые сервисы набирали популярность, а производители ноутбуков массово отказывались от дисководов. Последний гвоздь в крышку гроба забила Apple, выпустив в 2012 году MacBook Pro без CD-привода — тогда это казалось смелым шагом, а сегодня воспринимается как норма.

Но диски не исчезли полностью. Blu-ray до сих пор используют для фильмов в 4К, а некоторые госструктуры предпочитают архивные DVD — они дешевы и, в отличие от флешек, не подвержены спонтанному размагничиванию. Да и любители ретро-техники продолжают охотиться за редкими релизами игр на CD — например, оригинальная Half-Life на диске сегодня стоит дороже, чем в Steam.

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

Почему все это исчезло

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

Три причины краха:

• Первая и главная — объем. В 1990-х 1,44 МБ дискеты хватало для текстовых документов, но уже к началу 2000-х этого было недостаточно даже для одной MP3-песни. CD на 700 МБ казались спасением, но и они быстро устарели, когда размеры софта перевалили за гигабайты. Современные игры и видеофайлы просто не поместились бы на десятках дисков, которые пришлось бы таскать с собой.
• Вторая причина — скорость. Загрузка программы с кассеты занимала минуты, запись DVD — десятки минут, а копирование файлов с дискеты напоминало медитацию. Когда на смену пришли USB-накопители с их мгновенным доступом к данным, терпеть эти задержки стало невозможно.
• Наконец, надежность. Магнитные ленты размагничивались, дискеты боялись кофе и магнитов, а царапины на CD превращали их в елочные украшения. Потерять данные было проще, чем сохранить — особенно если учесть, что резервные копии требовали такого же ненадежного носителя.

Некоторые архаичные носители до сих пор используются там, где важнее стабильность, а не прогресс. В авиации, например, часть бортовых систем Boeing 747 до недавнего времени обновлялась через 3,5-дюймовые дискеты — потому что проверенная временем технология надежнее экспериментальных решений.

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

Что мы потеряли и что приобрели

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

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

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

Флешки, SD-карты и облака: вы находитесь здесь — что дальше

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

Твердотельные накопители, основанные на кремниевых чипах, приближаются к физическим пределам. Производители научились упаковывать данные невероятно плотно — современные 3D NAND-чипы содержат до 200 слоев памяти. Однако закон Мура (формулирующий неизбежность технологического прогресса) хотя и универсален, имеет определенные физические ограничения: стоимость новых фабрик по производству микросхем измеряется десятками миллиардов долларов.

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

Будущее, которое уже тестируют в лабораториях:

• ДНК-хранилища. В 2017 году гарвардские ученые записали на ДНК кишечной палочки GIF-анимацию и изображение. Технология CRISPR позволяет редактировать геном, превращая его в биологический жесткий диск. Пока процесс дорогой и медленный, но потенциал огромен: один грамм ДНК может хранить 215 петабайт данных — эквивалент 14 тысяч современных SSD.
• Молекулярные диски. Исследователи из Университета Брауна (Провиденс, США) создали прототип накопителя, где информация кодируется органическими молекулами. Метод напоминает древние глиняные таблички, только вместо клинописи — бинарный код из присутствия или отсутствия конкретных молекул.
• Кварцевые кристаллы. Технология «5D-памяти» использует фемтосекундные лазеры для записи данных в кварцевое стекло. Такие носители выдерживают температуру до 1000°C и могут хранить информацию миллиарды лет. В 2018 году Илон Маск отправил в космос Tesla с кварцевым диском, содержащим трилогию А. Азимова «Основание».
• Арктические архивы. На Шпицбергене уже работает «Арктический мировой архив», где данные хранятся на специальной пленке в стальных контейнерах. Туда поместили исходники GitHub, цифровое искусство и даже конституции некоторых стран — на случай глобальной катастрофы.

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

Ты точно программист, если читаешь это! Больше мемов, инсайтов и боли кодеров тут.

Больше новостей — в нашем тг-канале «Представляешь»

Улучшенная технология уже встроена в стандартную лицензию сервиса. Алгоритм создан на основе внутренних разработок в области обработки естественного языка (NLP) и прошёл обучение на большом массиве машинно-сгенерированных текстов. В приоритете — высокая точность и минимизация ложных срабатываний.

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

Главный фокус — на научные и студенческие работы

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

Именно в этих типах текстов ИИ используется особенно активно. Согласно исследованию «Я — профессионал», 85% российских студентов регулярно прибегают к нейросетям. Среди них:

• 77% используют ИИ для поиска информации,

• 43% — для написания курсовых, эссе и дипломов,

• 24% — для подготовки презентаций.

Ранее уже фиксировались случаи защиты дипломов, полностью написанных с помощью нейросетей.

ИИ на взлёте — а детекторы не дремлют

В январе 2025 года на российский рынок вышла китайская бесплатная нейросеть deepseekV3. За короткий срок она стала самой популярной ИИ-платформой в стране, увеличив мобильный трафик в 5 раз. Параллельно OpenAI представила GPT-4o — мультимодальную модель нового поколения.

На этом фоне «Антиплагиат» усиливает позиции: его решения уже используют 92% вузов, участвующих в программе «Приоритет 2030», включая МГУ, СПбГУ, НИУ ВШЭ, МГТУ им. Баумана, РЭУ им. Плеханова и другие топ-университеты.

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

Я — Олег Филон, ментор Эйч Навыки и Senior DevOps Engineer. Мы разберем ключевые инструменты, которые помогают автоматизировать разработку, тестирование и развертывание приложений. Сегодня на повестке — развертывание собственного облака с помощью KVM и libvirt.

О минимальных требованиях и поддержке виртуализации

Сейчас популярная тема на Youtube — Home Lab, или домашняя сеть с кучей компьютерного и сетевого оборудования, часто в выделенном помещении вроде серверной. И один из самых известных блогеров в этом направлении — Jeff Geerling, вот его GitHub. У меня, кстати, тоже есть небольшой блог — здесь можно почитать статьи, а здесь — посмотреть код на Гитхабе.

Однако наша цель гораздо скромнее — мы будем строить на обычном ПК или ноутбуке персональное облако, используя KVM-модуль из ядра Linux и набор утилит libvirt и qemu. Сразу определимся с минимальными требованиями к железу, чтобы попробовать руками всё обсуждаемое.

Мой рабочий ноут — китайский Chuwi GemiBook Plus с процессором Intel N100, 4 ядра, 16GB памяти, nvme диск на 960GB — вполне справляется с такими задачами.

Сразу объяснюсь за невольную рекламу дешёвых китайских ноутов: я не сразу выбрал этот 200-евро-бук. У меня в домашней сети есть несколько SBC (single board computer) на arm64 и risc-V — опыт весьма интересный. Во-первых, Линукс на таких экзотических компьютерах сильно отличается от обычных ПК. Во-вторых, я стал ценить не абстрактные BogoMIPS из dmesg, а реальный отклик в повседневной работе: веб, YouTube, билды приложений. Неудобств нет, а TDP (thermal design power) — 2-5W.

Как и многие из вас, я беспокоюсь, что оставляю углеродный след, но нельзя сравнивать мой Intel 10W N100 и процессор, который греется как утюг, но для глажки бесполезен, и даже наоборот, требует себя охлаждать — сначала мощными кулерами, а в жаркую погоду ещё и кондиционерами с весьма низким КПД. Короче, ваш компьютер справится с 2-3 виртуалками без проблем. Но на всякий случай проверьте, что аппаратная виртуализация поддерживается процессором.

Установить связку KVM+libvirt можно во многие дистрибутивы Linux. Не будем, однако, спешить, а выполним полезную подготовительную работу. Моя основная ОС уже много лет — Ubuntu. В ней есть удобный инсталятор, новые релизы каждые полгода и LTS (Long Term Support) для тех, кто предпочитает стабильность. Есть ещё бесплатный на 5 машин Ubuntu Pro с патчами безопасности в дополнительном репо. Но главная фича, из-за которой я не меняю дистрибутив — поддержка файловой системы ZFS. Вот о ней и поговорим.

Лирическое отступление: что такое ZFS и в чем ее прикол

ZFS — самая сложная из многочисленных ФС. Она является дефолтной во FreeBSD и не только, а также в дистрибутиве Proxmox, который использует OpenZFS. Разница между Open и просто ZFS в лицензии. Оригинальная лицензия не была свободной. Переписывание многих модулей и библиотек, чтобы эту ФС можно было включить в ядро Linux, заняло много лет. В Ubuntu, начиная c версии 20.04, уже можно выбрать ZFS как опцию при установке. Кратко перечислю, что нам даёт ZFS:

1. Встроенное шифрование диска, не нужны никакие LUKS и танцы с бубном.
2. Модные контейнерные OverlayFS, виртульные диски формата QCOW2, используют COW (copy-on-write). ZFS это тоже умеет, можно сказать, она оптимизирована для контейнеров и ВМ.
3. Замечательная фича — встроенный RAIDZ. В моём Proxmox сервере 8 портов SATA, мощный корпус со стойкой на 8 HD. Купил 7 штук одинаковых 4TB дисков, добавил в пул raidZ, в итоге 24TB довольно шустрого хранилища.
4. Можно забыть как кошмарный сон мучения с mdadm, lvm2. Партишены увеличиваются без всякой суеты с PV/VG/LV. Впрочем, XFS это тоже умеет, поговорим позже и о ней.

На будущее: виртуализация никак не привязана к файловой системе, можно использовать то, что уже есть, в том числе и привычный дистрибутив. Буду рассказывать, однако, только об установке на Ubuntu.

Готовимся к установке KVM+libvirt

По умолчанию libvirt создаёт внутреннюю сеть на виртуальном устройстве в режиме nat. Для единственного хоста это не так важно, виртуалка доступна, но полезно настроить плоскую сеть, где ВМ будет иметь свой IP-адрес и физический хост.

Для этого сделаем заранее на хостовой машине виртуальное устройство br0 и будем привязывать виртуалки к этому устройству. Cеть в обычном десктопном Ubuntu настраивается сервисом NetworkManager:

• через графический интерфейс,
• через утилиту интерфейса командной строки nmcli,
• через nmtui с текстовым интерфейсом.

Для серверных конфигураций документация рекомендует netplan. В случае сервера необходимо присваивать хостовым машинам статические IP-адреса вплоть до того, что Proxmox — гораздо более мощный сервер виртуальных машин с возможностью кластеризации, миграции ВМ, ceph и так далее. Он отказался от NetworkManager и требует наличия ethernet порта.

Мы же хотим сохранить удобство десктопной OS и добавить серверные возможности, поэтому будем использовать пакет netplan.io, который вполне совместим с NetworkManager. Вот пример конфигурации для хостовой машины, создающий на физическом ethernet устройстве виртуальный интерфейс br0:

Создав файл /etc/netplan/01-br0.yaml, сначала проверим его корректность: sudo netplan try /etc/netplan/01-br0.yaml, и если Configuration accepted, применяем его: sudo netplan apply .... Посмотрим, что у нас с сетью. Должно быть что-то похожее на это:

Во второй строке вывода стоит мой eth0, который является физическим интерфейсом, он активен (link state UP), но адреса не имеет. В последней строке мой br0, который выступает виртуальным интерфейсом с правильным статическим адресом. Более того, если мы посмотрим настройки с помощью brctl из пакета bridge-utils, то увидим что у нас появился полноценный бридж:

Подготовка к установке KVM+libvirt завершена, возвращаемся к документу с сайта https://sysguides.com/. Для Ubuntu это команда:

На первых порах удобно прибегнуть к десктопному приложению virt-manager, позволяющему создавать, запускать, управлять виртуальными машинами. Под капотом прячется много низкоуровневых утилит, поэтому рано или поздно придётся познакомиться и с libvirt-clients, и с qemu-utils, и с guestfs-tools.

Разворачиваем виртуальные машины

Теперь можем попробовать создать первые виртуалки. Первым делом, как рекомендовано, добавим себя в группу libvirt, чтобы иметь возможность управлять виртуальными машинами, и настроим ACL на каталог, где хранятся образы виртуальных машин:

Самый простой и знакомый способ создания виртуальной машины — использовать iso-образ. Установка будет напоминать сотни раз пройденные шаги: скачать образ, указать путь к нему, задать имя виртуальной машины, количество оперативной памяти, выделить ядра процессора и так далее.

Расскажу чуть подробнее про пару новых опций для virt-manager. Во-первых, это использование настроенного ранее виртуального интерфеса br0. Во-вторых, формат виртуального диска QCOW2. Вот, например, настройки одной из моих виртуалок:

Здесь показаны 4 размера:

• ls -lh видимый размер файла имиджа;
• du -BM занимаемое место на диске, qemu-img info выдаёт его внутренние параметры, в частности: virtual size — 10 GiB; реальный размер файла disk size — 5.11 GiB.

Это возможности того самого COW (copy-on-write). Виртуальный размер — тот, что мы указали при создании ВМ, а реальный размер файла — сколько фактически места занято на диске. Внутри ВМ мы будем видеть эту разницу как свободное место, и оно также остаётся свободным на хостовой ФС. Можно заказывать размер диска с запасом, QCOW2-формат не займёт место, пока оно не потребуется под данные внутри ВМ.

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

Общий вид virt-manager со списком ВМ на 2 хостах:

Десктопное приложение virt-manager — не единственный способ создания ВМ. Можно (и иногда удобнее) использовать командную строку и соответствующие утилиты. Также установить ВМ из готового образа в формате для libvirt/qemu. Например, для релиза 14.2 FreeBSD всё, что заканчивается на .qcow2.xz, raw.xz — это образы для libvirt/qemu. После скачивания и проверки контрольных сумм выполним команды:

Предположим, вы успешно создали одну или несколько ВМ, проверили их в графическом режиме или настроили ключи для ssh. Настало время навести порядок с DNS.

У меня раздавал адреса и имена роутер от провайдера. Удобнее настроить на вашем основном компе сервис dnsmasq, который включается первым и по умолчанию всегда доступен. Он умеет также dhcp, так что в одном конфиге сможем сразу задавать и IP-адреса, и имена ВМ. Вот часть моего конфига:

MAC-адреса присваиваются в virt-manager, адреса до 99 оставил под WiFi; со 100 до 200 виртуалки с отдельными диапазонами для каждого хоста; адреса с 201 по 254 — «железные» хосты, то есть реальные устройства. Напомню, после каждой правки конфига сервис dnsmasq надо рестартовать.

Если в будущем ваше персональное облако разрастётся, рекомендую обратить внимание на китайский KVM-свитч 4K HDMI USB KVM Switch. В этом случае KVM означает Keyboard Video Mouse — переключатель для управления несколькими компьютерами с одного комплекта устройств. Это сокращение как нельзя кстати для нашей темы.

Мы разобрали, как развернуть персональное облако DevOps с помощью KVM и libvirt. В следующей статье рассмотрим Fedora Core дистрибутив и инструмент mise — удобную альтернативу pyenv и другим менеджерам версий.

Как все начиналось?

Идея голосового управления исполнительными устройствами появилась отнюдь не в эпоху научно-технического прогресса — напротив, желание отдавать голосовые команды неодушевленным предметам испытывали уже дальние предки, что находит свое отражение в сказках народов мира: «Сим-сим, откройся», «Горшочек, не вари!», «Свет мой, зеркальце, скажи…». Знакомые с детства фразы демонстрируют не только наличие самой идеи голосового управления, но и существование концепции протокола взаимодействия с исполнительными устройствами. Это случилось задолго до появления первых гальванических элементов, не говоря уже об электронике.

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

Что касается распознавания речи, то эксперименты в этой области велись как минимум с середины XX века. В 1952 году Bell Telephone Laboratories (Bell Labs), исследовательское подразделение American Telephone and Telegraph Company (AT&T), представило Audrey — машину, способную «понимать» человеческую речь (она могла распознавать цифры от 0 до 9). Это стало возможным благодаря успехам в решении смежной задачи — синтеза речи, достигнутом в первой половине XX века в стенах той же Bell Labs. Как синтез речи, так и ее распознавание в те времена основывались на представлении звуков в виде формант — набора резонансных частот, создаваемых голосовыми связками человека в процессе разговора. Распознавание производилось путем сравнения формант говорящего с предварительно записанными образцами. Ожидаемо, устройство работало точнее, когда буквы называл тот человек, чей голос использовался при записи образцов.

В 1986 году компанией International Business Machines (IBM) была разработана печатная машинка с голосовым управлением Tangora. В основу ее работы было положено использование cкрытой модели Маркова (Hidden Markov model): устройство рассчитывало вероятность того, может ли обрабатываемый звук являться частью какого-либо из известных ему слов. Изменение подхода к распознаванию речи позволило существенно увеличить словарный запас устройства, который составил 20 тысяч слов. Функционировала машинка на базе компьютера IBM PС/AT, а для работы с новым пользователем ей требовалось 20-минутное обучение.

В 1987 году компания Worlds of Wonder выпустила в продажу кукол Julie. Куклы понимали 16 слов и были способны вести диалог посредством встроенного синтезатора речи. У кукол также были датчики освещенности и температуры, показания которых использовались для формирования ответных реплик, что позволяло сделать диалоги более осмысленными. Julie нужно было обучать воспринимать голос конкретного человека, как и в случае с печатными машинками Tangora.

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

Что происходит сегодня?

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

Методы обработки сигнала зависят от конкретной задачи. Например, при распознавании коротких голосовых команд можно обойтись без разбиения на отрезки, если подобрать подходящую корреляционную функцию и установить минимальный порог схожести. Однако такой подход не всегда дает точные результаты. Так, в мобильном телефоне Siemens C55 упрощенный алгоритм голосового управления мог путать похожие по звучанию слова, например, «свет» и «считать».

Несмотря на кажущуюся простоту, системы голосового управления широко применяются и сегодня. Более того, существует ряд решений, представляющих собой готовые модули, с помощью которых разработчики электроники могут реализовать голосовое управления своими устройствами без дополнительных трудозатрат. В качестве примеров подобных решений — Voice Recognition Module (аналогичные модули представлены у различных производителей) и Voice Interaction Module от Yahboom Tchnology.

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

Так, один из ключевых этапов любого ML-проекта – разметка данных. Эта операция занимает около 25% времени всего цикла реализации Data Science-решения. Меня зовут Полина Богданова, я Бизнес-аналитик в компании Embedika и сегодня я расскажу, что из себя представляет разметка данных и как грамотно выстроить этот процесс. Подробно разберу область NLP — технология машинного обучения, которая позволяет ИИ интерпретировать и понимать человеческий язык.

Как происходит разметка текста

Data labeling (разметка данных) — это качественное преобразование данных путем добавления метатегов в текст документов, что позволяет AI понять контекст и в последующем эффективно задавать и выполнять те или иные сценарии. Это один из ключевых этапов любого ML-проекта, так как от качества разметки зависит конечный результат.

Разметку данных принято рассматривать с позиции «ученик и учитель», где ученик — это сама модель, а учитель — специалист. На этапе обучения происходит обработка информации и добавление метатегов, что позволяет искусственному интеллекту ориентироваться в эталонных примерах и понимать, чем один отличается от другого.

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

Методы разметки

Обучение «с учителем» можно разделить на две большие категории: с использованием активного обучения и без его него.

С применением активного обучения

Данный тип обучения начинается с этапа разметки данных. В документе с помощью тегов/меток (метки - более распространенное слово) размечаются необходимые формулировки. Например, для классического договора нужно определить: стороны договора, услуги, которые будут оказываться в рамках договора, сроки, стоимость.

Далее модели показывают некоторое количество размеченных документов и учитель позволяет алгоритму самостоятельно обрабатывать информацию и находить те фрагменты, которые соответствуют первому этапу обучения. На этом этапе алгоритм «уточняет» у человека корректность выделения данных. Если система допускает много ошибок, необходимо дополнительно разметить примеры, которые будут эталонными образцами. Обычно цикл обновления повторяется, пока число правильных ответов не достигнет 90%.

Без применения активного обучения (ручная)

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

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

Автоматическая разметка

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

Подготовка перед разметкой

Определение конечного результата

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

Сбор данных

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

Более того, нельзя забывать про NDA и обезличивание документов. Чтобы избежать раскрытия чувствительной информации (данные о клиентах, внутренней структуре организации, финансовых показателях), стоит предварительно ее обезличить.

Анализ документов

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

Подготовка инструкции

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

Информирование команды

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

Оценка качества разметки

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

Для оценки качества разметки, можно использовать разные метрики:

• Точность (Accuracy). Определяет, насколько точно модель распознает именованные сущности в тексте.

Формула: Accuracy = Количество правильно найденных токенов сущностей/Общее количество токенов сущностей

Пример: Если 10 имен было распознано как 10 имен, а 10 адресов как 10 адресов, то Accuracy = 100%.

• Полнота (Recall). Метрика показывает долю верно определенных моделью фрагментов текста среди фрагментов текста, которые относятся к сущности согласно эталонной разметке.

Формула: Recall = Количество правильно обнаруженных токенов сущностей/ Общее количество истинных токенов сущностей.

Пример: Эта метрика показывает насколько успешно модель найдет 10 адресов и 10 имен. Если модель не обнаружила 5 имен и 5 адресов, хотя они были, то Recall — 50%.

• Точность (Precision). Показывает долю верно определенных фрагментов текста среди всех частей текста, которые модель определила как рассматриваемую сущность.

Формула: Precision = Количество правильно обнаруженных токенов сущностей/Общее количество предсказанных токенов сущностей.

• Баланс (F1-score). Гармоническое среднее между метриками Precision и Recall позволяет получить более сбалансированный показатель качества.

Формула: F1-score =2* (Presicion * Recall/Presicion + Recall)

Если на выходе модель выдает нерелевантные данные, то важно выявить причину расхождения заданных параметров с результатом. Проблема не всегда в данных или разметке. Возможно, ML-специалисты не выстроили все необходимые параметры.

Мы в своей практике используем внутренний софт, в котором есть детальные реестры с размеченными фрагментами. Реестр позволяет оперативно произвести корректировку разметки, если она некачественная, без обращения к исходному документу.

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

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

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

Внутренние сотрудники

Плюсы:

• Контроль качества;
• Соблюдение конфиденциальности;
• Заинтересованность в результате.

Минусы:

• Дороже, чем привлеченные специалисты;
• Другие задачи встают на стоп;
• Трудности масштабирования.

Фрилансеры

Плюсы

• Экономия времени и внутренних ресурсов;
• Выстраивания коммуникации напрямую с исполнителем;
• Возможность масштабирования (привлечение нескольких специалистов на фрилансе).

Минусы:

• Несогласованность действий между участниками разметки.
• Отсутствие экспертности в профильных сферах.

Аутсорс компании

Плюсы:

• Экономия времени и внутренних ресурсов.
• Возможность масштабирования.
• Доступ к экспертам (если их нет внутри компании).
• Возможность установить фиксированную стоимость за количество документов и доработки.

Минусы:

• Непрозрачность процесса.
• Форс-мажоры на стороне аутсорс-компании.
• Трудно повлиять на качество результата.

Чек-лист — что нужно учесть при разметке данных:

1. Определите бизнес-цели, четко обозначьте, что заказчик ждет на выходе;
2. Выявите необходимый объем документов для разметки (больше=дороже, но качественнее);
3. Подготовьте данные для разметке, убедитесь в их качестве;
4. Определите подход (ручная или автоматическая разметка);
5. Сформулируйте понятную задачу для команды разметки и создайте четкую инструкцию ;
6. Важно помнить, что время разметки напрямую зависит от объемов и качества составленной инструкции.
7. При необходимости повторите цикл разметки.

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

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