Уровни дизайна системы
(продолжение предыдущего поста)

1. Level 0: Основы
На этом базовом уровне закладываются фундаментальные элементы системы:
* HTTP Methods (Методы HTTP) — основа взаимодействия между клиентом и сервером (GET, POST, PUT, DELETE и др.).
* REST APIs (REST API) — стандартизированный способ построения API для обмена данными.
* Basic Database Operations (Базовые операции с БД) — работа с базами данных (создание, чтение, обновление, удаление данных — CRUD-операции).

Этот уровень формирует «скелет» системы, без которого невозможно дальнейшее развитие архитектуры.

2. Level 1: Освоение базовых блоков
Здесь система усложняется за счёт внедрения инфраструктурных компонентов:
* Load Balancers (Балансировщики нагрузки) — распределяют нагрузку между серверами для повышения производительности и надёжности.
* Caching Strategies (Стратегии кэширования) — ускоряют доступ к данным за счёт временного хранения результатов запросов (например, Redis, Memcached).
* Message Queues (Очереди сообщений) — обеспечивают асинхронную обработку задач (например, RabbitMQ, Kafka), снижают нагрузку на систему и повышают её устойчивость.

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

3. Level 2: Взаимосвязанные компоненты
На этом уровне система проектируется с учётом сложных сценариев:
* API (API-интерфейсы) — формализуют взаимодействие между компонентами системы.
* CQRS (Command Query Responsibility Segregation) — разделяет команды (изменение данных) и запросы (чтение данных), что упрощает архитектуру и повышает производительность.
* Use circuit breakers, retries and timeouts (Использование схем прерывания, повторных попыток и таймаутов) — защищает систему от каскадных сбоев: если один сервис недоступен, система не падает, а обрабатывает ошибку.
* Add rate limiting and backpressure (Ограничение скорости и обратная связь по нагрузке) — предотвращает перегрузку системы за счёт контроля числа запросов.
* Design idempotent endpoints (Проектирование идемпотентных конечных точек) — гарантирует, что повторные идентичные запросы не изменят состояние системы.
* Separate read and write paths (Разделение путей чтения и записи) — оптимизирует работу с данными: чтение выполняется быстрее, запись — надёжнее.

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

4. Level 3: Надёжность и мониторинг
Здесь акцент делается на мониторинге и диагностике:
* Monitoring (Мониторинг) — сбор метрик (время отклика, загрузка ЦП, память) для отслеживания состояния системы.
* Logging (Логирование) — запись событий и ошибок для последующего анализа.
* Alerting Systems (Системы оповещения) — автоматическое уведомление о критических событиях (сбои, превышение лимитов).

Эти инструменты позволяют оперативно реагировать на проблемы и поддерживать стабильную работу системы.

5. Level 4: Масштабирование и развитие
Финальный уровень посвящён масштабируемости и гибкости:
* Scalability (Масштабируемость) — способность системы справляться с ростом нагрузки (горизонтальное и вертикальное масштабирование).
* High Availability (Высокая доступность) — минимизация простоев за счёт резервирования компонентов (например, кластеризация баз данных).
* Distributed Systems (Распределённые системы) — разделение системы на независимые узлы, работающие совместно (например, микросервисы).
* Microservices (Микросервисы) — разбиение монолита на небольшие независимые сервисы, упрощающие разработку и развёртывание.
* Event Driven Architecture (Архитектура, управляемая событиями) — система реагирует на события (например, сообщения в очереди), что повышает её гибкость.
* Handle partial failures in distributed systems (Обработка частичных сбоев в распределённых системах) — система продолжает работать, даже если некоторые узлы недоступны (например, с помощью паттернов retry, circuit breaker).

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

Таким образом, уровни дизайна системы выстраиваются от базовых принципов (Level 0) до сложной архитектуры, способной масштабироваться и эволюционировать (Level 4). Каждый уровень дополняет предыдущий, формируя надёжную, производительную и гибкую систему.

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

Роскомнадзор ввел новые ограничения в отношении мессенджера Telegram. Об этом сообщает телеканал «Москва 24» со ссылкой на источник на телеком-рынке.

В СМИ отметили, что пользователи активно жалуются на медленную загрузку видео. По информации источника, «это новые ограничения со стороны РКН».

Тем временем Роскомнадзор опроверг блокировку Telegram в России. «По отношению к Telegram в настоящее время новых мер ограничений не применяется», – сообщили в ведомстве.

https://t.me/infomoscow24/104004

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

Жизненный цикл образа Docker
(продолжение в следующем посте)

Жизненный цикл образа Docker
(продолжение предыдущего поста)

Жизненный цикл образа Docker включает несколько ключевых этапов, которые отображены на схеме:

1. Создание Dockerfile
Разработчику необходимо создать файл конфигурации Dockerfile, в котором задаются инструкции для настройки окружения приложения. В Dockerfile указываются базовый образ (директива FROM), рабочая директория (WORKDIR), копирование файлов (COPY), выполнение команд (RUN) и другие настройки.

2. Сборка образа (Build process)
С помощью команды docker build -t my-node-app . запускается процесс сборки образа на основе Dockerfile. Docker последовательно применяет инструкции из файла, формируя слои образа. Параметр -t задаёт тег (имя) для образа — в данном случае my-node-app.

3. Теггирование образа (Tagging)
После сборки образу присваивается тег (уникальное имя), например, my-node-app. Теггирование упрощает дальнейшую работу с образом — его легче идентифицировать и использовать.

4. Хранение образа локально
Собранный образ сохраняется на локальной машине пользователя. Список локальных образов можно вывести с помощью команды docker images.

5. Удаление локального образа (при необходимости)
Если образ больше не нужен, его можно удалить с помощью команды docker rmi my-node-app. Это освобождает место на диске.

6. Аутентификация для работы с Docker Hub
Чтобы загрузить образ в публичный реестр Docker Hub, требуется аутентификация. Выполняется команда docker login, где пользователь вводит свои учётные данные Docker Hub.

7. Перетегирование для Docker Hub
Перед загрузкой в Docker Hub образ необходимо перетеггировать, добавив имя пользователя:
docker tag my-node-app username/my-node-app.
Здесь username — это логин пользователя в Docker Hub. Это обязательное условие для публикации образа.

8. Загрузка образа в Docker Hub (Push)
Выполняется команда docker push username/my-node-app, которая отправляет образ в публичный реестр Docker Hub. После этого образ становится доступным для скачивания другим пользователям.

9. Скачивание образа (Pull)
Любой пользователь может скачать опубликованный образ с Docker Hub с помощью команды docker pull username/my-node-app. Скачанный образ сохраняется локально на машине пользователя.

10. Использование образа для создания контейнеров
После скачивания образ используется для запуска контейнеров — изолированных экземпляров приложения. Контейнеры работают на основе образа и могут быть запущены с помощью команды docker run.

Таким образом, жизненный цикл Docker-образа включает создание конфигурации (Dockerfile), сборку и теггирование локального образа, его загрузку в публичный реестр (Docker Hub) и последующее скачивание и использование другими пользователями для развёртывания приложений. Каждый этап управляется специальными командами Docker CLI и обеспечивает гибкость и безопасность при работе с образами.

SSD стали дороже золота, если сравнивать цену за грамм

Портал Tom’s Hardware проанализировал рынок SSD и пришёл к выводу, что твердотельные накопители SSD большой ёмкости стали дороже золота, если сравнивать цену за грамм. Это утверждение верно для NVMe-накопителей на 8 ТБ, также к этому показателю стремительно приближаются модели с 4 ТБ. Ситуация связана с дефицитом металлов на рынке ОЗУ и SSD из-за высокого спроса со стороны компаний в сфере искусственного интеллекта.

Tom’s Hardware использовал цены на SSD в Newegg, Microcenter, Best Buy и Walmart, получив более ста вариантов. Требования были такими: NVMe SSD с интерфейсом PCIe 4.0 или 5.0 ёмкостью 4 ТБ, продаваемые магазином и имеющиеся в наличии. В анализ не стали включать накопители корпоративного класса.

Оценка среднего веса этого сегмента SSD даёт в среднем 8,2 г для моделей на 8 ТБ или 8 г в случае вариантов на 4 ТБ. Рассматривались только версии без радиаторов.
В настоящее время золото стоит $148 за грамм. Даже если брать нижний предел веса накопителя в 8 г, средняя стоимость золота составит около $1148. В то же время средняя цена потребительского накопителя на 8 ТБ достигает примерно $1476, а высокопроизводительная модель будет стоить значительно больше.

Стоимость некоторых моделей накопителей ёмкостью 4 ТБ также приближается к эквивалентной цене золота. Существует явный разрыв между более дорогими моделями. За некоторым исключением, большая часть сегмента до $800 приходится на SSD для хранения данных. Это означает, что если пользователю нужна и высокая производительность, то придётся заплатить больше.

https://www.tomshardware.com/pc-components/storage/high-capacity-nvme-ssds-are-quickly-becoming-as-expensive-as-gold-by-weight-we-ran-the-figures-heres-what-we-found

Сравнение цены золота и SSD наглядно на графике

Как работает CDN
(продолжение в следующем посте)

Как работает CDN
(продолжение предыдущего поста)

Сеть доставки контента (CDN) — это географически распределённые серверы (также называемые пограничными серверами - edge servers), которые обеспечивают быструю доставку статического и динамического контента. Давайте разберём, как это работает.

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

Приведённая выше схема иллюстрирует этот процесс:

1. Боб вводит в браузере www.myshop.com. Браузер ищет доменное имя в локальном кэше DNS.

2. Если доменное имя отсутствует в локальном кэше DNS, браузер обращается к DNS‑резолверу для разрешения имени. DNS‑резолвер обычно находится у провайдера интернет‑услуг (ISP).

3. DNS‑резолвер рекурсивно разрешает доменное имя (подробности см. в моём предыдущем посте). В конце концов он обращается к авторитетному серверу имён для разрешения доменного имени.

4. Если мы не используем CDN, авторитетный сервер имён возвращает IP‑адрес для www.myshop.com. Но при использовании CDN у авторитетного сервера имён есть псевдоним, указывающий на www.myshop.cdn.com (доменное имя CDN‑сервера).

5. DNS‑резолвер запрашивает у авторитетного сервера имён разрешение для www.myshop.cdn.com.

6. Авторитетный сервер имён возвращает доменное имя для балансировщика нагрузки CDN — www.myshop.lb.com.

7. DNS‑резолвер обращается к балансировщику нагрузки CDN для разрешения www.myshop.lb.com. Балансировщик выбирает оптимальный пограничный CDN‑сервер на основе IP‑адреса пользователя, провайдера пользователя, запрашиваемого контента и нагрузки на сервер.

8. Балансировщик нагрузки CDN возвращает IP‑адрес пограничного CDN‑сервера для www.myshop.lb.com.

9. Теперь мы наконец получаем фактический IP‑адрес, к которому нужно обратиться. DNS‑резолвер передаёт IP‑адрес браузеру.

10. Браузер обращается к пограничному CDN‑серверу (edge server) для загрузки контента.

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

Если в кэше пограничного CDN‑сервера (edge CDN server) нет нужного контента, запрос направляется на региональный CDN‑сервер. Если контент по‑прежнему не найден, запрос идёт на центральный CDN‑сервер или даже на исходный сервер — веб‑сервер в Лондоне. Это называется CDN‑распределительной сетью, где серверы развёрнуты с учётом географического расположения.

Советы по работе с PATH
(продолжение в следующем посте)

Советы по работе с PATH
(продолжение предыдущего поста)

Следующие советы помогут эффективно управлять PATH и решать распространённые проблемы, связанные с поиском и запуском программ в терминале.

1. Добавление директории в PATH:
* В конце PATH (чтобы приоритет был у уже существующих путей):

     export PATH=$PATH:/my/dir
     

* В начале PATH (чтобы добавленная директория имела приоритет):

     export PATH=/my/dir:$PATH
     

* Для оболочки fish:

     set PATH $PATH /my/dir
     

2. Настройка PATH в конфигурационных файлах оболочки:
* Для bash: отредактируйте файлы ~/.bashrc или ~/.bash_profile.
* Для zsh: используйте файл ~/.zshrc.
* Для fish: настройте в файле ~/.config/fish/config.fish.

3. Просмотр текущего PATH:
* Чтобы увидеть содержимое PATH в одной строке:

     echo $PATH
     

* Чтобы вывести каждую запись PATH на отдельной строке (для bash/zsh):

     echo $PATH | tr ':' '\n'
     

4. Поиск программ в PATH:
* Показать первую директорию, где найдена программа (например, python3):

     which python3
     

(в zsh команда which работает как type).
* Показать все директории, где найдена программа (в порядке приоритета):

     which -a python3
     

5. Узнать, какая именно версия программы будет запущена:
* Используйте команду type, чтобы увидеть, что именно запустится при вызове программы (включая алиасы, встроенные команды и кэшированные записи):

     type python3
     

6. Очистка кэша PATH (для bash/zsh):
* Иногда обновление PATH не работает из-за кэширования. Очистите кэш с помощью команды:

     hash -r
     

* Это необходимо, если после добавления директории в PATH команды не работают корректно.

7. Важные нюансы:
* Bash и zsh кэшируют результаты поиска программ в PATH. Если вы добавили новую директорию, но команды не работают — очистите кэш (hash -r).
* Порядок добавления директорий в PATH влияет на приоритет поиска программ.
* Убедитесь, что изменения в конфигурационных файлах применяются (перезапустите терминал или выполните source ~/.bashrc / source ~/.zshrc / source ~/.config/fish/config.fish).

Вышла jQuery 4.0

Возможно, звучит как шутка, но вышла новая версия популярной JS-библиотеки jQuery - 4.0. Напомню, что версия 3.0 вышла почти 10 лет назад.

По данным организации W3Techs эту библиотеку используют на 70.9% из 10 млн наиболее посещаемых сайтов в сети.

Выпуск jQuery 4.0 содержит изменения, нарушающие обратную совместимость и связанные с удалением устаревшего кода, удалением некоторых внутренних недокументированных параметров, прекращением поддержки некоторого излишне усложнённого поведения и прекращением поддержки API, ранее объявленных устаревшими.
Для упрощения миграции можно использовать специальный плагин.

Причем удаление поддержки устаревших API и браузеров позволило сократить размер gzip-архива с библиотекой на 3 КБ (slim-версия теперь занимает 19.5 КБ, а полная - 27.5 КБ).

Среди основных изменений:

- Прекращена поддержка браузера IE 10 и более старых версий (поддержка IE 11 сохранена, но будет удалена в jQuery 5.0), а также других старых браузеров таких как Edge Legacy, Android Browser и Firefox до ветки 115.

- Встроена поддержка API Trusted Types, развиваемого для защиты от манипуляций с DOM, приводящих к межсайтовому скриптингу (DOM XSS), например, при некорректной обработке полученных от пользователя данных в блоках eval() или вставках ".innerHTML", что может привести к выполнению JavaScript-кода в контексте определённой страницы. В методы jQuery теперь может передаваться HTML-код в форме объектов TrustedHTML.

- jQuery теперь использует модули ESM (ECMAScript Module), соответственно код библиотеки может поставляться и импортироваться как модуль

- Удалены устаревшие функции: jQuery.isArray, jQuery.parseJSON, jQuery.trim, jQuery.type, jQuery.now, jQuery.isNumeric, jQuery.isFunction, jQuery.isWindow, jQuery.camelCase, jQuery.nodeName, jQuery.cssNumber, jQuery.cssProps и jQuery.fx.interval.
Вместо данных функций рекомендуется использовать штатные JavaScript-функции Array.isArray(), JSON.parse(), String.prototype.trim() и Date.now()

- Размер урезанного варианта (slim), не содержащий модули ajax и effects, сокращён до 19.5k за счёт прекращения поставки объектов Deferred (рекомендуется использовать штатные Promises) и Callbacks.

https://blog.jquery.com/2026/01/17/jquery-4-0-0/

Добавлены материалы по библиотеке Pandas и анализу данных на языке Python
https://metanit.com/python/pandas/
#python #pandas

РКН планирует использовать ИИ для блокировки VPN и интернет-трафика, на проект заложено 2,3 млрд рублей

По информации СМИ, Роскомнадзор планирует за 2,3 млрд рублей создать систему на базе искусственного интеллекта для блокировки VPN и интернет‑трафика. Согласно плану цифровизации РКН, новая система должна начать работать уже в этом году. Алгоритм на базе ИИ будет отслеживать «зеркала» заблокированных сайтов не по IP‑адресам, а через анализ слов, фраз и предложений. Это позволит блокировать не только сайты, но и тех, кто цитирует или копирует запрещённые ресурсы. Кроме того, ИИ будет способен отслеживать зашифрованный трафик через VPN, а также замедлять доступ к конкретным ресурсам и торрент‑трекерам.

Новый механизм будет работать на базе уже действующих в сетях операторов технических средств противодействия угрозам (ТСПУ), которые обеспечивают фильтрацию по технологии DPI (Deep Packet Inspection, глубокая фильтрация трафика по содержимому пакетов). С их помощью уже заблокировано более 1 млн ресурсов, а также ежедневно ограничивается доступ к 5,5 тыс. новых адресов.

Как отмечают эксперты, опрошенные СМИ, машинное обучение может повысить эффективность блокировок и помочь в выявлении запрещенного контента и VPN‑сервисов. Кроме того, внедрение систем на основе ИИ также соответствует требованию для федеральных ведомств отчитываться по подобным проектам.

https://www.forbes.ru/tekhnologii/553640-algoritmiceskie-upraznenia-rkn-budet-fil-trovat-trafik-s-pomos-u-masinnogo-obucenia

Как работает Single-Leader Replication (Репликация с одним лидером)
(продолжение в следующем посте)

Как работает Single-Leader Replication (Репликация с одним лидером)
(продолжение предыдущего поста)

По мере роста нагрузки на приложение на первый лан выходят такие характеристики как отказоустойчивость и надежность. И одним из способов повышения отказоустойчивости и надежности является "Репликация с одним лидером" или Single-Leader Replication. Рассмотрим, как она работает.

1. Назначение ролей узлов

В системе Single-Leader Replication:
* Один узел назначается лидером (leader) — он отвечает за обработку всех операций записи (DML-запросов: INSERT, UPDATE, DELETE).
* Остальные узлы называются последователями (followers) — они реплицируют изменения, сделанные лидером, и могут отвечать на запросы чтения.

2. Обработка операций записи (write operations)

* Все операции записи направляются исключительно на лидер.
* Лидер записывает изменения в своё локальное хранилище.
* Затем лидер распространяет изменения на все последователи — это может происходить асинхронно или синхронно:
* Асинхронная репликация: лидер сразу подтверждает успешную запись, а затем отправляет изменения последователям. Быстрее, но есть риск потери данных, если лидер выйдет из строя до отправки изменений.
* Синхронная репликация: лидер ждёт подтверждения от всех последователей, что они записали изменения, прежде чем подтвердить успешную запись. Надежнее, но медленнее.
* Также существует полусинхронная репликация, когда лидер ждёт подтверждения от заданного количества последователей.

3. Обработка операций чтения (read operations)

* Запросы на чтение могут направляться как к лидеру, так и к последователям:
* Чтение с лидера: обеспечивает строгую согласованность (strong consistency) — клиент всегда получает самые актуальные данные.
* Чтение с последователей: может привести к окончательной согласованности (eventual consistency) — данные могут быть немного устаревшими, пока последователи не обновятся. Задержка репликации может составлять от нескольких секунд до нескольких минут.

4. Отказоустойчивость (failover)

* Если лидер выходит из строя, один из последователей автоматически становится новым лидером.
* Клиенты перенастраиваются для отправки записей новому лидеру.
* Остальные последователи начинают получать изменения данных от нового лидера.
* При этом возможны проблемы:
* Если использовалась асинхронная репликация, новый лидер может не получить все записи от старого лидера.
* Возможен сценарий «split brain» (расщеплённый мозг), когда старый лидер возвращается в сеть и считает себя действующим лидером.

5. Распределение нагрузки

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

6. Репликация изменений

* Последователи получают журнал изменений (log) от лидера и применяют их к своей локальной копии базы данных.
* Если последователь выходит из строя, он может восстановиться, запросив у лидера все изменения, произошедшие с момента последней транзакции.

7. Итоги

Single-Leader Replication обеспечивает:
* Централизованную обработку записей через одного лидера.
* Распределение нагрузки чтения между последователями.
* Отказоустойчивость за счёт автоматического повышения последователя до лидера при сбое.
* Гибкость в выборе стратегии репликации (асинхронная, синхронная, полусинхронная) в зависимости от требований к скорости и надёжности.

Россия в рейтинге внедрения ИИ оказалась ниже Кении

Институт экономики ИИ Microsoft поместил Россию на 119-ю строчку по темпам внедрения искусственного интеллекта. Она расположилась между Кенией и Камеруном.

За прошлый год страна добилась улучшения этого показателя. ИИ используют около 70% опрошенных российских компаний
Распространение ИИ в России в первой половине прошлого года эксперты оценили в 7,6%, во второй — 8%. Таким образом, за год показатель вырос на 0,4%.

Лидерами рейтинга являются Объединенные Арабские Эмираты (59,4% — в первом полугодии, 64,0% — во втором), Сингапур (58,6 и 60,9%), Норвегия (45,3 и 46,4%), Ирландия (41,7 и 44,6%), а также Франция (40,9 и 44,0%). В топ-10 вошли Испания (39,7 и 41,8%), Новая Зеландия (37,6 и 40,5%), Нидерланды (36,3 и 38,9%), Великобритания (36,4 и 38,9%) и Катар (35,7 и 38,3%).

Генеративный искусственный интеллект используют около 70% опрошенных российских компаний, следует из данных исследования VK и агентства Prognosis. При этом главной целью применения ИИ бизнес видит в разгрузке сотрудников, пишет Forbes. Так, компании стремятся освободить сотрудников от выполнения рутины за счет делегирования ряда задач технологии. Чаще всего ИИ применяется для клиентской поддержки, генерации контента, маркетинга и работы с базами знаний.

https://www.rbc.ru/technology_and_media/20/01/2026/696f3d8d9a794776030bf2d1?from=from_main_10

Google подтвердила, что усложнит установку приложений из сторонних источников

Google подтвердила, что в Android появится механизм, усложняющий установку приложений из сторонних источников. Компания утверждает, что цель — не искоренить софт за пределами Google Play, а заставить пользователей пройти дополнительные шаги.

Издание Android Authority обнаружило в интерфейсе Google Play элементы, намекающие на систему верификации разработчиков и возможно продолжить установку без проверки. При этом верификация происходит онлайн, чтобы её было сложнее обойти. Важно отметить, что первые знаки о внедрении новой функции начали появляться в системном Package Installer ещё летом 2025 года. Теперь же компания начинает добавлять реализацию в Google Play, что говорит о подготовке к массовому внедрению.

Новость вызвала недовольство среди пользователей. Они уверены, что Google пытается ограничить сторонние приложения в Android и хочет постепенно закрывать систему, чтобы сделать её больше похожей на iOS. Если это в итоге произойдёт, то пользователям будет в разы сложнее устанавливать приложения из независимых магазинов и получать сборки напрямую от разработчиков,

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

https://www.androidauthority.com/google-sideloading-android-high-friction-process-3633468/

Несмотря на резкое падение спроса на разработчиков сервис HH по прежнему относит ИТ-специальности к самым востребованным профессиям в 2026 году.
Так, для разработчиков ПО доступно более 106 тыс. вакансий, для сравнения для сварщиков - более 123 тыс. вакансий, а для слесарей - более 144 тыс.

Если смотреть в целом, то в список подобных профессий по версии HH входят:

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

- Дата-сайентисты (более 5 тыс. вакансий за год) помогают бизнесу принимать решения, основываясь на «больших данных». Востребованы там, где есть цифровая информация - от банковской сферы до ритейла.

- Специалисты по кибербезопасности (более 26 тыс. вакансий) останутся профессией с возрастающим спросом в ИТ-сфере из-за роста киберугроз, а также за счет цифровизации, которая заставляет компании активно инвестировать средства в защиту информации;

- Разработчики ПО (более 106 тыс. вакансий за год) – основа цифровой экономики и рынка труда в ИТ-сфере, особенно востребованы fullstack- и Java-разработчики с успешным опытом коммерческой разработки для создания и поддержки сложных систем;

- Представители рабочих профессий с высокой квалификацией и специальными техническими допусками: сварщики (более 123 тыс. вакансий), слесари (более 144 тыс.), машинисты (более 140 тыс.), монтажники (более 95 тыс.), автослесари (более 70 тыс.), механики (более 50 тыс.);

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

https://www.kp.ru/daily/27750.5/5197444/

Большинство генеральных директоров сообщают об отсутствии отдачи от масштабных инвестиций в ИИ

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

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

Только 12% сообщили как о снижении затрат, так и о повышении доходов, в то время как 56% не увидели ни того, ни другого. 26% отметили снижение затрат, но почти столько же столкнулись с их увеличением.

Внедрение ИИ остается ограниченным. Даже в таких основных сценариях использования, как генерация спроса (22%), услуги поддержки (20%) и разработка продуктов (19%), лишь меньшинство широко внедряет ИИ.

Это соответствует выводам исследования Массачусетского технологического института, проведенного в августе, которое показало, что только 5% предприятий успешно внедрили инструменты ИИ в масштабах всей страны, в то время как остальные 95% не получили никакой отдачи от своих усилий в области ИИ.
Кроме того, исследование, опубликованное на прошлой неделе, пришло к выводу, что использование чат-бота с ИИ экономит страховым агентам всего три минуты в день.

https://www.theregister.com/2026/01/20/pwc_ai_ceo_survey/?td=rt-3a