Прежде чем учить Docker, нужно три-шесть месяцев на фундамент: командная строка Linux, сети, скрипты на Bash и Python, Git и понимание того, как вообще устроено приложение. Это не разминка перед «настоящим DevOps». Это и есть восемьдесят процентов профессии. Kubernetes, с которого почему-то начинают курсы, — последний инструмент в очереди, а не первый.
Звучит как плохая новость для того, кто уже открыл роадмап и приготовился ставить контейнеры. Но есть и хорошая: фундамент конкретен. Его можно выписать в чеклист и пройти по порядку. Дальше — что именно в этот фундамент входит, почему без каждого блока вы не отладите простейшую поломку, в каком порядке всё это учить и сколько на это честно уходит времени.
Главная мысль одной строкой: DevOps-инженер автоматизирует то, что до него делали руками. Нельзя автоматизировать процесс, которого ты не понимаешь. Поэтому сначала надо научиться делать руками — поднять сервер, разобраться, почему он не отвечает, прочитать логи, понять, как приложение попадает с ноутбука разработчика на боевую машину. И только потом учить инструменты, которые всё это автоматизируют. Кто перепрыгивает фундамент, заучивает команды из урока — и разваливается на первой реальной поломке, потому что в проде уроков нет.
Антон открыл популярный роадмап DevOps, увидел в начале Docker, дальше Kubernetes, Terraform, облака — и пошёл по списку сверху вниз. За три месяца научился собирать образы и поднимать контейнеры по инструкции. А потом контейнер на сервере перестал отвечать, и Антон завис. Логи он читать не умел. Почему процесс упал — не понимал. Что такое порт, на который никто не достучался, — представлял смутно. Урок такого не показывал.
Проблема не в Антоне и не в его старании. Проблема в порядке. Он начал с крыши.
DevOps — это автоматизация доставки кода: сборка приложения, упаковка, выкатка на серверы, мониторинг. Каждый инструмент здесь автоматизирует ручную операцию. Docker упаковывает приложение в контейнер — но контейнер это процесс операционной системы с ограничениями, и не понимая, что такое процесс, вы не поймёте, что такое контейнер. Конвейер сборки гонит код от коммита до боевого сервера — но это просто записанная последовательность команд, которые вы должны уметь выполнить вручную. Kubernetes управляет сотнями контейнеров — а если для вас один контейнер магия из урока, управлять вам нечем.
Вот фундамент целиком, до единого инструмента DevOps. Linux — командная строка, файловая система, процессы, права доступа, логи. Сети — TCP/IP, порты, DNS, HTTP, обратный прокси. Скрипты — Bash для рутины, основы Python для задач сложнее. Git — система контроля версий, на которой держится весь современный процесс. И понимание устройства приложения — клиент и сервер, база данных, переменные окружения, путь кода от коммита до открытого сайта. Пять блоков. Ни один не про автоматизацию. Все пять — про то, что эта автоматизация автоматизирует.
Рынок 2026 года не оставляет вариантов обойти этот фундамент. DevOps — профессия высокого барьера входа: нужен предыдущий опыт, Linux, администрирование или разработка. Медиана зарплат по hh.ru в январе 2026-го — 216 800 ₽, у senior около 340 000 ₽. Это деньги уровня middle, а массовой позиции junior DevOps почти нет. Высокая планка не потому, что сразу много платят. Потому что без фундамента в эту профессию просто не входят.
Первый кит и самый главный. DevOps живёт в Linux-консоли: серверы под Linux, контейнеры внутри Linux, конвейеры гоняют команды Linux. Надо не «знать про Linux» — надо жить в терминале так, чтобы команды шли из пальцев без подглядывания.
Что именно. Командная строка: перемещение по системе, поиск файлов, чтение и правка конфигов через консоль, перенаправление вывода, конвейеры из команд. Файловая система: как устроено дерево каталогов, где лежат конфиги, где логи, что такое точки монтирования. Процессы: как посмотреть, что запущено, кто сколько ест памяти, как убить зависший процесс, чем процесс отличается от службы. Права доступа: владелец, группа, режим доступа — почему скрипт «не запускается» ровно потому, что у файла нет права на исполнение. Логи: где они лежат и как читать. systemd: как запускают и перезапускают службы. И SSH — как зайти на удалённый сервер, потому что вся работа идёт на машинах, которых вы никогда не видели вживую.
Зачем так глубоко. Вернёмся к Антону и его упавшему контейнеру. Контейнер — это изолированный процесс Linux. Чтобы понять, почему он упал, нужно зайти на сервер по SSH, посмотреть список процессов, найти логи, прочитать, на чём приложение споткнулось, проверить, хватило ли памяти и прав. Каждое действие из этой цепочки — базовый навык Linux. Не умеете ни одного — контейнер для вас чёрный ящик, который то работает, то нет по неизвестным причинам.
Это не неделя по верхам и не «прошёл вводный курс — поехали дальше». Linux — основа, на которую ляжет всё остальное, и на неё стоит заложить больше всего времени. Команду можно подсмотреть. Понимание того, что происходит под командой, не подсматривается.
Третий кит, который недооценивают чаще всех. И зря: в тяжёлый день половина работы DevOps — диагностика «почему оно не отвечает», а без понимания сетей такая диагностика превращается в гадание на кофейной гуще.
Что нужно понимать. TCP/IP — как данные вообще ходят по сети, что такое IP-адрес и пакет. Порты — почему сервис «слушает» порт, что значит «порт занят» или «порт закрыт», как одна машина держит десятки сервисов на разных портах. DNS — как доменное имя превращается в адрес, и почему «сайт не открывается» часто значит «имя не разрешилось в адрес», а не «сервер лёг». HTTP — как клиент шлёт запрос и что означают коды ответа, почему 502 и 504 — это не одно и то же. Обратный прокси и балансировщик — как один входной адрес распределяет запросы по нескольким серверам.
Разберём на живом примере. Приложение развёрнуто, но в браузере не открывается. Где искать? Сначала: имя вообще разрешается в адрес — это DNS. Потом: на нужном порту кто-то слушает — это порты и процессы. Дальше: запрос доходит до приложения, или его рубит прокси — это HTTP и обратный прокси. Может, само приложение отвечает ошибкой — это уже логи. Человек, понимающий сети, проходит эту цепочку за минуты и находит точку обрыва. Человек без сетей перезагружает сервер наугад и молится.
Сети — тот блок, на котором держится вся отладка. Инструмент покажет вам, что «соединение не установлено». Что с этим делать, он не подскажет. Подскажет понимание того, как это соединение вообще устанавливается.
Скрипты — второй кит, и в нём половина смысла профессии. DevOps-инженер не делает руками то, что можно записать в скрипт. Не умеете автоматизировать в коде — вы не DevOps, вы человек, который вручную копирует файлы на сервер и каждый раз молится, что не перепутал.
Bash — для автоматизации рутины прямо в терминале: пробежать по списку серверов, собрать логи, прибраться, проверить, что служба жива. Это язык, на котором говорит сама командная строка. Python — для задач посложнее, где Bash становится нечитаемым: разобрать данные, сходить во внешнюю систему по сети, написать проверку с внятной логикой. Глубоко программировать не нужно — нужны переменные, условия, циклы, функции, работа с файлами и запросы по сети. Уровень «могу написать рабочий скрипт и понять чужой».
Git стоит особняком, но без него фундамент дырявый. Это система контроля версий, и на ней держится весь современный процесс доставки кода. Коммит, ветка, слияние, история изменений, командная работа в общем репозитории — без этого вы не поймёте даже, откуда конвейер сборки берёт код. CI/CD, ради которого DevOps существует, запускается ровно в момент коммита в Git. Не понимаете Git — не понимаете, что именно автоматизируете.
Эти три инструмента — не «дополнительно, если останется время». Без них всё, что выше Linux и сетей, повисает в воздухе. Скрипт связывает ручные действия в автоматику. Git связывает код с конвейером. Уберите их — и вы вернулись к ручному копированию файлов, то есть к работе, которую DevOps как раз и пришёл отменить.
Пятый блок — самый невидимый, потому что не сводится к одной команде. Не обязательно быть программистом. Обязательно понимать, как приложение собирается, запускается и работает, — иначе вам нечего автоматизировать, вы просто не знаете, что происходит между «разработчик написал код» и «пользователь открыл сайт».
Что входит. Клиент-серверная модель: что выполняется в браузере, что на сервере, как они разговаривают. База данных: зачем приложению хранилище, что значит «приложение не может подключиться к базе» — частая поломка, которую без этого понимания не диагностировать. Зависимости и окружение: почему «у меня на ноутбуке работало, а на сервере нет» — это вопрос разных окружений, и именно его решает контейнер. Переменные окружения: как одно и то же приложение настраивают под тест и под прод, не меняя код. Жизненный цикл: коммит, сборка, тесты, упаковка, выкатка, запуск — вся дорога, которую DevOps мостит автоматикой.
Без этой картины контейнеры и конвейеры остаются абстракцией. Контейнер изолирует приложение вместе с его окружением — но «зачем» понятно только тому, кто хоть раз ловил расхождение между машиной разработчика и сервером. Конвейер прогоняет код через сборку и тесты — но что он, собственно, собирает, ясно только тому, кто представляет, как приложение устроено. Этот блок не выучить отдельным курсом за выходные. Он набирается, пока вы возитесь с предыдущими четырьмя и видите, как приложение реально живёт на сервере.
Три-шесть месяцев на фундамент до первого инструмента DevOps — при честных двух-трёх часах в день. Не неделя, не месяц. Эту цифру стоит принять заранее: она избавит от соблазна перепрыгнуть и от разочарования через полгода метаний.
Порядок не произвольный, каждый слой опирается на предыдущий. Сначала Linux — самый объёмный блок, на него уйдёт больше всего. Параллельно с Linux заходят сети: они тесно сплетены, серверы и соединения изучаются вместе. Когда в терминале уже свободно — Bash, потому что он растёт прямо из командной строки. Затем основы Python для задач, где Bash тесен. Git стоит подключить рано и пользоваться им с первого же своего скрипта, чтобы он стал привычкой, а не отдельной темой. А понимание устройства приложения копится фоном всё это время — через то, что вы сами поднимаете и ломаете на учебном сервере.
Проверка готовности простая. Можете зайти по SSH на сервер, найти упавший процесс, прочитать его логи и понять, почему он упал? Можете объяснить по шагам, почему сайт не открывается, и проверить каждое звено — DNS, порт, прокси, приложение? Написать скрипт, который проходит по серверам и собирает отчёт? Развернуть простое приложение с базой, настроить его через переменные окружения и положить код в Git? Если на все четыре «да» — вот теперь можно трогать Docker. Тогда контейнер ляжет на понимание, а не на пустоту.
Реальная боль с форумов выглядит ровно наоборот. Люди идут в DevOps без этой базы, заучивают инструменты по урокам, рассылают резюме — и получают тишину. А на редком собеседовании слышат: «Покажите, как вы поднимали инфраструктуру в проде». Показывать нечего: умеешь повторять команды, но не понимаешь, что под ними. Рынок 2026 года это формулирует жёстко — «дефицит навыков, а не людей». Соискателей с курсом «DevOps с нуля» в резюме много. Людей с реальным фундаментом мало. В этот зазор и надо целиться — но войти в него можно только через базу.
Сначала — честно сказать себе, что фундамент впереди инструментов. Не «месяц Linux для галочки и побежали к Kubernetes», а три-шесть месяцев на пять блоков, пока они не станут рефлексом. Это первое решение, и от него зависит, потратите вы полгода с толком или год впустую.
Дальше — идти по порядку и не прыгать. Linux и сети вместе, потом Bash, потом основы Python, Git с самого начала и параллельно. Не открывайте курс по контейнерам, пока не проходите чеклист готовности из предыдущего раздела. И учите не в пустоту, а на руках: поднимайте учебный сервер, ломайте его, чините, разворачивайте на нём простые приложения. Навык набирается там, где что-то сломалось и вы это починили, — а не там, где досмотрели лекцию до конца.
Загвоздка в том, что собрать этот фундамент в осмысленную программу с нуля трудно: разрозненные ролики по Linux, отдельно сети, отдельно Bash — и непонятно, в каком объёме каждый блок и где остановиться. Чтобы не угадывать, пройдите Профтест: пара минут вопросов про ваш опыт и цель — и на выходе программа, которая ведёт от фундамента к инструментам в правильном порядке, под вашу точку старта, а не общий список из интернета.
Антон, с которого начался текст, в итоге закрыл роадмап и сел за Linux. Полгода: терминал, сети, скрипты, свой сервер, который он ронял и поднимал десятки раз. Скучно — после блестящих уроков про Kubernetes особенно. Зато когда он вернулся к контейнерам, упавший контейнер перестал быть загадкой. Стал процессом, который можно открыть и прочитать. Фундамент — самая нудная часть пути. И ровно он отделяет того, кто знает команды, от того, кого позовут чинить прод в три ночи.
