Как перейти в DevOps из backend-разработки: план 2026

Что бэкенд-разработчик уже умеет для DevOps

Переход в DevOps из backend-разработки начинается с инвентаризации: Git, базы данных, HTTP и API у вас уже есть. Заметную часть стека DevOps бэкенд-разработчик закрывает ещё до начала обучения. Git, ревью кода, работа с базами данных, HTTP и API, умение читать чужой код и писать скрипты на Python или Go: всё это DevOps-инженер использует каждый день. Новичку из другой сферы эту базу ещё предстоит набрать, у вас она уже есть.

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

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

Отсюда практический вывод: программа «DevOps с нуля» на 14-19 месяцев для вас избыточна. Первые модули таких курсов посвящены Git и основам Python, то есть вы заплатите за то, что уже знаете.

Сколько вы будете зарабатывать после перехода

Переход из бэкенда в DevOps почти никогда не даёт прибавки сразу. По исследованию Хабр Карьеры за первое полугодие 2026 года, средняя зарплата DevOps-инженера 238 000 ₽, медиана бэкенд-разработчика 254 000 ₽. Цифры посчитаны по-разному (среднее и медиана), но порядок один: это горизонтальный переход, а не скачок.

Источник этих цифр важен: Хабр Карьера считает оклады, которые специалисты указывают в анонимном калькуляторе, вакансии в расчёт не берутся. В общем отчёте за то же полугодие учтено 45 226 зарплат, медиана по IT 191 000 ₽, бэкенд в Москве 278 000 ₽, в регионах 220 000 ₽.

По грейдам DevOps разбор рынка на Хабре от февраля 2026 года даёт такие вилки: junior получает от 120-150 тыс. ₽, middle 220-300 тыс. ₽, senior от 350 тыс. ₽.

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

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

Причина переходить в другом: потолок выше и длиннее. У смежной роли SRE, куда DevOps-инженеры часто растут дальше, медиана по тому же исследованию 312 000 ₽. Плюс инфраструктурные навыки меньше зависят от моды на конкретный фреймворк.

Чего не хватает разработчику: пять пробелов

Самый большой пробел у бэкендеров не инструментальный. Разработчик привык, что работа закончена, когда тесты зелёные и PR смержен. DevOps-инженер отвечает за то, что происходит после: деплой, нагрузка, ночной инцидент, откат. Это сдвиг мышления, и инструменты его только обслуживают.

Конкретные технические пробелы обычно такие:

1. Linux глубже уровня «запустить». Процессы и сигналы, systemd, права доступа, journalctl, диагностика через top, lsof, ss. Без этого любой инцидент превращается в гадание.
2. Сети. DNS, TCP, балансировщики, прокси, сертификаты. Разработчик видит сеть как «запрос ушёл и вернулся», DevOps разбирается, где именно он потерялся.
3. Контейнеры и оркестрация. Docker вы, скорее всего, уже трогали. Kubernetes на уровне эксплуатации кластера, а не «у нас есть helm-чарт от соседней команды», это отдельный большой блок.
4. Инфраструктура как код. Terraform или Ansible: серверы, сети и доступы описываются файлами и проходят ревью так же, как код приложения.
5. Наблюдаемость. Метрики, логи, трейсы, алерты. Zabbix, Prometheus и Grafana hh.ru называет среди типовых навыков DevOps уровня middle, и это та часть, где разработчику проще всего блеснуть: вы знаете, какие метрики приложения реально важны.

Авторы роадмапа DevOps на Tproger формулируют главную ошибку так: новички хватаются за Kubernetes раньше Linux и CI/CD. У разработчиков соблазн ещё сильнее, потому что Kubernetes «звучит как код». Не поддавайтесь: без базы kubectl превращается в копирование команд из чужих README.

План перехода на 6-9 месяцев на своём же сервисе

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

Месяцы 1-2: Linux, сети и «двенадцать факторов»

Поставьте Linux на виртуалку или дешёвый VPS и разверните сервис руками, без Docker. Настройте nginx как обратный прокси, выпустите TLS-сертификат, заведите systemd-юнит. Именно ручной деплой показывает, что потом будут автоматизировать.

Параллельно перечитайте методологию «Двенадцать факторов» глазами эксплуатации. Её писали разработчики облачной платформы Heroku по опыту сотен приложений. Конфигурация через переменные окружения, логи в stdout, процессы без состояния: проверьте, соответствует ли им ваш сервис.

Месяцы 3-4: Docker и CI/CD

Упакуйте сервис в контейнер, затем соберите docker compose с базой и кэшем. Следом напишите пайплайн в GitLab CI или GitHub Actions: линтер, тесты, сборка образа, деплой на тот же VPS по коммиту в main. К концу этапа каждое изменение должно доезжать до сервера без единой ручной команды.

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

Месяцы 5-6: Terraform и Kubernetes

Опишите инфраструктуру в Terraform: сервер, сеть, DNS-запись. Затем поднимите небольшой кластер (k3s или managed Kubernetes у облачного провайдера) и перенесите сервис туда через Helm. Сломайте его намеренно: убейте под, заполните диск, уроните базу. Посмотрите, что произойдёт.

Здесь у разработчика есть фора. Вы сами можете добавить в сервис readiness- и liveness-пробы, корректное завершение по SIGTERM и метрики приложения. Без доступа к коду эти доработки пришлось бы ждать от команды разработки.

Месяцы 7-9: мониторинг, инциденты и поиск работы

Подключите Prometheus и Grafana, настройте алерты на латентность и ошибки. Напишите короткий постмортем по одной из устроенных вами поломок. Этот документ на собеседовании весит больше, чем строчка «знаю Kubernetes» в резюме.

Не гонитесь за полнотой на каждом этапе. Задача плана не выучить все флаги kubectl, а получить один сквозной сценарий, который вы можете показать и объяснить: коммит, пайплайн, образ, кластер, алерт. Каждый следующий инструмент вы будете добавлять уже на работе, под конкретную задачу.

Темп рассчитан на 8-10 часов в неделю параллельно с основной работой. Если у вас уже был опыт с Docker и CI на текущем месте, первые два этапа сжимаются до месяца, и весь путь укладывается примерно в полгода.

Внутренний переход или новая компания

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

Как это выглядит на практике:

• Возьмите на себя пайплайн своей команды: ускорьте сборку, добавьте кэширование, уберите ручные шаги из релиза.
• Вызовитесь на дежурства (on-call).
• Попроситесь в пару к инфраструктурной команде на одну задачу: миграцию сервиса в Kubernetes, настройку алертов, перевод конфигов в Terraform.
• Через 3-6 месяцев такой работы разговор о смене роли с руководителем идёт уже по фактам и результатам: вы можете показать ускоренный релиз, настроенные алерты и разобранные инциденты.

Если в компании нет отдельной инфраструктурной команды, это даже лучше. Роль «разработчик, который отвечает за деплой и мониторинг» часто появляется там сама собой, и её можно оформить официально.

Обсуждая смену роли с руководителем, говорите на языке пользы для команды. «Хочу в DevOps» звучит как риск потерять разработчика. «Могу сократить время релиза и взять на себя пайплайны» звучит как решение проблемы, которую руководитель и так видит.

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

Пять ошибок бэкендеров при переходе в DevOps

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

1. Начинать с Kubernetes. Он кажется «самым кодовым» инструментом, но без Linux и сетей вы будете чинить кластер наугад.
2. Учить десять инструментов поверхностно. Работодателю важнее один стек, доведённый до прода: одно облако, одна CI-система, один стек мониторинга.
3. Игнорировать сети. Многие инциденты в проде упираются в DNS, просроченные сертификаты или таймауты, а не в код.
4. Писать инфраструктуру как приложение. Разработчики любят абстракции, и Terraform-модули быстро превращаются в фреймворк, который никто, кроме автора, не понимает. В инфраструктуре простота и предсказуемость ценятся выше изящества.
5. Соглашаться на junior. Ваш опыт разработки имеет рыночную цену; подавайтесь на middle и гибридные роли.

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

Курс или самостоятельно: что показывает каталог SkillEdge

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

Сравнивая программы в каталоге курсов DevOps на SkillEdge, мы видим 12 полных программ уровня «DevOps-инженер» от 8 школ. Цены на них от 19 890 ₽ до 141 578 ₽, медиана 110 000 ₽. Важнее цены другое: в названии 6 из 12 программ прямо стоит «с нуля», и только одна адресована действующим IT-специалистам.

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

Цифры с графика: программа «DevOps-инженер: курс для действующих IT-специалистов» стоит 97 500 ₽ и длится 8 месяцев. Курс с нуля той же школы обойдётся в 115 000 ₽ и 14 месяцев, расширенный в 134 600 ₽ и 19 месяцев. Разница в 11 месяцев приходится в основном на базу, которая у разработчика уже есть.

Второй вариант для бэкендера: собрать обучение из коротких модулей под конкретные пробелы. Например, курс по GitLab CI/CD от Merion Academy стоит 16 250 ₽, а программа Skillbox по инфраструктурной платформе на Kubernetes стоит 59 008 ₽. Вместе это 75 258 ₽ против медианы полных программ 110 000 ₽, и такой набор закрывает самые дефицитные навыки.

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

Нужна ли сертификация CKA

Сертификат не заменяет опыт, но для бэкендера без строчки «DevOps» в трудовой он работает как внешнее подтверждение навыков. Самый узнаваемый вариант Certified Kubernetes Administrator от Linux Foundation: практический экзамен, где задачи решаются в командной строке живого кластера.

Ключевые параметры CKA по данным Linux Foundation:

• Стоимость экзамена $445, и в неё уже входит одна пересдача, а также два пробных симулятора.
• Длительность 2 часа.
• Сертификат действует 2 года, потом его нужно подтверждать заново.
• Самый весомый блок, troubleshooting (поиск и устранение неисправностей в кластере), даёт 30% итоговой оценки, больше любого другого домена.

Troubleshooting хорошо ложится на опыт разработчика. Отладка у вас в крови, просто объектом станет не код, а кластер. Наше мнение: CKA имеет смысл сдавать после плана из раздела выше, не вместо него. Сертификат без пет-проекта легко раскрывается на первом же техническом собеседовании.

Как переписать резюме и пройти собеседование

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

Что переформулировать в опыте:

• «Писал микросервис на Go» превращается в «Разработал и вывел в прод сервис, настроил CI в GitLab, сократил время сборки с 12 до 4 минут» (подставьте свои реальные цифры).
• Участие в разборе инцидентов, дежурства, миграции баз, настройка алертов выносятся в отдельные пункты.
• Пет-проект из плана описывается как проект: стек, архитектура, ссылка на репозиторий с Terraform и пайплайном.

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

Сильный ход для бэкендера: рассказать историю, где вы как разработчик нашли причину инфраструктурной проблемы. Утечка соединений к базе, неправильный health-check, тяжёлая миграция при деплое. Такая история показывает ровно то, за что разработчиков в DevOps ценят.

Кому переход из бэкенда в DevOps не подойдёт

DevOps подходит не каждому сильному бэкендеру, и это нормально. Если вам больше всего нравится проектировать бизнес-логику и писать сложный код, в новой роли его станет заметно меньше. Значительная часть работы DevOps-инженера состоит из YAML-конфигов, разбора логов и согласований с другими командами.

Три признака, что стоит подумать ещё раз:

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

Есть и промежуточный вариант: остаться разработчиком, но забрать себе платформенные задачи команды. В крупных компаниях для этого есть отдельное направление, платформенная инженерия: команда строит внутренние инструменты, через которые разработчики сами деплоят свои сервисы. Туда бэкендеров берут охотнее, чем классических админов, потому что платформа сама по себе является продуктом с кодом и API.

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

Если же вы решились, начните с первого этапа плана уже на этой неделе: поставьте Linux на VPS и разверните свой сервис руками. Полный план обучения для тех, кто стартует без опыта разработки, есть в материале как стать DevOps-инженером, а требования и зарплатные вилки собраны на странице профессии DevOps-инженер. Посчитать, когда окупится обучение, поможет калькулятор ROI.