DevOps-инженер не «настраивает серверы» и не «модный сисадмин с зарплатой повыше». Его работа — построить конвейер, по которому код разработчика доезжает до пользователя сам: без ручных правок на боевом сервере, без ночных дежурств, без фразы «а у меня локально работало». DevOps делает так, чтобы релиз был нажатием кнопки, а не операцией с молитвой. Большую часть дня он не чинит упавший сервер — он пишет, по сути, программу, которая поднимает, обновляет и сторожит инфраструктуру вместо человека. Медиана зарплаты на hh.ru в январе 2026 — около 217 000 ₽, и за эти деньги платят не за знание команд Linux, а за умение убрать человека из процесса там, где человек ошибается.
И сразу честно. DevOps — не первая профессия и не вход в ИТ «полегче». Сюда приходят из разработки, из системного администрирования, из эксплуатации — с уже набитой шишкой понимания, как ломается прод. Если вы прямо сейчас выбираете, куда войти с нуля, — дочитайте, но скорее как разведку на будущее, чем как маршрут на завтра. А если у вас уже есть Linux под пальцами и желание разобраться, что это за роль, которую все называют, но мало кто описывает, — вот картина изнутри.
Чтобы понять профессию, надо понять конфликт, который её породил. Долгие годы в любой компании сидели две команды и тихо ненавидели друг друга.
Разработчики писали код и хотели одного — чтобы новые фичи выкатывались чаще. Их KPI — скорость изменений. Эксплуатация — те самые админы — отвечали за то, чтобы всё работало без сбоев, и хотели ровно обратного: чтобы ничего не трогали. Их KPI — стабильность. Каждый релиз был линией фронта. Разработчик приносил код и говорил «выкатывайте». Админ выкатывал, прод падал, и начиналось знаменитое: разработчик клянётся, что «у меня локально всё работало», админ отвечает, что «значит, у тебя кривое окружение». Никто не виноват, пользователь без сервиса, премию режут всем.
DevOps — это решение этой войны. Сначала как идея: хватит делить ответственность по принципу «я свою часть сделал». Пусть будет один процесс и одна команда, отвечающая за код от строчки до работающего сервиса у пользователя. Слово склеено из development и operations именно поэтому — это не должность, это про то, чтобы разработка и эксплуатация перестали быть двумя враждующими отделами.
И вот тут первая развилка, которую путают почти все. DevOps как культура — это то, как работает вся команда. DevOps как должность — это человек, который эту культуру строит руками: возводит мост между «написали» и «работает» и кладёт по этому мосту автоматику. Когда в вакансии пишут «ищем DevOps-инженера», имеют в виду второе. Но без первого второе бессмысленно — можно нанять человека с Kubernetes в резюме и оставить две враждующие команды, и ничего не изменится.
Теперь то, из-за чего рассыпается образ «сидит и админит серверы».
Центральная вещь, которую строит DevOps, называется CI/CD — конвейер непрерывной интеграции и доставки. Представьте сборочную линию завода, только собирает она не машины, а каждое изменение кода. Разработчик отправил новую строчку — и дальше всё едет само. Сначала автоматически прогоняются тесты: не сломал ли он чужое. Потом из кода собирается готовый к запуску образ. Потом этот образ выкатывается сначала на тестовый стенд, а если всё чисто — на боевой. Без единого ручного действия. Задача DevOps — построить эту линию и следить, чтобы она не вставала.
До CI/CD релиз выглядел так: вечер пятницы, админ руками копирует файлы на сервер, что-то идёт не так, откатить нельзя, потому что никто не помнит, что было до. После CI/CD релиз — это один коммит и зелёная галочка через десять минут. Компании, которые освоили этот конвейер, выкатывают изменения не раз в месяц, а десятки раз в день. Вот за что платят DevOps — не за дежурство у сервера, а за то, что дежурить больше не надо.
Вторая опора — инфраструктура как код, IaC. Раньше сервер настраивали руками: зашёл, поставил, сконфигурировал. Через год никто не помнит, что и зачем там стоит, а если сервер умер — поднимать всё заново по памяти. DevOps описывает всю инфраструктуру текстовым файлом: сколько серверов, какая память, какие сервисы, как связаны. Инструмент вроде Terraform читает этот файл и разворачивает всё сам. Сервер теперь не уникальный питомец, которого выхаживают, — он скот, которого при поломке не лечат, а заменяют новым из того же описания. Нужно поднять копию всей системы для тестов — запустил файл, через десять минут готово. Эта разница — между «знаю, где у меня что» и «надеюсь, что помню» — и есть граница между DevOps и старым админством.
Два слова, которые в любой вакансии DevOps стоят первыми, — Docker и Kubernetes. За ними прячется простая идея, которую стоит понять без жаргона.
Docker — это контейнер. Коробка, в которую упаковали приложение вместе со всем, что ему нужно для жизни: нужная версия языка, библиотеки, настройки. Коробка запускается одинаково где угодно — на ноутбуке разработчика, на тестовом стенде, на боевом сервере. Та самая фраза «а у меня локально работало» умирает здесь: если работает в контейнере, работает везде одинаково, потому что окружение приехало вместе с кодом, а не осталось на чужой машине.
Дальше — арифметика. Одно приложение — это не одна коробка, а десятки и сотни: отдельно сервис оплаты, отдельно каталог, отдельно уведомления. Управлять сотней контейнеров руками невозможно. Здесь выходит Kubernetes — дирижёр, который раскладывает контейнеры по серверам, перезапускает упавшие, добавляет новые под нагрузкой и убирает лишние, когда нагрузка спала. В чёрную пятницу пришёл вал покупателей — Kubernetes сам поднял больше копий сервиса оплаты. Схлынуло — сам погасил. Без него этим занимался бы человек в три часа ночи, и занимался бы плохо.
Поэтому в роли так много про облака. Все эти контейнеры и оркестраторы живут на чужих или своих серверах, и DevOps выбирает, где и почём их держать, как балансировать стоимость и надёжность. В России этот выбор за последние годы сместился к отечественным платформам — навык работы с локальными облачными решениями сейчас отдельно ценится на рынке. Но принцип везде один: инфраструктура управляется не мышкой в панели, а кодом.
Картинку «героически чинит упавший прод по ночам» стоит разобрать, потому что она и притягивает не тех, и отпугивает тех, кого надо.
Хороший рабочий день DevOps скучный. Утром — посмотреть на дашборды мониторинга: графики нагрузки, память, время ответа сервисов. Всё зелёное — отлично. Дальше — рутина созидания, а не тушения: дописать кусок пайплайна, который пока требует ручного шага; перенести сервис в контейнер; настроить, чтобы система сама себя масштабировала. Большая часть работы DevOps — это устранение будущих пожаров, а не борьба с текущими. Каждая автоматизированная сегодня рутина — это инцидент, которого не случится через месяц.
Мониторинг — отдельная половина профессии, про которую новички не думают. Мало построить систему, надо видеть её насквозь. DevOps настраивает так, чтобы система сама кричала до того, как упадёт: не «сервис лежит», а «время ответа выросло вдвое, через полчаса ляжет». Это называется наблюдаемость, и без неё DevOps не инженер, а слепой пожарный.
А потом приходит он — инцидент. Платёжный сервис перестал отвечать в пиковый час. Вот теперь начинается то, ради чего нужен особый склад нервов. Пока вокруг паника и менеджеры считают убытки поминутно, DevOps должен холодно смотреть на графики и искать причину: что выкатили последним, где скакнула нагрузка, какой сервис потянул за собой остальные. Не суетиться. Откатить, потушить, а уже потом, на холодную голову, разобрать, почему случилось, и сделать так, чтобы не повторилось. Способность не терять голову, когда теряют все, — здесь не бонус к резюме, а профпригодность.
Самое живучее заблуждение, которое стоит добить отдельно, потому что на нём строят неверные ожидания и не туда идут учиться.
Считается, что DevOps — это системный администратор, который выучил пару новых слов, переименовался и приписал к зарплате ноль. Будто сменилась вывеска, а суть та же — следить за серверами.
Разница не в зарплате, разница в подходе к работе. Системный администратор традиционно решает задачи руками: пришла проблема — зашёл, починил. Его ценность — в том, что он умеет починить. DevOps на ручную задачу смотрит иначе: если я делаю это руками второй раз, я делаю это неправильно. Его инстинкт — не починить, а написать то, что будет чинить само и впредь. Админ — мастер, который держит хозяйство. DevOps — инженер, который строит фабрику, чтобы хозяйство держалось без него. Это разные профессии с разной философией, хоть и растёт вторая часто из первой.
Поэтому DevOps пишет код. Не приложения для пользователя, но настоящий код: скрипты автоматизации, описания инфраструктуры, конфигурации пайплайнов. Граница между «эксплуатацией» и «разработкой», та самая, из-за которой когда-то воевали два отдела, внутри DevOps просто стёрта. Он по обе стороны сразу — и в этом весь смысл роли. Назвать его сисадмином — всё равно что назвать архитектора каменщиком на том основании, что оба имеют дело со стенами.
Вот теперь вопрос, ради которого всё писалось, — и задать его себе честно стоит до того, как вкладываться в долгий путь.
Профессия ложится на человека, которому физически противна повторяющаяся ручная работа. Не «лень», а именно зуд: сделал что-то дважды руками — и внутри свербит мысль «это надо автоматизировать». Если вы из тех, кто скорее потратит день на скрипт, чем десять раз сделает задачу за пять минут, — это родной для DevOps инстинкт. Если ручная рутина вас не раздражает, а успокаивает, — вам, скорее всего, в другую роль.
Нужно системное мышление — способность держать в голове не один сервис, а всю картину связей: что от чего зависит, что упадёт, если дёрнуть здесь. DevOps видит не дерево, а лес, и узкие места леса. И нужна та самая холодность в инциденте: когда прод лежит и все смотрят на вас, паника отнимает минуты, а минуты простоя — это деньги. Кто в стрессе вскипает, тот будет выгорать на каждом сбое.
Заметьте, чего в списке нет. Нет «любви к серверам» и нет «фана от командной строки». Это инструменты, а не призвание. Призвание здесь — нелюбовь к хаосу и ручному труду, желание заменить и то и другое надёжной машиной. Linux, Docker, Kubernetes, Terraform — этому учат. Складу ума, который от вида повторяющейся рутины тянется написать автоматизацию, — почти нет.
Прежде чем вкладывать год в фундамент и движение к DevOps, прогоните себя через три честные проверки.
Первая — на зуд автоматизации. Вспомните последнюю скучную задачу, которую делали много раз подряд. Что вы чувствовали — спокойствие привычки или желание один раз настроить так, чтобы больше не возвращаться? Если второе — это ваш инстинкт. Вторая — на холодную голову. Представьте: что-то важное сломалось прямо сейчас, на вас смотрят, убытки идут поминутно. Вы соберётесь и пойдёте по графикам или вскипите? Третья — на бэкграунд. DevOps честно не первая профессия. Если Linux и устройство сервисов для вас пока пустой звук — это не приговор, но это означает, что путь длиннее, чем кажется, и начинать стоит с фундамента, а не с Kubernetes.
Самый дешёвый способ не свернуть не туда — заранее понять, ваш ли это склад работы, а не только звучит ли солидно слово «DevOps» и красива ли его зарплата. Профтест на этом портале как раз про это — не про моду на профессию, а про сопоставление вашего склада ума и целей с тем, что роль реально требует и какой путь к ней ведёт. Пятнадцать минут теста против года движения не туда — обмен выгодный.
Тот разработчик, что вечно воевал с админами за каждый релиз, и тот админ, что в ответ запрещал трогать прод по пятницам, — DevOps появился, чтобы их примирить. Не победой одного над другим, а тем, что между ними встал конвейер, на который ни одному не надо больше дышать.
И вопрос для того, кто метит в эту роль, звучит не «выучу ли я Kubernetes». Kubernetes учится. А «получаю ли я удовольствие, когда сложное и хрупкое становится простым и надёжным моими руками». Вот с этого ответа профессия и начинается.
