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

«Золотой век» начинающих айтишников (джунов) закончился, а рынок IT переживает перезагрузку после бурного роста, сообщили в SuperJob.
По данным рекрутингового сервиса, вакансий стало меньше (-13%), а конкуренция среди начинающих специалистов резко выросла (+11% резюме). Предложение зарплаты в целом по IT-сфере за 2025 год выросло на 8,8%.

Среди самых высокооплачиваемых направлений для IТ-специалистов остается область разработки ИИ. В это направление входят такие специальности, как написание LLM на Fine tuning и инференс-моделях, RAG, AI-продакты.
«Зарплатная вилка здесь составляет от 500 тыс. до 1 млн руб., так как спрос рынка на этих специалистов только растет и эта тенденция продолжится».

Второе место занимают направления AppSec/DevSecOps. Мидл-специалисты здесь могут получать от 400 тыс. до 700 тыс. руб.

Также востребованы сейчас и Go-разработчики (специалисты по ПО на языке программирования Go), зарплаты которых начинаются от 400 тыс. руб.

В топ попадают менеджеры по развитию бизнеса и специалисты по продажам в области IT. В 2026 году ситуация останется похожей.
Максимальные доходы традиционно сохраняются у solution-архитекторов и техлидов, где зарплаты senior-уровня достигают самых высоких значений благодаря ответственности за архитектурные решения и стратегию развития продуктов.
Чуть ниже, но также в верхнем сегменте находятся специалисты по AI и ML, так как компании продолжают активно внедрять инструменты анализа данных и автоматизации.

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

Пятерку замыкают опытные full-stack-разработчики, особенно если они работают со сложными и востребованными стеками, совмещая несколько направлений разработки.

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

На рынке труда в IТ в 2025 году значительно усилилась конкуренция за вакансии на фоне сокращения общего числа открытых позиций. Рост зарплат по отдельным специальностям и уровням в ряде случаев не покрывает уровень инфляции.
Наиболее сложная ситуация сохраняется для специалистов начального уровня: компании все реже инвестируют в массовый наем джунов, отдавая приоритет более эффективным сотрудникам.
В то же время конкуренция работодателей за специалистов middle+ остается высокой, и именно в этом сегменте возможна точечная корректировка зарплат в 2026 году.

В целом в IT-сфере из-за эффекта высокой базы темпы прироста доходов будут снижаться, в прогнозе SuperJob на 2026 год указан средний рост зарплат на 8–10%.
Однако у стратегически важных IT-специалистов (архитекторов, DevOps, разработчиков senior-уровня, ML-инженеров) заработные платы будут расти быстрее — на 12–15%.
Разрыв в зарплатах между junior- (начинающими) и senior- (старшими) специалистами продолжит расти, констатировали в рекрутинговом сервисе.

https://www.rbc.ru/life/news/695241d59a79474610e80e31

Краткая шпаргалка по архитектурным паттернам и стилям
(продолжение в следующем посте)

Краткая шпаргалка по архитектурным паттернам и стилям
(продолжение предыдущего поста)

1. Архитектурные паттерны (Architectural Patterns) — это проверенные решения для типичных задач проектирования архитектуры ПО. На схеме представлены ключевые паттерны:
* MVP (Model-View-Presenter) — разделяет логику представления, данные и управление взаимодействием;
* MVC (Model-View-Controller) — классическая схема разделения на модель (данные), представление (UI) и контроллер (логика взаимодействия);
* MVVM (Model-View-ViewModel) — улучшает MVC, добавляя слой ViewModel для привязки данных;
* DDD (Domain-Driven Design) — фокусируется на модели предметной области, отделяя бизнес-логику от инфраструктуры.

2. Архитектурные стили (Architecture Styles) — определяют общую структуру и взаимодействие компонентов системы. Примеры на схеме:
* Monolith — монолитная архитектура, где всё приложение — единый блок;
* Layered — слоистая архитектура (например, UI, бизнес-логика, данные);
* Event-Driven — управление через события (асинхронные взаимодействия);
* Microservices — система из независимых сервисов, взаимодействующих через API;
* Space-Based — архитектура, ориентированная на распределённое хранение данных;
* Master-Slave — главный (Master) управляет подчинёнными (Slave) узлами;
* SOA (Service-Oriented Architecture) — сервисы взаимодействуют по стандартизированным интерфейсам;
* Mikrokernel — ядро с минимальным функционалом и подключаемыми модулями;
* Serverless — выполнение кода без управления серверами (например, через облачные функции);
* Hexagonal — разделение на ядро (бизнес-логика) и адаптеры (интеграция с внешними системами);
* Clean — чёткое разделение на слои: домен, приложение, инфраструктура;
* REST — архитектурный стиль для веб-сервисов с принципами stateless, cacheable и др.

3. Паттерны проектирования (Design Patterns) — шаблоны для решения конкретных задач на уровне классов и объектов. Разделены на три группы:
* Creational (порождающие) — управляют созданием объектов:
* Factory Method, Abstract Factory, Builder, Prototype, Singleton.
* Structural (структурные) — организуют структуру классов:
* Adapter, Bridge, Decorator, Composite, Facade, Flyweight, Proxy.
* Behavioral (поведенческие) — определяют взаимодействие и алгоритмы:
* Chain of Responsibility, Command, Iterator, Mediator, Memento, Observer, State, Strategy, Template Method, Visitor.

Итог:
* Архитектурные стили задают «скелет» системы (как компоненты взаимодействуют).
* Архитектурные паттерны — готовые схемы для конкретных задач (например, разделение логики в MVC).
* Паттерны проектирования — микрорешения для кода (как создавать, структурировать и связывать объекты).

Все эти элементы помогают проектировать ПО, балансируя между гибкостью, масштабируемостью и поддерживаемостью.

В сети представлен скрипт PowerShell для удаления функций ИИ из Windows.

Скрипт доступен в репозитории на gtihub:
https://github.com/zoicware/RemoveWindowsAI?tab=readme-ov-file

Как сказано в преамбуле проекта, цель скрипта — удалить ВСЕ ИИ функции для улучшения пользовательского опыта, конфиденциальности и безопасности, так как текущая сборка Windows 11 25H2 и будущие сборки будут включать в себя всё больше функций и компонентов ИИ.

Среди функций скрипта, в частности:

Отключение Copilot
Отключение Recall
Отключение Input Insights и сбора данных о наборе текста
Copilot в Edge
Image Creator в Paint
Удаление службы AI Fabric
Отключение действий ИИ
Отключение ИИ в Paint
Отключение голосового доступа
Отключение голосовых эффектов ИИ
Отключение ИИ в поиске по настройкам

ИТ-шники из Индии уже в России. Но есть нюансы...

"«В основном я работал в компаниях вроде Microsoft и использовал новые инструменты — ИИ, чат-боты, чат GPT и тому подобные, по сути я разработчик», — улыбаясь рассказывает журналистам смуглый мужчина в шапке и рабочей форме. С корреспондентами он говорит на английском.

Индийского IT-шника отвлекли от подметания улицы в Санкт-Петербурге. Вместе с другими 16 трудовыми мигрантами он приехал из Индии в северную столицу еще осенью прошлого года. Их устроило к себе ​​АО «Коломяжское», которое занимается уборкой и очисткой территории...."

https://www.gazeta.ru/social/2026/01/14/22334203.shtml

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

5 базовых концепций для высокой доступности приложения
(продолжение предыдущего поста)

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

1. Распределение нагрузки (Load Balancing)
- Суть: распределение входящих задач или запросов между несколькими экземплярами системы.
- Как реализовано на схеме: центральный элемент — Load Balancer — принимает запросы от клиентов (например, с ноутбуков или мобильных устройств) и направляет их на доступные экземпляры сервисов (Payments API, Orders API).
- Цель: предотвратить перегрузку отдельных компонентов, равномерно распределить нагрузку, повысить общую производительность и доступность системы.
- Дополнительно: Load Balancer выполняет проверки работоспособности (health checks) и перенаправляет трафик, если один из экземпляров выходит из строя.

2. Микросервисная архитектура (независимые сервисы)
- Суть: разбиение системы на небольшие независимые сервисы, которые работают автономно.
- Как реализовано на схеме: показаны отдельные сервисы — Payments API (с собственной базой данных — Payments Database) и Orders API.
- Цель: изоляция сбоев — если один сервис выходит из строя, это не влияет на работу других. Это повышает устойчивость системы (resilience).
- Пример: сбой в Orders API не затронет Payments API, и платежи продолжат обрабатываться.

3. Избыточность экземпляров (Multiple Instances)
- Суть: запуск нескольких копий (экземпляров) ключевых компонентов системы, готовых заменить основные в случае сбоя.
- Как реализовано на схеме: подразумевается, что для каждого сервиса (например, Payments API, Orders API) работают несколько экземпляров.
- Цель: гарантировать непрерывную работу системы — если основной экземпляр падает, его заменяет резервный.
- Преимущества: минимизация простоев, быстрое восстановление после сбоев.

4. Репликация данных (Data Replication)
- Суть: автоматическое копирование данных из основной базы данных (Primary Database) в резервную (Secondary Database).
- Как реализовано на схеме: стрелка с подписью «Replication» между Primary Database и Secondary Database показывает процесс синхронизации данных.
- Цель: защита данных от потери при сбое основной базы. Если Primary Database становится недоступной, система переключается на Secondary Database.
- Особенности: репликация может быть синхронной (данные копируются в реальном времени) или асинхронной (с небольшой задержкой).

5. Аварийное переключение (Failover)
- Суть: автоматический переход на резервный компонент (сервис, база данных) при сбое основного.
- Как реализовано на схеме: если основной компонент (например, Primary Database) выходит из строя, система переключается на Secondary Database (указано: «If a main component fails, you switch to a backup»).
- Цель: обеспечить непрерывность работы системы при отказах ключевых компонентов.
- Ключевые элементы:
- мониторинг состояния компонентов;
- автоматизация процесса переключения;
- минимизация времени простоя (RTO — Recovery Time Objective).

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

Представлен проект Just the Browser для чистки браузеров от излишней функциональности, напрямую не связанной с навигацией в Web (прежде всего для чистки функциональности, связанной с AI).

Проект предоставляет скрипты для изменения конфигурации Google Chrome, Microsoft Edge и Mozilla Firefox, и отключения в них сопутствующих возможностей, часто раздражающих пользователей, таких как работа с AI-сервисами, интеграция со сторонними продуктами, отправка телеметрии и показ рекомендованного контента на странице открытия новой вкладки.

Для Windows инструмент представляет скрипт PowerShell, а для Mac/Linux код написан на Shell. Код доступен на github, и там же инструкции по использованию - https://github.com/corbindavenport/just-the-browser

Что такое HTTP Header?
(продолжение в следующем посте)

Что такое HTTP Header?
(продолжение предыдущего поста)

HTTP Header — это метаданные, которые сопровождают HTTP-запросы и ответы, предоставляя дополнительный контекст о коммуникации между клиентом (браузером) и сервером. Они состоят из пар «ключ-значение» и определяют типы контента, учётные данные для аутентификации, поведение кэширования и политики безопасности.

На изображении показаны два типа заголовков: HTTP Request Header (отправляется от клиента к серверу) и HTTP Response Header (отправляется от сервера к клиенту). Разберём их подробнее.

#### 1. HTTP Request Header (заголовки запроса)

Эти заголовки отправляются от клиента (браузера) к серверу и содержат информацию о запросе, возможностях клиента и ожиданиях от ответа. На изображении представлены следующие заголовки:

- Accept: image/webp — указывает типы контента, которые клиент может обработать (в данном случае — изображения в формате WebP).
- Accept-Encoding: gzip — сообщает серверу, какие алгоритмы сжатия поддерживает клиент (здесь — gzip).
- Cookie: name=maxtext — передаёт на сервер сохранённые ранее cookies, чтобы связать запрос с конкретной сессией пользователя.
- Cache-Control: max-age=604800 — задаёт время кэширования ответа (в секундах). Значение 604800 соответствует одной неделе.
- Content-Type: text/html — определяет тип контента в теле запроса (здесь — HTML-документ).
- Content-Length: 30 — указывает размер тела запроса в байтах.
- Referer: https://name.com — показывает URL страницы, с которой был отправлен запрос (помогает серверу понять источник трафика).
- User-Agent: Mozilla/5.0 — идентифицирует браузер или клиентское приложение, отправившее запрос. Сервер может адаптировать ответ под возможности клиента.

#### 2. HTTP Response Header (заголовки ответа)

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

- Access-Control-Allow-Origin: \*** — определяет, какие источники (домены) могут обращаться к ресурсу. Звёздочка (*) означает, что доступ разрешён всем.
- **Alt-Svc: h2=":433"; ma=604800 — сообщает клиенту о поддержке альтернативных протоколов (например, HTTP/2 на порту 433) и сроке их действия (ma — max-age, в секундах).
- Cache-Control: max-age=604800 — аналогично запросу, задаёт время кэширования ответа на клиенте.
- Content-Type: image/webp — указывает тип контента в ответе (здесь — изображение в формате WebP).
- Content-Length: 30 — размер тела ответа в байтах.
- Date: Mon, 29 May 2023 17:15:36 GMT — дата и время создания ответа (в формате GMT).
- Set-Cookie: name=alex — сервер отправляет клиенту cookie для сохранения состояния сессии.
- Server: gws — сообщает о программном обеспечении сервера (здесь — Google Web Server, GWS).

#### Итог

- Заголовки запроса помогают серверу понять, что ожидает клиент, какие форматы данных он поддерживает и как обрабатывать запрос.
- Заголовки ответа дают клиенту инструкции по обработке данных (кэширование, тип контента, отправка cookies и т. д.) и содержат метаинформацию о сервере и ответе.

Приложения, созданные с помощью Vibe-кодирования, полны ошибок безопасности

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


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

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

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

https://devclass.com/2026/01/15/vibe-coded-applications-full-of-security-blunders/

Авторы Ubuntu протестировали ИИ на своей документации. Главный вывод оказался неожиданным: сэкономленное время съедается проверкой результатов.

Тестировались Claude Sonnet 4.5, Claude Haiku 4.5, GPT-5, GPT-5-mini и Gemini 3 Pro. Первая задача — перевести документацию с британского английского на американский. Claude Sonnet справился на 7 из 10, GPT-5 получил ноль баллов — просто отказался выполнять задачу без объяснения причин. Gemini работал медленно, а потом начал менять слова в обратную сторону. Когда автор указала на ошибку, модель сначала согласилась, затем "поговорила сама с собой" и заявила, что жалоба "необоснована".

На других задачах ИИ показал себя лучше. Claude написал метаописания для 250 страниц, сэкономив команде одну-две недели работы. Оптимизация линкчекера сократила время проверки с 10 минут до полутора — на 85%. Рабочий скрипт для автообновления редиректов тоже получился с первой попытки.

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

https://discourse.ubuntu.com/t/ubuntu-server-gazette-issue-11-ai-bots-shall-eat-my-docs/75029

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

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

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